DORA ICT Resilience Plan for CASPs: What 2026 Requires

Why does DORA matter more in 2026 than in 2025?

Most EU regulators took a guidance-and-engagement approach in 2025 but shifted to substantive review of ICT resilience plans in early 2026 — files that previously cleared without comment now generate substantive deficiency notices.

DORA entered into force on 17 January 2025, but the first year of supervision was a calibration period for both regulators and firms. Most EU supervisors took a “guidance and engagement” approach in 2025, prioritising firm education over enforcement. That approach changed in early 2026.

In Q1 2026, the Bank of Lithuania, the Estonian Financial Supervision Authority, and the German BaFin all signalled a shift to substantive review of ICT resilience plans. Files submitted in 2025 with template-style plans that cleared without comment now generate substantive deficiency notices on resubmission or annual review.

The supervisory message is consistent: DORA is not a documentation exercise. The plan must reflect actual operating reality, the testing must be performed and documented, the third-party register must be live and current, and the incident-reporting procedure must be exercised at least annually.

What must the ICT resilience plan contain?

The plan covers six mandatory sections — ICT risk-management framework, asset inventory, third-party register, business-continuity plan, incident-management procedure, and testing programme — mapped to the ESAs Joint Final Report on DORA Level 2.

A DORA-compliant ICT resilience plan for a CASP includes the following sections, mapping to the structure required by the ESAs Joint Final Report on DORA Level 2 measures:

1. ICT risk-management framework

• Documented governance structure for ICT risk
• Roles and responsibilities of the ICT function, the risk function, and the board
• Risk-appetite statement covering ICT risk
• Connection to the firm’s overall risk-management framework

2. ICT asset inventory

• All hardware and software supporting business operations
• Classification by criticality (critical / important / non-critical)
• Mapping of assets to business functions
• Update cadence for the inventory (typically quarterly)

3. ICT third-party register

• All ICT third-party providers, including cloud, SaaS, and managed services
• Classification by criticality
• Geographic location of services
• Concentration-risk analysis for the top 5 providers
• Exit strategy for each critical-or-important provider

4. Business-continuity and disaster-recovery plan

• Recovery time objectives (RTO) per critical function
• Recovery point objectives (RPO) per critical data set
• Backup arrangements and tested restoration procedures
• Crisis-management governance (who decides what, when)

5. Incident-management procedure

• Detection and classification of incidents
• Internal escalation matrix
• Regulatory reporting timelines (per RTS on incident classification)
• Customer-communication protocol
• Post-incident review process

6. Testing programme

• Annual schedule of basic testing (vulnerability scans, pen tests, tabletop exercises)
• Three-year cycle of advanced testing (TLPT) for significant firms
• Independence requirements for testers

The plan is filed at authorisation and reviewed annually thereafter. Material changes to the firm’s operating model or ICT setup trigger an interim update obligation.

Who qualifies for the DORA simplified framework?

Firms below all four thresholds qualify — €100M customer crypto-assets under custody, €15M annual revenue, 25 FTE headcount, and not designated significant by the home regulator.

DORA Article 16 recognises that a small advisory firm with five FTE and no custody activity should not face the same ICT-resilience burden as a Tier 1 bank. The simplified framework applies to firms below the following thresholds:

• Customer crypto-assets under custody below €100M
• Annual revenue below €15M
• Headcount below 25 FTE
• Not designated as significant by the home regulator

Class 1 advisory firms typically qualify. Most Class 2 exchanges in their first year of operation qualify. Class 3 custodians at meaningful scale typically do not qualify and face the full DORA framework.

The simplified framework reduces:

• The depth of governance documentation required
• The frequency and depth of independent testing
• The granularity of the third-party register

It does not eliminate any obligation. Even simplified-framework firms need an ICT resilience plan, a third-party register, and incident-reporting procedures.

What does DORA require on third-party risk?

DORA Article 28 brings cloud providers, SaaS vendors, and outsourced services into a contractually managed regime requiring audit rights, defined SLAs, exit-assistance clauses, and termination-for-regulatory-reasons rights.

DORA Article 28 brings ICT third-party providers — including cloud, SaaS, and outsourced services — into a contractually managed regime that goes well beyond pre-DORA outsourcing rules. The contractual requirements include:

• Description of the services and locations of provision
• Right to audit, including pooled audits with other clients
• Service-level agreements with explicit performance metrics
• Exit-assistance clauses
• Right to terminate for the firm’s regulatory or material risk reasons

Standard hyperscaler contracts often do not include all of these elements out of the box. AWS, GCP, and Azure have each released DORA-aligned addenda for financial-services customers; firms that adopted those addenda before 2025 are largely covered. Firms still on standard commercial terms typically have contractual gaps that supervisors will flag.

How should CASPs handle single-cloud concentration risk?

Pick one of four options — multi-region deployment on the same hyperscaler, active-active multi-cloud, active-passive with documented exit, or board-acknowledged residual risk — and document the choice for the regulator.

A pattern that supervisors are increasingly raising in 2026 is single-cloud concentration risk. Many CASPs run their entire production stack on a single hyperscaler — typically AWS in the EU, often a single AWS region (Frankfurt or Dublin).

DORA Article 29 requires assessment of concentration risk and, where the firm cannot mitigate it, documented acknowledgement of the residual risk. Mitigation options include:

1. Multi-region deployment. The same hyperscaler, but multiple regions. Cheapest, mitigates regional outages, does not mitigate hyperscaler-level outages.

2. Active-active multi-cloud. Workload running concurrently on two hyperscalers. Most expensive, mitigates hyperscaler outages, requires architectural complexity.

3. Active-passive with documented exit. Primary on one hyperscaler, tested ability to fail over to a second. Middle ground.

4. Documented residual risk. No active mitigation, board-acknowledged residual risk, accepted as part of risk appetite.

In supervisory dialogue, regulators want to see that the firm has explicitly considered the options and made an informed choice. Files with no concentration-risk discussion get a deficiency notice.

How fast must DORA incidents be reported?

Initial notification within four hours of major-incident classification; intermediate report within three working days; final report within one month — the four-hour clock starts at internal classification, not at incident occurrence.

DORA’s incident-reporting regime is materially stricter than pre-DORA arrangements. The clock for major incidents:

• T+0 (incident classified as major): Internal classification triggers external clock
• T+4 hours: Initial notification to the home regulator
• T+3 working days: Intermediate report with diagnostic detail
• T+1 month: Final report with root cause and remediation

The classification threshold is set in the RTS on incident classification (Commission Delegated Regulation 2024/1772). Major incidents typically include outages exceeding two hours of critical services, material data loss, security breaches affecting customer assets or personal data, and significant financial loss.

The four-hour clock is hard. Firms that have not exercised the procedure in advance routinely miss it on the first real incident. Annual tabletop exercises that simulate the clock are part of the standard DORA testing programme.

What should you look for in counsel on DORA?

Counsel that has personally drafted ICT resilience plans cleared in two or more EU member states without substantive deficiency — DORA expertise is not yet mature in the crypto-asset bar and most generalists treat it as a sub-section.

DORA-specific expertise is not yet mature in the EU crypto-asset bar. Most counsel that handles MiCA CASP files treats DORA as a sub-section of the application rather than a specialism in its own right. This is changing as 2026 supervisory pressure makes DORA the most common deficiency-notice topic.

Counsel that has personally drafted ICT resilience plans that cleared in two or more EU member states without substantive deficiency is meaningfully ahead of the field. The technical content (concentration-risk analysis, third-party register structure, incident-classification thresholds) is the kind of work that benefits from calibration across multiple files.