Risk acceptance and residual risk

Scope: spoken decision to filed record · Who: the officer who owns the register · Prerequisites: approved risk criteria and named risk owners · First result: one acceptance, fully recorded

1. Why this exists (the failure mode it prevents)#

"We accept that risk" is among the most common sentences in security governance, and among the least often written down. It closes a meeting. It ends the argument about a patch window nobody wants. Months later, nobody can say who said it, what was accepted, or when the acceptance was meant to run out.

Four symptoms follow, and each one surfaces later as a finding.

Acceptance by conversation. The decision exists only in a meeting that produced no artefact. ISO/IEC 27005:2022 defines risk acceptance as an informed decision to take a particular risk, and notes that accepted risks are subject to monitoring and review ¹. Neither "informed" nor "monitored" is demonstrable from a memory.

The exception that never expires. A deviation from policy was granted for one quarter, five years ago. The register of exceptions is now a register of permanent arrangements, and the word "temporary" has stopped meaning anything. The same standard separates retention, which is a temporary acceptance restricted to a period of time, from acceptance in general ¹.

Residual risk that was never recomputed. Controls were implemented, the treatment plan closed, and the register still shows the level from before the work. Residual risk is the risk remaining after treatment ¹. A number produced before the treatment existed cannot be that.

Three acceptances of one risk. An unpatched server is accepted by an application owner, again by an infrastructure manager, and again by a project sponsor. No authority table said which of them, if any, was allowed to decide.

How it surfaces#

An assessor works from artefacts. ISO/IEC 27001:2022 places risk assessment at clause 6.1.2 and risk treatment at clause 6.1.3, and repeats both as running operational activities at 8.2 and 8.3 ². Guidance splits the closing acts of treatment into two named sub-clauses. They are 8.6.2 Approval by risk owners and 8.6.3 Acceptance of the residual information security risks ³. The request is specific. ISO/IEC 27002:2022 control 5.2 has security responsibilities defined and allocated ⁴; a register with a blank decision column answers none of it.

Supervisors ask a sharper version of the same question. Under Regulation (EU) 2022/2554, the resilience strategy establishes the risk tolerance level for ICT risk, in accordance with the entity's risk appetite ⁵. The management body bears overall responsibility for setting and approving that strategy, including the appropriate risk tolerance level ⁶. Once a tolerance is board-approved, an acceptance above it is a decision the board did not delegate.

One loop, not three silos#

Acceptance is where the three disciplines meet in a single act, which is why it is so often mishandled.

The governance decision is who may accept what, and up to which level. It belongs to the body that sets the boundary rather than to the person who wants the exposure. ISO 31000:2018 asks the organisation to specify the amount and type of risk it may or may not take, relative to objectives ⁷. Top management and oversight bodies are asked to identify the individuals holding the accountability and authority to manage risk, the risk owners ⁸.

The risk instrument is the acceptance record itself: the risk as assessed, the treatment considered and declined, the residual level tested against the criteria, and the compensating controls that hold while the acceptance stands. Treatment is an iterative process that includes deciding whether the remaining risk is acceptable, and taking further treatment where it is not ⁹.

What compliance later demonstrates is that the loop closed. The named approver held the authority the table gave them, the record is current, and expiry produced a re-decision rather than silence. One loop, worked once, evidenced once.

2. Definitions (only the ones that cause disputes)#

Six terms decide most arguments about acceptance. Requirement text in the standards below is copyright and is paraphrased; only titles and defined terms are quoted.

Term	Working definition	Source
Residual risk	The risk remaining after treatment. It can contain unidentified risk, and it can contain retained risk.	ISO/IEC 27005:2022, 3.1.17 1
Risk acceptance	An informed decision to take a particular risk, with or without treatment. Accepted risks stay under monitoring and review.	ISO/IEC 27005:2022, 3.2.8 1
Risk retention	Temporary acceptance of the burden of loss from a risk. Retention can be restricted to a period of time.	ISO/IEC 27005:2022, 3.2.10 1
Risk owner	The person or entity holding both the accountability and the authority to manage a risk.	ISO/IEC 27005:2022, 3.1.5 1
Tolerance	The boundary the governing body sets, above which an exposure is not the officer's to accept. In one sector the term is used directly of ICT risk.	Regulation (EU) 2022/2554, Art. 6(8)(b) 5
Exception	A recorded deviation from a policy, rule or standard that stays in force for a stated period. The policy itself is expected to say how these are handled.	ISO/IEC 27002:2022, control 5.1 10

Two distinctions are worth stating plainly.

Acceptance is not tolerance. Tolerance is the standing boundary; acceptance is a single dated decision taken inside it. A framework describes appetite and tolerance statements as things that are established, communicated and maintained ¹¹. An acceptance that sits above tolerance is not a stronger acceptance. It is an escalation.

Acceptance is not an exception. An acceptance takes a risk; an exception suspends a rule. They often travel together and they are recorded differently, which section 3.3 sets out. A framework keeps them together in one outcome: changes and exceptions are managed, assessed for risk impact, recorded and tracked ¹².

3. The method — numbered steps, each with input, activity, output and owner#

The criteria this method applies are set elsewhere. Scales, the combination rule and the acceptance thresholds come from Risk appetite and criteria; the rows come from The risk register other people trust. This playbook starts where those two finish, when a decision has to be taken and written.

3.1 Derive the acceptance authority table#

• Input: the approved risk criteria, the level-of-risk scale, and the list of named risk owners.
• Activity: build one table that says, for each residual level, which role may accept, who must be informed, and for how long an acceptance may run. Anchor it in the criteria rather than in the organisation chart. Keep the top band unallocated on purpose, so that the highest exposures reach the governing body by design.
• Output: Acceptance authority table, approved in the same forum that approved the criteria.
• Owner: the risk function proposes; the management forum approves.

Two anchors make this a governance act rather than an internal convention. Roles, responsibilities and authorities for cybersecurity risk management are established, communicated, understood and enforced ¹³. And a management system asks for organisational roles, responsibilities and authorities to be assigned at clause 5.3 ¹⁴. Control guidance is more direct. Responsibilities for risk management activities are defined and allocated, in particular the acceptance of residual risks ⁴. The example that guidance gives for holding the responsibility is the risk owner.

A workable table has four bands and no ambiguity about the fourth.

Residual level	Who may accept	Who must be informed	Maximum duration
Low	Risk owner	Risk function	12 months
Medium	Risk owner with the security function's countersignature	Management forum, at the next meeting	12 months
High	Named executive with the accountable portfolio	Management forum, in session	6 months
Above tolerance	Not delegated. The governing body decides.	Governing body, in session, with the minute	3 months

3.2 Assemble the acceptance record#

• Input: the register row, the treatment options costed, and the criteria.
• Activity: write the record. Seven elements are mandatory, and each answers a question an assessor asks. The risk as assessed. The treatment considered and declined, with the reason. The residual level, and the test of that level against the criteria. The compensating controls and the expiry date. The two roles that own and approve it.
• Output: Acceptance record, one per accepted risk, filed against the register row.
• Owner: the risk owner writes it; the approver in the authority table signs it.

The rationale for selecting the option is not optional decoration. A treatment plan is expected to state the rationale for the selection of options and to name those accountable and responsible for approving and implementing it ¹⁵. Retaining the risk by informed decision is one of the listed treatment options, which is what makes acceptance a treatment choice rather than the absence of one ¹⁶.

The residual level has to be recomputed, not copied. Decision makers and stakeholders should know the nature and extent of whatever risk survives treatment ¹⁶. That remaining risk is documented, monitored, reviewed and, where appropriate, treated further. Where compensating controls are the reason the level dropped, name them in the record. A control is a measure that maintains or modifies risk, and controls do not always exert the effect assumed of them ¹⁷.

The template that carries these fields is Risk acceptance record.

3.3 Route a policy deviation through the exception register#

• Input: a request to depart from a stated policy, rule or standard.
• Activity: separate the two questions. The exception answers whether the rule is suspended, for whom, for how long, and under what conditions. The acceptance answers whether the exposure that follows is taken. Open both records, and cross-reference them by identifier.
• Output: Exception register entry, linked to an acceptance record where the deviation creates an exposure above the low band.
• Owner: the policy owner grants the exception; the risk owner takes the exposure.

The route is expected to exist. An information security policy is expected to contain statements on procedures for handling exemptions and exceptions ¹⁰. Compliance with policies, rules and standards is reviewed regularly ¹⁸. Where non-compliance is found, managers identify the causes, act on them, and review the effectiveness of what they did. The results are recorded. An exception that was never recorded turns up in that review as a non-compliance, which is a slower way to the same conversation.

The exception register needs eight fields: identifier, the rule departed from, the scope, the reason, the conditions attached, the compensating controls, the expiry, and the linked acceptance record. Grant it as a period, never as a state.

3.4 The worked case: a system that cannot be patched#

• Input: a vulnerability with no deployable fix, and the affected asset's register row.
• Activity: work the four questions in order. Is an update available? If it is available but cannot be installed, why not? What other controls hold the exposure down meanwhile? What ends the acceptance?
• Output: an acceptance record whose compensating-control field lists named controls, and whose review trigger names the event that reopens the decision.
• Owner: the system's risk owner, with the vulnerability-management function as author.

Control guidance already lists the second-choice measures, and an acceptance is stronger when it names which of them apply. Where no update is available, or one cannot be installed, other controls are considered ¹⁹. The options listed include a supplier workaround, turning off the affected service or capability, and access controls at network borders. They also include traffic filters that shield the vulnerable system, increased monitoring to detect actual attacks, and raising awareness of the vulnerability. The same guidance expects an audit log of all steps taken in technical vulnerability management ¹⁹.

Three rules make the case survive an audit. Name the compensating controls as controls, with owners and a way to check they run. "Increased monitoring" without a named rule and a named queue is a sentence, not a measure. Set the review trigger to the event rather than only to the calendar: a supplier fix, a public exploit, a change in exposure, or the decommissioning date. State that date where retirement is the real plan, because an acceptance with no end runs the system forever.

3.5 The product case: a requirement that does not apply#

• Input: a product with digital elements, and its cybersecurity risk assessment.
• Activity: decide whether the case is an acceptance at all. For product requirements the route is different, and using the wrong one is a defect in the technical file rather than a debating point.
• Output: either a justification recorded in the technical documentation, or an acceptance record about a residual exposure the requirements do not remove.
• Owner: the product owner, with the compliance function as reviewer.

Under Regulation (EU) 2024/2847, a manufacturer assesses the cybersecurity risks associated with the product ²⁰. The outcome is taken into account across planning, design, development, production, delivery and maintenance. The assessment is documented and updated as appropriate during the support period ²¹. It indicates whether, and in what manner, the requirements in Part I, point (2), of Annex I apply, and how they are implemented. The assessment goes into the technical documentation. Where certain essential cybersecurity requirements are not applicable, the manufacturer includes a clear justification to that effect there ²².

Read that last sentence carefully. The instrument provides for a documented justification of non-applicability. It does not provide for an internal acceptance of an applicable requirement left undone. Acceptance remains available for the residual risk that survives a correctly implemented requirement, never as a way around it.

3.6 Record it once, report it upward#

• Input: signed acceptance records and exception entries from the period.
• Activity: write the residual level and the acceptance identifier back to the register row, so one artefact holds the current picture. Carry the decision into the standing decision log, with the date, the deciding role and the expiry. Report the set upward as a distribution, not a list.
• Output: updated register rows, decision log entries, and a section in the management pack.
• Owner: the risk function.

Recording and reporting is a step of the process in its own right ²³. It aims to communicate activities and outcomes, to inform decision-making, and to assist interaction with those accountable. Reporting is described as an integral part of governance that supports top management and oversight bodies in meeting their responsibilities ²³. A framework states the same expectation as an outcome: risk responses are chosen, prioritized, planned, tracked, and communicated ²⁴.

Keep the records under document control rather than in a shared folder, at clause 7.5.3 ²⁵. The decision log itself is covered in Board and management reporting for security, section 3.7; this playbook only supplies the rows.

3.7 Review, expire, re-decide#

• Input: the acceptance set, with expiry dates and review triggers.
• Activity: run an expiry report before every management forum. Every acceptance inside the next period is either re-decided on current facts or lapses. A lapsed acceptance returns the row to the treatment queue; it does not quietly continue.
• Output: Expiry report, and a re-decision or lapse recorded against every listed acceptance.
• Owner: the risk function runs it; the approver in the authority table re-decides.

Monitoring and review is a planned part of the process with responsibilities clearly defined, taking place at all stages and feeding results back ²⁶. Where no treatment options are available, or the options do not sufficiently modify the risk, the risk is recorded and kept under ongoing review ¹⁶. That is the honest description of most long-running acceptances, and it is a better label than "closed".

Four triggers should reopen a decision before its expiry date. A material change to the asset or its exposure. A new vulnerability or exploit against the same weakness. An incident that used the accepted path, or a change to the criteria themselves. Independent review is expected when significant incidents occur, and when the organisation changes its controls or procedures significantly ²⁷. The acceptance set is a natural sample for that review.

Feed the summary into management review as an input, and take the resulting direction as an output, at clauses 9.3.2 and 9.3.3 ²⁸. Oversight closes the loop: risk management strategy outcomes are reviewed to inform and adjust strategy and direction ²⁹.

3.8 Know what cannot be accepted#

• Input: the appetite statement's never-accepted categories, and the legal register.
• Activity: mark the categories where the acceptance route is closed, and say why for each. Two reasons are distinct: the organisation has chosen not to take the risk, or a duty applies that an internal decision cannot displace.
• Output: a short standing annex to the authority table, reviewed with the criteria.
• Owner: the risk function, with legal counsel for the second category.

Where an instrument states measures as a minimum, an internal decision does not lower that floor. Directive (EU) 2022/2555 requires essential and important entities to take technical, operational and organisational measures, appropriate and proportionate, against risks to their network and information systems ³⁰. Those measures are based on an all-hazards approach and shall include at least ten listed items, from policies on risk analysis to access control and multi-factor authentication ³¹. An entity that finds it does not comply takes all necessary, appropriate and proportionate corrective measures without undue delay ³².

The practical reading is narrow and worth stating exactly. Proportionality under Article 21(1) is judged on exposure, size, and the likelihood and severity of incidents, so how a measure is implemented is a risk judgement. Whether it exists at all is not offered as an acceptance decision, and a known gap is handled as a correction. Management bodies approve the measures, oversee their implementation, and can be held liable for the entity's infringements ³³. That liability is a poor fit with an acceptance signed three levels down.

Where an exposure of this kind cannot be removed at once, record it as a nonconformity with a correction and a corrective action, at clause 10.2 ³⁴. The interim measures may look identical to compensating controls. The record and the closure test are not.

4. Deliverables (with template links)#

Deliverable	Format	Template	Retention
Acceptance authority table	markdown or xlsx	/templates/risk-acceptance-record, Authority table sheet	Life of the criteria, plus one cycle
Acceptance record	xlsx row plus signed approval	/templates/risk-acceptance-record	Three years after expiry
Exception register	eight-column register, no new file	Fields listed in section 3.3	Three years after expiry
Expiry report	one page per forum	Generated from the Acceptances sheet	Until the next report
Register residual level	register row field	/templates/risk-register	With the register

5. What the auditor or authority will ask [Callout: auditor-asks]#

• "Show the acceptance of the residual risk for this row. Who accepted it, and when?" — evidence: the acceptance record, with the approver's role and date.
• "Under what authority did that role accept at that level?" — evidence: the approved acceptance authority table, and the minute that approved it.
• "How was the residual level calculated after treatment, and against which criteria?" — evidence: the register row, the criteria, and the record's against-criteria field.
• "This acceptance expired four months ago. What happened?" — evidence: the expiry report and the re-decision entry, or the row's return to the treatment queue.
• "Which compensating controls hold this exposure down, and how do you know they run?" — evidence: the named controls, their owners, and the last monitoring output.
• "Show an exception granted this year and the exposure it created." — evidence: the exception entry, its conditions and expiry, and the linked acceptance record.
• "Which risks may nobody accept, and who decided that?" — evidence: the never-accepted annex, and the forum minute approving the criteria.
• "For this product, where is the justification that the requirement does not apply?" — evidence: the technical documentation entry, not an internal acceptance record.

6. Failure modes and how they surface as findings [Callout: failure-mode]#

• Acceptance with no expiry — surfaces as: "residual risks are recorded as accepted with no defined review or end date". Smallest fix: add an expiry column, set a default of twelve months, and re-confirm every open acceptance in one dated sitting.
• The approver who had no authority — surfaces as: "risk owners accepted residual risks above the levels the criteria delegate to them". Smallest fix: publish the authority table, then re-route every open acceptance above the delegated band.
• Residual level copied from before treatment — surfaces as: "the recorded residual level does not reflect the controls implemented under the treatment plan". Smallest fix: recompute the level at plan closure, and block closure until the field changes or the reason is stated.
• Exceptions used as a substitute for acceptance — surfaces as: "policy deviations are recorded without any assessment of the risk they create". Smallest fix: make the acceptance link mandatory on exception entries above the low band.
• Compensating controls that nobody owns — surfaces as: "controls relied on in accepting the risk are not assigned, monitored or tested". Smallest fix: give each named control an owner and one monitoring output, checked at expiry.
• A legal minimum accepted as a risk — surfaces as: "a required measure was not implemented and the gap was recorded as an accepted risk". Smallest fix: reclassify as a nonconformity, with a correction, a cause and a corrective action.

7. Mapping to standards (clause table, verified)#

Element	ISO/IEC 27001:2022	ISO 31000:2018	ISO/IEC 27002:2022	NIST CSF 2.0	Regulation	Evidence
Who may accept, and up to what level	5.3 Organizational roles, responsibilities and authorities	5.4.3 Assigning organizational roles, authorities, responsibilities and accountabilities	5.2 Information security roles and responsibilities	GV.RR-02	Reg. (EU) 2022/2554 Art. 5(2)(d)	Acceptance authority table, approved
The boundary the acceptance sits inside	6.1.2 Information security risk assessment	6.3.4 Defining risk criteria	—	GV.RM-02	Reg. (EU) 2022/2554 Art. 6(8)(b)	Approved criteria and tolerance statement
Acceptance as a treatment choice	6.1.3 Information security risk treatment	6.5.2 Selection of risk treatment options	—	ID.RA-06	—	Acceptance record, option and reason declined
The residual level after treatment	8.3 Information security risk treatment, as an operation	6.5.1 General; 6.5.2 remaining risk documented	—	ID.RA-06	—	Recomputed level and criteria test
Compensating controls where no fix exists	Annex A Information security controls reference	3.8 control	8.8 Management of technical vulnerabilities	ID.RA-07	—	Named controls, owners, monitoring output
The exception route for policy deviations	7.5.3 Control of documented information	—	5.1 Policies for information security; 5.36 Compliance with policies, rules and standards	ID.RA-07	—	Exception entry with conditions and expiry
Recording and reporting the decision	9.3 Management review	6.7 Recording and reporting	5.4 Management responsibilities	GV.OV-01	Dir. (EU) 2022/2555 Art. 20(1)	Decision log entry and management pack
Review, expiry and re-decision	9.1 Monitoring, measurement, analysis and evaluation	6.6 Monitoring and review	5.35 Independent review of information security	GV.OV-03	—	Expiry report and re-decision record
What cannot be accepted away	10.2 Nonconformity and corrective action	—	—	GV.RM-04	Dir. (EU) 2022/2555 Art. 21(2) and 21(4)	Never-accepted annex; nonconformity record
Product requirements that do not apply	—	—	—	—	Reg. (EU) 2024/2847 Art. 13(3) and 13(4)	Justification in the technical documentation

Clause and control identifiers in this table were read as printed. ISO/IEC 27001:2022 titles are cited from the publisher's contents listing ³⁵. Control numbers and titles are cited from ISO/IEC 27002:2022 ³⁶. Subcategory identifiers and names are cited from the framework's own listing ³⁷. A standardized method for calculating, documenting, categorizing and prioritizing risks is one of its outcomes ³⁸.

8. Checklist (interactive)#

• An acceptance authority table exists, and the forum minute approving it names a date.
• Every band in that table states a maximum duration, and the top band is not delegated.
• Every accepted risk has a record carrying the risk as assessed, the option declined and the reason.
• Every record states a residual level recomputed after treatment, tested against the criteria.
• Every record names its compensating controls, each with an owner.
• Every record carries an expiry date and at least one event-based review trigger.
• The approver named on each record holds the authority the table gives that level.
• The register row for each accepted risk carries the residual level and the acceptance identifier.
• The decision log holds one entry per acceptance, with date, role and expiry.
• An expiry report is produced before every management forum.
• Every acceptance expiring in the next period is re-decided or recorded as lapsed.
• A lapsed acceptance returns its row to the treatment queue within one cycle.
• The exception register links to an acceptance record for every entry above the low band.
• Every exception entry states the rule, the conditions, the compensating controls and an expiry.
• A standing annex lists the categories where acceptance is not available, with the reason.
• Gaps against a stated legal minimum are recorded as nonconformities, not as accepted risks.
• Product requirements found not applicable are justified in the technical documentation.
• Acceptance records are held under document control, with retention stated.
• The acceptance set is reported to management review as an input each cycle.

References#

1. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ³⁹
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. https://www.iso.org/standard/75652.html ⁴⁰
3. ISO/IEC. Information security, cybersecurity and privacy protection — Guidance on managing information security risks. ISO/IEC 27005:2022. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en ¹
4. ISO. Risk management — Guidelines. ISO 31000:2018. https://www.iso.org/standard/65694.html ⁴¹
5. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29 ⁴²
6. European Parliament and Council. Directive (EU) 2022/2555 (NIS 2 Directive). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng ⁴³
7. European Parliament and Council. Regulation (EU) 2022/2554 (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁴⁴
8. European Parliament and Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng ⁴⁵

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.