Leadership Framework
How I Run a Risk Register
Most risk registers are decoration — written once at kickoff, never opened again. A working risk register is a live document with named columns, an owner per risk, a clear scoring rule, a cadence, and an escalation threshold. This page gives the columns that matter, the scoring discipline that forces resolution, the cadence that keeps it honest, the escalation rules, and a one-page template you can use this week.
Definition
What a risk register actually is.
A risk register is a live document that names what could cause the project to fail, ranks those threats by likelihood and impact, assigns each one to a human owner, and tracks what is being done about them on a cadence. It exists so that the project does not have to be surprised by anything it has already imagined.
What a risk register is not: a one-time audit artifact, a slide produced for a steering committee, or a spreadsheet that grows but never shrinks. A register that has not been touched in three weeks is not a register. It is a snapshot. The discipline below is what keeps a register alive.
The Core Document
The columns that matter.
Ten columns. Less than this and the register cannot do its job; more than this and the register turns into an audit form that nobody updates. Each column has a specific purpose, and dropping any of them creates a predictable failure mode further on.
| # | Column | Purpose |
|---|---|---|
| 01 | ID | A stable identifier (R-01, R-02). Risks are referred to by ID in meeting notes and the after-action artifact, never by their description, because the description will get edited. |
| 02 | Description | One sentence. What could happen, and the consequence if it does. “Vendor delivers late” is not a risk; “If the vendor delivers later than week six, the validate phase cannot enter on schedule” is a risk. |
| 03 | Category | A small fixed list: data, dependency, people, schedule, scope, technical, external. Categories surface where the project’s threats cluster — if half the register is “people,” that is the finding. |
| 04 | Likelihood (1–5) | How likely the risk is to occur over the project window. 1 is rare, 5 is near-certain. Five-point scales force the team to take a position; three-point scales let everything sit at “medium.” |
| 05 | Impact (1–5) | How damaging the risk would be if it occurred. 1 is recoverable in days, 5 is the project does not finish. Same logic as likelihood — five-point scales force resolution. |
| 06 | Score (L × I) | A number from 1 to 25. Numbers force decisions in a way that heat-map colors do not. A risk scoring 16 or above gets a different conversation than one scoring 6. |
| 07 | Owner | One person’s name. Not a team. If you cannot put a name in the cell, the risk is not yet being managed — it is being watched. |
| 08 | Mitigation | What is being done now to lower likelihood or impact. Specific, dated, and verifiable. “Talking to the vendor” is not a mitigation; “weekly status call with vendor PM, contingency vendor identified by week three” is one. |
| 09 | Trigger | The observable event that converts this risk from possible to active. The trigger is what the team watches for between meetings. If no trigger can be named, the risk is too vague. |
| 10 | Status · Last reviewed | Open, mitigated, accepted, closed, or realized — and the date the register last looked at this row. A row that has not been reviewed in three weeks is a row to revisit, regardless of score. |
Scoring
Why five-point scales and a numeric score.
Three-point scales let everything settle at “medium.” Five-point scales force the team to choose. Multiplying likelihood and impact produces a 1-to-25 score that segments cleanly into the four decision quadrants below. The escalation rule downstream is built on that number.
The 5×5 matrix with four decision quadrants. Score sixteen and above triggers the escalation rule.
Cadence
The cadence that keeps it honest.
A register stays alive only if it is touched on a schedule. Three cadences, three different questions. Skipping the weekly skim is the most common reason registers go silent.
Weekly · 10 minutes
Skim the top five by score. Has the trigger fired? Has the owner moved the mitigation forward? Anything in the last week that should have changed a score? Update the “last reviewed” date on every row touched.
Monthly · 30 minutes
Full register walk. Every row in order. Re-score where evidence has changed. Close anything that is no longer plausible. Add anything new that has surfaced. The register should leave the meeting smaller or larger than it entered, never the same.
Quarterly · 60 minutes
Retire-and-add cycle. Pull every row scored 3 or below for two consecutive months and decide whether to close it or accept it. Look at the category counts — what is clustering tells you where the project is exposed.
Escalation
When the register reaches outside the project.
The score number is what makes escalation defensible. A risk does not get escalated because somebody felt anxious about it; it gets escalated because it crossed a numeric threshold the team agreed to in advance.
The three escalation rules.
- Score 16 or above: escalate to the named decision-maker in the project charter within 48 hours of the score being assigned. Carry a one-page brief: the risk, the score, the mitigation in place, and the decision being asked for.
- Trigger fired on any risk: escalate immediately, regardless of score. A risk whose trigger has fired is no longer a risk — it is an issue, and issues run on a different clock.
- Two consecutive monthly reviews with the same risk at score 12+ and the same owner: escalate for an owner-change decision. A risk that the owner cannot move in two months is a risk the project has not actually assigned.
Failure Modes
Where risk registers go wrong.
Every register I have watched go silent did so for one of these reasons. Treat the symptom early or the register quietly stops being trusted.
- The register only grows. New risks are added every cycle; nothing is ever closed. Fix: the quarterly retire-and-add cycle is non-negotiable. A register that cannot close rows is a register nobody reads.
- Owners are teams, not people. “Engineering” or “Marketing” in the owner column. Fix: replace each team name with a person’s name. If the team cannot decide who owns the risk, that is itself a finding.
- Scores never move. The same five-by-five number on the same row for two months. Fix: if a score has not moved in two cycles, the row is either not being worked or is genuinely accepted. Force the choice: close, accept formally, or assign a new owner.
- No triggers. The trigger column is blank or paraphrases the description. Fix: ask “what would I observe that tells me this risk has just become an issue?” If you cannot answer in one sentence, the risk is still too vague to manage.
- Closed risks have no link to the AAR finding that closed them. The row is marked closed; the institutional learning is lost. Fix: when a risk is closed via realization, link the row to the after-action finding that recorded what was learned. The register and the AAR are the same document at different timescales.
One-Page Template
Copy this and start your register.
Three example rows are filled in to show the shape. Drop the examples and start over for your project.
RISK REGISTER — Project: ______________ Version: ______ Last reviewed: __________ ID DESCRIPTION CATEGORY L I S OWNER MITIGATION TRIGGER STATUS REVIEWED R-01 Vendor delivers data feed late dependency 3 4 12 J. Rivera Weekly call; contingency vendor identified Status amber two weeks open __________ R-02 Key engineer leaves before validate phase people 2 5 10 A. Chen Cross-train two engineers by week four One-on-one signals attrition open __________ R-03 Source schema changes mid-build technical 2 3 6 M. Diallo Subscribe to vendor release notes Schema diff in nightly check open __________ … R-__ ____________________________________ __________ _ _ __ __________ ____________________________________ ____________________________ ____ __________ L = likelihood (1–5); I = impact (1–5); S = L × I; escalate when S ≥ 16 or trigger fires.
Worked Example
See the framework run on a real program.
The clearest live example of this framework on this site is the Workforce Stability program risk register, a ten-row register run on the cadence above and carried through twenty-six days of build. Three additional programs on this site track risk against the same column set and cadence.
- Workforce Stability — ten-row register, monthly walk, two risks realized and closed via AAR
- Veteran Regional Stability Index — risk register paired with KPI coverage gates and partial-publish rules
- Household Cost Tools (TCBI & TSCI) — register tracked the mod_deflate buffer cap as a realized risk; closed with an AAR finding
- Veteran Livability Index — register tracked source-attribution and clamp-band risks
- Series 01: How I Write a Project Charter (the upstream document the register defends)
Next in the Series
A register defends the work; the AAR reviews it.
Risks that fire become findings. Findings become sustain-improve-change items. The next leadership-framework piece is the After-Action Review — the four questions that turn what just happened into what the team does next.