DORA Article 6: the framework on paper, and the RTS that makes it real¶
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.
Level 1 and Level 2, in one paragraph¶
DORA itself is Level 1: the regulation the Parliament and Council adopted. It tells you what must exist. The technical detail comes from Level 2: regulatory technical standards (RTS) and implementing technical standards (ITS), drafted by the three European Supervisory Authorities and adopted by the Commission as delegated regulations. For the ICT risk management framework, the one that matters is Commission Delegated Regulation (EU) 2024/1774, mandated by DORA Article 15. It has 42 articles. If you write your framework from Article 6 alone, you are working from the table of contents and skipping the book.
What Article 6 requires¶
Article 6(1) wants a "sound, comprehensive and well-documented ICT risk management framework" as part of the overall risk management system. Paragraphs (2) and (3) fill in what it protects: information assets and ICT assets, explicitly including hardware, servers, premises, data centres and "sensitive designated areas". Physical security is in scope. People forget that.
Article 6(4) is the governance paragraph: entities other than microenterprises must assign ICT risk oversight to a control function with "an appropriate level of independence", and keep risk management, control and internal audit segregated, "according to the three lines of defence model, or an internal risk management and control model". Worth knowing: this paragraph has no Level 2 counterpart. The RTS does not tell you how to build your second line. This one is on you and your supervisor's expectations.
Paragraphs (5) to (7) are the maintenance loop. The framework is documented and reviewed at least once a year, and additionally after major ICT incidents, supervisory instructions, or lessons from testing and audits. It gets audited internally by auditors with sufficient ICT knowledge, and audit findings feed a formal follow-up process. The review produces a report, and that report is not free-form: Article 15(g) mandated an RTS on exactly its content and format, which became Article 27 of RTS 2024/1774. If your framework review report does not follow Article 27, you have written the wrong document.
Article 6(8) is the digital operational resilience strategy, points (a) to (h): link to business strategy, risk tolerance, information security objectives with KPIs, reference architecture, detection mechanisms, current resilience evidenced by incident numbers, testing, and a communication strategy for disclosable incidents. The RTS quotes this article by name. RTS Article 2 requires ICT security policies to align with "the digital operational resilience strategy referred to in Article 6(8)", and RTS Article 3 requires documented approval of the risk tolerance level "established in accordance with Article 6(8), point (b)". The strategy is not a shelf document; the Level 2 text hooks into it directly.
Paragraphs (9) and (10) are optional but interesting: a holistic multi-vendor strategy for ICT third parties, and the option to outsource verification of ICT risk management compliance, with the entity remaining "fully responsible". Neither has an RTS counterpart for full-scope entities.
The artefact: Article 6 mapped to the RTS¶
This is the mapping I wish someone had handed me on day one.
| DORA Art. 6 | What it demands | Where it gets concrete |
|---|---|---|
| 6(1) | The framework itself | Umbrella for all of RTS Title II (Arts. 2 to 27) |
| 6(2) | Protect information, ICT and physical assets | RTS Art. 2 (general policy elements), Art. 18 (physical and environmental security) |
| 6(3) | Minimise impact, inform the supervisor on request | RTS Arts. 8 to 17 (operations, capacity, patching, logging, networks, projects, changes) |
| 6(4) | Independent control function, three lines of defence | Level 1 only, no RTS counterpart |
| 6(5) | Annual review plus a review report | RTS Art. 27 (format and content of the report) |
| 6(6) | Internal ICT audit | Level 1 only; RTS Art. 27 only asks the report to cite audit results |
| 6(7) | Follow-up on audit findings | Level 1 only |
| 6(8) | Digital operational resilience strategy | Quoted directly in RTS Arts. 2 and 3 |
| 6(9) | Multi-vendor strategy (optional) | Level 1 only |
| 6(10) | Outsourced compliance verification (optional) | Level 1 only for full-scope entities; mirrored in RTS Art. 28(3) for the simplified regime |
Two practical conclusions from that table. First, the "Level 1 only" rows are where supervisory judgement fills the space, so that is where you should document your reasoning hardest. Second, everything else already has a specification: the RTS articles are a ready-made table of contents for your policy inventory. Encryption policy, RTS Articles 6 and 7. Patch management, Article 10. Logging, Article 12. Network security, Article 13. Write the framework from the RTS backwards and Article 6 compliance falls out as a by-product.
Proportionality: the simplified regime¶
Smaller entities listed in DORA Article 16(1), such as small and non-interconnected investment firms, get a simplified framework instead of Articles 5 to 15. The RTS gives them their own Title III, Articles 28 to 41: scaled-down governance, security, continuity and reporting requirements. One detail I find remarkable: RTS Article 28 quietly brings audit and follow-up obligations into the simplified regime even though Article 16 itself does not spell them out. Proportionality reduces the load; it does not remove the discipline.
What the supervisors did with it¶
The ESAs published the final draft of this RTS in January 2024 after a consultation that drew more than 420 responses, and they explicitly reworked it for "greater proportionality" before submitting it to the Commission (ESAs press release, 17 January 2024).
In Germany, BaFin ran six joint working groups with industry and the Bundesbank, over 30 sessions, comparing DORA against its own BAIT and VAIT circulars, and published guidance notes on the transition. BaFin also stated its intention to abrogate the BAIT, VAIT, ZAIT and KAIT circulars as DORA applies (BaFin, 19 September 2024). If your ISMS was built on BAIT or VAIT, the mapping work is not optional; the old rulebook is going away.
More DORA material lives in the DORA branch of the resource library. Next in this series: Articles 7 and 8, ICT systems and the identification exercise that everything else depends on.