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?

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

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’s simplified ICT framework 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’s ICT third-party register pulls cloud providers and SaaS vendors, together with any outsourced services, into a contractually managed regime requiring audit rights, defined SLAs, exit-assistance clauses, and termination-for-regulatory-reasons rights.

DORA’s ICT third-party register brings ICT third-party providers into a contractually managed regime that goes well beyond pre-DORA outsourcing rules. Cloud, SaaS, and outsourced services all fall inside it. 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 and GCP have both released DORA-aligned addenda for financial-services customers, as has Azure; 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 and document the choice for the regulator: multi-region deployment on the same hyperscaler, active-active multi-cloud, active-passive with documented exit, or board-acknowledged residual risk.

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’s contractual-arrangement rule 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 actually counts as a major incident?

The RTS on incident classification sets thresholds across seven dimensions, and an incident is major the moment it crosses the threshold on any single one — not all seven together.

• Affected clients. Materially affected client count, or percentage of total clients.
• Data lost. Volume or sensitivity of data lost, leaked, or modified.
• Financial impact. Direct loss to the firm, clients, or counterparties.
• Geographic spread. Number of member states or regions affected.
• Duration of unavailability. Hours or days of service downtime.
• Reputational impact. Media coverage, social-media volume, a complaint spike.
• Effect on critical or important functions. Disruption to specific defined operational functions.

The thresholds are calibrated by firm size. A 10,000-customer CASP and a 10-million-customer CASP face different absolute numbers but similar relative tests. The job is to know your firm’s specific thresholds and apply them the same way every time — because the classification decision is what starts the four-hour clock, and it’s the part supervisors scrutinise hardest.

How do operational teams actually hit the 4h/72h deadlines?

Three things need to be in place before any incident starts, and none of them can be built mid-crisis.

Detection-and-classification workflow. Monitoring has to detect incidents reliably and route them through a process that decides major vs non-major fast. Detection alone isn’t enough — the classification decision is what triggers the clock. Most major-CASP operations run a duty-officer rotation that handles classification 24/7, because the deadlines are calendar-time, not business-hours. An incident that starts at 11pm Friday has a four-hour clock running through Saturday morning.

Pre-built notice templates. The NCA submission isn’t drafted from scratch in the middle of an outage. Initial notice (4h), intermediate report (72h), and final report (1m) each get a template with placeholder fields. The duty officer fills the placeholders and submits. Drafting under time pressure produces errors.

Tested submission infrastructure. The home regulator usually accepts reports via a secure portal or a specific email address. Credentials, the submission process, and fallback channels all need testing before an incident — firms that test the channel during an incident discover the problem at the worst possible moment.

The 72-hour intermediate report is substantially heavier than the initial notice. By then the firm typically has a root-cause hypothesis, containment in place, confirmed customer-impact figures, and a recovery timeline. NCAs read it to judge whether the firm has the incident under control: competent containment and a clear forward plan usually avoid follow-up; weak containment or a vague plan usually triggers it.

The one-month final report is the document that closes the matter — definitive root-cause analysis, full customer-impact quantification, a lessons-learned framework, remediation completed and scheduled, and a board-engagement record. Firms that treat the month as a deadline rather than a deliverable and file something thin face NCA follow-up that keeps the supervisory engagement open for another three to six months. The substantive report closes it; the thin one doesn’t.

What does the 2025-2026 enforcement record show?

DORA went operationally binding on 17 January 2025, and the first 18 months reveal a consistent supervisory pattern. NCAs have prioritised enforcement against missed four-hour deadlines, under-classification of borderline incidents (caught through pattern analysis across multiple reported events), thin final reports, inadequate timestamping of the detection-classification-submission moments, and missing fallback infrastructure discovered when primary channels failed.

Fines under Article 109 in DORA-related enforcement have ranged from EUR 100,000 to EUR 5 million depending on firm scale and the violation pattern — the largest have been for repeat-pattern failures, not single missed incidents. The practical message is that NCAs use DORA reporting actively. A firm with mature incident-response infrastructure operates without enforcement risk; a firm that improvises ends up in supervisory dialogue it didn’t budget for. A mid-tier CASP building this from scratch typically spends EUR 200,000-500,000 in Year 1 and EUR 100,000-300,000 annually thereafter, lighter if pre-existing ICT incident-management infrastructure already exists.

What is critical ICT third-party provider (CTPP) designation?

CTPP designation is the newest moving part of DORA, and it operates one level above the firm’s own third-party register. Under DORA Articles 31-44, the ESAs Joint Committee (the EBA, EIOPA, and ESMA acting collectively) designates ICT providers whose failure would have material systemic impact across the EU financial-entity ecosystem, and pulls them under a direct EU-level Oversight Framework. Each designated CTPP is assigned a Lead Overseer (one of the three ESAs) that can run on-site inspections and require governance changes, and can impose penalties on the provider itself.

This is novel. It’s the first time non-financial-entity providers like cloud platforms and SaaS firms, along with specialised infrastructure, face direct EU supervisory oversight because of who their customers are. Designation runs on five criteria: systemic importance, substitutability, criticality of services, geographic concentration, and number of financial-entity users. A provider serving 80% of EU banks is systemically important; one serving two small specialist firms isn’t. Crucially, the assessment looks across all sectors — a provider can be designated on bank-sector concentration even if CASP usage is moderate, so CASPs need to watch the ESAs register across sectors, not just their own.

First designations went operational late 2025, starting with the major cloud providers (AWS, Azure, GCP), with specialised financial-services SaaS, payment-infrastructure providers, and (relevant to CASPs specifically) crypto-custody and blockchain-analytics providers expected to follow through 2026 as their EU financial-entity user base is assessed.

What changes for a CASP using a designated CTPP?

The common mistake is assuming designation shifts the compliance burden onto the provider. It doesn’t. The Oversight Framework adds a supervisory layer on the provider while the CASP keeps every obligation it already had. Using a designated CTPP needs no extra permission, but it does sharpen four things:

• Governance documentation. Relationship rationale, risk-management framework, performance monitoring, and escalation procedures — heightened beyond a standard ICT-provider relationship.
• Concentration monitoring. Single-provider and single-service concentration both need documented analysis, and so does geographic concentration. A CASP heavily concentrated on one designated CTPP draws supervisory engagement on concentration risk and substitutability.
• Article 30 contractual arrangements. Article 30 requires audit rights, a documented exit strategy, sub-contracting controls, measurable SLAs, business-continuity arrangements, data-location and access terms, and termination-for-regulatory-failure rights. Standard cloud-provider terms (the AWS Customer Agreement, Azure Online Services Terms, GCP Terms of Service) lack these provisions. The major providers have built financial-services-specific frameworks (AWS Financial Services, Azure Financial Services Compliance Framework, GCP Financial Services) that address Article 30 — CASPs should negotiate into those rather than rely on standard terms.
• Ongoing compliance monitoring. A provider’s own compliance problems with the Oversight Framework can affect the CASP’s operational continuity and supervisory standing, so monitoring the relationship has to be live.

A realistic build runs six to twelve months, then an annual review thereafter: inventory and CTPP identification against the ESAs register, governance documentation, Article 30 contract review and addenda, concentration analysis, and monitoring infrastructure. The build is real work, but the alternative is Article 109 exposure for inadequate ICT-risk management.

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’s 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 and third-party register structure, plus incident-classification thresholds) is the kind of work that benefits from calibration across multiple files.