Skip to content
atlas

Risk acceptance

Also known as: risk retention

A deliberate, recorded decision to live with a risk instead of spending more to reduce it.

Draft - this entry has not been reviewed yet.

Formal

The risk treatment option in which the organisation knowingly keeps a risk, because it is within the risk appetite or further controls would cost more than the harm; the decision is made and signed by someone with the authority to own the risk.

In plain English

Like driving on with a small chip at the edge of the windscreen - you note it, decide a new glass is not worth it yet, and look at it again after the winter.

In practice

At a ferry company, the IT manager writes down that the test server has no backup, the director signs that this is acceptable for one year, and the item is put on the list for review.

Why it matters

Accepting a risk is fine; ignoring it is not - the written decision shows who owns it and stops risks from being accepted without anyone deciding.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

  1. Have management set written risk acceptance criteria before any assessment, stating which combinations of likelihood and consequence may be accepted.
  2. Agree who may accept what, for example a team lead for low risks, a director for medium ones and only top management for anything outside the risk appetite.
  3. For each risk proposed for acceptance, check that it does not set aside a legal or contractual duty, such as reporting a personal data breach or meeting a PCI DSS requirement.
  4. Write an acceptance record with the risk description, the current residual rating, the reason for not treating it further, any compensating controls, the named owner and an expiry or review date.
  5. Have the risk owner with the right authority sign the record, and log it in the risk register.
  6. Monitor the conditions behind the decision, such as a newly exploited vulnerability in an accepted unsupported system.
  7. Review each acceptance at its expiry date, or earlier if the threat or the system changes, and either renew it, treat the risk or close it.
  8. Report the list of accepted risks to management at least once a year, and turn ageing audit or scan findings into explicit decisions.

Common pitfalls

  • Silent acceptance, where known findings sit untreated for months without an owner or a decision.
  • Acceptances signed by someone without authority over the business activity at risk.
  • Open-ended acceptances with no expiry date, which outlive the conditions they were based on.
  • Accepting risks that mainly fall on customers or data subjects, or that the law does not let you accept.

Good guides

Technical deep dive

ISO 31000:2018 calls this option retaining the risk by informed decision, and the word "informed" is the whole point. ISO/IEC 27001:2022 builds acceptance into two places: clause 6.1.2 a) 1) requires risk acceptance criteria to be established before assessment, and clause 6.1.3 f) requires risk owners to approve the treatment plan and accept the residual risks. An acceptance that cannot be traced to those criteria, or that was signed by someone without authority over the affected business activity, is a common audit nonconformity. In the NIST Risk Management Framework (SP 800-37 Rev. 2) the equivalent is the Authorize step, in which a senior authorizing official explicitly accepts the residual risk of operating a system.

A defensible acceptance record contains the risk statement, the current residual rating, the reason treatment is not pursued (cost, technical impossibility, planned decommissioning), any compensating controls, the named owner, the approver's level, and an expiry or review date. Mature organisations tie approval authority to rating: a team lead may accept low risks, a director medium, and only the executive board or management body anything outside the documented appetite. Time-boxing matters because the conditions behind the decision change; an unsupported operating system accepted in one year can become the entry point of a widely exploited vulnerability the next.

Acceptance has hard limits. It cannot waive legal obligations: a GDPR controller cannot accept away its duty to notify a personal data breach under Art. 33, and where a data protection impact assessment shows a high residual risk to data subjects, Art. 36(1) requires prior consultation of the supervisory authority, in Denmark Datatilsynet, rather than internal acceptance. Contractual standards behave similarly; in PCI DSS a requirement that cannot be met is handled with documented compensating controls, not by accepting the gap. And risks borne mainly by others, such as customers or data subjects, should not be accepted purely on the organisation's own cost-benefit reasoning.

The anti-pattern is silent acceptance: risks that are known, never treated and never decided on, often visible as ageing findings in vulnerability scans or audit reports. Functionally they are accepted, but without an owner, rationale or review date. The distinction from avoidance is that acceptance keeps both the activity and its risk; the distinction from mitigation is that no further controls are added.

What to learn first

Everything this builds on, foundations first.

  1. CIA triad
  2. →Governance
  3. →Threat
  4. →Asset
  5. →Vulnerability
  6. →Impact
  7. →Likelihood
  8. →Risk
  9. →Security control
  10. →Risk appetite
  11. →Residual risk
  12. →Risk acceptance

Relationships

Don't confuse with
Risk avoidance

Sources & further reading

Standards & official texts

  • ISO/IEC 27005:2022 (8.2 - Risk treatment options)

Course material

  • Cyber Security Fast Track - Kursuskompendium, Modul 5 og Ordliste (Risikohåndtering)

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.