Risk Acceptance Form & Approval Record
Records a deliberate decision to accept residual risk with the authority, duration and review trigger that makes it defensible later.
Available soon
- Format
- Word
- Size
- 59 KB
- Length
- 18 pages
- Version
- 1.1
- Updated
What's inside
- How to use this form
- The form
- Worked example — a completed acceptance
- Related documents
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
How to use this form
Use this form when [[Organisation Name]] decides to keep a residual risk rather than reduce, avoid or transfer it. One form covers one risk in the Information Security Risk Register. It records who accepted the risk, on what authority, on what conditions and until when, so that the decision can be defended later — to the board, an auditor or a regulator — by someone who was not in the room.
Accepting a residual risk is recorded on the Risk Acceptance Form, approved at the band's level, and reviewed by its date; outside tolerance only the board or its equivalent may accept. (RM-08). The rules are in the Risk Assessment Methodology & Scoring Model; the Risk Identification & Assessment Operating Procedure governs this form. Each completed form is listed in the register, which is the inventory of accepted risks.
Part | Who completes it | When |
|---|---|---|
A — The risk | Risk owner [[the accountable executive for the service or asset]], with the assessor | When acceptance is proposed as the treatment |
B — Why accept, and on what terms | Risk owner | With Part A |
C — Approval | The approvers for the band, and above them where the position requires | Before the risk is recorded as accepted; outside appetite, within [[30]] calendar days of the risk first being assessed outside appetite (RM-06) |
D — Reviews and renewal | Risk owner | Every quarter (RM-09), and at the review date |
E — Closure | Risk owner; verified by head of information security | When the acceptance ends |
Steps
- The risk owner and assessor complete Part A from the register entry, and the risk owner completes Part B.
- Head of Information Security checks the score, the band and the position against the Cyber Risk Appetite Statement Template, and whether a policy rule is not met (B2) — if one is, it is a P02 exception instead: see "Acceptance or exception?" below.
- The approvers for the band sign Part C. If the risk is outside appetite, it goes on to executive management; if outside tolerance, or Critical, to the board.
- Head of Information Security records the acceptance in the register — treatment "Accept", the approval date and the review date — and sets a reminder before the review date.
- The risk owner checks the conditions at every quarterly review (Part D). At the review date the acceptance is renewed on a fresh score, or it ends (Part E).
Guidance — delete before approval
Keep the field names in step with the columns of the Information Security Risk Register, so the register's acceptance columns can be filled from Part C without retyping.
If your organisation runs approvals in a workflow or governance tool, rebuild these fields there. Keep the order: the risk, the reasons, the approval at the right level.
Acceptance or exception?
This form and the P02 Security Exception Request & Approval Form look alike, and use the same 4 × 4 scale and bands, but they record different decisions.
Security exception (P02) | Risk acceptance (this form) | |
|---|---|---|
What is decided | That a specific rule in a policy or standard need not be met, in a stated scope, for a limited time | That a residual risk in the register is kept, knowingly, rather than treated further |
Starts from | A rule that is not met | A risk whose treatment has been chosen as Accept (RM-06) |
Lasts | At most Low 365, Medium 180, High 90, Critical 30 days, by band; renewals are limited | Until its review date: Low 12 · Medium 12 · High 6 · Critical 3 months, by band; renewed on a fresh score |
Recorded in | Security Exception Register | Information Security Risk Register |
Who signs | The P02 band's approver; where the gap leaves a risk outside appetite, or Critical, also the approver this pack requires for that position | The band's approvers; executive management as well outside appetite; only the board outside tolerance |
Governed by | Security Exception & Waiver Standard | Risk Assessment Methodology & Scoring Model (RM-08) |
When to use which.
- A rule is not met — a required control is missing, late or configured differently from the standard: a broken rule is a P02 exception, not a risk acceptance. Where the exception leaves a risk outside appetite, or scored Critical, the approver this pack requires for that position also signs the exception: the stricter of the two always applies. Record it under the Security Exception & Waiver Standard. That record, signed by the risk owner, is also the decision to carry the risk of the gap; do not complete this form as well. The extra signature goes on the Security Exception Request & Approval Form, in its signatures part, with the risk's position noted beside it. Link the exception from the register entry.
- Every rule is met, but the residual risk is still more than the owner would choose — or no rule covers it: use this form.
- Both at once — the owner wants to accept a risk that exists because a rule is not met: the exception comes first. If the exception is refused, the rule must be met; this form cannot be used to accept around a refused exception.
Guidance — delete before approval
If you have not adopted the P02 pack, record exceptions on this form with a note of the rule not met, and use the shorter exception durations (Low 365, Medium 180, High 90, Critical 30 days) as the review dates for those forms.
Before you submit — the risk owner's checklist
- The scenario names a threat, a weakness, an asset or service and a consequence (A2, RM-01).
- The score and band match the register, and each rating has a reason (A3).
- The position is worked out from the category's level in the appetite statement (A4, RM-05).
- Each other treatment option has been considered, with the reason it was not chosen (B1).
- The conditions are specific enough that someone else could check them (B3).
- You know who must sign for this band and position (Part C).
Field guidance
Field | What a good answer looks like | Common reason a form is returned |
|---|---|---|
A2 Consequence | The harm in business terms: which customers, what service, how much money, which legal duty. | "Data breach" — the approver cannot weigh it. |
A3 Existing controls | What is in place and whether it changes the score. If inherent and residual are the same, say why. | Controls listed that are planned, not in place. |
B1 Other options | What each would take, in money or time, and why it was not chosen. | "Not feasible" with no reason. |
B2 Reason | Why keeping the risk is worth it: the cost of reducing it against the harm, and any date when that changes. | "Business need" — nothing to weigh. |
B3 Conditions | Observable conditions: where, who, what must not happen. | "Staff to be careful" — nobody can check it. |
C1 Review by | The acceptance date plus the band's interval (Low 12 · Medium 12 · High 6 · Critical 3 months). An earlier date if the reason expires earlier. | No date, or a date beyond the band's interval. |
The form
Guidance — delete before approval
Replace the placeholders with blank space when you adopt the form, or leave them as prompts. Keep the approval tables in Part C identical to the Risk Assessment Methodology & Scoring Model.
Part A — The risk
Completed by the risk owner with the assessor, from the Information Security Risk Register entry. Every field here should match the register.
A1 Identification | |||
Acceptance reference given by information security; used in the register | [[RA-nn]] | Register reference the risk accepted | [[R-nn]] |
Category | [[RC-nn, name]] | Assessor | [[Role]] |
Risk owner (RM-02) the executive accountable for what it would hurt | [[Role]] | ||
Date raised | [[YYYY-MM-DD]] | New or renewal? if renewal, see Part D | [[New / Renewal of RA-nn]] |
Risk title as in the register | [[Short title]] | ||
A2 The scenario (RM-01) | |||
Threat what could happen | [[e.g. theft, ransomware, error]] | ||
Weakness what it would use | [[The gap or condition the threat exploits]] | ||
Asset or service what would be hurt | [[System, data or service]] | ||
Consequence in business terms | [[Harm to customers, service, money or legal position]] | ||
A3 Score (RM-03) | |||
Impact 1 Minor · 2 Moderate · 3 Major · 4 Severe | [[1–4]] | Reason | [[Why this level: the worst consequence]] |
Likelihood next 12 months: 1 Unlikely · 2 Possible · 3 Likely · 4 Almost certain | [[1–4]] | Reason | [[Why this level]] |
Inherent score before existing controls | [[I × L = n]] | Residual score after existing controls | [[I × L = n]] |
Residual band Low 1–3 · Medium 4–6 · High 8–9 · Critical 12–16 | [[Low / Medium / High / Critical]] | Existing controls and what they change | [[Controls in place, and their effect on the score]] |
A4 Position against appetite (RM-05) | |||
Category's appetite level Averse: appetite Low, tolerance Medium · Cautious: appetite Medium, tolerance High · Open: appetite High, tolerance High | [[Level: appetite band, tolerance band]] | ||
Position from the residual band and the level | [[Within appetite / Outside appetite, within tolerance / Outside tolerance]] | ||
Part B — Why accept, and on what terms
Completed by the risk owner. Acceptance is a treatment choice like the others (ISO/IEC 27001 Clause 6.1.3); this part shows the others were weighed.
B1 Other options considered | |||
Reduce change the likelihood or the impact with controls. | [[What it would take — why it was not chosen]] | ||
Avoid stop the activity that creates the risk. | [[What it would take — why it was not chosen]] | ||
Transfer share the impact with a third party, for example by insurance or contract | [[What it would take — why it was not chosen]] | ||
B2 Reason for accepting | |||
Why accepting is the right decision cost, benefit, timing | [[Why the residual risk is worth keeping: what reducing it would cost, and what keeping it buys]] | ||
Is a policy or standard rule not met? if yes, stop: it is a P02 exception, not an acceptance | [[No / Yes — P02 exception reference EX-…]] | ||
B3 Conditions and early end | |||
Conditions what must stay true while the risk is accepted | [[Conditions, each one checkable]] | ||
Who checks the conditions, and how often | [[Role; at each quarterly review (RM-09)]] | ||
What ends or reopens the acceptance besides the review date | [[e.g. the fix is delivered; a trigger occurs (RM-10); a condition is broken]] | ||
Part C — Approval
The residual band sets who must sign and how long before the acceptance must be reviewed (RM-04, RM-08). Outside appetite, executive management signs as well as the band's approvers; outside tolerance, the band's approvers only recommend and the board decides.
Residual band | Scores | Who must sign | Review within |
|---|---|---|---|
Low | 1–3 | Risk owner | 12 months |
Medium | 4–6 | Risk owner and Head of Information Security | 12 months |
High | 8–9 | Accountable executive and Head of Information Security | 6 months |
Critical | 12–16 | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | 3 months |
Who may accept, by band and position. Executive management means a decision of executive management [[e.g. Executive Committee]], recorded with its reference; the board means [[e.g. Board, or its Audit & Risk Committee]]. A dash marks a combination the appetite levels cannot produce.
Residual band | Within appetite | Outside appetite, within tolerance | Outside tolerance |
|---|---|---|---|
Low | Risk owner | — | — |
Medium | Risk owner and Head of Information Security | Risk owner and Head of Information Security, and executive management as well | — |
High | Accountable executive and Head of Information Security | Accountable executive and Head of Information Security, and executive management as well | Accountable executive and Head of Information Security recommend; only the board or its equivalent may accept |
Critical | — | — | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management recommend; only the board or its equivalent may accept |
C1 Decision | |||
Approval required the band's approvers, and above them by position (table above) | [[From the table above]] | ||
Decision | [[Accepted / Accepted with conditions / Refused — treat instead]] | ||
Accepted from | [[YYYY-MM-DD]] | Review by acceptance date + the band's review interval | [[YYYY-MM-DD]] |
C2 Signatures | |||
Band approver 1 | [[Role — the band's first approver]] | Signature and date | [[Signature, date]] |
Band approver 2 Medium and High bands | [[Role — or not required]] | Signature and date | [[Signature, date]] |
High band accountable executive, if not the risk owner | [[Role — or not required]] | Signature and date | [[Signature, date]] |
Outside appetite or tolerance, or Critical executive management or board decision | [[Body and meeting — or not required]] | Minute or decision reference | [[Reference]] |
Recorded in the register by | [[Name or role, date]] | Review reminder set for | [[YYYY-MM-DD]] |
Part D — Reviews and renewal history
The risk owner reviews the accepted risk every quarter with the rest of the register (RM-09). At the review date the acceptance is renewed — a new decision, on a fresh score, at the band's level — or it ends. An acceptance past its review date is counted in RMM-03, acceptances past review (target: zero).
Date | Type | Score and band now | Conditions met? | Outcome | By |
|---|---|---|---|---|---|
[[YYYY-MM-DD]] | [[Quarterly review / Renewal]] | [[I × L = n, band]] | [[Yes / No — which]] | [[Continue / Renewed to YYYY-MM-DD / Reassess / Close]] | [[Role]] |
[[YYYY-MM-DD]] | [[Quarterly review / Renewal]] | [[I × L = n, band]] | [[Yes / No — which]] | [[Continue / Renewed to YYYY-MM-DD / Reassess / Close]] | [[Role]] |
Part E — Closure
Completed when the acceptance ends. Head of Information Security confirms the change before the register entry is updated.
E1 Closure | |||
Why it is closing | [[Risk reduced / activity stopped / risk transferred / asset retired / refused at renewal]] | ||
New residual score and band | [[I × L = n, band]] | Register entry updated | [[YYYY-MM-DD]] |
Evidence | [[Reference, date]] | Verified by | [[Role, signature, date]] |
Worked example — a completed acceptance
This is the one accepted risk in the example register used across the Information Security Risk Management pack, for a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders: R-12, customer data on an unencrypted laptop at the smaller warehouse site is lost or stolen. Its category, customer and personal data, is Cautious in the example Cyber Risk Appetite Statement Template. The organisation, roles and dates are fictional.
Guidance — delete before approval
Note why the approval stops at the band: the residual score is 4, Medium, and Cautious allows up to Medium, so the risk is within appetite and risk owner and Head of Information Security may accept it. Had the same risk scored High, it would have been outside appetite, within tolerance, and the approval required would have been: accountable executive and Head of Information Security, and executive management as well.
Delete this worked example from your adopted form.
Part A — The risk
Completed by the risk owner with the assessor, from the Information Security Risk Register entry. Every field here should match the register.
A1 Identification — EXAMPLE | |||
Acceptance reference given by information security; used in the register | RA-01 | Register reference the risk accepted | R-12 |
Category | RC-02 Customer and personal data | Assessor | Head of Information Security |
Risk owner (RM-02) the executive accountable for what it would hurt | Head of Logistics | ||
Date raised | 2026-06-15 | New or renewal? if renewal, see Part D | New |
Risk title as in the register | Customer data on an unencrypted laptop at the smaller warehouse site is lost or stolen | ||
A2 The scenario (RM-01) — EXAMPLE | |||
Threat what could happen | Theft or loss of a laptop | ||
Weakness what it would use | Six older laptops at the smaller warehouse site are not encrypted: encrypting the old models before their March 2027 refresh would cost more than the risk | ||
Asset or service what would be hurt | Customer delivery lists held on those laptops | ||
Consequence in business terms | Business customers' contact names and delivery addresses exposed; a data incident to assess for notification | ||
A3 Score (RM-03) — EXAMPLE | |||
Impact 1 Minor · 2 Moderate · 3 Major · 4 Severe | 2 Moderate | Reason | Delivery lists only: no payment or account data, and only the customers served from one site. |
Likelihood next 12 months: 1 Unlikely · 2 Possible · 3 Likely · 4 Almost certain | 2 Possible | Reason | Laptops are lost or stolen from sites like this every year in the sector; nothing on these laptops makes the data unreadable. |
Inherent score before existing controls | 2 × 2 = 4 | Residual score after existing controls | 2 × 2 = 4 |
Residual band Low 1–3 · Medium 4–6 · High 8–9 · Critical 12–16 | Medium | Existing controls and what they change | Sign-in password on each laptop; the site is locked out of hours. Neither changes the score: a lost laptop's disk can be read without the password, so inherent and residual are the same. |
A4 Position against appetite (RM-05) — EXAMPLE | |||
Category's appetite level Averse: appetite Low, tolerance Medium · Cautious: appetite Medium, tolerance High · Open: appetite High, tolerance High | Cautious: appetite Medium, tolerance High | ||
Position from the residual band and the level | Within appetite | ||
Part B — Why accept, and on what terms
Completed by the risk owner. Acceptance is a treatment choice like the others (ISO/IEC 27001 Clause 6.1.3); this part shows the others were weighed.
B1 Other options considered — EXAMPLE | |||
Reduce change the likelihood or the impact with controls. | Encrypt the six laptops now — rejected: encrypting the old models would cost more than the risk, and they are replaced in the March 2027 refresh. | ||
Avoid stop the activity that creates the risk. | Take customer data off the laptops — partly adopted as a condition: no customer data exports. The site needs its delivery lists to dispatch orders. | ||
Transfer share the impact with a third party, for example by insurance or contract | Rely on insurance — not chosen: it would meet some costs of a breach but not the harm to customers or the duty to assess and notify. | ||
B2 Reason for accepting — EXAMPLE | |||
Why accepting is the right decision cost, benefit, timing | The six laptops concerned are replaced in the March 2027 refresh; encrypting the old models would cost more than the risk, and they hold customer delivery lists only. | ||
Is a policy or standard rule not met? if yes, stop: it is a P02 exception, not an acceptance | None needed — no rule in a policy or standard is being breached; if one were, this would be a P02 exception instead. | ||
B3 Conditions and early end — EXAMPLE | |||
Conditions what must stay true while the risk is accepted | Laptops stay on site, are locked away overnight and are not used for customer data exports. | ||
Who checks the conditions, and how often | Head of Logistics, at each quarterly review (RM-09): confirms the laptops are on site and locked away, and that no exports were made. | ||
What ends or reopens the acceptance besides the review date | Closed when the March 2027 refresh replaces the laptops. Reassessed within 10 working days (RM-10) if a laptop is lost or a condition is broken. | ||
Part C — Approval
The residual band sets who must sign and how long before the acceptance must be reviewed (RM-04, RM-08). Outside appetite, executive management signs as well as the band's approvers; outside tolerance, the band's approvers only recommend and the board decides.
Residual band | Scores | Who must sign | Review within |
|---|---|---|---|
Low | 1–3 | Risk owner | 12 months |
Medium | 4–6 | Risk owner and Head of Information Security | 12 months |
High | 8–9 | Accountable executive and Head of Information Security | 6 months |
Critical | 12–16 | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | 3 months |
Who may accept, by band and position. Executive management means a decision of executive management [[e.g. Executive Committee]], recorded with its reference; the board means [[e.g. Board, or its Audit & Risk Committee]]. A dash marks a combination the appetite levels cannot produce.
Residual band | Within appetite | Outside appetite, within tolerance | Outside tolerance |
|---|---|---|---|
Low | Risk owner | — | — |
Medium | Risk owner and Head of Information Security | Risk owner and Head of Information Security, and executive management as well | — |
High | Accountable executive and Head of Information Security | Accountable executive and Head of Information Security, and executive management as well | Accountable executive and Head of Information Security recommend; only the board or its equivalent may accept |
Critical | — | — | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management recommend; only the board or its equivalent may accept |
C1 Decision — EXAMPLE | |||
Approval required the band's approvers, and above them by position (table above) | Risk owner and Head of Information Security | ||
Decision | Accepted with conditions | ||
Accepted from | 2026-06-15 | Review by acceptance date + the band's review interval | 2027-06-15 |
C2 Signatures — EXAMPLE | |||
Band approver 1 | Head of Logistics (risk owner) | Signature and date | Signed, 2026-06-15 |
Band approver 2 Medium and High bands | Head of Information Security | Signature and date | Signed, 2026-06-15 |
High band accountable executive, if not the risk owner | Not required (Medium band) | Signature and date | — |
Outside appetite or tolerance, or Critical executive management or board decision | Not required (within appetite) | Minute or decision reference | — |
Recorded in the register by | Head of Information Security, 2026-06-15 | Review reminder set for | 2027-06-15; quarterly with the owner's review |
Part D — Reviews and renewal history
The risk owner reviews the accepted risk every quarter with the rest of the register (RM-09). At the review date the acceptance is renewed — a new decision, on a fresh score, at the band's level — or it ends. An acceptance past its review date is counted in RMM-03, acceptances past review (target: zero).
Date | Type | Score and band now | Conditions met? | Outcome | By |
|---|---|---|---|---|---|
2026-09-01 | Quarterly review (RM-09) | 2 × 2 = 4, Medium | Yes | Continue to review date | Head of Logistics |
The 2026-09-01 row is the owner's last quarterly review before the example's "as at" date, 2026-09-30; replace it with your own review dates. (EXAMPLE)
Part E — Closure
Completed when the acceptance ends. Head of Information Security confirms the change before the register entry is updated.
Not yet used: the acceptance is expected to close when the laptops are replaced in the March 2027 refresh, before its review date. (EXAMPLE)
Related documents
Document | Relationship |
|---|---|
Risk Assessment Methodology & Scoring Model | The rules this form applies: scale, bands, who may accept and review intervals (RM-01 to RM-12) |
Risk Identification & Assessment Operating Procedure | The procedure that governs this form |
Cyber Risk Appetite Statement Template | Sets each category's appetite and tolerance: the position in A4 |
Information Security Risk Register | Where each acceptance is recorded, with its approval and review dates; the inventory of accepted risks |
Risk Treatment Plan | Where the other treatment options are planned when acceptance is refused |
Risk Reporting Dashboard | Reports RMM-03, acceptances past review |
Security Exception & Waiver Standard | P02 pack: the route when a rule in a policy or standard is not met |
Adapting this template
Guidance — delete before approval
Small organisation: keep Parts A to C; Parts D and E may live in the register. Where the risk owner is also the head of information security — common when one person runs IT and security — name who signs as second approver instead, so nobody approves their own acceptance alone.
Regulated entity (NIS2, DORA, GDPR): NIS2 Article 21(1) expects measures proportionate to the risk; an acceptance shows why a residual risk was judged proportionate to keep. For DORA financial entities, RTS 2024/1774 Article 3(d) requires the residual risks to be identified, the roles that may accept those above the tolerance level to be assigned, an inventory of accepted residual risks with the reason for each, and a review at least once a year; this form, listed in the register, is that inventory, and no review interval here exceeds 12 months. DORA Articles 6(1) and 8 place it within the documented ICT risk-management framework. Where personal data is involved, GDPR Article 32 requires security appropriate to the risk to people: record in A2 the consequence for the people whose data it is, not only for the organisation.
IT run by a service provider: a risk in a service the provider runs is still yours to accept. The provider may supply the facts for Part A and the costs in B1, but the risk owner and approvers are your own. Where the provider asks to deviate from a contract or standard, that is an exception, not an acceptance.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Clause 6.1.3 — Information security risk treatment | Part B: acceptance chosen among the treatment options, and approved by the risk owner (Part C) |
ISO/IEC 27001:2022 | Clause 8.3 — Information security risk treatment | Parts C to E: the acceptance recorded, reviewed and closed |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | Whole form: the risk response chosen, tracked through reviews and communicated |
NIST CSF 2.0 | GV.RM-06 — “A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated” | Parts A and C: the standard scoring method, and approval set by band |
DORA — Delegated Regulation (EU) 2024/1774 | Article 3(d) — identifying residual risks, assigning who may accept those above tolerance, an inventory of accepted residual risks with justification, and their review at least once a year | Part C: who may accept above tolerance; Part B: the justification; Part D: review at least yearly |
DORA — Regulation (EU) 2022/2554 | Article 6(1) — a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system | Whole form: acceptance as part of the documented ICT risk-management framework |
Definitions
Term | Meaning in this form |
|---|---|
Acceptance | A recorded decision, approved at the right level, to keep a residual risk rather than treat it further, until a stated review date. |
Appetite | The highest residual band a category's risks may reach and be accepted without escalation, set in the appetite statement. |
Band | The range the residual score falls in: Low (1–3), Medium (4–6), High (8–9), Critical (12–16). It sets who must sign and the review interval. |
Exception | An approved, time-limited decision that a rule in a policy or standard need not be met, handled under the Security Exception & Waiver Standard. |
Position | Where the risk stands against its category's appetite: Within appetite; Outside appetite, within tolerance; Outside tolerance. |
Residual score | Impact × likelihood after existing controls, each rated 1 to 4 (RM-03). |
Review date | The date by which the acceptance must be renewed or ended: the acceptance date plus the band's interval, or earlier. |
Risk owner | The executive accountable for the service or asset the risk would hurt (RM-02). |
Tolerance | The highest residual band a category's risks may reach for a time while a plan brings them back; above it, only the board may accept. |