A cyber risk register usually looks healthy on the day it is presented to the risk committee and then decays: owners leave, review dates pass, risk acceptances outlive their expiry and the same top ten risks are copied into the next quarter's report unchanged. This health check tests whether the register is still a living management tool, with nine KPIs, each with a formula, a data source type, thresholds and an owner, plus a findings log and a remediation map. It is run quarterly by the cyber risk lead, checked by the second line risk function or internal audit, and signed off by the CISO and the chief risk officer or equivalent. It suits any organisation that keeps a cyber or technology risk register feeding enterprise risk management.
What this health check covers
The Risk Register Template gives the structure of the register: fields, scoring and treatment columns. The Risk Management Guide explains the programme around it. This page does not repeat either. It measures the register's condition over time: whether every risk has an owner, whether reviews and treatments happen on schedule, whether acceptances expire as they should, whether key risk indicators feed it and whether it reflects the organisation's stated risk appetite.
NIST IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management, published December 2025, describes cybersecurity risk registers as the means of recording cyber risk for integration into the enterprise risk portfolio. NIST CSF 2.0 places the same expectations in GV.RM-06 (a standardised method for calculating, documenting, categorising and prioritising risk) and ID.RA-06 (risk responses chosen, prioritised, planned, tracked and communicated). If you searched for a cyber risk register audit, risk management KPIs or key risk indicators for cyber, this is the run sheet.
Key takeaways
- Ownership is the first KPI: a risk without a named, current owner is not managed, whatever its score.
- Dates expose decay: missed reviews, overdue treatments and expired acceptances are the earliest signs that the register has become a report rather than a tool.
- Link risks to evidence: risks tied to specific controls and to key risk indicators can be re-scored from data; the rest are re-scored from memory.
- Appetite needs a test: count the risks above appetite that have no decision recorded; that number is what the board most needs to see.
- Thresholds are recommendations: the bands are NHI Mgmt Group starting points; set your own with the risk committee and record the rationale.
How to use this template
Copy the metrics table and the findings log into your own tracker, or add them as a tab in the register itself. Take a dated snapshot of the register at quarter end, calculate each KPI from the snapshot, score it against the green, amber and red thresholds, and log every amber or red result as a finding with an owner and a due date. Keep the snapshots: comparing two quarters shows which risks never moved, which is often the most useful finding.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| KRI threshold breaches and escalations (R5) | Monthly | Cyber risk analyst | Cyber risk lead | KRI dashboard extract, escalation records |
| Expiring risk acceptances (R4) | Monthly | Cyber risk lead | CISO | Acceptance list with expiry dates, renewal or closure decisions |
| Full KPI run (R1 to R9) | Quarterly | Cyber risk lead | CISO and [chief risk officer] | Register snapshot, KPI workbook, findings log, sign-off record |
| Risk appetite alignment (R8) reported to committee | Quarterly | CISO | [Risk committee] | Committee paper, minutes with decisions |
| Independent re-performance | Yearly | Internal audit or second line risk | Audit committee | Re-performed samples, variance notes |
Metrics
Scope is open cyber and technology risks on the register at quarter end. NHI Mgmt Group recommended thresholds; adjust to your risk appetite.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| R1 | Risks with owner | Open risks with a named owner who is a current employee at the agreed level of authority / open risks | Register snapshot joined to HR or directory record | 100% | 95% to below 100% | Below 95% |
| R2 | Risks reviewed in period | Open risks whose owner recorded a review by the due date set by their rating / open risks due for review in the period | Register review history or audit trail | ≥ 90% | 75% to below 90% | Below 75% |
| R3 | Overdue treatment | Treatment actions past their due date and not closed / open treatment actions | Treatment plan or action tracker | ≤ 10% | Above 10% to 25% | Above 25% |
| R4 | Risk acceptance expiry | Accepted risks past their acceptance expiry date with no renewal decision / accepted risks | Risk acceptance and exception register | 0% | Above 0% to 5% | Above 5%, or any high rated risk expired |
| R5 | KRI breach count | KRI threshold breaches in the period not escalated to the risk owner within the agreed time (count); alongside total breaches | KRI dashboard history; escalation records | 0 unescalated | 1 to 2 unescalated | 3 or more unescalated |
| R6 | Control linkage coverage | Open risks linked to at least one named control with a recorded effectiveness result / open risks | Register control mapping; control testing records | ≥ 90% | 70% to below 90% | Below 70% |
| R7 | Quantified risk share | Top risks (as defined for board reporting) with a documented frequency and loss estimate range / top risks | Register quantification fields; analysis worksheets | ≥ 80% | 40% to below 80% | Below 40% |
| R8 | Risk appetite breaches | Open risks rated above the stated appetite or tolerance with no recorded treatment or acceptance decision (count) | Register ratings; approved risk appetite statement; decision log | 0 | 1 to 2, each under 30 days old | 3 or more, or any 30 days or older |
| R9 | Register age | Median days since last substantive update (rating, treatment or description) across open risks | Register audit trail | ≤ 90 days | Above 90 to 180 days | Above 180 days |
Notes on the formulas
- R1 tests the owner, not the field: join owners to the HR or directory record. A leaver or a team mailbox as owner counts as no owner.
- R2 uses rating-based due dates: for example high risks monthly, medium quarterly, low half-yearly. Define the schedule in the Risk Management Policy Template and keep it stable so the KPI is comparable.
- R4 links to the exception process: acceptances must carry an approver, a rationale and an expiry date. See the Security Exceptions and Risk Acceptance Guide.
- R5 measures the response to breaches: a high breach count can be healthy if every breach was escalated and acted on; the unescalated count is the failure. The Key Risk Indicators for Cyber Risk Guide covers KRI design.
- R7 does not require a specific method: any documented range of frequency and loss counts. The Cyber Risk Quantification Guide and the FAIR Model and Open FAIR Standard Guide describe common approaches.
- R6 needs a current result: a link to a control counts only when that control has an effectiveness result from testing, assurance work or monitoring in the last 12 months. A link to a control that failed its last test should raise the residual rating, not lower it.
- R8 counts missing decisions, not high ratings: a risk above appetite with an approved treatment plan or a time-bound acceptance is managed. The failure is a risk above appetite that nobody with authority has decided on.
- R9 ignores cosmetic edits: count only changes to rating, treatment or description, not reformatting.
How to collect the data
- Take a dated snapshot: export the full register at quarter end with history or audit trail, so every KPI is calculated from the same data.
- Join owners to HR: match risk owners and treatment owners against the HR record or directory to find leavers and unowned items (R1).
- Export treatment actions: from the treatment plan or action tracker with due dates, status and closure evidence (R3).
- Export the acceptance register: accepted risks and exceptions with approver, rationale and expiry (R4).
- Pull KRI history: values, thresholds, breaches and escalation timestamps for the period (R5).
- Join control results: link each risk's controls to the latest control testing or assurance results (R6).
- Compare with appetite: apply the approved Cyber Risk Appetite Statement Template thresholds to current ratings and check the decision log (R8).
- Sample and verify: trace five risks from register entry to owner interview and evidence. Record variances, especially ratings that the owner cannot explain.
Red flags that need action now
- A high rated risk owned by someone who has left the organisation (R1).
- Risk acceptances for high rated risks that expired without a renewal decision (R4).
- KRIs in breach for more than one period with no escalation record (R5).
- Risks above appetite reported to the committee with no recorded decision, quarter after quarter (R8).
- The same top risks with identical ratings and wording for three or more quarters (R9).
- Treatment actions repeatedly re-dated with no change in scope or funding (R3).
- Risk ratings that do not change after a significant incident, audit finding or control failure in the same area (R6).
Findings log
| Finding ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-RISK-01 | [Number] open risks with no current owner | R1 | [High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-RISK-02 | [Number] expired risk acceptances | R4 | [Severity] | [Role] | [Date] | [Status] |
| HC-RISK-03 | [Number] risks above appetite with no decision | R8 | [Severity] | [Role] | [Date] | [Status] |
| HC-RISK-04 | [KRI] breached without escalation in [period] | R5 | [Severity] | [Role] | [Date] | [Status] |
| HC-RISK-05 | [Finding] | [Metric] | [Severity] | [Role] | [Date] | [Status] |
Findings about the register itself go here, not into the register as new risks. Risk accepted findings carry an expiry date and the approver's name and are re-opened at the next quarterly run.
Remediation map
| Finding type | Metrics | Where the fix is explained |
|---|---|---|
| Missing owners or review cadence | R1, R2, R9 | Risk Management Policy Template; Risk Register Template |
| Overdue treatment | R3 | Risk Treatment Plan Template |
| Expired or open-ended acceptances | R4 | Security Exceptions and Risk Acceptance Guide |
| KRIs missing or not escalated | R5 | Key Risk Indicators for Cyber Risk Guide |
| Risks not tied to controls | R6 | NIST SP 800-30 Risk Assessment Guide |
| No quantification | R7 | Cyber Risk Quantification Guide; Cyber Risk Quantification Worksheet Template |
| Appetite not applied | R8 | Risk Appetite and Tolerance for Cyber Guide |
Related guides
- Risk Management Guide: the programme this health check tests.
- Risk Register Template: the register structure the KPIs are calculated from.
- NIST IR 8286 Cybersecurity and ERM Integration Guide: how the cyber register rolls up to enterprise risk.
- Board Cyber Risk Reporting Guide: presenting the results to the board.
- Cyber Risk Appetite Statement Template: the appetite thresholds R8 tests against.
References
Framework anchors for the metrics: NIST CSF 2.0 GV.RM-02 (risk appetite and tolerance), GV.RM-03 (cyber risk in enterprise risk management), GV.RM-06 (standardised risk method), GV.OV-03 (risk management performance evaluated), ID.RA-05, ID.RA-06 and ID.RA-07 (changes and exceptions tracked); NIST SP 800-53 Rev. 5 PM-9 (Risk Management Strategy), PM-28 (Risk Framing), RA-3 (Risk Assessment), RA-7 (Risk Response) and CA-5 (Plan of Action and Milestones).
- NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
- NIST: CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework
Related NHI Mgmt Group resources: Risk Management Guide, Risk Register Template, Key Risk Indicators for Cyber Risk Guide, Security Exceptions and Risk Acceptance Guide.