DORA ICT Resilience Plan for CASPs: What 2026 Requires

Why does DORA matter for a CASP?

DORA entered into force on 16 January 2023 and has applied since 17 January 2025. CASPs authorised under MiCA are financial entities within its scope (Article 2(1)(f)), and MiCA’s own authorisation file asks for a description of the ICT systems and security arrangements that meet DORA.

Two points shape everything else. First, there is no light regime for CASPs: Article 16’s simplified ICT risk-management framework is reserved for a closed list of small entities, and CASPs are not on it. Second, DORA is applied proportionately (Article 4), so the depth of each element scales with the firm’s size, risk profile and services. A Class 1 adviser and a Class 3 trading platform run the same framework at very different depth.

The practical message: DORA is not a documentation exercise. The framework must reflect the firm’s actual systems, the testing must be performed and recorded, the register of information must be current, and the incident procedure must work at 3 a.m. on a Saturday.

What must the ICT resilience file contain?

DORA does not prescribe a single “plan” document. It requires a set of elements, which most firms package in a small number of documents:

1. ICT risk-management framework (Articles 5-6)

• Governance: the management body’s responsibility for ICT risk, roles of the ICT, risk and internal-audit functions
• Strategies, policies, procedures and tools to protect ICT assets
• Documented and reviewed at least once a year and after major incidents (Article 6(5))
• Connection to the firm’s overall risk-management framework

2. Identification of ICT assets and functions (Article 8)

• Business functions, roles and supporting information and ICT assets identified, classified and documented
• Mapping of critical or important functions to the ICT assets and third parties that support them
• Updated when the infrastructure changes

3. ICT third-party risk and the register of information (Articles 28-30)

• A strategy on ICT third-party risk
• A register of information on all contractual arrangements with ICT third-party service providers (Article 28(3))
• Concentration-risk assessment before contracting for services that support critical or important functions (Article 29)
• Exit strategies for those services (Article 28(8))

4. Business continuity and response-and-recovery plans (Article 11)

• Recovery time and recovery point objectives per function
• Backup and restoration procedures (Article 12)
• Crisis communication plans (Article 14)
• Testing of continuity and response-and-recovery plans at least yearly (Article 11(6))

5. Incident-management process (Articles 17-19)

• Detection, logging and classification of ICT-related incidents
• Internal escalation and decision rights for the “major” call
• Reporting to the competent authority on the Delegated Regulation 2025/301 timetable
• Client communication and post-incident review

6. Digital operational resilience testing (Articles 24-27)

• A testing programme proportionate to the firm, with systems supporting critical or important functions tested at least yearly (Article 24(6))
• Tests by independent parties, internal or external (Article 24(4))
• TLPT at least every three years where the authority requires it (Article 26)

The framework is reviewed at least annually, and material changes to the operating model or ICT setup should trigger an update.

Why CASPs cannot use the simplified framework

Article 16(1) lists the entities that may apply a simplified ICT risk-management framework: small and non-interconnected investment firms, payment institutions and e-money institutions exempted under PSD2 and EMD2, credit institutions exempted under CRD, and small institutions for occupational retirement provision. CASPs authorised under MiCA are not on the list, whatever their size.

Proportionality still helps a small CASP. Article 4 requires the rules to be applied in a way that reflects size, overall risk profile and the nature, scale and complexity of services. And where a CASP qualifies as a microenterprise, several specific requirements ease, for example tester independence (Article 24(4)) and the annual framework review (Article 6(5)). Neither removes an obligation outright: even the smallest CASP needs an ICT risk-management framework, a register of information and an incident process.

What does DORA require on third-party risk?

DORA brings every ICT service, including cloud, SaaS and managed services, into a contractually managed regime. Article 30 sets the minimum contract terms, including:

• A clear description of the services and the locations where they are provided and data processed
• Provisions on availability, authenticity, integrity and confidentiality of data, and on access and return of data on insolvency or termination
• Service-level descriptions
• Assistance in ICT incidents and cooperation with the competent authority
• Termination rights and minimum notice periods

For services supporting critical or important functions, Article 30(3) adds full service-level descriptions with precise quantitative and qualitative performance targets, notice and reporting duties, business-continuity requirements, participation in the firm’s TLPT, unrestricted rights of access, inspection and audit, and exit strategies with a transition period.

Standard hyperscaler terms do not always contain all of this. The large providers offer financial-services addenda; check each one against Article 30 rather than assuming it is complete.

How should CASPs handle single-cloud concentration risk?

Many CASPs run their whole production stack on one hyperscaler, often in a single region. Article 29 requires an assessment of ICT concentration risk before contracting for services that support critical or important functions. The options to document:

1. Multi-region deployment. The same hyperscaler, several regions. Cheapest; covers regional outages, not provider-wide ones.
2. Active-active multi-cloud. Workloads running on two providers at once. Most expensive and most complex; covers provider outages.
3. Active-passive with tested exit. Primary on one provider, tested failover to another. The middle ground.
4. Accepted residual risk. No active mitigation, with the residual risk accepted explicitly by the management body as part of risk appetite.

What matters is that the firm considered the options and made an informed, recorded choice.

How fast must DORA incidents be reported?

The time limits are set in Commission Delegated Regulation (EU) 2025/301, Article 5:

• Initial notification: as early as possible, within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. If the incident is classified as major only after 24 hours, the four hours run from classification.
• Intermediate report: within 72 hours of the initial notification, with updates without undue delay and when regular activities have been recovered.
• Final report: within one month of the intermediate report or the latest updated one.

A firm that cannot meet a deadline must tell the authority without undue delay. Firms that have not rehearsed the procedure routinely miss the first real deadline; the annual testing of continuity and response plans (Article 11(6)) is the natural place to rehearse it.

What actually counts as a major incident?

Commission Delegated Regulation (EU) 2024/1772 sets the test. Under Article 8, an incident is major where it has affected critical services and either a successful, malicious and unauthorised access to network and information systems has occurred that may result in data losses, or at least two of the other materiality thresholds in Article 9 are met:

• Clients, counterparts and transactions. More than 10% of the clients using the service, more than 100,000 clients, more than 30% of financial counterparts, more than 10% of daily transactions by number or value, or relevant clients or counterparts affected.
• Reputational impact. Media attention, repeated complaints, inability to meet regulatory requirements, or likely loss of clients or counterparts.
• Duration and service downtime. The incident lasts more than 24 hours, or services supporting critical or important functions are down for more than two hours.
• Geographical spread. Impact in two or more member states.
• Data losses. Impact on the availability, authenticity, integrity or confidentiality of data that harms business objectives or regulatory compliance.
• Economic impact. Costs and losses above EUR 100,000.

Recurring incidents that individually fall short count as one major incident where they occur at least twice in six months, share the same apparent root cause and together meet the test (Article 8(2)). The classification decision starts the four-hour clock, so the job is to apply these thresholds the same way every time and record why.

How do operational teams actually hit the deadlines?

Three things need to be in place before any incident starts.

Detection-and-classification workflow. Monitoring must detect incidents reliably and route them to someone who can make the major/non-major call fast. The deadlines run in calendar time, so many CASPs keep a duty-officer rotation. An incident that starts at 11 p.m. on Friday has its clock running through Saturday morning.

Pre-built report templates. The initial notification, intermediate report and final report each get a template with the fields the technical standards require. Drafting from scratch during an outage produces errors.

Tested submission channels. Credentials, the authority’s portal or channel and the fallback route all need testing before an incident.

The intermediate report is heavier than the initial notice: by then the firm usually has a root-cause hypothesis, containment in place, impact figures and a recovery timeline. The final report closes the matter with the root-cause analysis, full impact figures, lessons learned and remediation. A thin final report invites follow-up questions.

What does the enforcement record show?

There is no published EU-wide record of DORA fines against CASPs to quote. Penalties for DORA breaches are set in national law, and an ICT failure at a CASP can also breach MiCA, where Article 111 requires maximum fines for a legal person of at least EUR 5 million or 5% of annual turnover. A firm with rehearsed incident processes and a current register is in a far better position when the authority asks questions than one that improvises.

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

CTPP designation operates one level above the firm’s own third-party register. Under DORA Articles 31-44, the European Supervisory Authorities designate ICT providers that are critical for EU financial entities and place them under an EU oversight framework. Each designated CTPP has a Lead Overseer (one of the ESAs) with powers to request information, run inspections, issue recommendations and impose periodic penalty payments on the provider.

Designation rests on four criteria in Article 31(2): the systemic impact of a large-scale failure of the provider, taking into account how many financial entities and how much in assets rely on it; the systemic importance of the entities that rely on it; their reliance on it for critical or important functions; and how easily it can be substituted. The assessment looks across all financial sectors, so a provider can be designated because of bank-sector reliance even if CASP use is modest. The first designations were published in late 2025.

What changes for a CASP using a designated CTPP?

Designation does not shift the CASP’s obligations onto the provider. Using a designated CTPP needs no extra permission, but four things still apply in full:

• Governance documentation. Why the provider was chosen, how the relationship is monitored and how issues escalate.
• Concentration monitoring. Single-provider, single-service and geographic concentration all need documented analysis under Article 29.
• Article 30 contractual arrangements. The full Article 30 terms, including the Article 30(3) set for critical or important functions. Negotiate into the provider’s financial-services framework rather than relying on standard terms, and check it clause by clause.
• Ongoing monitoring. Recommendations the Lead Overseer issues to the provider can affect the CASP’s continuity, so the relationship needs live monitoring.

What should you look for in counsel on DORA?

Many advisers who handle MiCA CASP files treat DORA as one section of the application rather than a discipline of its own. Ask for evidence of ICT risk frameworks and registers of information the adviser has built for live firms, how they mapped critical or important functions, and how they handled concentration analysis and Article 30 contract reviews. Those are the parts that benefit from experience across several files.