| Key Takeaways |
| DORA ICT risk management (Articles 5-16) became mandatory for approximately 22,000 EU financial entities on 17 January 2025, with enforcement actions now live across all member states. |
| The framework follows a five-phase lifecycle: Governance (Art. 5), Identification (Art. 8), Protection and Prevention (Art. 9), Detection (Art. 10), and Response and Recovery (Art. 11-12). |
| Financial entities must assign ICT risk management to a dedicated control function with clear segregation from operational IT, aligned to the Three Lines Model. |
| The ESAs published binding Regulatory Technical Standards (RTS) on ICT risk management frameworks, making detailed compliance requirements prescriptive rather than principles-based. |
| A 90-day implementation roadmap structured around gap analysis, control deployment, and testing can bring most financial entities from partial to full DORA ICT compliance. |
| Organizations that map DORA requirements to existing ISO 27001, NIST CSF 2.0, and ISO 22301 controls can reduce duplication by 40-60% and accelerate compliance timelines. |
| The European Commission designated 19 critical ICT third-party providers in November 2025, including AWS, Azure, and Google Cloud, creating direct supervisory oversight for the first time. |
The Digital Operational Resilience Act represents the most significant shift in how European financial regulators approach technology risk.
Since its enforcement date of 17 January 2025, approximately 22,000 financial entities across the EU must demonstrate a documented, tested, and auditable ICT risk management framework that goes well beyond what most organizations had in place under previous national regimes.
Chapter II of DORA (Articles 5 through 16) establishes the core ICT risk management requirements. These articles prescribe how financial entities must govern, identify, protect against, detect, and recover from ICT-related disruptions.
The Regulatory Technical Standards published by the European Banking Authority, EIOPA, and ESMA translate these articles into detailed, auditable controls that supervisors are now actively examining.
This implementation guide breaks down each article cluster, maps them to actionable controls and KRIs, and provides a structured 90-day roadmap for organizations that need to close compliance gaps.
The approach integrates enterprise risk management frameworks with the specific prescriptive requirements of DORA, so risk professionals can leverage existing capabilities rather than building from scratch.
DORA Chapter II: Scope and Architecture of the ICT Risk Management Framework
DORA is an EU Regulation, not a Directive, meaning it applies directly in all member states without transposition.
The regulation covers banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and their critical ICT third-party service providers. Article 2 lists over 20 categories of in-scope entities.
Chapter II (Articles 5-16) establishes two tiers of compliance. Articles 5 through 15 define the full ICT risk management framework applicable to most regulated entities.
Article 16 provides a simplified framework for smaller institutions such as microenterprises, small payment institutions, and certain investment firms that meet specific thresholds. Understanding which tier applies is the first step in any compliance risk assessment.
Article-by-Article Breakdown
| Article | Title | Core Requirement | Key Deliverable |
| Art. 5 | Governance and Organisation | Management body defines, approves, and oversees ICT risk management | Board-approved ICT risk management policy |
| Art. 6 | ICT Risk Management Framework | Documented framework with strategies, policies, procedures, protocols, and tools | Comprehensive ICT RMF document with annual review cycle |
| Art. 7 | ICT Systems, Protocols and Tools | Sound, resilient, and updated ICT systems proportionate to business needs | ICT asset inventory with classification and criticality ratings |
| Art. 8 | Identification | Identify, classify, and document all ICT-supported business functions and assets | ICT asset register and dependency mapping |
| Art. 9 | Protection and Prevention | Implement ICT security policies, access controls, patch management, and encryption | ICT security policy suite with technical controls |
| Art. 10 | Detection | Mechanisms to detect anomalous activities and ICT-related incidents | SIEM/SOC capability with detection rules and alert thresholds |
| Art. 11 | Response and Recovery | ICT business continuity policy with response and recovery plans | Tested BCP and disaster recovery plans |
| Art. 12 | Backup Policies | Data backup policies with restoration and recovery procedures | Backup policy with verified RPO/RTO targets |
| Art. 13 | Learning and Evolving | Post-incident reviews and continuous improvement mechanisms | Lessons-learned register and improvement action tracker |
| Art. 14 | Communication | Crisis communication plans for internal and external stakeholders | ICT incident communication plan and escalation matrix |
| Art. 15 | Further Harmonisation | ESAs develop RTS for detailed ICT risk management specifications | Compliance with published RTS requirements |
| Art. 16 | Simplified Framework | Proportionate requirements for smaller entities | Simplified ICT risk management documentation |
Governance and Oversight: Articles 5 and 6
Article 5 places ICT risk governance squarely on the management body. Board members and senior executives must define, approve, and actively oversee the ICT risk management framework.
This goes beyond delegating to IT. DORA explicitly requires the management body to bear ultimate responsibility for managing ICT risk, allocate sufficient budget, and ensure appropriate risk management integration across the organization.
Article 6 details what the framework must contain: strategies, policies, procedures, ICT protocols, and tools necessary to protect information assets and ICT infrastructure.
The framework must be reviewed annually (or more frequently after major incidents) and audited by internal audit with sufficient ICT risk expertise.
DORA explicitly references the Three Lines Model, requiring segregation between ICT risk management functions, control functions, and internal audit.
Governance KRIs for DORA Compliance
| KRI | Green | Amber | Red |
| Board ICT risk training completion rate | >90% annually | 70-90% | <70% |
| ICT risk management framework review frequency | Annual + post-incident | Annual only | Overdue >3 months |
| ICT budget as % of total operational budget | >8% (sector benchmark) | 5-8% | <5% |
| Open ICT risk audit findings (critical/high) | 0 critical, <3 high | 1 critical or 3-5 high | >1 critical or >5 high |
| Time to close critical ICT audit findings | <30 days | 30-60 days | >60 days |
Identification and Asset Management: Articles 7 and 8
Article 7 requires financial entities to maintain sound, resilient, and sufficiently updated ICT systems, protocols, and tools that are proportionate to the nature, variety, complexity, and magnitude of risks they face.
Article 8 mandates identification, classification, and documentation of all ICT-supported business functions, roles, information assets, and their dependencies.
The identification phase is where many organizations stumble. DORA requires a complete ICT reference architecture that maps every business function to its supporting ICT assets, every interconnection to third parties, and every dependency that could trigger cascading failures.
This mirrors best practice in business impact analysis but extends it specifically to the ICT layer. The RTS published by the ESAs add further granularity, requiring entities to maintain an up-to-date inventory that classifies assets by criticality and maps them to business processes.
A practical approach starts with your existing risk register and IT asset management database, then builds dependency maps using network topology data, application architecture documents, and third-party contract registers.
Each asset should be tagged with its criticality rating, data classification, owning business unit, and recovery requirements.
ICT Asset Classification Framework
| Criticality | RTO Target | RPO Target | Testing Frequency | Example Assets |
| Critical (Tier 1) | <2 hours | <1 hour | Quarterly | Core banking, payment systems, trading platforms |
| Important (Tier 2) | <8 hours | <4 hours | Semi-annually | CRM, regulatory reporting, HR systems |
| Standard (Tier 3) | <24 hours | <24 hours | Annually | Internal portals, dev environments, archival systems |
| Non-essential (Tier 4) | <72 hours | <72 hours | Every 2 years | Legacy read-only systems, decommissioned apps |
Protection and Prevention: Article 9
Article 9 requires financial entities to implement policies, procedures, and technical controls to protect ICT systems and data. The scope covers access management, encryption, network security, vulnerability management, and patch management.
The RTS further specify requirements for identity and access management, including role-based access controls and privileged access management.
Mapping Article 9 to existing frameworks simplifies implementation considerably. Organizations already compliant with ISO 27001 or aligned to NIST CSF 2.0 will find substantial overlap.
The key is performing a structured gap analysis that identifies where DORA introduces specific requirements beyond what existing controls already address.
Common gaps include formal ICT change management procedures tied to risk assessment, mandatory encryption standards for data at rest and in transit, and documented network segmentation strategies.
DORA Article 9 Control Mapping to ISO 27001 and NIST CSF
| DORA Requirement | ISO 27001 Control | NIST CSF Function | Implementation Priority |
| ICT security policies and standards | A.5.1 Information security policies | GV.PO (Govern-Policy) | High – Foundation for all controls |
| Identity and access management | A.8.2-8.5 Access control | PR.AA (Protect-Identity/Access) | Critical – Immediate action |
| Encryption and cryptographic controls | A.8.24 Use of cryptography | PR.DS (Protect-Data Security) | High – Data protection baseline |
| Network security management | A.8.20-8.22 Network controls | PR.IR (Protect-Infrastructure) | High – Perimeter and segmentation |
| Vulnerability and patch management | A.8.8 Technical vulnerabilities | ID.RA (Identify-Risk Assessment) | Critical – Continuous process |
| ICT change management | A.8.32 Change management | PR.IP (Protect-Info Protection) | High – Prevent change-induced incidents |
Detection Mechanisms: Article 10
Article 10 mandates that financial entities establish mechanisms to promptly detect anomalous activities, including ICT network performance issues, ICT-related incidents, and potential material single points of failure.
Detection is the bridge between preventive controls and incident response, and DORA treats it as a distinct operational capability rather than a subset of protection.
The practical challenge lies in calibrating detection thresholds that catch genuine threats without generating alert fatigue.
DORA expects entities to demonstrate that detection mechanisms are regularly tested, updated to reflect the evolving threat landscape, and capable of triggering the incident reporting processes required under Chapter III.
Organizations should establish cybersecurity KRIs with clearly defined thresholds tied to escalation protocols.
Detection Capability Maturity Assessment
| Capability | Level 1 – Initial | Level 2 – Developing | Level 3 – Defined | Level 4 – Optimised |
| Log collection | Ad hoc, partial coverage | Centralised for critical systems | All systems with normalised format | Real-time correlation with enrichment |
| Alert triage | Manual review only | Basic rules, high false-positive rate | Tuned rules, SOC triage process | ML-assisted triage with auto-classification |
| Anomaly detection | None or reactive | Threshold-based alerts | Behavioural baselines established | Predictive analytics with pattern recognition |
| Threat intelligence | No formal feeds | Commercial feed subscription | Multiple feeds integrated into SIEM | Automated IOC matching with response playbooks |
| Detection testing | None | Annual penetration test only | Red team exercises semi-annually | Continuous purple team with MITRE ATT&CK mapping |
Response, Recovery, and Backup: Articles 11 and 12
Articles 11 and 12 form the operational resilience core of DORA. Article 11 requires a comprehensive ICT business continuity policy that encompasses response plans, recovery plans, and regular testing through exercises.
Article 12 adds specific backup requirements including data integrity checks, reconciliation procedures, and verified restoration capabilities.
These articles align closely with ISO 22301 business continuity management but add ICT-specific prescriptions.
Financial entities must define recovery time objectives and recovery point objectives for each critical function, test backup restoration regularly, and maintain the ability to recover operations at a secondary site. The management body must approve the BCP and review it at least annually.
Recovery planning under DORA must also account for scenarios where ICT third-party service providers fail.
Given that the ESAs designated 19 critical ICT third-party providers in November 2025 (including AWS, Microsoft Azure, and Google Cloud), concentration risk in cloud infrastructure is a supervisory priority.
Organizations need documented exit strategies and the ability to transition critical workloads, as outlined in operational resilience vs business continuity guidance.
Recovery Capability Requirements Under DORA
| Requirement Area | DORA Expectation | Typical Gap | Remediation Action |
| BCP/DRP documentation | Board-approved, tested, annually reviewed | Plans exist but untested or outdated | Schedule quarterly tabletop and annual simulation exercises |
| RTO/RPO targets | Defined per critical function with tested achievement | Targets set but never validated | Run failover tests and measure actual recovery times |
| Backup integrity | Regular integrity checks and reconciliation | Backups run but never tested for restoration | Monthly backup restoration tests with documented results |
| Secondary site capability | Demonstrated ability to operate from alternate location | DR site exists but switchover untested | Conduct live switchover exercises annually |
| Third-party exit strategy | Documented transition plan for critical ICT providers | No exit plan for cloud or key vendors | Develop exit plans with portability and data extraction procedures |
| Crisis communication | Defined internal and external communication protocols | Ad hoc communication during incidents | Create communication playbooks with pre-approved templates |
Learning, Evolving, and Communication: Articles 13 and 14
Article 13 requires financial entities to build capabilities to learn from ICT-related incidents, testing results, and vulnerabilities.
Post-incident reviews must produce documented lessons learned, and those lessons must feed into updates to the ICT risk management framework.
This creates a continuous improvement loop that supervisors will examine through internal audit risk assessment processes.
Article 14 addresses communication strategies during ICT-related incidents. Financial entities must have plans for communicating with staff, external stakeholders, clients, counterparts, and regulatory authorities.
The communication plan must be distinct from the incident response plan itself and should include designated spokespeople, pre-approved message templates, and defined escalation triggers.
Together, these articles create an expectation of organisational learning that moves beyond checkbox compliance.
Regulators want to see that incident data drives risk reassessment, that testing results influence control design, and that communication protocols have been rehearsed.
Organizations that already maintain a mature risk management lifecycle will recognise these as natural extensions of the Plan-Do-Check-Act cycle.
Simplified ICT Risk Management Framework: Article 16
Article 16 provides a proportionate alternative for smaller financial entities that meet specific size and complexity thresholds.
The simplified framework retains the core risk management principles but reduces documentation, testing, and governance requirements.
Qualifying entities include small and non-interconnected investment firms, payment institutions exempted under PSD2, and certain IORP institutions.
Even under the simplified framework, entities must maintain a documented ICT risk management approach, implement basic security controls, define response and recovery procedures, and report major ICT incidents to competent authorities.
The difference is largely in the degree of formality, the frequency of review, and the depth of testing required. A well-structured risk assessment process remains essential regardless of which tier applies.
DORA ICT Risk Management Implementation Roadmap
This phased roadmap targets organizations that have partial ICT risk management capabilities and need to close gaps to achieve full DORA compliance. Adjust timelines based on your starting maturity level and the resources available.
| Phase | Actions | Deliverables | Success Metrics |
| Days 1-30: Gap Analysis and Governance | Perform article-by-article gap assessment against DORA and published RTS. Brief the management body on findings. Assign ICT risk management control function ownership. Review existing policies against Art. 5-6 requirements. | DORA gap assessment report. Board briefing pack with risk ratings per article. Updated RACI matrix for ICT risk management. Draft ICT risk management policy aligned to Art. 6. | Gap assessment completed for all 12 articles. Board briefing delivered with documented decisions. ICT risk control function formally designated. Policy draft reviewed by legal and compliance. |
| Days 31-60: Control Deployment and Documentation | Build or update ICT asset inventory per Art. 7-8 requirements. Deploy or configure detection mechanisms per Art. 10. Update BCP/DRP documentation to meet Art. 11-12 standards. Develop ICT incident communication plan per Art. 14. | Complete ICT asset register with criticality ratings and dependency maps. Detection capability gap closure plan with SIEM tuning. Updated BCP with tested RTO/RPO targets. Crisis communication playbook with escalation matrix. | Asset inventory covers 95%+ of ICT infrastructure. Detection rules aligned to current threat landscape. BCP updated with all critical function recovery procedures. Communication plan approved by management body. |
| Days 61-90: Testing, Validation, and Continuous Improvement | Conduct tabletop exercise testing ICT business continuity scenarios. Run backup restoration tests per Art. 12 requirements. Perform internal audit readiness assessment. Establish lessons-learned process per Art. 13. Submit compliance attestation to competent authority. | Exercise report with findings and improvement actions. Backup test results with documented recovery times. Audit readiness checklist with evidence mapping. Lessons-learned register with action owners and due dates. Compliance status dashboard for board reporting. | Tabletop exercise completed with >90% participation. Backup restoration meets defined RPO/RTO for Tier 1 assets. Zero critical gaps in audit readiness assessment. Continuous improvement process documented and operational. Board receives first DORA compliance dashboard. |
Pitfalls and How to Avoid Them
| Pitfall | Root Cause | Remedy |
| Treating DORA as an IT-only project | Lack of management body engagement; ICT risk seen as technical rather than strategic | Anchor DORA compliance in the board agenda. Assign executive sponsor. Map ICT risks to business impact using financial materiality thresholds. |
| Incomplete ICT asset inventory | Reliance on manual spreadsheets; shadow IT not captured; cloud assets missed | Deploy automated discovery tools. Cross-reference CMDB with network scans, cloud console exports, and vendor contract registers. |
| Untested recovery plans | Plans documented but never exercised; testing deferred due to operational pressures | Schedule quarterly tabletop exercises and annual live failover tests. Make testing a board-reportable KRI. |
| Ignoring the simplified framework threshold | Assuming Article 16 applies without verifying eligibility criteria | Confirm entity classification with legal counsel. Document the basis for applying either the full or simplified framework. |
| Failing to map third-party dependencies | Third-party risk managed separately from ICT risk; no consolidated view of concentration risk | Build a third-party ICT dependency register linked to the asset inventory. Assess concentration risk across critical providers. |
| Duplicating controls across frameworks | Siloed compliance teams for ISO 27001, NIST, and DORA create overlapping controls | Establish a unified control framework with cross-mapping. Use a single control library with tags for each regulatory requirement. |
| Reactive rather than predictive detection | Legacy SIEM with static rules; no behavioural analytics or threat intelligence integration | Invest in detection engineering. Integrate threat intelligence feeds, establish behavioural baselines, and map detection coverage to MITRE ATT&CK. |
| No exit strategy for cloud providers | Assumption that cloud concentration risk is manageable without documented alternatives | Develop provider exit plans with data portability assessments, alternative provider evaluation, and transition timelines. |
Looking Ahead: DORA ICT Risk Trends for 2026-2028
The DORA landscape continues to evolve. The European Commission is required to conduct a review by January 2026 on strengthening requirements for statutory auditors and audit firms regarding digital operational resilience.
This review could expand the scope of audit assurance requirements and introduce new expectations for third-party assurance over ICT controls in financial entities.
Concentration risk in cloud infrastructure will intensify as a supervisory focus. With 19 critical ICT third-party providers now under direct ESA oversight, financial entities should expect increased scrutiny of multi-cloud strategies, exit planning, and concentration risk quantification.
The third-party risk management discipline will need to mature rapidly, moving from due diligence checklists to continuous monitoring and scenario-based stress testing of provider failure scenarios.
AI and machine learning adoption in financial services will create new ICT risk vectors that DORA frameworks must accommodate.
Organisations should begin integrating AI risk assessment frameworks into their DORA ICT risk management approach, particularly around model risk, data integrity, and algorithmic decision-making.
The intersection of the EU AI Act and DORA will create compound compliance obligations that forward-thinking risk functions are already preparing for.
Cross-border harmonisation will remain a challenge despite DORA being a directly applicable regulation. National competent authorities retain supervisory discretion, and interpretive differences are already emerging.
Financial entities operating across multiple EU jurisdictions should track national supervisory guidance and participate in industry working groups to influence consistent interpretation.
Building a robust GRC framework that accommodates both EU-level and national requirements will be essential for multi-jurisdictional compliance.
Ready to build your DORA ICT risk management framework? Visit riskpublishing.com for implementation templates, risk register frameworks, and expert consulting services tailored to financial entities navigating DORA compliance.
References
1. European Banking Authority – RTS on ICT Risk Management Framework – Joint ESA regulatory technical standards on ICT risk management.
2. EUR-Lex – Regulation (EU) 2022/2554 (DORA Full Text) – Official DORA regulation text.
3. ESMA – Digital Finance and Innovation: DORA – ESMA DORA implementation resources.
4. EIOPA – Digital Operational Resilience Act – EIOPA DORA guidance for insurance and pensions.
5. DORA Articles – Full Text Reference – Article-by-article text of the regulation.
6. BaFin – DORA Implementation Guidance – German supervisory guidance on DORA implementation.
7. ISO 27001:2022 – Information Security Management – International standard for information security controls.
8. NIST Cybersecurity Framework 2.0 – US federal cybersecurity risk management framework.
9. ISO 22301:2019 – Business Continuity Management – International standard for business continuity management systems.
10. DLA Piper – Application of DORA: Key Considerations – Legal analysis of DORA enforcement considerations.
11. IBM – What is DORA? – Technology perspective on DORA compliance requirements.
12. Projective Group – DORA ICT Risk Management in Detail – Detailed analysis of DORA Chapter II requirements.
13. Steptoe – Digital Operational Resilience: A Compliance Priority for 2025 – Legal analysis of DORA compliance timelines.
14. CSSF – ICT and Cyber Risk for DORA Entities – Luxembourg supervisory guidance on DORA ICT risk requirements.
15. ISO 31000:2018 – Risk Management Guidelines – International standard for enterprise risk management principles.
Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.