Risk & Uncertainty · Vocabulary
What Is a Risk Register?
The instrument is sound: a living record of what could go wrong, who owns it, and what is being done about it. What fails, in most organizations, is the implementation.
Definition
A risk register is the living record of the risks an organization or program has identified: for each risk, a description of what could go wrong, an assessment of its probability and consequence, a named owner, and the response under way. Maintained and consulted, it is the working instrument of risk management. Written once and filed, it is a compliance artifact with the same fields.
Nothing about the definition is controversial. The register is assumed by the formal treatments of risk practice, from the project management body of knowledge to the international risk management guidelines, and the fields barely vary between them: risk, likelihood, consequence, owner, response. Organizations do not fail at risk registers because they misunderstand the form. They fail because the form is the easy part, and everything that makes the form useful (maintenance, authority, and a connection to live decisions) is organizational work the template cannot do for them.
One boundary keeps the record honest: a register holds risks, which are uncertain and ahead of you, not issues, which have already happened. The distinction sounds pedantic and is not, because the two demand different management: a risk gets a probability, a trigger, and a contingent response; an issue gets an action plan and a deadline. Risk or Issue? draws that line in full. A register whose entries are mostly certainties is describing the past, and a register that only acquires entries after they materialize is confessing that identification happens in hindsight.
The Three Ways Implementations Fail
The compliance artifact
The register is created because a gate review requires one: populated at kickoff, formatted for governance, filed in the right place, and never consulted in the decisions it was meant to inform. The organization can prove that it considered risk. It cannot show a single decision the register changed. The document is real; the practice it stands for does not exist.
Entries that cannot feed a model
Consequences recorded as high or severe rather than as ranges of money and time. Probabilities recorded as likely, a word that different reviewers convert to different numbers. Descriptions too vague to verify. Entries in this form cannot be compared, aggregated, or fed into a contingency calculation, so even a register that is read cannot inform pricing, schedule, or reserve decisions.
Risk owners without authority
Every entry carries a name, but the name marks accountability without decision rights: the owner cannot approve the mitigation spend, move the schedule, or trigger the escalation the response plan calls for. Ownership without authority produces monitoring without management, and the risk waits on a committee while its window for cheap treatment closes.
The first failure is the most common, and it has its own treatment in the Builder's Library: The Risk Register Nobody Reads examines why a document created to manage uncertainty ends up managing an audit instead, and locates the cause in how the organization directs attention rather than in the template.
A Record Is Not an Instrument
The distinction that decides whether a register earns its keep is between a record and an instrument. A record proves that risk identification happened. An instrument changes what the organization does next: it is consulted before commitments, revised when conditions change, and closed out as risks materialize or expire. The fields are identical in both. The difference lives entirely in the surrounding architecture: whether any decision process actually pulls the register into the room.
That architecture is what the Four A's of Organizational Readiness™ names directly. Attention determines whether risk information reaches decisions while it can still shape them. Authority determines whether the named owner can act when it does. A register can be technically complete and still inert, because the conditions that make it consequential live in the organization, not in the spreadsheet.
The Two-Date Test
Take the largest entry in your register and find two dates: the date the entry was last edited, and the date it last changed a decision (a contingency sized, a commitment moved, an escalation made). In a working register the two dates travel together. When the first is old and the second cannot be found at all, you are holding a record, not an instrument.
What a Working Register Requires
The repair is not a better template; it is four properties, all of them organizational rather than clerical. For the first, From Risk Register to Model shows the mechanics of converting qualitative entries into inputs a decision can actually use.
Entries specific enough to quantify
Consequences as ranges of money and time, probabilities as numbers, descriptions concrete enough that someone outside the team could say whether the risk occurred. In this form entries can be ranked, aggregated, and used to size contingency; in any other form they can only be discussed.
Owners who hold the authority the response needs
One named owner per risk, granted the decision rights the response plan requires: to spend, to change the plan, to escalate. Assigning a name without moving the authority creates a watcher, not an owner.
Review tied to decisions, not to the calendar
The register is consulted where commitments get made: at stage gates, funding decisions, and commitments to dates and prices. A monthly update with no decision attached keeps the document current and the practice dead.
Triggers with escalation paths
Each significant entry names the observable condition that activates its response and the path the escalation takes. A trigger gives the owner something specific to watch for, which is what separates monitoring a risk from periodically re-rating it.
Research basis: Project Management Institute (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th ed. PMI. International Organization for Standardization (2018). ISO 31000:2018, Risk management - Guidelines. ISO. Hubbard, D.W. (2009). The Failure of Risk Management: Why It's Broken and How to Fix It. Wiley.
Frequently Asked Questions
What is a risk register?
The living record of identified risks: for each one, a description, an assessment of probability and consequence, a named owner, and the response under way. It is the working instrument of risk management when maintained and consulted, and a compliance artifact when written once and filed.
What should a risk register include?
For each entry: a description specific enough to verify, probability and consequence expressed concretely enough to compare, a single named owner plus the authority that owner holds, the response in progress, the escalation trigger, and the date of the last genuine review.
Why do risk registers fail?
Three recurring implementation failures: registers produced as compliance artifacts and never consulted in decisions; entries too vague or too ordinal to feed a model, forecast, or contingency calculation; and named risk owners who lack the authority their response plans require.
What is the difference between a risk and an issue?
A risk is uncertain and ahead of you, so it gets a probability, a trigger, and a contingent response. An issue has already materialized, so it gets an action plan and a deadline. Registers that mix the two lose both disciplines.
From Record to Instrument
Is your register managing risk, or documenting that you considered it?
The Risk & Uncertainty collection follows the full arc: why registers go unread, how entries become model inputs, and how forecasts get scored against outcomes. The Executive Diagnostic measures the conditions, Attention and Authority among them, that decide whether any of it takes hold.