Opinion
Risk acceptance: Accepted does not mean finished
An accepted risk remains a risk. Document the decision, authority, conditions and reassessment triggers so acceptance stays defensible.
Accepting a risk can be the right decision. Treating that acceptance as completed work is a different matter.
An organisation must be able to explain which uncertainty it is carrying and when that decision ceases to hold. A status field alone cannot show who was authorised to decide or which conditions applied.
Opinion by Julian Köhn, CTO and co-founder of Kopexa.
Not every risk can be removed immediately
Resources are limited. Dependencies, competing objectives and the effects of safeguards matter. A measure can cost money, interrupt operations or introduce a new risk. It is not realistic to resolve everything at once.
NIST IR 8286A Revision 1, published on 18 December 2025, places risk scenarios in the context of risk appetite and tolerance. Our practical conclusion: acceptance needs a reason and limits. A low number on a dashboard is insufficient.
Acceptance is not permission to disregard binding requirements. Before considering a risk acceptable, establish whether the proposed decision is legally permissible at all.
Two green entries can mean very different things
Consider a fictional legacy application. A technical change can only be made during the next maintenance window. Until then, a residual risk remains.
One entry reads:
Accepted. Remediation requires too much effort.
Another records the affected process and possible impact, the alternatives considered, the authorised decision-making role, and the maintenance window until which acceptance applies. It also names the existing additional safeguard on which the decision depends. If the threat changes or that safeguard fails, the decision must be reviewed.
Both entries can have the same status. Only the second makes the decision understandable. This is not a general recommendation to keep legacy applications running. It illustrates what a reasoned decision needs to contain.
Responsibility cannot be delegated to a form
An information security officer can prepare the assessment. That does not automatically authorise them to accept every business risk alone. Decision-making authority must fit the organisation, the potential impact and its internal rules.
A signature cannot replace the basis for a decision: what could happen, which safeguards currently work, what residual risk remains, and why an alternative was rejected.
The risk register should preserve that reasoning even when the people involved leave. Otherwise the organisation inherits a status whose original meaning nobody can explain.
A date alone is not enough
Regular reviews are useful. Events can require an earlier reassessment: a new location, a different type of data, a failed safeguard or new knowledge about an attack.
A practical decision record could contain:
| Field | What it should make clear |
|---|---|
| Risk | Scenario, affected assets and possible business impact |
| Assessment | Assumptions, method and remaining risk |
| Alternatives | Options considered and reasons for rejecting them |
| Authority | Decision-making role and basis of its authority |
| Conditions | Safeguards and restrictions on which acceptance depends |
| Reassessment | Review date and events that trigger an earlier review |
| Approval | Decision, date and the version approved |
This is a working aid, not a universal definition of an acceptable risk level. Your risk matrix and decision-making rules must suit your own context.
The goal is a defensible decision
A green risk register is not the objective. The organisation should understand its risks, implement measures and consciously carry any remaining risk.
Review one accepted entry. Could a responsible person who was not involved explain why the decision is still valid today? If not, the missing piece is the basis for the decision, rather than a different status colour.