Most cyber risk registers are lists of worries, such as "ransomware" or "insider threat", with a colour next to them and no owner who can say what would change the colour. A usable register records each risk as a specific scenario, scores it on shared scales, compares it with an agreed appetite, and tracks a dated treatment plan to a residual rating a named person has accepted. This template provides the statement format, register columns, scales, heat map, appetite thresholds, treatment, escalation and review rules, and worked rows including a service account risk and an AI agent risk. It aligns with ISO/IEC 27005:2022, ISO 31000:2018, NIST SP 800-30 Rev. 1, the NIST IR 8286 series and NIST CSF 2.0 GV.RM, and is for CISOs, risk managers and GRC teams.
How to use this template
- Replace text in square brackets, such as [Organisation], [Risk committee] and [£1m], with your own terms and values. "Must" is mandatory; "should" may be skipped with a recorded reason.
- Approve the scales (section 7) and thresholds (section 9) once at [Risk committee]. Teams must not adjust them, or scores stop being comparable.
- Use the fields in section 6 as columns in Excel, another spreadsheet or your GRC tool, one row per risk. Section 13 shows completed rows.
- Keep this register consistent with the enterprise risk register. NIST IR 8286 Rev. 1 describes cybersecurity risk registers (CSRRs) rolling up from system and organisation level into an enterprise risk register (ERR).
1. Purpose
This document sets out how [Organisation] records, assesses, treats, escalates and reviews cyber security risks, so that every risk has a clear statement, a named owner, consistent ratings, a treatment decision taken at the right level and a review date, and cyber risk stays within the appetite set by [Board].
2. Scope
The register covers risks to the confidentiality, integrity and availability of [Organisation]'s information, systems and services, including human and non-human identities (service accounts, API keys, certificates, AI agents), applications, infrastructure, cloud and SaaS, suppliers with access, and AI systems and their tools. Risks rated High or Critical are also reported in the enterprise risk register maintained by [Head of Enterprise Risk].
3. Roles and responsibilities
- [Board or Risk committee]: approves appetite and tolerance, reviews and accepts Critical risks.
- [CISO]: owns the method and register, challenges ratings and reports to [Risk committee].
- Risk owner: a named senior manager with authority over the budget needed to treat the risk; approves the treatment plan and accepts residual risk.
- Control and action owners: operate controls and report their effectiveness; deliver treatment actions by their target dates.
- [Second line risk or internal audit]: independently reviews ratings, overdue actions and expired acceptances.
ISO/IEC 27001:2022 clause 6.1.3 requires risk owners to approve the treatment plan and accept residual risk, so a risk owner must be a person, not a team.
4. Definitions
- Risk: NIST SP 800-30 Rev. 1 describes risk as "a measure of the extent to which an entity is threatened by a potential circumstance or event", typically a function of impact and likelihood.
- Inherent risk: the rating before recorded controls are considered.
- Residual risk: the rating after current controls, assessed on evidence that the controls operate. Target risk is the rating expected once treatment is complete.
- Risk appetite: "the amount and type of risk that an organization is willing to take in meeting its objectives" (NIST IR 8286 Rev. 1).
- Risk tolerance: "the organization or stakeholders' readiness to bear the remaining risk after responding to or considering the risk" (NIST IR 8286 Rev. 1). Here, tolerance thresholds are the measurable limits in section 9.
5. Risk statement format
Every risk must be written as a cause, an event and a consequence. NIST IR 8286 Rev. 1 says a complete scenario includes "a threat source, a threat event, a vulnerability that the threat source might exploit, any enterprise assets that may be impacted by the threat, and the resulting harmful impact".
Use this pattern: Because of [cause: vulnerability or condition], [threat source] may [event] affecting [asset or process], resulting in [consequence for the organisation].
| Weak statement | Usable statement |
|---|---|
| Ransomware | Because the VPN appliance is two critical patches behind and accepts password-only logins, a ransomware group may gain access and encrypt the ERP servers, stopping order processing for [5] days. |
| Service accounts | Because the backup service account is a Domain Admin whose password, unchanged since [2019], sits in a script on a file share, any domain user may retrieve it and take over the domain and backups. |
| AI risk | Because the support AI agent reads untrusted customer messages and can call refund and CRM tools, an attacker may use prompt injection to obtain refunds or other customers' records, causing loss and a notifiable breach. |
One risk equals one scenario. If the treatment or owner would differ, split the risk; group related risks with the category field.
6. Register columns
These fields extend the NIST IR 8286 Rev. 1 CSRR template (ID, priority, description, category, likelihood, impact, exposure rating, response type, cost and description, owner, status) with asset, threat, vulnerability and control fields. Mandatory fields are marked *.
| Field | What to enter | Example (risk R-014) |
|---|---|---|
| Risk ID * | Unique, never reused | R-014 |
| Risk category * | From [Organisation]'s fixed taxonomy | Identity and access (non-human) |
| Risk statement * | Cause, event, consequence (section 5) | See section 5, service accounts |
| Asset or process * | System, data set or process affected | Active Directory domain, backup platform |
| Threat | Source and event | Attacker or insider retrieves and uses the credential |
| Vulnerability | Weakness that makes the event possible | Excess privilege, non-expiring plain-text password |
| Risk owner * | Named person (section 3) | [Head of Infrastructure] |
| Inherent likelihood, impact, rating * | Scores from section 7, rating from section 8 | L4, I5, 20 Critical |
| Existing controls | Controls in place, with control owner and evidence | Account in tiered admin model; logon alerts in SIEM (tested [date]) |
| Residual likelihood, impact, rating * | Scores after existing controls | L3, I5, 15 High |
| Within appetite? * | Yes or no, against section 9 | No |
| Treatment option * | Avoid, mitigate, share or transfer, accept (section 10) | Mitigate |
| Treatment plan, cost, target rating | Actions, action owners, cost, expected rating | Replace with gMSA; remove Domain Admin; vault and rotate; [£8k]; L2 I4 = 8 |
| Target date * | Date treatment complete | [31 Mar 2027] |
| Status and acceptance * | Open, in treatment, accepted (who, date, expiry), closed | In treatment |
| Key risk indicator | Measure that shows the risk moving | Service accounts in privileged groups |
| Last and next review date * | Per section 12 | [15 Jan 2027]; [15 Feb 2027] |
7. Likelihood and impact scales
NIST SP 800-30 Rev. 1 uses five qualitative levels, "very low, low, moderate, high, very high", and allows semi-quantitative scales such as 1 to 10 or 0 to 100. This template uses 1 to 5 on both axes. Adjust thresholds to [Organisation]'s size; keep the number of levels.
| Score | Likelihood | Probability in the next 12 months | Indicators |
|---|---|---|---|
| 5 | Almost certain | > [80]% | Active in the sector; public exploit; reachable from the internet |
| 4 | Likely | [50 to 80]% | Happened here or to peers in [2] years |
| 3 | Possible | [20 to 50]% | Known technique; needs some access or skill |
| 2 | Unlikely | [5 to 20]% | Several controls must fail |
| 1 | Rare | < [5]% | Theoretical |
| Score | Impact | Financial | Operations | Data and legal | Reputation and safety |
|---|---|---|---|---|---|
| 5 | Severe | > [£10m] | Critical services down > [5 days] | Large breach of sensitive data; enforcement | Sustained national coverage; serious harm |
| 4 | Major | [£1m to £10m] | Critical service down [1 to 5 days] | Notifiable breach; regulator investigation | National coverage |
| 3 | Moderate | [£100k to £1m] | Degraded > [1 day] | Contract or SLA breach | Trade or social media |
| 2 | Minor | [£10k to £100k] | Absorbed within [1 day] | Internal policy breach | Local |
| 1 | Minimal | < [£10k] | None noticeable | None | None |
Score impact on the highest category affected, not the average, for the realistic worst case of the scenario as written.
8. Risk rating and heat map
Rating = likelihood × impact, from 1 to 25. Bands: Low 1 to 4, Medium 5 to 9, High 10 to 16, Critical 20 to 25.
| Likelihood \ Impact | 1 Minimal | 2 Minor | 3 Moderate | 4 Major | 5 Severe |
|---|---|---|---|---|---|
| 5 Almost certain | 5 Medium | 10 High | 15 High | 20 Critical | 25 Critical |
| 4 Likely | 4 Low | 8 Medium | 12 High | 16 High | 20 Critical |
| 3 Possible | 3 Low | 6 Medium | 9 Medium | 12 High | 15 High |
| 2 Unlikely | 2 Low | 4 Low | 6 Medium | 8 Medium | 10 High |
| 1 Rare | 1 Low | 2 Low | 3 Low | 4 Low | 5 Medium |
In reports, plot each risk twice, inherent and residual. A risk whose residual position equals its inherent position has no effective controls, whatever the controls column says.
9. Risk appetite and tolerance thresholds
NIST CSF 2.0 GV.RM-02 expects "Risk appetite and risk tolerance statements are established, communicated, and maintained". [Organisation]'s appetite by rating band:
| Residual band | Position | Who may accept | Treatment plan due | Maximum acceptance period |
|---|---|---|---|---|
| Critical (20 to 25) | Outside appetite | [Risk committee] only, in exceptional cases | [10 working days] | [3 months] |
| High (10 to 16) | Outside tolerance unless accepted | Executive risk owner with [CISO] agreement | [30 days] | [6 months] |
| Medium (5 to 9) | Within tolerance | Risk owner | [90 days] or accept | [12 months] |
| Low (1 to 4) | Within appetite | Risk owner | Not required | Until next review |
Category statements to adapt:
- Personal data: no appetite for risks that could cause a notifiable breach of special category data; no residual risk above Medium in this category.
- Identity: low appetite for unowned or over-privileged non-human identities; at least [98]% of service accounts, API keys and AI agent identities have a named owner, and no production static credential is older than [365] days.
- AI: no appetite for AI agents that can take irreversible financial or production actions without human approval.
A breached tolerance threshold creates or re-rates a register entry immediately.
10. Treatment options and treatment plans
NIST defines risk response as accepting, avoiding, mitigating, sharing or transferring risk.
| Option | Use when | Register requirement |
|---|---|---|
| Avoid | The activity is not worth the risk | Record what stopped or changed; close once verified |
| Mitigate (reduce) | Controls can bring the risk within tolerance at reasonable cost | Actions, owners, dates, cost and target rating |
| Share or transfer | A third party or insurer can bear part of the impact | Contract or policy reference, limits and exclusions; residual still rated, as reputational damage is not transferred |
| Accept | Within tolerance, or treatment costs more than the exposure | Accepted at the section 9 level, with expiry and conditions |
Each treatment plan must list actions with an owner, target date, cost and the control each action adds or improves. Under ISO/IEC 27001:2022, map actions to Annex A controls and update the Statement of Applicability (clause 6.1.3).
11. Escalation rules
- A new or re-rated Critical risk must be reported to [CISO] within [1 working day] and to [Risk committee chair] within [5 working days].
- A High risk without an approved plan after [30 days] is escalated to the owner's line manager and the next [Risk committee].
- A treatment action overdue by [30 days] goes up one management level, and by [90 days] to [Risk committee]. An expired acceptance reverts the risk to open and outside tolerance.
- An incident triggers re-rating of the linked entry within [10 working days] of containment, or a new entry if none matches.
- A departing risk owner must be replaced within [30 days]; until then the risk is reported as unowned.
12. Review cadence
| Activity | Frequency | Responsible |
|---|---|---|
| Critical risks reviewed | [Monthly] | Risk owner and [CISO] |
| High risks reviewed | [Quarterly] | Risk owner |
| Medium and Low risks reviewed | [Six-monthly] and [annually] | Risk owner |
| Summary to [Risk committee] | [Quarterly] | [CISO] |
| Scales, appetite and full reassessment | [Annually] | [CISO], [Head of Enterprise Risk] |
| Event-driven review | After incidents, major change, new threat intelligence or regulation | Risk owner |
| Independent review | [Annually] | [Internal audit] |
NIST SP 800-30 Rev. 1 treats maintaining the assessment as a step in its own right.
13. Example register entries
| ID | Risk (short form) | Owner | Inherent | Key existing controls | Residual | Treatment and target | Status |
|---|---|---|---|---|---|---|---|
| R-014 | Over-privileged backup service account with static password in a script enables domain takeover and backup deletion | [Head of Infrastructure] | L4 I5 = 20 Critical | Tiered admin model; SIEM alert on interactive logon | L3 I5 = 15 High | Mitigate: gMSA, remove Domain Admin, vault and rotate; [31 Mar 2027] | In treatment |
| R-021 | Prompt injection via customer messages makes support AI agent issue refunds or disclose other customers' data (OWASP LLM01:2025, LLM06:2025) | [Head of Customer Operations] | L4 I4 = 16 High | Refunds over [£100] need human approval; CRM tool scoped to the requesting customer; tool calls logged | L2 I4 = 8 Medium | Accept residual; add output filtering and red team test by [30 Jun 2027] | Accepted to [30 Jun 2027] |
| R-003 | Unpatched internet-facing VPN appliance with password-only access enables ransomware and five-day outage | [CIO] | L4 I5 = 20 Critical | EDR on servers; offline backups tested [quarterly] | L3 I5 = 15 High | Mitigate: patch within [7] days, phishing-resistant MFA, replace appliance; [28 Feb 2027] | In treatment |
Registers usually miss risks like R-014 and R-021 because service accounts and API keys are rarely listed as assets. See the Service Account Security Guide and the NHI Ownership Guide. Agent risks combine model behaviour with the credentials the agent holds: the PocketOS database deletion involved an AI coding agent using an over-privileged token. See the Agentic AI Security Guide.
14. Source references
- ISO: ISO/IEC 27005:2022 Information security, cybersecurity and privacy protection, Guidance on managing information security risks
- ISO: ISO 31000:2018 Risk management, Guidelines
- NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
- NIST: IR 8286 Rev. 1 Integrating Cybersecurity and Enterprise Risk Management (ERM)
- CSF Tools: NIST Cybersecurity Framework 2.0, GV.RM Risk Management Strategy
- NIST CSRC Glossary: Risk response
- OWASP: Non-Human Identities Top 10 2025
- OWASP GenAI Security Project: Top 10 for LLM Applications 2025
Implementation guidance
- Agree the method first: approve sections 7 to 9 before populating; changing scales later forces a full rescore.
- Seed from evidence: start with incident history, audit and penetration test findings, vulnerability and identity posture data and threat intelligence, then run workshops to add context and owners.
- Calibrate and pilot: have three assessors score the same five risks independently; differences of more than one level mean the scale wording needs tightening. Pilot in one business unit for a quarter.
- Link to evidence: tie each residual rating to control evidence and a key risk indicator, so ratings move with data, not opinion.
- Quantify the top risks: estimate loss ranges for the highest residual risks so treatment spend can be compared with exposure. See the Cyber Risk Quantification Guide.
Small organisations can run a spreadsheet with mandatory fields only, reviewed quarterly by the leadership team. Large organisations should use a GRC platform linked to the asset inventory, control library and ticketing. See the GRC Platform Buyer's Guide.
| Template section | ISO/IEC 27001:2022 | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 5 to 8 Statements, scales, rating | 6.1.2, 8.2 | ID.RA-04, ID.RA-05, GV.RM-06 | RA-3 |
| 9 Appetite and tolerance | 6.1.2 (risk acceptance criteria) | GV.RM-02 | PM-9 |
| 10 and 11 Treatment and escalation | 6.1.3, 8.3 | ID.RA-06, GV.RM-04 | RA-7 |
| 12 Review | 8.2, 9.3 | GV.RM-03, GV.OV | PM-9 |
Track five measures: risks with a current named owner; High and Critical risks with an approved plan; overdue actions; expired acceptances; and risks reviewed on time. See the Control Mapping Guide.
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Cyber Risk Quantification Guide · ISO 27001 Certification Guide · Vulnerability Management Guide · Third-Party Access Guide