Articles 7 and 8 made you write down what you run. Article 9 is where DORA tells you to defend it, and where the RTS drops the high-level language and starts naming specific controls: encryption, patching, logging, network segmentation. Today, protection and prevention, and the exact technical standards behind each word.
The oversight post ended with DORA on one page: a table matching each Level 1 article to the Level 2 standard that makes it concrete. A table is a decent start. But the DORA package isn't really a table — it's a graph. Fourteen legal acts, 215 articles, and a web of implements-links and cross-references that a table flattens out. So I built the version you can actually navigate.
Article 5 gave the board the accountability, Article 6 gave you the framework and its RTS. Articles 7 and 8 are where the real work starts, because they demand something most organisations quietly do not have: a complete, current picture of what they actually run. Today: ICT systems and the identification exercise everything else depends on.
Article 5 put the management body on the hook. Article 6 describes the thing they are on the hook for: the ICT risk management framework. And here is where most DORA write-ups stop too early, because Article 6 is only half the text you need. The other half lives in a delegated regulation most people have never opened. Today I want to connect the two.
DORA gets treated like an IT project. Article 5 says otherwise. It is the first substantive article of the regulation, it is about governance, and it puts the board on the hook before a single firewall rule is mentioned. Today I want to walk through what Article 5 requires, what the defined terms actually mean, and what this looks like in practice.
Most writing about regulation answers the wrong question. It tells you what the rules say. It rarely tells you what to build.