Risk Registers that Actually Work

How to turn the most maligned governance artefact into a living instrument for preventing failure

The risk register sits unloved in the project folder. It was last updated three weeks ago, during a governance meeting where everyone stared at a spreadsheet and mumbled reassurances about mitigation plans. Two risks marked “green” are quietly destroying the programme. The real threats haven’t been written down at all.

You know this pattern. The risk register has become a compliance theatre — evidence that governance is happening, not a tool that actually prevents problems. It doesn’t have to be this way.

A risk register that actually works is specific, honest, and actively used. It focuses attention on threats that matter. It prompts genuine investigation rather than comfortable reassurance. And crucially, it tells you what to do on Monday morning, not just what to worry about in the abstract.

————————

Why Most Risk Registers Fail

The dysfunction starts with how we populate them. Someone creates a template with columns for Likelihood, Impact, RAG rating, and Mitigation. A workshop is convened. People throw out concerns in a slightly awkward round-robin. “Resource availability.” “Stakeholder engagement.” “Technical complexity.” These are written down, scored on a 1–5 scale, and colour-coded. Everyone feels productive.

The resulting document is simultaneously too long and too vague. It contains twenty risks that all sound the same. The scores are arbitrary. The mitigations read like defensive statements rather than action plans. “Continue to monitor.” “Escalate if needed.” “Maintain close communication with stakeholders.”

The real problems are:

Vagueness replaces specificity. “Stakeholder resistance” could mean anything from a minister vetoing the programme to a single team member preferring the old system. The register doesn’t distinguish between them.

Scoring becomes ritual. Likelihood and impact ratings are debated as if they’re objective measurements. They’re not. They’re collective guesses, often influenced more by organisational politics than by evidence. A risk that might embarrass senior leadership gets scored lower than it should.

Static documents in dynamic environments. The register is reviewed monthly at a governance board. Meanwhile, the real threats evolve daily. By the time the board discusses a risk, it’s already materialised or been overtaken by events.

No link to action. The mitigation column describes what should happen in principle. It rarely specifies who will do what by when. The register becomes a list of worries, not a plan for action.

The result is predictable. When the programme encounters serious trouble, someone opens the risk register and discovers the actual problem wasn’t listed. Or it was listed but scored “low.” Or it was there but the mitigation plan was never executed.

————————

The Structure of a Working Risk Register

A functioning risk register is not a spreadsheet full of vague concerns. It’s a structured instrument that identifies specific threats, links each threat to evidence, and drives concrete action.

Here’s what that looks like in practice:

Risk Description: Be Brutally Specific

Replace generic categories with precise statements. Not “data migration risk” — instead: “Patient records for 47,000 individuals currently stored in the legacy PAS system contain non-standard date formats and free-text clinical notes that cannot be automatically parsed by the new EPR platform. Attempting bulk migration will corrupt appointment histories.”

Specificity forces honesty. It’s harder to mark a risk as “green” when you’ve written down exactly what will break and why. It also makes the mitigation plan obvious — you now know which 47,000 records need manual review and which data fields are problematic.

The description should answer:

• What specific event or condition threatens the programme?
• Which part of the system or organisation is affected?
• What would trigger or accelerate this risk?

A good test: if you removed the risk from your register and showed it to someone unfamiliar with the programme, could they understand the threat without further explanation? If not, it’s too vague.

Evidence and Indicators: What Are You Actually Observing?

For each risk, document the evidence that makes you believe it’s real. This might be:

• Direct observation (“Three of the five clinical leads have stated in writing that they will not participate in user testing”)
• Historical precedent (“The last two digital programmes in this trust experienced 40%+ staff turnover during implementation”)
• Technical analysis (“Load testing shows the authentication service fails under 200 concurrent users; we expect 800+ at go-live”)
• External intelligence (“The supplier announced redundancies in their UK support team last quarter”)

The evidence section serves two purposes. First, it prevents phantom risks — vague fears with no grounding in reality. Second, it establishes what you’re monitoring. If the evidence changes, the risk assessment should change.

Include early warning indicators. What would you observe if this risk was starting to materialise? For the data migration example above, early warnings might include: “Manual sample testing of 500 records reveals parsing errors in 12%+ of cases” or “Migration team raises concerns about timeline in three consecutive sprint retrospectives.”

Impact: Describe the Actual Consequence

Replace numeric scores with descriptions of real-world consequences. Not “Impact: 4” — instead: “Programme go-live delayed by 3–6 months. Trust continues paying £180k/month for parallel-running legacy systems. Clinical staff lose confidence in digital transformation. Two neighbouring trusts postpone their own EPR procurements pending outcome.”

This forces you to think through the chain of effects. A technical failure isn’t just a technical problem — it has operational, financial, and reputational consequences. Writing them down clarifies what you’re actually trying to prevent.

For different risk categories, impact descriptions will vary:

Delivery risks — Timeline delays, budget overruns, scope reduction, programme cancellation.

Operational risks — Service disruption, patient safety incidents, regulatory non-compliance, staff burnout.

Strategic risks — Loss of stakeholder confidence, policy reversal, reputation damage, lost opportunity for wider transformation.

Technical risks — System outages, data loss or corruption, security breaches, integration failures.

The impact statement should be specific enough that a decision-maker can weigh it against the cost and effort of mitigation. “We might miss the deadline” doesn’t enable decision-making. “We will miss the April go-live, requiring a six-month extension and a return to the Treasury for additional funding” does.

Mitigation: Turn Worries into Work

This is where most risk registers collapse into useless abstraction. “Monitor closely” is not a mitigation. Neither is “escalate to SRO if needed.”

A real mitigation plan has three components:

Immediate action — What gets done this week to reduce the likelihood or impact? Who owns it?

Contingency preparation — If the risk materialises despite mitigation, what’s the fallback plan?

Monitoring cadence — How often will this risk be reviewed, and what evidence will trigger escalation?

For the data migration risk described earlier, an actual mitigation plan might read:

Immediate action: Data quality lead to manually review 1,000 randomly sampled patient records by Friday. Identify all non-standard date formats and free-text patterns. DevOps team to build parsing exception-handling into migration scripts by end of sprint.

Contingency: If exception rate exceeds 15%, defer migration of affected records. Implement dual-running period where clinical staff verify migrated data against legacy system for 30 days before legacy decommissioning.

Monitoring: Sample testing of 500 records per week during migration phase. Any batch with 10%+ parsing errors pauses migration for immediate investigation. Risk reviewed in daily migration stand-up.

Notice the specificity. You could hand this to someone on Monday morning and they would know exactly what to do.

Ownership: Name Names

Every risk needs a named owner — a single person accountable for ensuring mitigation happens and for escalating if the risk status changes. Not “Delivery Team” or “Technical Workstream.” A person. With a job title and an email address.

The owner doesn’t have to personally execute all the mitigation work, but they are responsible for ensuring it happens and for raising the alarm if it doesn’t.

In a large programme, you might have a second-level structure: a risk owner (who manages the mitigation) and a risk decision-maker (who approves contingency actions or accepts the risk). Make these roles explicit.

————————

A Worked Example: NHS Digital Transformation Programme

Let’s apply this to a realistic scenario — a mid-sized NHS trust implementing a new Electronic Patient Record (EPR) system. The programme has a £12 million budget, an 18-month timeline, and involves replacing three legacy systems used across four hospital sites.

Here’s how a traditional risk register might list one of the major threats:

This tells you almost nothing. Which stakeholders? What kind of engagement problem? What happens if the mitigation fails?

Here’s the same risk in a working register:

————————

Risk ID: R07

Category: Operational / Change Management

Owner: Sarah Chen, Associate Director of Digital Transformation

Decision-maker: Mike Okafor, Deputy Chief Executive

Description:

The Emergency Department (ED) consultant body has historically opposed digital record systems, citing concerns about clinical safety and workflow disruption. Three of the four ED consultants did not participate in the EPR requirements workshops. In the previous PAS upgrade (2019), ED consultants delayed go-live by refusing to sign off on the system, resulting in a parallel-running period that cost £220k.

If ED consultants do not actively engage with EPR design and testing, they are likely to withhold clinical sign-off at the final governance gate. This would force either a delayed go-live or a go-live without ED, creating a critical gap in the patient pathway.

Evidence and Indicators:

• Only 1 of 4 ED consultants attended EPR requirements workshop (October 2024)
• ED Clinical Director stated in writing: “We will not be rushed into a system that compromises patient safety” (email 12 Nov 2024)
• Historical precedent: 2019 PAS upgrade delayed 4 months due to ED sign-off refusal
• ED staff survey (Nov 2024) shows 62% believe “digital systems slow down clinical work”

Early warning indicators:

• Continued absence from user testing sessions (next session: 15 Jan)
• Formal request to be excluded from Wave 1 go-live
• ED staff raising safety concerns through clinical governance route
• ED consultants escalating concerns directly to Medical Director

Impact:

Programme go-live delayed by 3–6 months OR programme proceeds with ED excluded from Wave 1, creating a critical patient pathway gap. Patients transferring between ED and inpatient wards would require manual data re-entry, increasing error risk and reducing care quality.

Financial impact: £180k for each additional month of parallel-running legacy systems. Reputational impact: loss of clinical confidence in digital programme, reduced participation in future transformation initiatives.

Mitigation Plan:

Immediate actions (this month):

• Sarah Chen to arrange 1:1 meetings with each ED consultant before Christmas. Objective: understand specific clinical safety concerns and workflow worries. (By 20 Dec)
• Clinical Safety Lead to conduct walkthrough of ED workflows using EPR demo environment with ED consultants. (By 10 Jan)
• Programme to commission independent clinical safety assessment of EPR in ED context from external ED consultant. (Commissioned by 6 Jan, report by 31 Jan)

Medium-term actions (next quarter):

• Establish ED-specific user testing group with protected time for ED consultants. Minimum 2 consultant participants for each testing cycle. (First session 15 Jan)
• Technical team to implement ED-requested workflow modifications if clinically justified and technically feasible. (Assessed by 31 Jan, implemented by 28 Feb if approved)
• SRO to present EPR approach at ED Consultant meeting with explicit invitation for concerns to be raised. (Meeting 22 Jan)

Contingency:

If ED consultants remain opposed after above actions:

• Seek Medical Director intervention to mandate participation
• Offer extended go-live timeline with ED as Wave 2 (6 months after main hospital), allowing ED to observe benefits in other departments
• Commission independent external review of ED safety concerns to validate or refute objections
• If engagement remains impossible, escalate to Trust Board for decision on whether to proceed without ED or delay entire programme

Monitoring cadence:

• Weekly review in programme board (attendance tracking, sentiment analysis)
• Fortnightly 1:1 check-ins between Sarah Chen and ED Clinical Director
• Risk escalated to SRO immediately if: ED formally requests exclusion from go-live; ED raises safety concerns through clinical governance; fewer than 2 ED consultants participate in testing

Status: Active

Last reviewed: 4 December 2024

Next review: 11 December 2024

————————

Notice the difference. You know exactly what the problem is. You know what will happen if it materialises. You know who’s doing what by when. You know what you’re watching for. And you know what you’ll do if mitigation fails.

This is a risk register entry you can actually use.

————————

Risk Categories That Reflect Real Threats

Generic risk categories (strategic, operational, financial, reputational) encourage generic thinking. Better categories reflect the actual failure modes of your type of programme.

For a digital transformation programme, consider:

Technical Integration Risks — Will the systems actually talk to each other? Data migration failures. API incompatibilities. Performance under load. Security vulnerabilities.

Clinical Safety Risks — Could the new system harm patients? Medication errors due to interface design. Missed test results. Clinical workflow disruption during critical care moments.

Change and Adoption Risks — Will people actually use it? Staff resistance. Inadequate training. Workflow design that doesn’t match real clinical practice. Workarounds that undermine the system.

Supplier and Dependency Risks — Will external parties deliver? Vendor delays. Key personnel leaving the supplier. Scope disagreements. Support and maintenance quality.

Regulatory and Compliance Risks — Will we meet legal and professional standards? Data protection failures. Failure to meet NHS Digital standards. CQC compliance issues.

Benefits Realisation Risks — Even if implemented successfully, will it actually deliver value? Benefits case based on unrealistic assumptions. Changes in the external environment that invalidate the original case. Inability to measure benefits.

These categories direct attention to where failure actually happens. They’re harder to answer with comfortable platitudes.

For other programme types, adjust accordingly:

Infrastructure programmes — Planning and consenting. Land acquisition. Environmental impact. Community opposition. Construction quality. Contractor performance.

Organisational change programmes — Leadership commitment. Middle management resistance. Cultural misalignment. Competing priorities. Communication breakdown.

Policy implementation programmes — Legislative delays. Political reversal. Unintended consequences. Implementation capacity in delivery bodies. Public reaction.

The categories should reflect your actual experience of where things go wrong, not a textbook taxonomy.

————————

The Update Cycle: Making It a Living Document

A risk register that sits untouched between monthly governance meetings is useless. Real threats evolve faster than that.

Establish three rhythms:

Daily or weekly operational review — The delivery team scans the register for any risks where early warning indicators have been triggered. This is a 15-minute stand-up, not a formal meeting. “Any change in risk status? Any new evidence? Anything we’re seeing that’s not on the register?”

Fortnightly detailed review — Risk owners report on progress against mitigation actions. This is where you update the evidence section, adjust timelines, and decide whether to escalate or close risks. This might be part of a programme board meeting or a dedicated risk review session.

Monthly governance review — The SRO and programme board focus on the top 5–8 risks (usually those with the highest unmitigated impact). The question isn’t “What’s the RAG status?” — it’s “What have we learned about this risk in the past month, and does that change our mitigation approach?”

Between these formal reviews, the register should be a working document. When someone discovers new information about a risk, they update the evidence section immediately. When a mitigation action completes, it’s marked done. When a new threat emerges, it’s added within 48 hours, not deferred until the next scheduled review.

This requires the register to be genuinely accessible. A locked SharePoint file that requires three permissions and a VPN isn’t going to be updated in real-time. Use a tool that allows concurrent editing, version history, and notifications when high-impact risks are updated.

————————

Common Pitfalls and How to Avoid Them

Pitfall 1: Optimism bias in scoring

Teams habitually underestimate likelihood and impact, especially for politically sensitive risks. The trust’s relationship with a difficult supplier is marked “low impact” because no one wants to admit dependency. The possibility of the SRO leaving mid-programme is omitted entirely because it seems disloyal to mention.

How to avoid it: Use reference class forecasting. What happened in similar programmes? The IPA Annual Report 2019-20 shows that major UK Government programmes frequently experience 2–3 year delays and 50–100% budget overruns. If your register shows all risks as “low” or “amber,” you’re probably underestimating.

Pitfall 2: Treating the register as a blame document

People stop reporting risks honestly if they fear the register will be used against them. “Why didn’t you flag this sooner?” becomes a weapon. The result: risks are sanitised, genericised, or omitted.

How to avoid it: Establish a cultural norm that adding a risk to the register is responsible behaviour, not an admission of failure. The SRO should explicitly praise people who identify and escalate risks early. Consider adapting the principles from blameless incident reviews — focus on what the organisation learned, not who failed to spot it sooner.

Pitfall 3: Action-free mitigation plans

“Monitor closely” and “maintain regular communication” are not mitigations. They’re descriptions of general good practice. They don’t reduce the likelihood or impact of anything.

How to avoid it: Every mitigation plan must include at least one action with a named owner and a deadline. If you can’t think of any action that would reduce the risk, either the risk is unavoidable (in which case, state that explicitly and focus on contingency planning) or you don’t understand the risk well enough yet (in which case, your immediate action is to investigate further).

Pitfall 4: Zombie risks that never close

Risks that were relevant six months ago remain on the register even though circumstances have changed. The register grows to 40+ entries. No one can remember which ones matter.

How to avoid it: Actively close risks when they’re no longer relevant. “Legacy system decommissioning risk” gets closed when the legacy system is actually decommissioned. Archive closed risks (don’t delete them — they’re useful for post-programme learning) but remove them from the active register. Keep the active register to 15–20 entries maximum.

Pitfall 5: Confusing risks with issues

A risk is something that might happen. An issue is something that’s already happening. Mixing them in the same register creates confusion.

How to avoid it: Maintain a separate issues log for problems that have materialised. When a risk becomes an issue, close it in the risk register and open it in the issues log. The issues log has a different structure — it focuses on resolution plans and tracking progress, not on likelihood and mitigation.

————————

Tools and Templates

You don’t need expensive risk management software. A well-maintained spreadsheet or a shared document can work perfectly well for programmes with 15–20 active risks.

If you do want tooling, look for:

• Concurrent editing with version history (Google Sheets, Microsoft Excel Online, Airtable)
• Ability to filter and sort by category, owner, or status
• Automated notifications when high-impact risks are updated
• Easy export for governance reporting

Avoid tools that impose complex workflows or require dedicated administrators. The tool should make updating the register easier, not harder.

For very large programmes (£100m+, multi-year, 50+ active risks), consider dedicated risk management platforms like Resolver, LogicManager, or Archer. But start simple. If your team isn’t maintaining a spreadsheet-based register effectively, a fancy platform won’t solve the problem.

A minimal working template:

————————

Closing Questions: Is Your Risk Register Working?

Ask yourself:

• If I opened the risk register right now, would it identify the three biggest threats to programme success?
• Could someone unfamiliar with the programme read a risk description and understand the specific threat without asking for clarification?
• Does every risk have a mitigation plan with named owners and deadlines for specific actions?
• Has the register changed in the past week based on new information, or is it static between governance meetings?
• When was the last time someone added a politically uncomfortable risk to the register?

If you answered “no” to any of these, the register isn’t working yet. But the structure outlined above will get you there.

A working risk register is not a bureaucratic obligation. It’s a truth-telling instrument. It forces you to name the things that might go wrong before they do. It turns vague anxiety into concrete action. And it gives you a fighting chance of preventing the failures you can see coming.

————————

Related Reading on Failure Hackers

• After Action Review (AAR) Made Practical — How to learn from failures after they occur
• The Signal in the Noise — A story about detecting problems through weak signals before they appear in formal metrics
• Mastering the Five Whys Technique in Remote Teams — Digging beneath surface symptoms to understand root causes

————————

Stay ahead of project failure

Join the Failure Hackers mailing list for tools, frameworks and analysis to help you spot the warning signs before it is too late.