How to Implement DORA Compliance: Step-by-Step Guide for Financial Institutions [2026]

Step 1: ICT Asset Inventory

You cannot manage risk on systems you don't know about. Start here:

• Catalogue all ICT systems — Applications, databases, middleware, cloud services, SaaS tools, APIs
• Map business dependencies — Which business functions depend on which ICT systems?
• Classify criticality — Use DORA's criteria: critical or important functions (Art. 3(22))
• Include AI and ML systems — Model serving endpoints, training pipelines, feature stores, data feeds
• Document data flows — Where does data flow between systems, including cross-border transfers?

Timeline: 2-3 weeks for a mid-size institution (50-200 ICT systems)

Common mistake: Excluding shadow IT, personal productivity tools, and SaaS subscriptions. DORA covers all ICT that supports critical functions.

Step 2: Gap Analysis Against DORA's Five Pillars

Map your current state against each DORA pillar:

1. ICT Risk Management (Art. 5-16) — Do you have a documented ICT risk management framework? Is it approved by the management body?
2. ICT Incident Management (Art. 17-23) — Do you have classification criteria, reporting templates, and escalation procedures for ICT incidents?
3. Digital Operational Resilience Testing (Art. 24-27) — Do you conduct regular vulnerability assessments, penetration testing, and threat-led penetration testing (TLPT)?
4. ICT Third-Party Risk (Art. 28-44) — Do you have a third-party register? Are contractual provisions DORA-compliant?
5. Information Sharing (Art. 45) — Do you participate in threat intelligence sharing arrangements?

Output: Gap matrix with red/amber/green status per requirement, remediation priorities, and effort estimates.

Step 3: ICT Risk Management Framework

DORA Article 6 requires a comprehensive ICT risk management framework. Key components:

• Risk identification — Threat modelling for each critical ICT system, including AI-specific threats (adversarial attacks, model drift, data poisoning)
• Risk assessment — Likelihood × impact scoring with documented methodology
• Risk treatment — Accept, mitigate, transfer, or avoid — each decision documented with rationale
• Protection and prevention — Security controls mapped to identified risks (Art. 7-8)
• Detection — Monitoring and alerting for anomalous ICT activity (Art. 10)
• Response and recovery — Incident response procedures and business continuity plans (Art. 11-12)
• Learning and evolving — Post-incident reviews feeding back into the framework (Art. 13)

Step 4: Incident Classification and Reporting

Set up your incident management before you need it:

• Classification criteria based on DORA Article 18 and RTS criteria (clients affected, data loss, duration, geographic spread, economic impact)
• Reporting templates — Initial notification (within 4 hours of classification as major), intermediate report (within 72 hours), final report (within 1 month)
• Escalation matrix — Who decides if an incident is major? Who notifies the competent authority?
• Communication plan — Internal stakeholders, board, clients, and regulators

Step 5: Third-Party Risk Register

DORA Article 28 requires a register of all ICT third-party service providers:

• Inventory — Every ICT vendor, cloud provider, SaaS tool, API dependency, and AI model provider
• Criticality assessment — Which providers support critical or important functions?
• Contractual review — Do contracts include DORA-mandated provisions (Art. 30)? Exit strategies? Audit rights?
• Concentration risk — Are critical functions over-dependent on a single provider?
• Sub-outsourcing chains — Do your providers use sub-contractors? Are those documented?

Step 6: Resilience Testing Program

DORA Article 24 requires proportionate testing. Build your program in tiers:

• Tier 1 (All entities): Vulnerability assessments, open-source analysis, network security assessments, gap analyses, physical security reviews, source code reviews, scenario-based tests, compatibility testing, performance testing
• Tier 2 (Significant entities): Threat-led penetration testing (TLPT) at least every 3 years — using TIBER-EU or equivalent framework
• AI-specific testing: Adversarial ML attacks, model robustness testing, data pipeline chaos testing, inference performance under stress

Key requirement: Testing must be conducted by independent parties (internal or external) with no conflicts of interest.

Step 7: Business Continuity Testing

Test your continuity plans with realistic scenarios:

• Scenario 1: Primary data centre unavailable — can you failover within your RTO?
• Scenario 2: Key cloud provider experiencing regional outage — do backup procedures work?
• Scenario 3: AI model serving degraded — can business functions continue with manual fallbacks?
• Scenario 4: Ransomware — can you recover critical systems from immutable backups?

Document everything: Test results, identified gaps, remediation actions, and follow-up testing dates.

Step 8: Board-Level Governance

DORA Article 5(2) puts responsibility squarely on the management body:

• Approve the ICT risk management framework and review it at least annually
• Set risk appetite for ICT and digital operational resilience
• Receive regular reporting on ICT risk posture, incidents, and testing results
• Ensure adequate budget and resources for ICT security and resilience
• Training: Board members must maintain sufficient knowledge of ICT risks (Art. 5(4))