# 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*.

<!--
Guidance: How to use this template
- When to use: whenever a risk is retained at a level that needs
  approval beyond routine register entry: any High or Critical
  residual risk, any risk above the appetite of its category, and the
  other triggers in section 1. Low and Medium risks within the appetite
  of their category are accepted in the risk register (Medium with a
  written reason) without this record.
- Fill first: Part A (risk) and Part B (scores) from the risk register,
  then Part C (why treatment stops here). Route to the approver in
  Part G only after the compensating controls in Part D are in place
  or dated.
- Main pitfall: open-ended acceptance. Every record has an expiry date
  on the calendar, a review date before it, and an owner who will be
  asked to renew, treat or close.
- Second pitfall: acceptance by the wrong person. The approver must
  hold the authority for the residual band in DOC-ISMS-015 section 9;
  a risk owner cannot accept a High risk alone.
- Related templates: `isms/isms-risk-appetite-criteria` (DOC-ISMS-015),
  `compliance/risk-methodology` (DOC-ISMS-010),
  `compliance/risk-register` (DOC-ISMS-016),
  `compliance/risk-treatment-plan` (DOC-ISMS-013),
  `isms/isms-risk-assessment-report` (DOC-ISMS-017),
  `security/security-exception-request` (DOC-ISMS-122),
  `isms/control-evidence-matrix` (DOC-ISMS-033).
-->

## Document control

<!-- Guidance: The document control covers the record set (the form and the register). Each individual acceptance carries its own ACC-NNN identifier and approval in Part G. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-019 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ciso], [@ceo] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.1.2 a, 6.1.3 f, 8.3); ISO/IEC 27005:2022 |
| Acceptance criteria | DOC-ISMS-015 version [x.y], section 9 |
| Risk register | DOC-ISMS-016 |
| Treatment plan | DOC-ISMS-013 |
| Active acceptances | [Number, from section 6] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared the record set] | YYYY-MM-DD |
| CISO or security lead | [@ciso] | [Reviewed] | YYYY-MM-DD |
| Top management | [@ceo] | [Approved the form and routing] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@isms-manager] | First issue with the approved acceptance criteria |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. When an acceptance record is required](#1-when-an-acceptance-record-is-required)
- [2. Approval authority by band](#2-approval-authority-by-band)
- [3. Acceptance record form](#3-acceptance-record-form)
- [4. Worked example](#4-worked-example)
- [5. Lifecycle of an acceptance](#5-lifecycle-of-an-acceptance)
- [6. Register of acceptances](#6-register-of-acceptances)
- [7. Monitoring, renewal and revocation](#7-monitoring-renewal-and-revocation)
- [8. Relationship to security exceptions](#8-relationship-to-security-exceptions)
- [9. Size tiers](#9-size-tiers)
- [10. Records and evidence](#10-records-and-evidence)
- [11. References](#11-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. When an acceptance record is required

<!-- Guidance: State the triggers so risk owners know when a register entry is not enough. An auditor will sample High residual risks in the register and ask for the record behind each. -->

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

| Trigger | Example *(Example)* |
|---|---|
| Residual score is High (10 to 16) or Critical (17 to 25) | A legacy component cannot be replaced before next year |
| Residual risk exceeds the appetite of its category in DOC-ISMS-015 section 3 | A Medium confidentiality risk in a category marked Averse |
| Treatment is rejected as not cost-effective for a risk above Low | Full redundancy would cost more than the expected loss |
| A planned treatment is delayed beyond its due date and the risk stays above appetite | Hardware supply delays laptop replacement |
| Top management chooses to retain a risk after a major incident review | Interim acceptance while a redesign is funded |
| An acceptance is renewed after expiry | Second six-month acceptance for the same risk |

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

<!-- Guidance: Copy the authority table from DOC-ISMS-015 section 9, not from memory. If the two differ, DOC-ISMS-015 wins and this table must be corrected. -->

| Residual band | Approver | Maximum period *(Example)* | Must also be informed |
|---|---|---|---|
| Medium (5 to 9) | Risk owner and department head; top management if the category is Averse | 12 months | ISMS manager |
| High (10 to 16) | Top management ([CEO / COO / delegated executive]) | 6 months | Steering committee |
| Critical (17 to 25) | Not acceptable without treatment; exceptionally top management by documented decision | 3 months | Board or owners where one exists; steering committee |

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

<!-- Guidance: Use one copy of this form per acceptance, numbered ACC-NNN. Keep the wording factual; the approver must understand what they are accepting without reading the whole register. -->

### Part A: Risk

| Field | Value |
|---|---|
| Acceptance ID | [ACC-NNN] |
| Risk ID (register) | [R-NNN] |
| Risk title | [Short title] |
| Description (cause, event, consequence) | [Text] |
| Catalogue references | [THR-NNN, VUL-NNN from DOC-ISMS-018] |
| Assets or processes affected | [From DOC-ISMS-012] |
| Risk category and appetite | [Category / Averse, Cautious or Open] |
| Risk owner | [@risk-owner] |
| Proposed by | [@proposer] |
| Date proposed | YYYY-MM-DD |

### Part B: Scores before and after

| Measure | Likelihood | Impact | Score | Band | Basis |
|---|---|---|---|---|---|
| Current, with existing controls | [1 to 5] | [1 to 5] | [L x I] | [Band] | [Evidence for ratings] |
| With compensating controls in Part D | [1 to 5] | [1 to 5] | [L x I] | [Band] | [Why the controls change the rating] |
| Target if full treatment were applied | [1 to 5] | [1 to 5] | [L x I] | [Band] | [Treatment considered in Part C] |

The residual score being accepted is the second row.

### Part C: Rationale and options considered

| Option | Considered? | Outcome | Reason |
|---|---|---|---|
| Modify (reduce) | [Yes / No] | [Chosen in part / Rejected] | [Cost, feasibility, timing] |
| Avoid | [Yes / No] | [Rejected] | [Business impact of stopping the activity] |
| Share (transfer) | [Yes / No] | [Chosen in part / Rejected] | [Insurance or contract position] |
| Retain (accept) | Yes | Proposed | [Why retaining the residual is reasonable now] |

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

### Part D: Compensating controls

| Control | Annex A reference | Owner | Status | Evidence |
|---|---|---|---|---|
| [Control description] | [A.x.y short label] | [@control-owner] | [In place / Due YYYY-MM-DD] | [Record or system] |

### 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.

| No. | Condition | How monitored | Monitored by |
|---|---|---|---|
| 1 | [Condition] | [Metric, review or alert] | [@owner] |

### Part F: Expiry, review and exit

| Field | Value |
|---|---|
| Acceptance start | YYYY-MM-DD |
| Review date (before expiry) | YYYY-MM-DD |
| Expiry date | YYYY-MM-DD (within the maximum period for the band) |
| Early review triggers | [Incident affecting the risk, change to the asset, threat intelligence, condition breach] |
| Exit plan | [Treatment that will end the need for acceptance, with RTP reference and date] |

### Part G: Review and approval

| Role | Name | Opinion or decision | Date |
|---|---|---|---|
| Risk owner | [@risk-owner] | [Proposes acceptance] | YYYY-MM-DD |
| ISMS manager or CISO | [@ciso] | [Agrees / Disagrees, with reason] | YYYY-MM-DD |
| Approver for the band | [@approver] | [Accepted / Accepted with conditions / Rejected] | YYYY-MM-DD |
| Informed | [Steering committee / board] | [Minute reference] | YYYY-MM-DD |

### Part H: Decision record

| Field | Value |
|---|---|
| Decision | [Accepted / Accepted with additional conditions / Rejected, treat instead] |
| Additional conditions set by the approver | [Text or "None"] |
| Register updated | [Yes, DOC-ISMS-016 updated YYYY-MM-DD] |
| Treatment plan updated | [Yes, RTP-NNN / Not applicable] |

## 4. Worked example

<!-- Guidance: The example shows the level of detail an auditor expects. It uses Quillmere Analytics Ltd (small tier, 46 staff, B2B SaaS analytics, processor of customer personal data). -->

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

| Field | Value |
|---|---|
| Risk ID | R-018 |
| Description | The legacy scheduled export service uses local accounts instead of the identity provider, so a leaver's account could remain usable and export customer datasets (confidentiality) |
| Catalogue references | THR-006, VUL-013, VUL-001 |
| Category and appetite | Confidentiality of customer and personal data / Averse |
| Risk owner | Head of Product |
| Proposed | 2027-03-25 |

| Measure | L | I | Score | Band |
|---|---|---|---|---|
| Current, with existing controls | 3 | 4 | 12 | High |
| With compensating controls | 2 | 4 | 8 | Medium |
| Target with full treatment (service replaced) | 1 | 4 | 4 | Low |

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:

| Control | Annex A reference | Status |
|---|---|---|
| Access only from the VPN, which requires MFA through the identity provider | A.8.5 secure authentication | In place |
| Local accounts reviewed monthly against the HR leaver list | A.5.18 access rights provisioning and review | In place |
| Export volume alerts sent to the on-call engineer | A.8.16 monitoring activities | In place |
| No new customers onboarded to the legacy service | A.8.3 restricting access to information | In place |

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

<!-- Guidance: The states below are the values used in the Status column of section 6. Keep the diagram and the register consistent. -->

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Submitted : risk owner proposes
  Submitted --> Rejected : approver declines
  Submitted --> Active : approved at the right level
  Active --> UnderReview : review date or trigger
  UnderReview --> Active : renewed with new expiry
  UnderReview --> Closed : treated or risk no longer exists
  Active --> Revoked : condition broken
  Active --> Expired : expiry passed without decision
  Rejected --> [*]
  Closed --> [*]
  Revoked --> [*]
  Expired --> [*]
```

| State | Meaning | Effect in the risk register |
|---|---|---|
| Draft | Being prepared by the risk owner | Risk shown as open |
| Submitted | Waiting for review and approval | Risk shown as open, decision pending |
| Active | Accepted and within its period | Risk shown as accepted with expiry |
| UnderReview | Review date reached or a trigger occurred | Risk shown as accepted, review in progress |
| Rejected | Approver declined; treatment required | Risk returns to treatment in DOC-ISMS-013 |
| Closed | Treatment completed or risk gone | Risk rescored or closed |
| Revoked | A condition was broken | Risk shown as open; escalated |
| Expired | Expiry passed without renewal | Risk shown as open; reported as overdue |

## 6. Register of acceptances

<!-- Guidance: Keep every acceptance, including rejected and closed ones, so history is visible. Report counts by status and band to every management review. -->

| ACC ID | Risk ID | Title | Residual | Approver | Start | Expiry | Status |
|---|---|---|---|---|---|---|---|
| ACC-001 *(Example)* | R-018 | Legacy export service without single sign-on | 8 Medium (Averse category) | CEO | 2027-04-01 | 2027-09-30 | Active |
| ACC-002 *(Example)* | R-024 | Recovery in the DR region exceeds the internal recovery time objective (contractual recovery times still met); full active-active design rejected as not cost-effective | 8 Medium | Head of Engineering Operations and CTO | 2027-04-01 | 2028-03-31 | Active |
| ACC-003 *(Example)* | R-012 | Embedded charting component from a supplier is out of vendor support until replacement | 12 High | CEO | 2027-05-21 | 2027-11-21 | Active |
| ACC-004 *(Example)* | R-007 | Contractor laptops not enrolled in MDM during migration | 9 Medium | Head of Engineering Operations and CTO | 2027-02-15 | 2027-08-15 | Closed |
| ACC-005 *(Example)* | R-015 | Shared admin account on the marketing website | 10 High | CEO | 2027-05-21 | 2027-11-21 | Revoked |
| ACC-006 *(Example)* | R-021 | Customer data copied into test environment without masking | 12 High | CEO | Not started | Not applicable | Rejected |

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

| Status | Count | Of which High | Of which Medium |
|---|---|---|---|
| Active | 3 | 1 | 2 |
| Closed | 1 | 0 | 1 |
| Revoked | 1 | 1 | 0 |
| Rejected | 1 | 1 | 0 |
| **Total** | **6** | **3** | **3** |

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

<!-- Guidance: Describe who watches the dates and what happens at each one. Pitfall: acceptances that expire silently. Auditors check whether expired acceptances were renewed or treated on time. -->

- 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

<!-- Guidance: Exceptions to a policy and acceptances of a risk are related but not the same. Decide which record leads, so the same decision is not approved twice with different conditions. -->

| Situation | Leading record | Link |
|---|---|---|
| A policy or standard requirement cannot be met for a specific system or person | Security exception request (`security/security-exception-request`, DOC-ISMS-122) | The exception creates or updates a risk in DOC-ISMS-016; if its residual needs approval beyond the risk owner, reference this record |
| A risk from the risk assessment is retained at a level needing approval | This record (DOC-ISMS-019) | No exception needed unless a policy is also breached |
| Both apply | Exception request, with this record attached | Same approval level, same expiry |

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

## 9. Size tiers

<!-- Guidance: The decision logic is the same at all sizes; what changes is who approves and how the register is kept. -->

| Aspect | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large or multi-site: Quillmere Group *(Example)* |
|---|---|---|---|
| Typical active acceptances | 2 to 5 | 5 to 12 | 20 to 40 across sites |
| Who reviews before approval | Part-time ISMS manager (Head of Engineering Operations, 0.5 FTE) | ISMS manager with the security team | CISO's security office; site security coordinator for site risks |
| High approver | CEO | CEO or COO | Divisional managing director for site risks; group executive for group-wide risks |
| Where the register is kept | A tab in the risk register spreadsheet | GRC tool or ticketing workflow with approval steps | Group GRC tool, filtered by site and division |
| Reporting | Quarterly to the CEO | Monthly to the steering committee | Monthly to divisional boards, quarterly to the group executive committee |
| Special cases | Few approvers: avoid the CEO approving risks the CEO owns; use an independent board member or investor representative where available | Patient safety risks reviewed by the clinical safety officer | OT safety-related risks reviewed by the site safety manager before approval |

## 10. Records and evidence

<!-- Guidance: These records prove acceptance follows the approved criteria. Map them in the control evidence matrix (`isms/control-evidence-matrix`). -->

| Record | Proves | Owner | Location *(Example)* | Retention *(Example)* |
|---|---|---|---|---|
| Completed acceptance records (ACC-NNN) with approvals | Residual risk accepted by an authorised owner (6.1.3 f) | Risk owners; ISMS manager keeps the set | GRC tool or document management system | Life of the risk plus 3 years |
| Register of acceptances | Overview and status of all acceptances | ISMS manager | DOC-ISMS-019 section 6 | Current plus dated snapshots for 3 years |
| Review reminders and renewal decisions | Acceptances are reviewed before expiry | ISMS manager | Ticketing system | 3 years |
| Condition monitoring evidence | Conditions are maintained | Control owners | Systems named in Part E | 3 years |
| Management review minutes | Acceptances reported to top management (9.3) | Steering committee secretary | DOC-ISMS-085 | 6 years |
| Risk treatment results | Clause 8.3 record retained | ISMS manager | DOC-ISMS-013 and this record set | 3 years |

## 11. References

<!-- Guidance: Cite the editions used and keep the authority table aligned with DOC-ISMS-015. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | 3rd edition 2022; Amd 1 2024-02-23 | Clauses 6.1.2 a, 6.1.3 f, 8.3, 9.3 |
| ISO/IEC 27005:2022 | 4th edition | Risk acceptance and treatment guidance |
| ISO 31000:2018 | Current; a revision is in progress | Treatment options and retention of risk |

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.