Cyber Risk Register: What It Should Include
Short answer: A cyber risk register is a living document that records every identified information security risk, its score, its assigned owner, the treatment decision, and the current status of that treatment. At minimum it needs: risk ID, asset, threat/vulnerability description, likelihood score, impact score, risk score, existing controls, residual risk, treatment decision, owner, deadline, and review date.
TL;DR: A risk register is only as useful as it is current. Build it with all the required fields, assign a named owner to each risk, and run a formal review cycle every quarter minimum. A register nobody updates is worse than no register — it creates false assurance.
Key Takeaways - A risk register is not a vulnerability list — it captures business decisions about risk, not just technical findings. - Residual risk (risk remaining after controls) is the number that matters to leadership, not the inherent risk score. - Every risk entry needs a named owner who is accountable for the treatment decision — shared ownership means no ownership. - Treatment decisions must be documented with a rationale, especially for accepted risks — regulators and auditors want to see that risk acceptance was deliberate. - The IBM 2024 Cost of a Data Breach Report found the average breach cost USD 4.88 million globally — a well-maintained risk register is evidence of due diligence, not just a compliance artifact (IBM).
What a risk register is — and what it is not
A risk register is a decision log as much as a data store. It records: - What risks were identified (and when, and by whom) - How each risk was scored - What the organization decided to do about each risk - Who is responsible for that decision and its execution - Whether the treatment is on track
What it is not: - A vulnerability report (a Nessus scan output is an input to the risk register, not the register itself) - A to-do list for the security team (business-side risk owners are responsible for many treatment decisions) - A static annual deliverable (it is a living document with a continuous review cycle)
Organizations that treat their risk register as a compliance checklist to fill out once a year miss most of its value. The register is useful only if it reflects the current risk posture.
The required fields: a complete template
Core identification fields
| Field | Description | Example |
|---|---|---|
| Risk ID | Unique identifier for tracking and cross-referencing | CR-2026-047 |
| Risk name | Short descriptive title | Unpatched ERP application — remote code execution |
| Date identified | When the risk was first recorded | 2026-08-14 |
| Identified by | Team or individual who surfaced the risk | Security Operations |
| Asset(s) affected | The systems, data, or processes at risk | ERP platform (SAP S/4HANA), finance data |
| Threat description | What could cause harm | Exploitation of unpatched CVE-2026-XXXXX via public-facing interface |
| Vulnerability description | The weakness that enables the threat | Missing security patch — 90 days overdue; no compensating control |
Scoring fields
| Field | Description | Example |
|---|---|---|
| Inherent likelihood | Likelihood before existing controls (1–5) | 4 (High) |
| Inherent impact | Impact before existing controls (1–5) | 5 (Very High) |
| Inherent risk score | Likelihood × Impact | 20 (Critical) |
| Existing controls | Controls already in place that reduce the risk | Network segmentation; WAF in detection mode |
| Residual likelihood | Likelihood after existing controls (1–5) | 3 (Moderate) |
| Residual impact | Impact after existing controls (1–5) | 5 (Very High) |
| Residual risk score | Residual Likelihood × Residual Impact | 15 (High) |
Residual risk is the number that drives treatment decisions. Inherent risk is useful context but is not actionable on its own — every risk has existing controls of some kind, even if just policy.
Treatment and ownership fields
| Field | Description | Example |
|---|---|---|
| Treatment decision | Mitigate / Transfer / Accept / Avoid | Mitigate |
| Treatment rationale | Why this treatment was chosen | Residual score exceeds appetite threshold; patching scheduled |
| Treatment plan | Specific actions with owners and deadlines | Apply patch by 2026-09-30 — Infra Team lead |
| Risk owner | The business-side accountable person | VP of Finance (asset owner) |
| Technical lead | The security/IT person executing treatment | Infrastructure Engineer |
| Treatment status | Not started / In progress / Completed / Overdue | In progress |
| Target completion date | When treatment should be complete | 2026-09-30 |
| Actual completion date | When treatment was completed (or null) | — |
Lifecycle and review fields
| Field | Description | Example |
|---|---|---|
| Review frequency | How often this risk is reviewed | Quarterly |
| Next review date | Scheduled review date | 2026-12-15 |
| Last reviewed | Date of last formal review | 2026-09-01 |
| Status | Open / Closed / Transferred to issue tracker | Open |
| Notes | Free-text for context, escalations, dependencies | Patch delayed by change freeze; temporary WAF block rule applied |
The four treatment decisions and how to document them
Every risk in the register gets one of four treatments. Document the rationale for each.
Mitigate
You implement or strengthen a control to reduce the likelihood or impact. Document: - What control is being implemented - Who owns the implementation - The target residual risk score after the control is in place - The deadline
Transfer
You shift financial or contractual responsibility for the risk. Document: - The transfer mechanism (cyber insurance policy number and coverage limit, or vendor contract clause) - What residual risk remains after transfer - The review date for the transfer mechanism
Accept
You acknowledge the risk and choose not to treat it further, because the cost of treatment exceeds the expected loss, or because the residual risk falls within the defined risk appetite. This is a legitimate business decision — but it must be: - Documented with the rationale - Signed by the named risk owner - Reviewed on a defined schedule
An undocumented acceptance looks like negligence to an auditor. A documented, signed acceptance looks like governance.
Avoid
You eliminate the activity, system, or process creating the risk entirely. Document what was eliminated and when. This is the cleanest treatment but often the least feasible.
Keeping the register current: ownership and review cadence
The ownership model
Each risk entry needs two people: - Risk owner — the business-side leader who accepts accountability for the risk and the treatment decision. This is typically the system owner or the business process owner, not the CISO. - Technical lead — the security or IT professional executing the treatment plan.
The CISO owns the risk program. Individual business leaders own the risks within their domain. Conflating these roles creates situations where security teams are accountable for risks they have no authority to resolve.
Review cadence
| Risk score band | Review frequency |
|---|---|
| High / Critical (15–25) | Monthly |
| Moderate (6–12) | Quarterly |
| Low (1–5) | Annually or upon significant change |
Beyond scheduled reviews, trigger an unscheduled review when: - A new vulnerability is disclosed that could change a risk score - An incident occurs related to a registered risk - The organization undergoes a significant change (acquisition, new system, new regulation) - A risk owner changes
Avoiding shelf-ware
The most common failure mode of a risk register is that it gets built once, reviewed at audit time, and ignored the rest of the year. Signs your register is becoming shelf-ware:
- More than 20% of entries have overdue treatment deadlines
- Risks haven't been re-scored since the initial assessment
- The register doesn't reflect systems deployed in the last 12 months
- Risk owners can't describe the risks they nominally own
Assigning a risk program manager who owns the review process — separate from the technical security team — significantly improves register currency.
For the broader framework context in which the register operates, see the enterprise cyber risk management framework guide. For how risks are initially identified and scored before they enter the register, see the cyber risk assessment methodology guide.
Frequently asked questions
What is the difference between a cyber risk register and a vulnerability register?
A vulnerability register lists technical weaknesses in systems (CVEs, misconfigurations, gaps). A cyber risk register records business decisions about information security risks — a broader category that includes vulnerabilities as one input but also covers process risks, third-party risks, and strategic risks that don't map to a specific CVE.
How many risks should a cyber risk register contain?
There is no fixed number. A well-scoped register for a mid-sized enterprise typically contains 30–100 active risks. Registers with hundreds of entries are often too granular to be actionable at the governance level — consider aggregating at a risk theme level and tracking technical details in a linked issue tracker.
Who signs off on risk acceptance entries?
The named risk owner — the business-side leader accountable for the affected asset or process — must sign off on any risk acceptance decision. Acceptance by the security team alone is not sufficient and will not satisfy auditors reviewing the governance record.
Can a risk register be maintained in a spreadsheet?
Yes, especially for smaller programs. A well-structured spreadsheet with the required fields and a disciplined review process is more useful than a GRC platform nobody uses. For larger programs, a dedicated GRC tool provides workflow automation, audit trails, and reporting capabilities that spreadsheets cannot match.
Learn how to build and maintain a full enterprise risk program, including risk registers and executive reporting. ThreatBlock's Enterprise Cyber Risk Management course covers the entire lifecycle.
About the author: Samaksh is Lead Instructor at ThreatBlock and holds the OSCP, CRTP, CRTO, and CEH certifications, with expertise in cybersecurity risk management and compliance. Read more on the author page · Editorial policy.