DORA ICT Risk Management Framework: What to Document

DORA's ICT risk management framework is not one document. Article 6 sets the overall duty, but Articles 8 through 15 break it into eight required building blocks: identification, protection and prevention, detection, response and recovery, backup, learning and evolving, communication, and a harmonised RTS layer. A financial entity that has only a single high-level "ICT risk policy" is missing most of what Article 6 actually requires.

Article 6 sets the duty, Articles 8-15 fill it in

Article 6 is the anchor: every financial entity must maintain a sound, comprehensive, and well-documented ICT risk-management framework, approved by the management body, reviewed at least annually, and updated after major incidents or supervisory findings. It names five functions the framework must perform: identify, protect, detect, respond, and recover.

What Article 6 does not spell out is what each function looks like as an actual document a supervisor can ask to see. That detail sits in Articles 8 to 15 of Chapter II, and in the regulatory technical standards the European Commission adopted under Article 15's mandate, Commission Delegated Regulation (EU) 2024/1774. Read together, they turn five verbs into eight concrete deliverables.

The eight required pieces of the framework

1. Identification (Article 8)

Before anything can be protected, it has to be found and classified. The entity must maintain a current, complete inventory of ICT assets, hardware, software, network resources, and the physical infrastructure supporting them, mapped to the business functions and information assets each one serves. Assets supporting a critical or important function need to be identifiable at a glance, because everything downstream, incident classification, resilience testing scope, third-party risk assessment, depends on this map being accurate.

2. Protection and prevention (Article 9)

This is where most of the policy volume sits: information security policy, access management (least privilege, strong authentication), network segmentation, encryption and cryptographic controls, patch and vulnerability management, and physical security for data centres and sensitive areas. The RTS under Article 15 sets minimum content for each of these, so "we have a security policy" is not sufficient; the policy has to cover the specific controls the RTS names.

3. Detection (Article 10)

Mechanisms to detect anomalous activity quickly, unusual network traffic, failed access attempts, performance degradation, and to alert the right people fast enough to act. Detection capability has to be proportionate to the complexity of the entity's ICT environment, but multiple layers of control, not one dashboard, are what supervisors expect to see evidenced.

4. Response and recovery (Article 11)

A documented ICT business-continuity policy and disaster-recovery plans that state recovery time and recovery point objectives for each critical system, and that are actually tested against those objectives, not just written and filed. This is the article that connects the risk-management pillar directly to resilience testing: a recovery plan nobody has rehearsed is a plan in name only.

5. Backup policies and restoration (Article 12)

Backup frequency, scope, and storage location, kept logically and physically separate from the primary system where the risk profile warrants it, plus documented, periodically tested restoration procedures. DORA treats an untested backup as equivalent to no backup: the requirement is restoration capability, not just a backup file existing somewhere.

6. Learning and evolving (Article 13)

Post-incident reviews, root-cause analysis, and a formal mechanism that feeds lessons back into the framework, plus ICT security awareness programmes and, for relevant staff, digital operational resilience training. A framework with no feedback loop tends to repeat the same gaps across incidents.

7. Communication (Article 14)

Crisis communication plans covering staff, clients, counterparties, the media, and competent authorities, with pre-agreed disclosure procedures so an incident does not also become a communications failure.

8. Further harmonisation under the Article 15 RTS

Article 15 mandates the RTS that fills in the technical detail for the seven items above, ICT project and change management, human resources policy, and identity and access management among them. Article 16(3) uses the same RTS to define the lighter, simplified version of the framework available to smaller entities. Treat the RTS as the checklist against which each individual policy gets drafted, not as a separate, ninth document.

Governance: who actually owns this

Article 6 makes the framework a board-level obligation, not a delegation to the IT or security function. The management body has to approve it, allocate the budget it needs, and retain enough ICT knowledge to meaningfully challenge what it is approving. Our explainer on the management body's Article 5 duties covers the accountability side in more depth; the framework described here is what that accountability is actually exercised over.

Proportionality: the simplified framework

Not every in-scope entity has to build all eight pieces at full depth. Article 16 carves out a simplified framework for small and non-interconnected investment firms, certain exempted payment and e-money institutions, and a handful of other narrowly defined entities. The RTS under Article 16(3) still requires a documented approach to each of the eight functions above, monitoring, a continuity plan, and a record of third-party dependencies, but the required depth and testing frequency scale down with the entity's size and interconnectedness. Proportionality changes how much evidence a smaller entity needs to produce; it does not remove any of the eight functions from scope.

Review triggers: annual is the floor, not the whole story

Article 6(5) sets an annual review as the minimum cadence, but three other triggers force a review outside that schedule: a major ICT-related incident, a supervisory instruction or finding, and conclusions drawn from resilience testing or an internal audit. An entity that only revisits its framework once a year and treats the other three triggers as optional is not meeting the letter of Article 6, even if the calendar review happens on time.

Why this framework underpins every other DORA pillar

The asset inventory built for Article 8 is the same inventory a register of information draws on to flag which ICT third-party arrangements support a critical function. The recovery objectives set for Article 11 are what threat-led penetration testing checks against. The incident classification thresholds used for major-incident reporting presuppose the detection capability built for Article 10. Weaknesses here rarely stay contained to this pillar; they tend to resurface as findings in whichever pillar gets tested next.

Common gaps seen in practice

• A single high-level policy standing in for eight. One "ICT risk management policy" document that gestures at identification, protection, and response in a few paragraphs each, without the specific controls the Article 15 RTS names, will not hold up to scrutiny.
• Untested recovery and backup procedures. Recovery time objectives exist on paper but have never been rehearsed against a realistic scenario, so the entity does not actually know whether it can meet them.
• No documented link between incidents and framework changes. Article 13's learning requirement is treated as a lessons-learned meeting rather than a tracked process that produces framework updates.
• Reviews triggered only by the calendar. The framework gets its annual refresh but is not revisited after a major incident or a supervisory finding, missing two of the four required triggers.
• Board sign-off as a formality. The management body approves a document it has not substantively reviewed, which does not satisfy Article 6's requirement that the body retain enough ICT knowledge to challenge the framework.

A practical checklist

• Map each of the eight functions to a named, owned document, not one combined policy, and check each against the Article 15 RTS's minimum content.
• Confirm recovery and backup procedures have been tested this year, not just written.
• Trace a straight line from the last major incident to a specific framework change, so the Article 13 learning loop is demonstrable.
• Check whether the entity qualifies for the Article 16 simplified framework, and if so, confirm the simplified version still covers all eight functions at proportionate depth.
• Calendar all four review triggers, not just the annual one, so a supervisory finding or a resilience-test result reliably reaches the framework document.

Entities working through a full DORA checklist or scoping their next DORA gap assessment can use the DORA Readiness Score to see how the ICT risk management pillar scores against the other four before committing budget to a full review.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 6, 8-16, EUR-Lex.
• Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, RTS on ICT risk management tools, methods, processes and policies, EUR-Lex.
• ESMA, Digital Operational Resilience Act (DORA).
• EBA, Digital operational resilience Regulation (DORA).

Last updated: 31 August 2026.