Risk Registers Don't Work

I’m going to say something that might be controversial: your risk register is probably lying to you.

Not deliberately. It’s a faithful record of what your risks looked like the last time someone bothered to update it. The problem is that was probably three months ago, and the threat landscape has changed four times since then.

I was reviewing a client’s risk register recently and found an entry for “emerging AI-related risks” rated as medium likelihood, medium impact, with a review date six months out. Meanwhile, their development teams had already deployed half a dozen AI agents, their competitors had been hit by a deepfake-enabled fraud, and a critical vulnerability in an AI library they used had been disclosed and exploited in the wild. All within the quarter. The risk register hadn’t budged.

We’re using a quarterly snapshot tool in a real-time threat environment. It’s like checking the weather forecast once a season and being surprised when it rains.

What’s wrong with risk registers?

Let me be clear, I’m not saying risk registers are useless. They serve a purpose. They create accountability, they force documentation, and they give leadership something to review. But they have fundamental limitations that become more dangerous as the pace of change accelerates.

They’re point-in-time. A risk register captures the state of play at the moment someone filled it in. By the time it’s reviewed, it’s stale. In a world where a new critical vulnerability can go from disclosure to exploitation in hours, point-in-time assessment is dangerously inadequate.

They incentivise paperwork over action. I’ve seen teams spend more time debating whether a risk should be rated 3.5 or 4.0 on some arbitrary scale than actually doing something about it. The risk register becomes an end in itself rather than a tool that drives decisions.

They struggle with interconnected risks. Real-world risks don’t sit in neat rows on a spreadsheet. They interact, compound, and cascade. A supply chain compromise that coincides with a critical vulnerability in your AI provider while you’re in the middle of a cloud migration, the risk register treats these as three separate items. Reality treats them as one very bad week.

They create a false sense of completeness. If it’s on the register, it’s “managed.” If it’s not on the register, it doesn’t exist. This leads to a dangerous blind spot for novel risks that don’t fit existing categories.

What a risk radar looks like

The alternative isn’t to abandon structured risk management. It’s to evolve it. Think of it as moving from a paper map to a GPS. The map was useful, but it didn’t update in real time, it couldn’t warn you about traffic, and it certainly couldn’t reroute you when a road was closed.

A risk radar has several characteristics that differentiate it from a traditional risk register:

Continuous data feeds, not periodic updates

Instead of waiting for someone to manually update a risk assessment, a risk radar ingests data continuously from multiple sources:

Threat intelligence feeds that reflect what’s actually being exploited in the wild right now
Vulnerability scanning data that shows your current exposure, not last month’s
Control monitoring data that confirms whether your mitigations are actually working
Business context data that reflects what’s changed in your environment, new deployments, new vendors, new products, organisational changes
External signals like regulatory changes, industry incidents, and supply chain disruptions

The risk picture updates as the underlying data changes, not when someone opens a spreadsheet.

Dynamic risk scoring

Traditional risk scoring is static, someone assigns a likelihood and impact rating based on their judgment at a point in time. A risk radar calculates risk scores dynamically based on current data.

For example, a vulnerability in your web application framework might be rated medium risk in your static register. But if threat intelligence shows active exploitation, your external scanning confirms you’re exposed, and your control monitoring shows your WAF rule for that vulnerability failed its last test. The dynamic score should be screaming red. Automatically. Without waiting for a human to reassess it.

This doesn’t mean you eliminate human judgment. It means you augment it with real-time data so that judgment is applied to the right problems at the right time.

Interconnection mapping

Risks don’t exist in isolation. A good risk radar maps dependencies and cascading effects:

If this vendor is compromised, which of our services are affected?
If this vulnerability is exploited, what’s the blast radius given our current segmentation?
If this AI model changes behaviour, which business processes are impacted?

Mapping these interconnections means you can identify compound risk scenarios that a flat risk register would miss entirely.

Threshold-based alerting

Instead of reviewing risks on a schedule, you set thresholds that trigger alerts when conditions change:

A risk score crosses a predefined threshold → alert to the risk owner
A control test fails for a critical risk mitigation → escalation to security leadership
A new vulnerability is disclosed affecting a system in your critical path → immediate notification

This shifts the operating model from “pull” (we go and check periodically) to “push” (the system tells us when something needs attention).

How to get there practically

If you’re thinking “this sounds expensive and complicated,” you’re partially right. But the journey doesn’t have to be all-or-nothing. Here’s a phased approach.

Phase 1: Automate the data you already have

You’re probably already collecting most of the data you need. Vulnerability scans, threat intelligence, control monitoring results, incident data. It’s just sitting in different silos.

Start by integrating your existing data sources into a single view. This doesn’t require a fancy platform. I’ve seen effective risk radars built on top of existing SIEM platforms, business intelligence tools, or even well-structured dashboards.

The key question: can I see, in one place, what my top risks are based on current data rather than last quarter’s assessment? If not, start there.

Phase 2: Add dynamic scoring

Take your top 10 or 20 risks and define scoring rules based on observable data. You don’t need to do this for every risk on your register, start with the ones that matter most.

For example: “Supply chain compromise risk” scored based on the number of critical vendors with recent security incidents + your assessment of their control maturity + any relevant threat intelligence. Update the score daily. Compare it to your static register rating. I guarantee they’ll diverge, and the dynamic score will be more accurate.

Phase 3: Build the interconnection map

Start mapping the relationships between your risks, your assets, and your controls. When a vulnerability is disclosed, you should be able to trace from the vulnerability → to the affected systems → to the business services they support → to the controls that mitigate the risk → to the risk owners who need to act.

This is where graph databases and dependency mapping tools come in. It doesn’t have to be perfect, even a basic dependency map is infinitely more useful than none at all.

Phase 4: Implement threshold-based alerting

Once your data is flowing and your scoring is dynamic, set up alerts for the conditions that require action. This closes the loop from “we have data” to “we act on data.”

Keep the alert thresholds tight initially and tune them over time. Too many alerts and people will ignore them. Too few and you’ll miss important changes.

The human element

A risk radar doesn’t replace human judgment. It enhances it. The goal isn’t to automate risk management decisions. It’s to make sure the right information reaches the right people at the right time so they can make better decisions faster.

The risk committee still meets. The risk owners still make decisions. But instead of reviewing stale data on a quarterly basis, they’re working with current information and spending their time on decisions rather than data gathering.

In my experience, the biggest barrier to this shift isn’t technology, it’s culture. People are comfortable with the quarterly review cycle. It’s predictable. It’s manageable. Moving to a continuous model feels relentless. But the threats we face are relentless, and our risk management approach needs to match.

Questions to take back

When was the last time your risk register fundamentally surprised you? If the answer is “never,” it’s probably not telling you anything useful.
How long does it take for a significant external event (a new threat, a major breach, a regulatory change) to be reflected in your risk assessment? If it’s more than a week, you’re operating blind for that period.
Could your current risk management approach have detected the compound risk scenario that would actually hurt your organisation? Or does it only track individual risks in isolation?
What data are you already collecting that could feed a more dynamic risk picture, but isn’t being used for that purpose?

The world doesn’t update its threats on your review schedule. Your risk management shouldn’t either.

Time to upgrade from the map to the GPS.