There's a scene that repeats itself in organisation after organisation, one that is honestly frustrating and irritating to me as a cybersecurity expert.
A meeting room. A whiteboard. Someone has opened a spreadsheet called "Risk Register 2026 FINAL v7". The coffee is strong, time is tight, and the atmosphere feels oddly comfortable. Not because the situation is safe, but because the process is familiar, just like the cinnamon buns from the local café. A risk matrix with red, yellow, and green is drawn up. They discuss "likelihood" and "impact" on a five-point scale. They agree on a few phrases that sound serious:"Increase awareness","Review procedures","Conduct annual exercise". Then they save, archive, and move on.
It looks serious. Itfeelslike governance. But when the next incident comes, such as ransomware, supplier issues or a cloud configuration error, when a DDoS attack happens, or a misconfigured permission is discovered, it often turns out the organisation has built a map over coffee of a landscape that has already changed shape – it no longer even matches reality.
Welcome to today's performance of "risk theatre" presented by Circus Risk. Here is a show that highlights the difference between documented security and evidence-basedcapability.
Risk theatre in practice: a fire extinguisher that only exists on a PowerPoint slide
The risk matrix and register in the example above aren't "wrong". The problem is how they're used as a substitute for operational resilience; the risk method has become a tick-box exercise.
Traditional risk matrices often rely on ordinal scales (1–5) which are then treated as mathematically precise. This leads to well-known and documented issues. Rankings can be reversed, differences compressed, and uncertainties lost in the colouring. The result may look neat but isn't robust. It's like the old saying: lies, damned lies and statistics.
More specifically, it's like measuring fever with a colour scale ("quite red"), comparing patients by "feel" and calling it medical precision. What looks like control in the risk matrix is actually false control and lacks effective sensors from an all-risk perspective.
Why does risk theatre persist? Psychology, governance and social incentives
If risk theatre is so weak, why do so many keep doing it? The answer is simpler than you might think.
It provides immediate reassurance.A heatmap is like a weather map: it gives the brain a quick overview. Management likes speed. The problem is it's often more rhetoric than reality check.
It creates a sense of objectivity.Five-point scales feel "fair". Everyone gets a say. But it often ends up a compromise between opinions rather than a reading of actual capabilities.
It fits bureaucratic reward systems.The process rewards those who write best and "put the picture together". It doesn't necessarily reward those who ensure the organisation can restore, detect, isolate, communicate and keep operations running.
It suits a world of audit trails but in the wrong way.Many believe compliance means documents. But modern regulation and best practice point in another direction: systematic approaches, testability and continuous improvement, not annual rituals.
Why it fails to deliver real resilience and continuity
Cyber incidents are effectivelycapability interruptions, interruptions of availability, integrity, confidentiality, traceability. In concrete terms, they are interruptions to business delivery.
The most common incident patterns reported in recent years are strongly linked to:
Social engineering and phishing.
Ransomware/extortion.
Supplier and ecosystem risks.
Availability disruptions.
The point is clear. Threats are real, repetitive and rapidly changing. Measuring "risk" as an annual temperature on a five-point scale produces a governance model designed for a world where nothing changes. But digital ecosystems are the opposite. They change constantly. That's precisely why risk theatre creates false security. You think you "have it under control" because you have assessed but you haven't proven you can.
What the regulations actually signal: from paperwork to capability
Two clear signals from the EU's modern cyber regulations should be clear by now:
Risk management should translate into appropriate, proportionate actions as part of a systematic approach. NIS2 emphasises risk management as culture and practical capability, not a one-off exercise. Risks can't be zero, but they can be negligible, transferred, managed, accepted… PROPORTIONATELY.
Operational resilience and continuity are central, especially in DORA for the financial sector. The focus is on ICT risk management, incidents, testing and operational resilience.
In practice: legislation points to organisations needing to show they have capabilities (policies, processes, controls, testing, improvement) not just a documented "risk picture". This doesn't mean "risk" disappears. It means risk becomes a conclusion from capability, not a guess hoping to be right.
The better alternative: swap "risk assessment" for "vulnerability picture through proven control capability"
Here comes the shift that often feels disruptive, but is actually logical. Those who know me by now know I'm indeed disruptive.
So what if Circus Risk puts on a new show?
Circus Risk asks:
"What is the likelihood (1–5) that something will happen?"
Resilience Theatre asks:
"Which known threats are relevant, and which controls must be in place to reduce vulnerability? What is demonstrably missing? What capabilities do we need?"
The difference is between:
Step 1: Start with recognised threats, not abstract risks
Begin with public threat landscapes and incident data: for example, ENISA's threat landscape and industry reports. This provides a common factual basis: "this keeps happening over and over".
Step 2: Translate threats into required controls
For each threat you need a small, clear "resilience package":
what must be in place to reduce vulnerability?
what is the minimum standard ("baseline")?
what is the systematic approach over time?
There is also support in best practice summaries and meta-reviews on which controls actually have effect (not always huge effect, but measurable and relevant).
Step 3: Measure the gap as vulnerability (not "risk")
This makes it clearer for management:
The threat: ransomware, phishing, cloud misconfiguration, DDoS, supply chain.
Capability requirements: a small selection of controls that must be "at least in place".
Vulnerability: the difference between what's required and what actually exists.
This is a vulnerability model that is easy to understand: "We lack X and Y, so we are exposed."
Step 4: Turn actions into a maturity ladder with a timeline
What's often missing in risk theatre is an actionable "next steps" logic. In a capability model, actions become natural:
1–3 months: close the most urgent gaps for quick vulnerability reduction.
3–6 months: expand, standardise, secure suppliers.
6–12 months: systematic approach, measurement, recurring testing and improvement.
It becomes crystal clear:
(1) where it hurts,(2) what it means for the business,(3) what to do next, and(4) how to follow up to ensure it's done.
"But we have to do risk analyses"
Yes, but risk analysis doesn't have to mean risk matrix. NIS2/DORA emphasise risk management as systematic and action-oriented. What you want is controllable risk through proven capability. THEN vulnerabilities and capability are more effective than risk matrices.
References
ENISA. (2023).ENISA Threat Landscape 2023.
Krisper, M. (2021).Problems with Risk Matrices Using Ordinal Scales.
National Institute of Standards and Technology. (2022).Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218).
National Institute of Standards and Technology. (2024).Incident Response Recommendations and Considerations for Cybersecurity Risk Management (NIST SP 800-61 Rev. 3).
Verizon. (2024).Data Breach Investigations Report (DBIR).
Zimmermann, V., & Renaud, K. (2021).The nudge puzzle: Matching nudge interventions to cybersecurity decisions.
Wiley (Risk Analysis). (2022/2023).How People Understand Risk Matrices, and How Matrix Design Can Improve Comprehension.
Bada, A. et al. (2024).Evidence-based cybersecurity policy? A meta-review of security controls.
European Union. (2022).Directive (EU) 2022/2555 (NIS2).
European Union. (2022).Regulation (EU) 2022/2554 (DORA).
