Article 8 of DORA is short and brutal: identify, classify and document your ICT risks, continuously, across everything that supports your business functions. What it does not tell you is where to start. And that is where most risk registers die, in one of two ways.
The first death is the blank page. A two-person compliance team opens an empty register, holds a workshop, writes down the eight risks everyone could think of that afternoon, and never touches the file again. The second death is the copy-paste. Someone imports a generic risk list from a consultant's template, two hundred rows of risks that belong to no system, no function and no owner, and the register is technically full and practically empty.
Both fail the same inspection question: show me how this risk connects to your actual estate.
Why we ship 78 scenarios in the box
DORA GRC comes with a threat scenario register: 78 pre-built ICT threat scenarios covering the ground an ICT risk assessment is expected to cover. Cyber attacks from phishing and ransomware to supply chain compromise. Availability failures in infrastructure, cloud and power. Third-party events from provider insolvency to a subcontractor failing two links down the chain. Data integrity and confidentiality events. People and process failures, from privileged misuse to change gone wrong.
The point of the library is not that 78 is a magic number. The point is coverage and a starting position. The scenarios are sourced from the ENISA Threat Landscape and MITRE ATT&CK, and each one carries its intelligence with it: the ATT&CK techniques, the DORA articles it touches, and a trend signal showing whether the threat is rising or stable. A systematic library means the categories you forgot in the workshop are still in front of you, and the scenario you have never experienced, and therefore never thought of, is on the list anyway. For a small team, it converts risk identification from an authorship problem into a selection problem, which is a much easier problem.
The scenario register: 78 built-in scenarios across cyber, availability, data, third party, operational and compliance, each with likelihood and impact, ATT&CK references and a trend signal.
From scenario to risk: the part that matters
A scenario only becomes a risk when it lands in your world. The workflow in DORA GRC is built around that transition:
- Select. Go through the library and pick the scenarios that are plausible for your estate. Discard the rest, and record that you considered them. A documented "not relevant, because" is evidence too.
- Anchor. Link each selected scenario to the functions, assets and providers it could hit. This is the step that turns a generic sentence into your risk, and it is the step generic templates never survive.
- Assess. Score likelihood and impact, inherit the criticality context from the functions involved, and set the treatment.
- Visualise. The scenario's causes and consequences feed the bowtie, with your controls placed as barriers, so the gap between "we have a risk" and "we manage a risk" is visible.
The chain matters more than any single link: scenario to risk to function to control to test. When the supervisor pulls one thread, the rest follows, and that is precisely what Article 8's mapping is supposed to produce.
💡 Do not import all 78. A register with 78 unowned scenarios is the copy-paste death with better formatting. Pick the fifteen or twenty-five that are real for your estate, anchor every one of them, and give every one an owner. A small register where every risk is connected beats a big one where nothing is. You can always promote more scenarios from the library as your estate changes, and that promotion, dated and reasoned, is exactly the "continuous identification" Article 8 asks for.
The library is also how you stay current
Threats move. The ESAs' statement on frontier AI told financial entities to fold AI-assisted attacks into their risk frameworks, and with a scenario library that is a concrete action instead of a vague ambition: add the AI scenarios, anchor them to the models and providers in your estate, and check which barriers exist on the new paths. The same applies when a new attack pattern makes the news. The question stops being "should we update the risk framework" and becomes "which scenario does this map to, and are we covered".
That is also what makes the library the freshness mechanism, not just the starting point. Each scenario shows where it came from and how the threat is moving, so "are we covered against what is actually happening" has an answer with a date on it.
One scenario, fully loaded: the DORA articles it touches, the ATT&CK techniques behind it, the ENISA source it came from, and the trend. From here it goes straight into the risk assessment wizard.
That is also what makes the annual review honest. Reviewing a register of anchored scenarios means walking the estate and asking what changed. Reviewing a workshop list from two years ago means starting over.
How it fits the rest of DORA GRC
Scenarios feed the risk register, risks feed the bowties, controls double as barriers and as evidence in the compliance tracker, and the risks linked to critical functions surface in the CIF risk exposure view, so the functions with the thinnest coverage are visible at a glance. One dataset, read from four angles.
Sources: Regulation (EU) 2022/2554 (DORA), Articles 6 and 8. ISO/IEC 27005 on information security risk management. ESAs Joint Committee, Statement on frontier AI models (JC 2026 25), 31 July 2026.