Short answer: A risk register is a structured list of the risks your organization faces. Each entry records the risk, its likelihood and impact, the owner accountable for it, the treatment decision (mitigate, accept, transfer, or avoid), and its current status. NIST SP 800-171, ISO 27001, SOC 2, and NIST CSF all expect you to identify and manage risk, and a maintained register is how you show it. Keep it small: 15–30 well-defined risks that leadership reviews regularly beat hundreds of entries nobody reads.
What is a cybersecurity risk register?
A cybersecurity risk register is the working record of your security risk management. It answers four questions leadership should always be able to answer:
- What could go wrong?
- How likely is it, and how bad would it be?
- Who owns it?
- What are we doing about it, and is it working?
NIST describes the cybersecurity risk register as a key tool for connecting cybersecurity risk to enterprise risk management, so security risks are recorded, prioritized, and reported in a way leadership can compare with other business risks (NIST IR 8286).
Which frameworks require risk assessment?
| Framework | What it expects |
|---|---|
| NIST SP 800-171 / CMMC Level 2 | Requirement 3.11.1: periodically assess risk to operations, assets, and individuals from operating systems and handling CUI, at a frequency you define |
| ISO/IEC 27001:2022 | Clause 6.1.2: a defined risk assessment process, with risk owners identified. Clause 6.1.3: risk treatment decisions |
| SOC 2 | Trust Services Criteria CC3 (Risk Assessment): identify and analyze risks to objectives, including fraud risk and significant changes |
| NIST CSF 2.0 | Govern function (risk management strategy, GV.RM) and Identify function (risk assessment, ID.RA) |
A register isn’t always mandated by name, but it’s the most common way to produce the evidence auditors and assessors ask for.
What should a risk register include?
These fields cover what most frameworks and auditors look for:
| Field | What to record |
|---|---|
| Risk ID | A unique reference (e.g., R-012) |
| Risk description | A specific scenario: threat + asset + consequence |
| Category | Technical, operational, third-party, compliance, people |
| Likelihood | Simple scale, e.g., 1–5 |
| Impact | Same scale, based on financial, operational, contractual, and reputational effect |
| Inherent risk | Likelihood × impact before controls |
| Existing controls | What already reduces the risk |
| Residual risk | Risk remaining after existing controls |
| Treatment | Mitigate, accept, transfer (e.g., insurance), or avoid |
| Treatment plan | Actions, linked to projects or POA&M items |
| Owner | One accountable person, not a team |
| Target date and status | Open, in progress, closed, accepted |
| Last reviewed | When the entry was last confirmed accurate |
Sample entry
| Field | Example |
|---|---|
| Risk | Ransomware encrypts file server and backups, halting production for 1–2 weeks |
| Likelihood / Impact | 3 / 5 → Inherent 15 (High) |
| Existing controls | Endpoint protection, nightly backups |
| Gaps | Backups reachable from the network; no restore test in 12 months |
| Residual | 12 (High) |
| Treatment | Mitigate: immutable/offline backups, quarterly restore test, MFA on remote access |
| Owner | Operations Director |
| Status | In progress |
How do you build a risk register from scratch?
- Start from what matters. List critical business processes, sensitive data (customer data, CUI, financial records), and key systems and vendors.
- Use proven scenarios. Most small and mid-sized organizations share a core set: ransomware, business email compromise, credential theft, a critical vendor or MSP compromise, data loss from misconfigured cloud storage, insider error, and non-compliance with contractual security requirements.
- Score consistently. Define what each likelihood and impact level means in your terms, such as dollar ranges or days of downtime, so scores are comparable.
- Record existing controls honestly. A risk assessment or gap assessment against NIST 800-171 tells you what’s actually in place.
- Decide treatment and assign owners. Every risk gets a decision and a named person.
- Get leadership sign-off, especially for risks you choose to accept.
How do you keep a risk register from going stale?
- Keep it short. Consolidate duplicates; cap the active list at the risks that are plausible and material.
- Review on a schedule. Monthly for the top risks, and a full review at least annually or after major changes (new systems, acquisitions, incidents, new contracts).
- Link risks to work. Every “mitigate” decision should point to a project, ticket, or POA&M item. If nothing is happening, the register should show it.
- Report trends, not just lists. In leadership updates, show the top risks, what changed since last time, and decisions needed.
- Feed it from real events. Incidents, near misses, audit findings, and security questionnaire gaps are all signals to add or rescore risks.
Frequently Asked Questions
What is the difference between a risk register and a POA&M?
A risk register tracks risks and how you’ve decided to treat them. A POA&M (Plan of Action and Milestones) tracks specific security requirements that aren’t fully implemented, with remediation steps and dates. It’s a required document for NIST SP 800-171. They connect: a POA&M item is often the treatment plan for a risk. See SSP & POA&M development.
Can we use a spreadsheet for our risk register?
Yes. For most small and mid-sized organizations a well-structured spreadsheet is enough. What matters is consistent scoring, named owners, and regular review, not the tool.
Who should own the risk register?
A security leader, such as a CISO, vCISO, or designated IT/security manager, maintains it and runs reviews. Individual risks are owned by the business leaders accountable for the affected processes, and leadership approves risk acceptance.
How many risks should a risk register have?
There’s no required number. For a small or mid-sized organization, 15–30 well-defined risks is a practical range. Fewer can mean blind spots; hundreds usually means vague, duplicate entries that no one maintains.
How USCIBER can help
USCIBER’s Security & Risk Assessment (from $6,500) delivers a working risk register with scored risks, owners, and a prioritized improvement plan. Our vCISO service keeps it current and reports it to leadership.
Sources
- NIST IR 8286 — Integrating Cybersecurity and Enterprise Risk Management (ERM), and the companion IR 8286A on identifying and estimating cybersecurity risk
- NIST SP 800-171 Rev. 2 — Requirement 3.11.1, Risk Assessment
- ISO/IEC 27001:2022 — Clauses 6.1.2 (information security risk assessment) and 6.1.3 (risk treatment)
- AICPA — 2017 Trust Services Criteria (CC3, Risk Assessment)
- NIST — Cybersecurity Framework (CSF) 2.0
This article is general information, not legal advice.