A cyber risk register is a shared, living record of the security risks your organization has identified. Each entry describes a scenario, rates its likelihood and impact, names an owner, and records the chosen response and its status. It is a decision tool, not a spreadsheet of every possible bad thing.
Why a register exists
Without one, risk lives in people's heads and in scattered tickets. Leaders cannot compare a database exposure with a vendor outage, and nobody can say which risks were accepted on purpose.
NIST describes risk registers as the way to document cybersecurity risk so it can be rolled up from system level to enterprise level and weighed against business objectives. That roll up is the point. A register lets a team of five and a company of five thousand answer the same question: what could hurt us, and what are we doing about it?
What each entry should hold
Keep the first version small. These fields cover most needs:
- A short ID and a title written as a scenario, such as "Customer data exposed through a misconfigured storage bucket".
- The asset or service affected.
- The threat and the weakness that lets it happen.
- Likelihood and impact ratings, with the scale you used.
- The business consequence in plain words.
- The risk owner, one named person.
- The treatment decision: reduce, avoid, share, or accept.
- Planned actions, a due date and current status.
- The date of last review and the date of next review.
NIST publishes example register and risk detail schemas alongside its IR 8286 series, which are worth reading before you invent your own columns.
What to leave out
Do not list raw vulnerabilities. A scanner finding is an input, not a register entry. Ten thousand findings on one application might support a single risk scenario, or none.
Do not list control gaps with no consequence attached. "No MFA on admin accounts" becomes useful when it reads "Attacker takes over an admin account and changes production data".
Keep it alive
A register that is filled in once and filed away is worse than none, because it gives false comfort. Set a review rhythm that matches how fast your environment changes. Review the top risks more often than the long tail, and review any risk after a major change or incident.
Two habits keep it honest. First, record the date and reason when a risk is accepted, and who accepted it. Second, close entries that no longer apply instead of letting them pile up.
Where it connects
The register feeds your treatment plans, your board reporting and your audit evidence. If a later risk assessment changes a rating, update the register entry and note why. That change history is what auditors and executives actually want to see.
Quick check
How many risks should a register hold?
As many as people will actually review. For many small teams that is 15 to 40 well written scenarios, not hundreds of entries.
Can a spreadsheet be a register?
Yes. The fields and the review habit matter more than the tool.
Sources
- NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management
- NIST IR 8286A, Identifying and Estimating Cybersecurity Risk
- NIST IR 8286 Rev. 1
Last reviewed: 19 October 2026.