What Is a Risk Register, and What Makes One Worth Keeping?

A risk register is "a repository of risk information including the data understood about risks over time." That is OMB Circular A-11's wording, carried into the NIST computer security glossary and quoted in the footnotes of NIST IR 8286r1, published December 2025. The notional cybersecurity risk register template in that document carries twelve fields. Here is the contrarian part: the two fields that decide whether a register does anything are Risk Owner and Risk Response Type, and they are the two that downloadable spreadsheet templates skip most often. A register with no named owner and no chosen response is a findings list wearing a better title.

One correction before you cite anything on this subject. The NIST document most risk-register content still links to, NISTIR 8286 from October 2020, was withdrawn on 18 December 2025 and superseded in its entirety by IR 8286r1. The withdrawal notice is the first page of the old PDF, so it is not hidden, just unread. If a vendor white paper on your desk cites the 2020 edition, nobody has re-checked it since last December. NIST sells nothing, and neither does the UK's National Cyber Security Centre, the other source here, which is why both appear instead of a platform's research blog.

The rest of this article: the twelve fields and what each is for, the four risk responses, the three artifacts a register gets confused with, who owns it, and when one stops earning its maintenance.

Key takeaways

• The register is a communication instrument, not an inventory. IR 8286r1 calls it "a formal communication vehicle for sharing and coordinating cybersecurity risk activities as an input to ERM decision-makers."
• Twelve fields in the NIST notional template. The load-bearing ones are Risk Owner, Risk Response Type and Status, the three that force a decision rather than record an observation.
• Four responses to a negative risk: accept, transfer, mitigate, avoid. NIST is explicit that transfer has a limit, because reputational consequences do not travel with the money.
• A register is not a POA&M, a findings list, or a risk treatment plan, and confusing them is the most common reason one goes stale.
• You do not have to finish the register before fixing obvious things. NIST says so in a footnote.

The definition, and the second definition that quietly disagrees

The NIST glossary carries two definitions of "risk register" and they are not saying the same thing. The first, from OMB Circular A-11 by way of IR 8286r1 and SP 800-221, is the repository framing quoted above: a record of what you have understood about risks over time. It is a ledger. The second, sourced to NISTIR 8170, calls it "a central record of current risks, and related information, for a given scope or organization," and says current risks include both accepted risks and risks with a planned mitigation path annotated in a POA&M. That emphasis is on present state, and on an accepted risk still being a live entry. IR 8286r1 also reports the ISO framing, describing the register (or risk log) as "a record of information about identified risks."

Three definitions, one object, and the difference matters. Build to the first and the register grows forever. Build to the second and you keep a current-state view but need a separate mechanism for the audit trail. Most teams want both, never decide which the spreadsheet is, and end up with a tab called "old risks" nobody has opened since the last audit. Decide in the first hour, then design the Status field to match.

The twelve fields, and what each one is actually for

IR 8286r1's Table 1 describes each element of its notional template. All twelve are below, grouped where the template splits one idea across adjacent columns, with the job each field does:

• ID and Priority. A sequential identifier so a risk can be referred to without describing it again, and a relative criticality, either ordinal or on a named scale.
• Risk Description. NIST asks for a scenario, not a noun: one that "describes the source of uncertainty, any predisposing conditions, the resources affected, and the anticipated result." Its worked example is construction activity severing an unprotected fiber optic cable and taking enterprise financial systems down with it. Compare that with "phishing," which is what most registers contain.
• Risk Category. A grouping construct so entries can be consolidated by theme. NIST suggests SP 800-53 control families, which has the side effect of making your register comparable to somebody else's.
• Current Assessment: Likelihood, Impact and Exposure Rating. Three fields: the probability before any response, the consequences if none is applied, and the two combined. NIST notes other frameworks call that combination "level of risk," so an auditor using that phrase means this column.
• Risk Response Type. One of the four below. A decision, not an observation.
• Risk Response Cost and Description. The estimated cost of the response, and what you will actually do, in a sentence a stranger could act on.
• Risk Owner. "The designated party responsible and accountable for ensuring that the risk is maintained in accordance with enterprise requirements." NIST distinguishes the owner from a risk manager, who monitors the chosen response. Two roles, often two people.
• Status. The current condition of the entry and any subsequent activity.

NIST's own footnote says the register "may contain many more (or fewer) fields," so twelve is a starting shape, not a requirement. What is not optional is at least one field that forces a decision, because a register made entirely of observation fields cannot be wrong, and a document that cannot be wrong is not a control.

Four responses, and the one that has a limit nobody mentions

For negative risks, IR 8286r1 names four response types:

• Accept. Risks within tolerance. No further action beyond monitoring.
• Transfer. For risks outside tolerance, share part of the consequences with another party, cyber insurance being the obvious instance.
• Mitigate. Apply actions, including security controls, that reduce threats, vulnerabilities or impact to an acceptable level.
• Avoid. Respond so the risk does not occur, which NIST says may be best when there is no cost-effective way to reduce it. The lost opportunity is part of that calculation.

The line worth pinning to a wall is NIST's caveat on transfer: "While some of the financial consequences may be transferrable, there are often consequences that cannot be transferred, like the loss of customer trust." A register where half the high-exposure entries say "transfer: cyber insurance" has confused a cheque with a control.

Two concepts travel with the responses. Residual risk is what remains after a response is applied; IR 8286r1 says that when it stays above the acceptable line the risk owner evaluates whether it can be brought down further, and if the response costs more than the activity is worth, considers avoiding the activity. And responses generate risk of their own: NIST's example is multi-factor authentication reducing an access-control risk while introducing a productivity risk. If your register has never recorded a risk created by one of your own controls, it is not being maintained honestly.

What a register is not

Three artifacts get called a risk register and are not one.

A findings list is an input, not the register. A penetration test or gap assessment produces observations someone made about your environment in one particular week. Those are candidate entries until somebody attaches a scenario, an owner and a response. Our piece on turning findings into a remediation plan covers that conversion.

A POA&M is a close relative with a different job. IR 8286r1 describes the plan of actions and milestones as a "risk register-like report" federal agencies must produce for each system, an output of the Assess step in SP 800-37r2, documenting planned mitigation actions including those that cannot be implemented immediately. A POA&M is a commitment to fix on a schedule. A register also holds risks you have decided to accept and never fix. In the defense supply chain, what a POA&M can and cannot defer is the more relevant page.

A risk treatment plan is not the register either. It is the plan for executing the responses the register records. We are not restating ISO 27001's requirements for it from memory, and neither should anything else you read.

Who owns it, and who it is written for

The register's audience is not the security team. It is whoever allocates money.

IR 8286r1 frames its whole argument around that flow. Registers built from system-level assessments are "aggregated, normalized, analyzed, and used to create enterprise-level risk registers for each discipline," and those in turn are "aggregated, normalized, and prioritized into risk profiles." A risk profile is what OMB Circular A-123 defines as "a prioritized inventory of the most significant risks identified and assessed through the risk assessment process versus a complete inventory of risks." Note the "versus." A profile is deliberately not everything, and the filtering is the value.

The UK NCSC's board toolkit states the governance expectation from the other end: "The board need assurance that a cyber risk register is in place (as part of the overall organisation risk register), that covers risk ownership and an escalation mechanism for the whole extended enterprise." Two things in that sentence get missed. The cyber register is a part of the organisation register, not a parallel universe, and NCSC says on the same page that cyber security risk "should be integrated within your overall approach to risk management, and not be dealt with as a standalone topic." And an escalation mechanism is named as a required feature, meaning the register needs a route by which an entry stops being the security lead's problem.

If nobody can say who signs off an accepted risk, the register has no top. We wrote about that failure mode more generally in who owns compliance; it is the same defect, an artifact with no accountable name attached decaying into documentation.

What an auditor and an enterprise buyer actually do with it

An auditor checks that the process ran, not that your judgement was correct. Expect questions about when entries were added, who assessed them, whether the response was approved by someone with authority, and whether Status moved between reviews. A register with twenty entries all created three weeks before fieldwork tells its own story.

An enterprise buyer's security reviewer wants something else: evidence that you know your own weak points, because a vendor claiming to have none is either not looking or not telling. A register you can describe fluently in a call, including two entries you have accepted and why, does more for a deal than a clean-looking document. The buyer-side view is in our vendor risk management program guide.

The honest caveat: when a register stops earning its keep

Three cases where we would tell you to do less, not more.

If you are a fifteen-person company with one product, twelve columns is overhead. Six will do: scenario, exposure, response type, owner, what you are doing, status. The value is in the decisions, and decisions do not need columns.

If the register exists only to be shown to an auditor, it is a cost, not a control, and everyone in the room knows it. We have built registers like that under time pressure and they were the least useful thing we delivered that quarter. The tell is whether anything in the document has ever changed because of a decision made elsewhere in the business.

And do not sequence your programme behind it. NIST's second footnote in IR 8286r1 says organizations building a risk management program for the first time "should not wait until the risk register is completed before addressing obvious issues," though over time it should become the ordinary means of communicating risk information. If your laptops have no disk encryption, fix that this week; it does not need a row first. Letting known problems accumulate while the documentation catches up is what we called compliance debt.

Where Top Floor fits

Most of what makes a register work is judgement about your business, so we do not hand clients a template and leave. We are useful on the first pass: writing scenarios in the shape NIST describes, naming owners you can hold to it, and making the exposure scale consistent so the roll-up is not noise. That sits inside compliance as a service for teams with no internal risk function, and inside audit and readiness when the register has to survive a specific examination. For teams heading toward ISO 27001, it is the document the rest of the management system hangs off.

Where we are not useful: if you already have a risk function and a working register, hiring anyone to re-do it is spend with no return. Ask us to pressure-test three entries instead.

How to decide this week

Open whatever you call a risk register and check four things. Does every entry read as a scenario with a source, an asset and a consequence, or are some of them single words? Does every entry name a person, not a team? Does every entry carry one of accept, transfer, mitigate or avoid, chosen deliberately? Has any Status field changed in the last quarter? Any no is this quarter's work, and it is editing, not buying. If all four hold, the next step is upward: one page in front of whoever approves budget, showing the five highest-exposure entries and what each would cost to move.

Frequently asked questions

Is a risk register the same thing as a POA&M?

No. NIST IR 8286r1 calls the plan of actions and milestones a "risk register-like report" that federal agencies must produce for each system, documenting planned mitigation actions including those that cannot be implemented immediately. The difference is what each document will hold. A POA&M is a commitment to remediate on a schedule. A risk register also holds risks you have consciously accepted and do not intend to fix, which is a legitimate outcome that needs somewhere to live.

Who should own a risk register?

Ownership works at two levels. Each entry needs a named risk owner, which NIST defines as the party responsible and accountable for ensuring that risk is maintained according to enterprise requirements, sometimes working with a separate risk manager who monitors the response. The register as a whole needs an owner senior enough to escalate, because the NCSC board toolkit treats an escalation mechanism as a required feature. A register whose only owner is the security lead has no route by which anything leaves that desk.

How often should a risk register be updated?

There is no universal number, and any article that gives you one has invented it. The practical test is event-driven rather than calendar-driven: entries change when a control changes, when an assessment or penetration test lands, when a new system or vendor comes into scope, and when a response is completed. A periodic review by the accountable owner sits on top of that, so accepted risks are not accepted by default forever. If nothing has moved in a quarter, that is a finding about the process rather than evidence of a stable environment.

Does a spreadsheet count as a risk register?

Yes. Nothing in the NIST guidance requires a platform, and IR 8286r1 notes that formats vary, including dashboards, GRC tools and file formats for exchanging register data. A spreadsheet fails for a different reason than being a spreadsheet: no version history anyone trusts, no controlled access, and no way to see who changed an exposure rating and when. Buy a tool when you feel those specific pains, not because the document type feels unserious.