DORA Implementation Playbook for CASPs (2026)

DORA is the most cited and least implemented piece of EU financial regulation of the current cycle. Regulation (EU) 2022/2554¹^[1] — the Digital Operational Resilience Act — has been in force since 17 January 2025. More than a year later, the vast majority of CASPs we work with are still mid-build on at least three of the eight workstreams supervisors actually inspect.

That gap matters for one specific reason: DORA does not grant CASPs a softer landing than banks. The regulation is sectorally agnostic. A MiCA-authorised crypto-asset service provider is held to the same five-pillar framework as a globally systemic bank, scaled only by proportionality — not by exemption. The ESAs (EBA, ESMA and EIOPA acting through the Joint Committee) have made clear that proportionality reduces evidence volume, not evidence scope.

This playbook is the operational view of the DORA implementation cycle — the rolling, never-quite-finished sequence of work CASP CTOs, CISOs, Heads of Operations and boards now own. It walks through each of the eight workstreams, the supervisor evidence pack each one produces, the 24-hour major-incident notification clock that catches firms unprepared, and the failure modes we see most often in 2026 inspections.

The temptation to read DORA as a banking regulation that also caught crypto is exactly the wrong starting point. DORA was deliberately designed as the horizontal ICT-resilience regime for the entire EU financial sector — banks, insurers, pension funds, payment institutions, EMIs, investment firms, trading venues, central counterparties, AND crypto-asset service providers. The EBA² operational-resilience policy hub treats CASPs as in-scope from authorisation day one.^[2]

What is unusual about CASPs in 2026 is the compression of regulatory obligations. A bank has had decades to layer up ICT controls. A newly MiCA-authorised CASP is being asked to satisfy MiCA, DORA, the Travel Rule, forthcoming AMLR requirements, and host-state conduct rules simultaneously. The compliance, ICT, and operational teams are usually the same five to fifteen people.

There are three structural reasons DORA bites CASPs harder than incumbents:

• Cloud concentration. Most CASPs run on a single Tier-1 cloud provider and one or two specialist crypto-AML, custody, or node-infrastructure vendors. DORA's ICT third-party risk regime is built precisely to surface that concentration.

• On-chain incident surface. A bank's incident taxonomy does not include private-key compromise, smart-contract exploits, oracle failure, bridge attacks or chain reorganisations. DORA's major-incident definitions still apply — they just have to be mapped onto crypto-native fault modes.

• Board literacy gap. DORA pushes ultimate accountability for ICT risk to the management body. On a CASP board, that often means founder-CEOs with deep crypto fluency but limited regulated-firm governance experience. Supervisors notice within minutes of an inspection interview.

DORA is built around five pillars: ICT risk management, ICT-related incident management, digital operational resilience testing, ICT third-party risk management, and information sharing. In practice — once you decompose the Regulation, the RTS, the ITS and the Joint Committee guidelines — the work breaks into eight operational workstreams. Each produces its own evidence pack that an NCA will ask to see.

The ICT risk management framework is the foundation document — Articles 5 to 16 of DORA. It sets out how the CASP identifies, classifies and protects ICT assets, detects anomalous activity, responds to incidents, and learns from them. The management body must approve it, review it at least annually, and demonstrably understand it.

The most common failure mode is treating this as a single policy PDF. Supervisors expect a linked policy stack: ICT risk policy, information security policy, access management policy, change management policy, asset inventory, business impact analysis, BCP, DR plan, and crisis communication plan — each with version control, approval evidence, and demonstrable use.

Articles 17 to 23 require firms to detect, log, classify and respond to ICT-related incidents — and to escalate major ICT-related incidents to the NCA. The classification criteria are quantitative and unforgiving: clients affected, transactions affected, data losses, reputational impact, duration, geographic spread and economic impact, scored against the Joint Committee thresholds.

The deliverable is an incident-handling SOP that runs from detection through to the 4-hour initial / 24-hour intermediate / 1-month final reporting clock — covered in detail in the next section.

Articles 24 to 27 require a digital operational resilience testing programme proportionate to size and risk. Every firm runs basic testing (vulnerability assessments, scans, penetration testing of public-facing systems, scenario testing of critical functions). Firms designated as significant must additionally run threat-led penetration testing (TLPT) at least every three years. The ESMA³ work programme tracks the Joint Committee deliverables that govern how testing is scoped, scored and shared with NCAs.^[3]

For CASPs in particular, scope definition is the trap. Wallet infrastructure, signing services, MPC clusters and smart-contract interaction layers all qualify as critical functions that must be in scope. Excluding them is the most common audit finding.

Articles 28 to 30 require a register of information covering every contractual arrangement with an ICT third-party service provider, with extended fields where the function is critical or important. The register is submitted annually to the NCA on a structured template — and is the document supervisors will ask for first in any inspection.

DORA prescribes minimum contractual provisions for any ICT contract supporting a critical or important function: audit rights, sub-outsourcing transparency, exit strategies, service-level metrics tied to recovery objectives, security obligations, data location, incident notification, termination triggers. Standard cloud or vendor MSAs almost never satisfy these out of the box.

Article 45 encourages — does not yet mandate — participation in cyber-threat intelligence-sharing arrangements between financial entities. For CASPs, the realistic options are sector ISACs, crypto-specific threat-sharing fora, and bilateral arrangements with infrastructure peers. The evidence pack is short — a policy, membership records, and at least one logged use — but its absence is increasingly noted at inspection.

Articles 31 to 44 establish a wholly new EU regime — direct oversight of Critical ICT Third-Party Service Providers⁴ by a Lead Overseer drawn from the ^[4]ESAs. A small number of Tier-1 cloud providers and other systemically important ICT vendors have been or will be designated as CTPPs.

The practical implication for CASPs: where your provider is CTPP-designated, you do not get to outsource your DORA contractual obligations to the Lead Overseer. The firm remains responsible for the register entry, the due diligence file, the exit strategy and the contractual provisions. CTPP oversight does not transfer firm-level accountability.

DORA does not prescribe specific Recovery Time Objective or Recovery Point Objective numbers, but it does require firms to set them for every critical or important function, justify them by reference to the business impact analysis, and test against them. For a CASP, that means defined RTO / RPO for order matching, custody / signing, settlement, fiat on-off ramps, KYC and Travel Rule messaging, and the public client interface.

The standard supervisory question — "what is your RTO for custody, and how did you arrive at it?" — is failed startlingly often. The right answer cites the BIA, the customer harm analysis, the contractual SLAs upstream, and the tested DR runbook.

Article 5 makes the management body — i.e. the board and executive management — "ultimately responsible" for ICT risk management. They must approve the framework, set risk tolerance, allocate budget, oversee the third-party strategy, and maintain sufficient knowledge and skills to understand ICT risks.

The evidence pack: annual board training records, board pack templates including ICT risk reporting, minuted approvals of the framework, a documented incident-escalation protocol that reaches the management body within hours, and — for non-executive directors — a credible ICT-risk skills matrix.

The summary view, with the supervisor evidence pack each workstream produces:

The single most operationally unforgiving piece of DORA is the major ICT-related incident notification clock. Once an incident is classified as major against the Joint Committee thresholds, the firm owes the NCA three distinct reports in escalating detail.

The clock starts at awareness — the moment the firm becomes aware the incident meets the classification criteria — not at incident inception. That distinction is where most firms either save themselves or fail. A well-built classification process makes the awareness moment auditable. A poorly built one means a supervisor can later assert that awareness was earlier than logged.

The three failure modes we see most often:

• No pre-drafted initial-notification template. Teams burn 90 of their 240 minutes building the template instead of investigating.

• No on-call classification authority. Engineering knows there is a problem, but no one is empowered to declare the incident major.

• Unclear NCA channel. The submission portal or email channel has never been used. The first attempt is during the live incident.

NCAs across the EEA are now running DORA-focused inspections as a matter of course alongside MiCA supervisory work. The minimum pack a CASP should be able to produce within 48 hours of an inspection notice:

• ICT risk management framework with board approval minute and most recent annual review.

• Linked policy stack — information security, access management, change management, BCP, DR, crisis communication.

• ICT asset inventory and business impact analysis identifying critical and important functions.

• Incident register with classification worksheets and a worked example of a major-incident notification (live or rehearsal).

• Most recent testing plan and results, including penetration test, scenario tests and (where applicable) TLPT engagement letter and scope.

• ICT third-party register in the structured ITS template, with critical-or-important flags, CTPP flags, and sample DORA-aligned contracts.

• RTO / RPO matrix and most recent DR test results against those targets.

• Board training records and an ICT-risk skills matrix for the management body.

• Exit strategy documents for every critical-or-important ICT outsourcing arrangement.

Across the CASP cohort we work with — including the firms we walked through the MiCA authorisation cycle — five DORA failure modes dominate.

First, copy-paste policy stacks. Templated frameworks that were never tailored to the firm's actual architecture. Inspectors read fast, and the giveaway is usually a reference to a system the firm does not operate.

Second, register-as-spreadsheet. The ICT third-party register is treated as a list of vendors with no link to the BIA, no critical-or-important assessment, no contractual fields, and no sub-outsourcing chain. The ITS template forces structure; treating it as procurement admin guarantees a finding.

Third, untested DR plans. A DR plan with no recent test, or a test that ran against staging rather than a meaningful failure scenario, is treated as no plan at all.

Fourth, weak contractual provisions. Cloud or SaaS contracts inherited from the pre-authorisation startup phase, never renegotiated to include DORA's mandatory clauses. CTPP designation does not fix this — the firm still owns its contract.

Fifth, absent management-body literacy. A founder-led board cannot defend the framework in inspector interviews because the framework was written by a consultant and signed by the board without engagement. The fix is the same as the one we use for bank-diligence files: pre-rehearsed Q&A, board training that ties to actual control evidence, and a designated ICT-risk director.

In 2026 the supervisory calendar for a EEA-authorised CASP runs on four parallel tracks: MiCA ongoing supervision, DORA implementation and inspection, AMLR readiness, and PSD3 / PSR adoption (for firms whose business model touches payment services). The temptation is to run each as a separate programme. The firms we see executing well treat them as overlapping evidence layers on a shared operational backbone.

That backbone is the same in every well-run regulated firm: a documented control set linked to risks, a tested incident process, a third-party register, a board that reads ICT papers, and a compliance function that can produce the underlying evidence on demand. DORA forces a degree of structural rigour that — if implemented well — makes the other three tracks materially cheaper to run. The eight workstreams should not be costed as standalone DORA spend.

The 2026 inspection pattern is also worth noting. NCAs are no longer running pure desk reviews. We are seeing on-site reviews, control walkthroughs with engineering teams in the room, live tests of incident classification on a hypothetical scenario, and direct interviews with the management body asking pointed questions about how often the ICT risk framework is reviewed and what changed at the last review. Document-only readiness will not survive the new inspection style.

Three practical recommendations follow from the 2026 pattern. First, rehearse the incident clock quarterly — not annually. The 4-hour window is unrecoverable if the muscle memory is not there. Second, refresh the third-party register every six months, not just before submission; vendor changes, sub-outsourcing chains and CTPP flags evolve continuously. Third, put one non-executive director through structured ICT-risk training and make that person the management-body interlocutor for inspections. The board-level governance workstream becomes credible the moment one director can defend the framework on their own.

Yes. CASPs authorised under MiCA are explicitly listed as financial entities in scope of DORA Article 2. Proportionality applies, but there is no exemption from any of the five pillars. Small CASPs may run a simplified ICT risk framework — they still need a framework, a register, an incident process, testing, and a management body that owns ICT risk.

Only firms designated by NCAs as significant — based on size, systemic relevance, complexity and risk — must perform TLPT, and at least every three years. In practice that captures the largest CASPs and any firm whose failure would have material market or customer impact. Smaller CASPs are not required to run TLPT but must still run advanced testing, scenario testing and threat-informed penetration testing of public-facing systems.

An incident classified as major against the Joint Committee thresholds in the ITS on incident classification — measured across clients affected, transactions affected, data losses, geographic spread, duration, economic impact, and reputational impact. The classification is the firm's responsibility, supported by a documented decision. The 4-hour initial / 24-hour intermediate / 1-month final clock starts at the moment the incident is classified as major (and no later than 24 hours from awareness for the initial notification).

Yes — and arguably more. CTPP designation puts the provider under direct ESAs oversight, but it does not displace firm-level responsibility under Articles 28 to 30. The firm still owns the register entry, the contract, the due-diligence file, the exit strategy, and the contingency plan for CTPP failure. CTPP designation should make exit strategies harder to define, not easier — concentration risk is precisely why providers get designated.

DORA is the lex specialis for ICT and operational resilience. Where MiCA sets out operational requirements (e.g. business continuity, ICT outsourcing, custody arrangements), DORA fleshes them out and prevails on detail. The right way to read them is together: MiCA defines the regulated activity perimeter and governance; DORA defines the ICT-resilience overlay. A coherent AML and operational compliance retainer handles both as a single workstream.

• MiCA Compliance Guide for CASPs: Full authorisation walkthrough that interlocks with the DORA operational overlay.

• AML Compliance Retainer for CASPs: How ongoing AML, MiCA and DORA workstreams are run as one operational stack.

• AMLR Readiness — 12-Month Roadmap: The companion roadmap for the AMLR transposition timeline running in parallel with DORA.

• Bank Diligence File for a Crypto Firm: The diligence pack banks now ask for — DORA evidence is increasingly part of it.

• Compliance Advisory: Hands-on build-out of the eight DORA workstream evidence packs for CASPs and EMIs.

DORA is not a one-off compliance project. It is a rolling implementation cycle that runs alongside MiCA supervision, AMLR transposition and PSD3 adoption — and the firms that win the next three years of CASP supervision will be the ones that treat the eight workstreams as permanent operational functions, not deliverables. The supervisor's first inspection is the easy one; the second is the audit of how you ran the framework in between.