Risk Acceptance Record Template (ISO/IEC 27001 6.1.3 f)

Risk Acceptance Record: [Risk ID and short title]

A record of the formal decision to accept one information security risk at a stated residual level, for a limited time and on stated conditions, by a person with the authority for that risk band. It holds the risk description, the score before and after treatment, the rationale, the compensating controls, the conditions, the expiry and review dates and the approval, followed by the register of all acceptances. It supports the residual risk acceptance by risk owners that ISO/IEC 27001:2022 + Amd 1:2024 clause 6.1.3 f expects, using the acceptance criteria set under clause 6.1.2 a (DOC-ISMS-015), and provides part of the risk treatment results retained under clause 8.3. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

• 1. When an acceptance record is required
• 2. Approval authority by band
• 3. Acceptance record form
• 4. Worked example
• 5. Lifecycle of an acceptance
• 6. Register of acceptances
• 7. Monitoring, renewal and revocation
• 8. Relationship to security exceptions
• 9. Size tiers
• 10. Records and evidence
• 11. References
• Standard and licence note

1. When an acceptance record is required

Create one record per risk when any of these is true:

No record is needed for Low risks within appetite and for Medium risks within the appetite of their category: those are accepted by the risk owner in the register (DOC-ISMS-016) with a date and expiry.

What cannot be accepted:

• a risk that would knowingly breach a law, regulation or binding contract term;
• a Critical risk without immediate interim measures and a documented top management decision;
• a risk whose owner has not been identified.

2. Approval authority by band

Rules applied in every record:

1. The approver must be independent of the person proposing the acceptance where practical; a risk owner never approves their own High or Critical acceptance alone.
2. The CISO or ISMS manager reviews every record before approval and records an opinion (agree or disagree with reasons). The approver may decide against that opinion, but the disagreement stays on record.
3. An acceptance expires at the earlier of its expiry date and the date any condition in Part E is broken.

3. Acceptance record form

Part A: Risk

Part B: Scores before and after

The residual score being accepted is the second row.

Part C: Rationale and options considered

Business justification: [What the organization gains or protects by accepting; what it would cost to treat further; why now].

Part D: Compensating controls

Part E: Conditions

List the conditions that must stay true for the acceptance to remain valid (for example "no customer personal data stored in the component", "monthly access review completed"). Breaking any condition ends the acceptance.

Part F: Expiry, review and exit

Part G: Review and approval

Part H: Decision record

4. Worked example

ACC-001 (Example): R-018 legacy export service without single sign-on

Rationale: replacing the service is planned with the new data platform in Q3 2027 (RTP-019). Rebuilding authentication in the legacy service for six months would cost about USD 40,000 in engineering time (Example; use local currency), more than the compensating controls below, which cost about USD 6,000.

Compensating controls:

Conditions: (1) monthly review completed and recorded; (2) no new customers on the service; (3) replacement remains funded and dated.

Expiry and approval: the residual band is Medium, but the category is Averse, so DOC-ISMS-015 section 9 escalates approval one level to top management. Start 2027-04-01, review 2027-09-01, expiry 2027-09-30. Reviewed by the ISMS manager (Head of Engineering Operations, part-time 0.5 FTE) on 2027-03-29 with the opinion "agree"; accepted by the CEO on 2027-03-31.

5. Lifecycle of an acceptance

6. Register of acceptances

Summary (Example, as of 2027-07-31):

ACC-003 and ACC-005 are two of the 14 High acceptances that top management recorded on 2027-05-21 to correct certification finding CBF-2027-01 (see isms/isms-worked-walkthrough); ACC-004 closed when all contractor laptops were enrolled; ACC-005 was revoked at the July monthly review, which found the shared account still used after the condition date; ACC-006 was rejected and the risk treated through test data masking (A.8.11). (Example)

7. Monitoring, renewal and revocation

• The ISMS manager reviews the register [monthly] and sends a reminder to each risk owner [30] days before the review date.
• At review, the risk owner proposes one of: renew (new record version with a new expiry, same approval level), treat (link to RTP), or close (risk no longer exists).
• A renewal of a High acceptance more than [once] requires top management to confirm why treatment is still not feasible, and the steering committee is informed.
• Any breach of a condition is reported to the ISMS manager within [2] working days; the acceptance is revoked and the risk escalated under DOC-ISMS-015 section 10.
• Active, expired and revoked acceptances are reported at each management review (DOC-ISMS-085) with counts by band, and in the ISMS performance report (DOC-ISMS-081).
• Each annual risk assessment (DOC-ISMS-017) lists all active acceptances and confirms they still reflect the current score.

8. Relationship to security exceptions

Both routes use the same approval levels from DOC-ISMS-015 section 9.

9. Size tiers

10. Records and evidence

11. References

Related templates: isms/isms-risk-appetite-criteria, compliance/risk-methodology, compliance/risk-register, compliance/risk-treatment-plan, isms/isms-risk-assessment-report, isms/isms-threat-vulnerability-catalogue, security/security-exception-request, compliance/management-review.

Official text: https://www.iso.org/standard/82875.html, https://www.iso.org/standard/88435.html, https://www.iso.org/standard/80585.html.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.1.2 a, 6.1.3 f and 8.3) and ISO/IEC 27005:2022. Clause numbers are cited only; the form, rules, states, figures and examples are original text written for this template, and all figures are worked examples. No ISO or IEC text is reproduced, and you need the official standards to interpret the requirements. Check the current editions before use. This template does not promise certification; certification decisions belong to the accredited certification body.

Template licence: MIT.