Open your ICT risk register and look at it the way your board does. Forty rows. Ten columns. Likelihood times impact, a colour, an owner. Every row is technically correct, and none of them explains anything.
That gap matters more under DORA than it did before. Article 5 puts the management body in charge of ICT risk, and you cannot own what you do not understand. Article 6 requires a framework that actually manages risk, not one that stores it. So when we built the risk module in DORA GRC, we added something risk engineers in other industries have used for decades: the bowtie diagram.
What a bowtie shows
A bowtie puts one risk in the middle and reads left to right:
- Left side: causes. The threats that could trigger the event. A phishing mail, an unpatched server, a failing supplier.
- Centre: the top event. The moment you lose control. Ransomware detonates. The core system goes down. Customer data leaks.
- Right side: consequences. What happens next. Downtime, regulatory reporting, financial loss, reputational damage.
- Barriers on both sides. Preventive controls on the left stop the causes from reaching the event. Mitigating controls on the right limit the damage when it happens anyway.
The shape looks like a bowtie, and that is the whole trick. One page shows what could go wrong, why, what you have put in the way, and what catches you when prevention fails. The approach lines up with ISO 27005, which our risk methodology follows.
The bowtie for R-020, ransomware encrypts production systems. Three causes on the left, four consequences on the right, and every barrier placed on the path it protects.
Why this beats a table
Three things happen when you draw a risk instead of listing it.
Gaps become visible. A cause with no barrier in front of it is an unmanaged path to the event. In a table that gap hides between columns. In a bowtie it is an empty space anyone can point at. Controls get a purpose. Every control sits on a specific line between a specific cause and a specific event. "Why do we have this control?" stops being a philosophical question. If a control sits on no line at all, that is worth a conversation too. One-sided risk work gets exposed. Many ICT risk registers are all prevention and no mitigation. A bowtie with a crowded left side and an empty right side is a picture of an organisation that has never planned for the day prevention fails. Under DORA, with its focus on response, recovery and resilience testing, that is exactly the imbalance supervisors look for.💡 One risk per page. The fastest way to improve board reporting on ICT risk: pick the top five risks and present each as one bowtie on one slide. The discussion changes immediately, because directors stop asking what the numbers mean and start asking why a barrier is missing. That discussion, minuted, is the Article 5 evidence trail.
A concrete example
Take the top event "ransomware encrypts production systems". On the left: phishing, exposed remote access, a compromised software update. Barriers in front of them: awareness training, MFA, patching, supply chain checks from your vendor due diligence. On the right: backup restore, incident response, communication plans, and the reporting obligations that kick in when the event is major.
Now the AI angle from the ESAs' frontier AI statement becomes easy to place: AI-assisted attackers strengthen the causes on the left side. Your response is either new barriers or stronger ones, and the diagram shows exactly where they go.
How it works in DORA GRC
You do not draw anything. The bowtie is generated from data you already maintain: risks link to threat scenarios, controls and consequences in the register, and the diagram assembles itself from those links.
Causes and consequences are maintained as data, with barrier controls linked to each. The diagram builds itself from these links.
Change a control, and every bowtie it sits on updates. Each risk can be exported as a one-page visual for board packs and audits, and gaps, like a cause without a barrier, are visible the moment they exist rather than at the annual review.Sources: Regulation (EU) 2022/2554 (DORA), Articles 5, 6 and 8. ISO/IEC 27005 on information security risk management. CCPS and ISO 31010 on bowtie analysis as a risk assessment technique.