A risk register template with owner, likelihood, impact, mitigation and status columns, plus worked example entries that show the difference between a real risk and a filed one.
Most risk registers are graveyards: risks are buried in them so meetings can move on. This template is built to resist that, starting with example rows that show what a genuinely useful entry looks like. Copy it directly from this page; nothing is gated.
Last reviewed 3 July 2026 · Free and ungated
The filled-in register is exactly the artefact operators work from. Selected senior operators from the Global Board examine the decision behind it and report back, confidentially, on the risks it is missing.
Bring independent operator perspectives into this decisionA risk written as "resource constraints" cannot be mitigated, owned or closed, only discussed. The standard this template enforces is that every risk names a specific event, a consequence someone would recognise when it happened, and a mitigation that costs something. The example rows below are written to that standard deliberately, so the register starts with its quality bar visible.
| Risk (specific event and consequence) | Owner | Likelihood | Impact | Mitigation (and its cost) | Status |
|---|---|---|---|---|---|
| The integrator's named solution architect rotates off after design phase, and the replacement reopens settled design decisions, adding 6–8 weeks | Programme director | Medium | High | Named-resource clause with substitution approval rights; design decisions logged with rationale so they survive personnel changes | Open: clause in contract redline |
| Finance restates the cost baseline mid-programme, invalidating the approved benefits case and triggering re-approval | CFO delegate | Low | High | Baseline signed off by finance before gate one and frozen; changes require steering committee decision, not restatement | Mitigated: baseline signed |
| The top-two customer accounts learn of the systems migration and demand contractual service guarantees before renewal | Commercial director | Medium | Medium | Pre-emptive briefing of both accounts with a service-continuity commitment; renewal conversations moved ahead of migration window | Open: briefings scheduled |
| Data quality in the legacy CRM is worse than sampled, extending migration by a quarter and delaying benefit realisation | Data workstream lead | High | Medium | Full-volume profiling before cutover plan is fixed (cost: three weeks of specialist time); benefits phased to decouple from single cutover date | Open: profiling underway |
| Key business-side product owner returns to day job at month four under pressure from their function, stalling decisions | Sponsor | High | High | Backfill for the product owner's role funded from the programme budget; escalation path agreed with their line executive in writing | Open: backfill unfunded |
| Change-request spend breaches its contingency envelope by month six as deferred scope returns | PMO lead | Medium | Medium | Monthly change-spend report to steering committee against a hard envelope; scope deferrals logged with the date they are expected back | Mitigated: envelope reporting live |
| A regulatory change in a core market lands during the freeze window, forcing emergency releases through an untested process | Compliance lead | Low | High | Regulatory horizon scan with a named contact per market; emergency-release path designed and rehearsed before freeze begins | Open: rehearsal not scheduled |
The register is reviewed at every steering or leadership meeting, but reviewed means three questions per open row, not a read-through: has likelihood moved, is the mitigation actually happening, and would we still recognise this risk if it fired? Anyone can raise a risk; only the named owner can change its status; and the register keeper (usually PMO) enforces the writing standard by rejecting rows that name a theme instead of an event. Closed risks stay visible for a quarter, because closed risks have a habit of reopening quietly.
Every register has a missing section: the risks the organisation cannot see because everyone in the room shares the same assumptions. On a vendor programme, that might be a commercial trap that only someone who ran the same vendor relationship would recognise; on an integration, a retention pattern that only shows up post-close. One of the fastest uses of a Digital Advisory brief is having selected senior operators review the register and, more importantly, name what is absent from it, because the deliverable is a list of risks you did not know to write down.
Only if the numbers change behaviour. A five-by-five grid gives false precision when the inputs are judgement calls; three honest levels with a named owner and a costed mitigation beat a heat map that nobody acts on.
For a single programme, eight to fifteen open rows. Fewer suggests the uncomfortable ones are missing; more suggests themes are being logged instead of events, or that closing has stopped. The example entries above show the granularity that keeps the count honest.
Not here. An issue is a risk that has already fired and needs an action log with dates; mixing them lets live problems hide among hypothetical ones. Keep the register for events that have not happened yet and might.