Risk Register

Origin & evolution

The register grew up inside formal project management. The Project Management Institute, founded in 1969, published the first Guide to the Project Management Body of Knowledge in 1996, and risk management became one of its core knowledge areas. The PMBOK Guide treats the register as the central output of risk identification: a structured list of identified risks, prioritised for attention, with responses and owners assigned to each. The same artefact recurs across PRINCE2 and ISO 31000, which is rare enough that it signals genuine convergence on a useful idea.

The thinking has shifted in emphasis over time. Early practice treated the register as a document produced during planning and filed away. Mature practice treats it as a standing instrument reviewed on a cadence, where risks are reassessed, closed when they pass, and added as new ones appear. The distinction between a threat☠️ThreatSecurityA specific security threatView reference → (a risk with negative impact) and an opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → (a risk with positive impact) entered the guidance, widening the register from a worry list into a full ledger of uncertainty in both directions. The persistent failure mode stayed constant: a register written once and never reopened. A dead register gives false comfort, because it documents the risks a team imagined at the start and silently omits everything learned since.

How it works in practice

A programme migrating a bank's core ledger to new infrastructure keeps a register with about forty live entries. One reads: "Legacy data contains undocumented edge cases that fail validation on import." Likelihood is rated high from a sample migration, impact is severe because it blocks cutover, the owner is the data lead, and the mitigation is a two-week reconciliation spike with a named go/no-go date. Each fortnight the steering group walks the top ten by exposure. When the spike finishes and the edge cases are mapped, the entry's likelihood drops and it moves toward closure. A new risk about a vendor's slipping delivery date takes its place near the top. The register is not the safety; the recurring review is. The document only makes the conversation possible.

Risk register vs. its neighbours

• Risk is one entry, a single uncertain event with its own probability, impact, owner, and response. The register is the collection that holds all of them and ranks them against each other. A risk on its own cannot be prioritised, because priority is relative; it needs🫀NeedUserA user need, pain, desire, or constraintView reference → the register's other entries to have a position.
• Programme is the body of coordinated work the register protects. The register is an instrument the programme runs to stay aware of its own exposure. One programme keeps one authoritative register, which is why a fragmented register split across spreadsheets tends to mean a fragmented programme.
• Decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → is a commitment made, often in response to a risk crossing a threshold. The register surfaces the exposure; the decision is the act of spending money, changing scope, or accepting the risk. Linking the two records why a choice was made, which is exactly what gets lost when a programme is audited a year later.

In the graph

In the Unified Product Graph, risk_register🧯Risk RegisterProgram ManagementA register of project risks sits in the programme-management region as a container rather than a leaf. A programme connects to it through program_tracked_via_risk_registerProgramtracked viaRisk Registerhierarchy, and each individual risk hangs off it through risk_register_contains_riskRisk RegistercontainsRiskhierarchy. Modelling the register as its own node, distinct from the risks inside it, is what keeps the artefact alive in structure: the register can be reviewed, versioned, and queried as a whole, while each risk carries its own likelihood, owner, and links to the decisions it triggered. A register whose risks connect to no owners and no decisions shows up as exactly what it is, a list nobody is acting on.