Appearance
Risk Acceptance
Governed Risk Acceptance is the formal decision, by an authority empowered to make it, to carry a risk knowingly for a defined period.
Two things called "accept"
They are entirely different, and conflating them is the most common error in this area.
Treatment strategy: accept | Governed Risk Acceptance | |
|---|---|---|
| What it is | Planning intent | A formal governance decision |
| Who records it | The risk owner | An approving authority |
| Approval | None | Maker-checker, with segregation of duties |
| Justification | Optional narrative | Required business justification |
| Expiry | None | Mandatory validity expiry |
| Effect on status | None | Risk status moves to accepted |
| Permission | risk.update | risk.accept |
Setting the treatment strategy to accept approves nothing
Choosing accept in the treatment plan states an intention to carry the risk. It is a planning field.
Formal acceptance requires a request, a justification, an expiry date and independent approval. Until that happens, nothing has been accepted.
Acceptance is not elimination
An accepted risk stays on the register.
- Status becomes
accepted - The accepting authority, the justification and the acceptance date are recorded
- An expiry date is mandatory
- The exposure is unchanged
When the expiry passes, acceptance lapses and the risk returns to active governance.
The alternative — closing an accepted risk — would systematically under-report exposure. An organisation with forty accepted risks would show a register of zero.
The acceptance states
| Acceptance status | Meaning |
|---|---|
not_requested | No acceptance has been sought |
requested | Submitted for review |
in_review | Under review |
accepted | Formally accepted, within its validity window |
rejected | Declined |
expired | The acceptance validity has passed |
The governed workflow
The default chain is request, then risk and compliance review, with the option to escalate to senior management or CRO approval.
Segregation of duties: the requester cannot act as reviewer or approver. Transition history and audit events are captured throughout.
The review stage projects into the reviewer's Workbench with a deep link to the risk, and dispatches a notification.
Where acceptance appears
GRC Calendar. Acceptance expiry dates are projected as calendar events, alongside scheduled risk review cadence and treatment target dates. See GRC Calendar.
Workbench. Pending acceptance decisions appear in the reviewer's queue; returned requests appear in the requester's.
Risk register. The risk shows its acceptance status, the accepting authority and the expiry.
Acceptance versus exception
Both record a decision to live with something. They operate at different levels.
| Risk Acceptance | Exception | |
|---|---|---|
| Applies to | A risk on the register | A requirement or control |
| Reference | On the risk (RSK-YYYY-NNNN) | EXC-YYYY-NNNN |
| Question it answers | "Do we accept this exposure?" | "Do we accept not meeting this specific control?" |
| Effect | Risk status becomes accepted | Governance disposition becomes accepted_deviation |
A single situation often needs both: an exception for the specific control deviation, and acceptance of the residual risk that deviation creates. They are not duplicates — one is about a rule, the other about an exposure.
Writing a justification that will survive
The justification is read twice: by the approver now, and by an assessor or a successor later. Write for the second reader.
| Weak | Better |
|---|---|
| "Cost of remediation is disproportionate." | "Full remediation requires replacing the settlement platform, estimated at 18 months and materially above the annualised loss expectancy for this exposure. The platform is already scheduled for replacement in the FY28 technology plan. Compensating controls reduce residual likelihood to Low." |
| "Accepted by management." | "Accepted by the Chief Risk Officer on the recommendation of the Operational Risk Committee, minuted 14 March. Exposure is within stated appetite for operational risk in this business line." |
Permissions
| Action | Permission |
|---|---|
| View risks and acceptance state | risk.read |
| Set treatment strategy | risk.update |
| Request formal acceptance | risk.update |
| Approve or reject acceptance | risk.accept |
| Approve risk treatments | risk.approve |
All require the risk_management entitlement.
Example
Risk RSK-2026-0022 — Legacy settlement platform lacks modern authentication controls.
| Field | Value |
|---|---|
| Inherent | Critical |
| Residual | Medium, after compensating controls |
| Treatment strategy | accept |
| Acceptance status | accepted |
| Requested by | Head of Operations |
| Approved by | Chief Risk Officer |
| Justification | Platform replacement scheduled FY28; remediation cost disproportionate; residual within appetite; compensating controls documented |
| Validity expiry | 12 months |
| Related exception | EXC-2026-0031 |
On the register: the risk remains visible, at Medium residual, with accepted status and a visible expiry.
Eleven months later: a Workbench task and a calendar event bring the acceptance back for renewal. The FY28 plan has slipped to FY29. The CRO renews for a further 12 months with an updated justification noting the slippage — a decision that is now on the record and can be challenged by the board or an auditor.
What did not happen: the risk did not disappear from the register for a year, and the renewal was not automatic.
Troubleshooting
"I set the strategy to accept but the status has not changed." Correct. Treatment strategy is intent. Request formal acceptance.
"I cannot approve an acceptance I requested." Segregation of duties. An independent approver is required.
"An accepted risk became open again." The acceptance expired. Acceptance is time-bound by design.
"Acceptance is rejected." The reviewer's rationale is on the workflow history. Common reasons are inadequate justification, a missing expiry, and residual rating outside stated appetite.