Risk Register

A risk register is a living record of the uncertain events that could affect a project, product, or organization, each assessed and assigned an owner. Its job is not to list every worry but to make risks visible, comparable, and actively managed: someone is responsible for each one, and its status changes over time.

Key components

Each entry (row) typically records:

• ID and title — a stable identifier and a short name.
• Risk statement — written as cause, event, and consequence: "Because the vendor has a single data center (cause), an outage could occur (event), halting order processing for the duration (consequence)." A statement like "vendor risk" is a topic, not a risk.
• Category — technical, financial, legal, people, schedule, external, and so on, to allow grouping.
• Likelihood and impact — each scored on a fixed scale (commonly 1–5), with the scale's meaning defined in advance (e.g. impact 5 = more than 10% of budget or a missed regulatory deadline).
• Score — usually likelihood × impact, used to rank and to place the risk on a heat map.
• Owner — one named person accountable for monitoring and response, not a team.
• Response — avoid, mitigate, transfer, or accept, with the specific actions, their owners, and due dates.
• Residual risk — the score expected after mitigation, so the response's value is explicit.
• Triggers and indicators — the early signal that the risk is materializing (see Key Risk Indicators).
• Status and dates — open, mitigating, closed, or occurred; date raised and date last reviewed.

Building and maintaining one

1. Identify risks from several sources: workshops, a Premortem, SWOT Analysis, Stakeholder Analysis, lessons from past projects, and assumptions in the plan.
2. Write each as cause, event, consequence.
3. Score against the pre-agreed scales; calibrate across raters.
4. Rank, and focus response effort on the top items.
5. Assign owners and mitigation actions with dates.
6. Review on a fixed cadence, re-score, close retired risks, and add new ones. Record risks that occurred, since they become issues.

How it differs from related artifacts

• Risk register vs. Risks Actions Issues Decisions — a RAID log is a broader running log; the register is the deeper, scored view of the risks part, and is often one tab inside a RAID log.
• Risk register vs. Premortem — a premortem is a one-off exercise that generates risks and their assumptions; the register is where those risks are then tracked over time.
• Risk register vs. Key Risk Indicators — indicators are metrics with thresholds; the register holds the risk and references the indicator that signals it.

Common pitfalls

• Vague risk statements — without cause and consequence, nobody can tell what to mitigate.
• Registered once, never reviewed — a stale register gives false comfort; every entry needs a review date.
• Everything is medium — undefined or uncalibrated scales cluster scores; define the scale and force ranking.
• Owner is a team or "TBD" — unowned risks don't get managed.
• Mitigations without actions — "monitor closely" is not a response; name the action, owner, and date.
• Confusing risks with issues — a risk is uncertain future; once it occurs, move it to the issue log and record the outcome.
• Too long to use — hundreds of low-value entries bury the few that matter; prune and cap the active list.

Learn more

• Premortem for a failure-first technique to discover risks.
• Risks Actions Issues Decisions for the surrounding RAID log.
• Key Risk Indicators for monitoring the signals behind each risk.
• Project Management for the wider planning context.