Why DORA Applies to Every CASP — Not Just Banks
The Digital Operational Resilience Act — Regulation (EU) 2022/2554, universally abbreviated to DORA — is frequently filed mentally under "banking regulation." For crypto-asset service providers, that mental filing is a compliance risk. DORA entered into force on 16 January 2023 and has applied in full since 17 January 2025, and its scope provision sweeps in the crypto sector explicitly.
Under Article 2, DORA applies to a long list of "financial entities" — and that list names crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens directly, alongside credit institutions, investment firms, payment institutions and insurers. The legal consequence is blunt: if your firm holds a MiCA CASP authorisation, or is in the process of obtaining one, you are a DORA financial entity. The same regulation that requires a systemic bank to run threat-led penetration tests requires your exchange, custody or brokerage operation to manage ICT risk, report major incidents on a fixed clock, and govern its technology suppliers to a defined standard.
Because DORA is a Regulation rather than a Directive, it is directly applicable in every Member State. There is no national transposition step that could soften or delay it, and — unlike MiCA — there was no crypto-specific transitional or grandfathering window. The 17 January 2025 application date applied to CASPs on the same terms as to every other financial entity. A firm that received its MiCA authorisation in, say, March 2026 does not get a separate DORA runway: it is expected to be operationally resilient from the first day it operates as an authorised CASP.
The one-sentence version: MiCA decides whether you are allowed to provide crypto-asset services; DORA decides whether your technology stack is resilient enough to be trusted to do so. Both bind you simultaneously, and a clean MiCA file does not earn you a single DORA point.
DORA vs MiCA: Two Regimes, One Firm
The most common — and most expensive — misconception we see among crypto founders is the assumption that satisfying MiCA's operational requirements automatically discharges DORA. It does not. The two regimes overlap in spirit but are distinct in law, and they are supervised against different technical standards.
MiCA's own conduct rules already require CASPs to have sound administrative arrangements, business continuity policies and adequate ICT systems. DORA then goes much further on exactly that ICT dimension, prescribing in granular detail how those systems must be governed, tested, monitored and reported. In practice, DORA operationalises and raises the bar on the technology-resilience expectations that MiCA states at a higher level. The interaction is now visible in supervision: in ESMA's 2025 peer review of Malta's MFSA, ICT and DORA-readiness were treated as something an NCA should assess before granting a CASP authorisation — not as a post-authorisation clean-up. We covered the broader authorisation bar in our complete guide to CASP licence requirements.
The timing matters acutely in 2026. The MiCA Article 143 transitional period ends on 1 July 2026, after which only firms holding a granted authorisation may operate — a deadline we analyse in depth in our guide to the MiCA transitional cliff and our 2026 compliance deadlines tracker. The firms crossing that line into full authorisation are inheriting their DORA obligations in the same moment. A CASP that spent the transitional period focused entirely on the MiCA file, and parked DORA, is now authorised and non-resilient at the same time — a combination that NCAs are well placed to notice.
| Dimension | MiCA | DORA |
|---|---|---|
| Core question | May you provide crypto-asset services? | Is your technology operationally resilient? |
| Instrument | Regulation (EU) 2023/1114 | Regulation (EU) 2022/2554 |
| Applies since | Phased; CASP regime from 30 Dec 2024 (transitional to 1 Jul 2026) | 17 January 2025 — no crypto transitional period |
| Focus | Authorisation, conduct, capital, client-asset safeguarding | ICT risk, incident reporting, testing, third-party oversight |
| Who enforces | NCAs + ESMA/EBA | NCAs + the ESAs (incl. oversight of critical providers) |
The Five Pillars of DORA at a Glance
DORA is organised around five thematic blocks. Every CASP needs a defensible position on all five — though, as discussed below, the depth required scales with the firm's size and risk profile.
| Pillar | What it requires of a CASP |
|---|---|
| 1. ICT risk management | A documented ICT risk-management framework owned by the management body, covering identification, protection, detection, response and recovery. |
| 2. Incident management & reporting | Classify ICT-related incidents, and report "major" ones to your competent authority on a fixed initial / intermediate / final cadence. |
| 3. Resilience testing | A regular testing programme; advanced threat-led penetration testing (TLPT) for entities identified by their NCA. |
| 4. ICT third-party risk | Govern technology suppliers through contractual standards and maintain a register of information on all ICT arrangements. |
| 5. Information sharing | Optional, voluntary arrangements to exchange cyber-threat intelligence with peers. |
Pillar 1: ICT Risk Management and Board Accountability
The foundation of DORA is a comprehensive ICT risk-management framework: a documented set of strategies, policies, procedures and tools to protect the firm's information assets and keep critical functions running through disruption. The framework must cover the full lifecycle — identifying ICT-supported business functions and their dependencies, protecting and preventing, detecting anomalous activity, responding and recovering, and learning from incidents.
DORA's defining governance feature is that it places ultimate responsibility on the management body, not on the IT department. The board (or its equivalent) must approve the ICT risk strategy, set the firm's risk tolerance for ICT disruption, allocate an adequate budget, and maintain enough collective knowledge to challenge the resilience posture meaningfully. "We outsourced it to our cloud provider" is not an answer DORA accepts: accountability cannot be delegated out of the firm. For a crypto business where the founders are often the board, this means the people at the top must be able to speak to ICT resilience in concrete terms.
A frequent crypto-firm gap: treating ICT risk as a security-team deliverable with no board fingerprints on it. If your management body cannot point to a board-approved ICT risk strategy, a defined risk appetite, and minutes evidencing oversight, you have a documentation problem that an NCA will find on the first look.
Pillar 2: Incident Classification and the 24h / 72h / 1-Month Clock
DORA replaces vague "tell the regulator if something serious happens" expectations with a structured, rule-based reporting regime. Two steps matter: first you classify an ICT-related incident, then — if it qualifies as major — you report it to your competent authority on a defined timeline.
Classification is not a judgement call left to instinct. DORA's technical standards set out criteria for assessing whether an incident is major, including the number of clients or financial counterparts affected, the amount or criticality of data lost, the duration and downtime of the disruption, the geographical spread, the economic impact, and the criticality of the services affected. A custody outage that prevents clients from withdrawing assets, a breach exposing client data, or a trading-engine failure during market hours will frequently cross the "major" threshold.
Once an incident is classified as major, the reporting clock runs in three stages, fixed by DORA's regulatory and implementing technical standards on incident reporting:
| Report | Indicative timing | Purpose |
|---|---|---|
| Initial notification | Broadly within 24 hours of becoming aware and classifying the incident as major (and as little as 4 hours after classification) | Alert the authority that a major incident has occurred |
| Intermediate report | Within 72 hours of the initial notification | Update on status, impact and remediation in progress |
| Final report | No later than one month after the intermediate report | Root-cause analysis and corrective measures taken |
The exact trigger points and reporting templates are prescribed by the technical standards rather than left to firm discretion, and entities must use the standard forms. Significant cyber threats (near-misses that did not become incidents) may also be reported on a voluntary basis. The operational implication for a CASP is that incident response is no longer purely a technical firefight — there must be a pre-built compliance workflow that can classify an incident and file a regulator notification inside hours, at any time of day. A firm that discovers, mid-incident, that nobody owns the regulatory notification has already failed this pillar.
Practical control: pre-draft your initial-notification template, pre-identify the competent-authority submission channel, and run a tabletop exercise where the clock starts at 02:00 on a weekend. The 24-hour initial window is unforgiving precisely because incidents do not occur during office hours.
Pillar 3: Resilience Testing and When TLPT Bites
DORA requires every financial entity to run a digital operational resilience testing programme proportionate to its size and risk. At the baseline, this means a regular cycle of vulnerability assessments, open-source and network security scans, gap analyses, physical and logical security reviews, scenario-based tests, compatibility and performance testing, and penetration testing of critical systems. The point is to find weaknesses before an attacker does, on a documented schedule, with findings tracked to remediation.
The advanced tier — threat-led penetration testing (TLPT) — is where DORA gets demanding, and it does not apply to everyone. TLPT involves a controlled, intelligence-led red-team attack on the firm's live production systems, modelled on real threat actors. Under DORA it must be carried out at least every three years, but only by entities that competent authorities identify as in scope, based on their impact, systemic importance and ICT risk profile. The methodology is aligned with the established TIBER-EU framework.
For most small and mid-sized CASPs, the realistic position is that they fall below the TLPT threshold and must instead evidence a robust baseline testing programme — but they cannot assume that status. The determination is the NCA's, and a CASP that grows quickly, custodies significant client assets, or becomes systemically relevant in its market may be brought into the TLPT population. Either way, "we ran a pen test once" is not a programme. DORA expects a structured, recurring, risk-based testing cycle with governance around it.
Pillar 4: Third-Party Risk and the Register of Information
This pillar is, for crypto firms, frequently the heaviest lift — because CASPs are unusually dependent on third-party technology. Cloud hosting, blockchain-node infrastructure, custody-tech vendors, market-data and price-oracle providers, KYC/AML screening tools, and managed-security services are all ICT third-party service providers in DORA's sense, and DORA holds the firm responsible for the resilience risk they introduce.
Two obligations stand out. First, contracts with ICT providers must meet DORA's mandatory contractual standards (set out in Article 30): clear service descriptions and service levels, data location and processing terms, full assistance during ICT incidents, audit and access rights for the firm and its supervisors, defined security requirements, subcontracting conditions, and — critically — robust exit strategies so the firm can move off a provider without operational collapse. Legacy supplier contracts signed before DORA almost never contain these clauses; remediating the contract estate is a core part of compliance.
Second, every financial entity must maintain a register of information cataloguing all of its contractual arrangements for the use of ICT services, distinguishing those that support critical or important functions. This register is not an internal nicety: entities must keep it current and report it to their competent authority, and supervisors use the aggregated registers to map concentration risk across the financial system. Building and maintaining an accurate register — with the prescribed data fields for each contract and provider — is one of the most underestimated operational tasks under DORA.
The concentration trap: if your exchange, your custody provider and your analytics stack all ultimately run on the same hyperscale cloud region, DORA wants you to see and manage that single point of failure. A register that hides concentration behind vendor names is not doing its job.
Pillar 5: Information Sharing
The fifth pillar is the lightest. DORA encourages — but does not mandate — financial entities to participate in voluntary arrangements to exchange cyber-threat information and intelligence with trusted peers, within communities designed to enhance collective resilience. Participation must respect data-protection and confidentiality rules, and entities notify their competent authority on joining or leaving such an arrangement. For a CASP, the practical value is real: crypto-targeting threat actors reuse techniques across firms, and shared indicators of compromise can be an early-warning system. But unlike the first four pillars, choosing not to participate is not itself a breach.
Oversight of Critical ICT Third-Party Providers
DORA introduces something genuinely new to EU financial regulation: a direct Union-level oversight framework for Critical ICT Third-Party Providers (CTPPs). The European Supervisory Authorities (the ESAs) designate certain ICT providers — in practice, the large cloud and core-technology providers on whom much of the sector depends — as critical, and assign each a Lead Overseer drawn from the ESAs. That Lead Overseer can examine the provider, request information, conduct inspections, and issue recommendations, with the power to impose periodic penalty payments for non-cooperation that can reach 1% of the provider's average daily worldwide turnover.
For a CASP, the CTPP regime is mostly indirect but strategically important. It does not transfer your responsibility — you remain accountable for your own ICT third-party risk even when your provider is a supervised CTPP. But it does mean your largest dependencies are themselves under EU scrutiny, and DORA restricts reliance for critical or important functions on ICT providers established outside the EU unless they have an EU presence that brings them within reach of the framework. When you select infrastructure, the provider's DORA posture is now part of due diligence, not an afterthought.
Proportionality: What Smaller CASPs Actually Have to Do
DORA is explicitly built on the principle of proportionality: obligations scale with a firm's size, risk profile, and the nature and complexity of its services. This is the provision that prevents a five-person startup CASP from being held to the same operational standard as a systemic bank — but it is widely misread as an exemption, which it is not.
The headline relief sits in Article 16, which allows a simplified ICT risk-management framework for certain entities — notably micro-enterprises (broadly, fewer than 10 staff and annual turnover or balance-sheet total not exceeding EUR 2 million) and some small and non-interconnected entities. Qualifying firms apply a lighter-touch version of the risk-management framework and sit outside the most advanced testing obligations, such as mandatory TLPT.
What proportionality does not do is switch off the core duties. Even the smallest CASP must still manage ICT risk in a documented way, classify and report major incidents on the regulatory clock, govern its ICT third-party providers under DORA's contractual standards, and maintain a register of information. Proportionality reduces depth and documentation; it does not create a category of CASP to which DORA simply does not apply.
How to use proportionality correctly: document why your firm qualifies for the lighter framework (the micro-enterprise test, your risk profile), rather than silently doing less. A reasoned, evidenced proportionality assessment is itself a compliance artefact; an unexplained gap is just a gap.
The CASP-Specific Risks DORA Was Not Written For
DORA is sector-neutral by design, but crypto firms carry an ICT risk profile that makes several of its requirements bite harder than they do for a traditional intermediary. A serious DORA implementation for a CASP has to translate the generic framework onto crypto-native failure modes:
- Private-key and wallet infrastructure. The compromise of signing keys or a custody wallet is the crypto equivalent of an irreversible vault breach. Your ICT risk framework, access controls and incident playbooks must treat key-management systems as the highest-criticality assets you hold.
- Irreversibility. On-chain transactions cannot be clawed back. An ICT failure that releases the wrong transaction is not recoverable the way a mistaken bank transfer often is — which raises the stakes on the "detect and respond" parts of the framework.
- A wide, blockchain-facing attack surface. CASPs are persistent, high-value targets for phishing, social engineering, ransomware and smart-contract exploitation. Baseline testing has to reflect that the threat model is more aggressive than for a comparable non-crypto firm.
- Dense third-party dependency. Node providers, oracles, custody-tech vendors and liquidity infrastructure create a web of interdependencies that the register of information must capture honestly — including the concentration risk that emerges when several "different" vendors rest on the same underlying infrastructure.
Firms that already understand these dynamics from their MiCA and AML work — for instance, the operational discipline behind CASP authorisation and the failure patterns we catalogue in our analysis of the biggest MiCA compliance mistakes — have a head start. DORA asks them to express that same operational maturity in a specific, evidenced, regulator-facing form.
Is your CASP DORA-ready as well as MiCA-ready?
Compliora maps your firm's regulatory obligations across MiCA and DORA, flags the gaps, and turns them into a prioritised action plan — so authorisation and operational resilience are handled as one programme, not two.
Start your free assessment →DORA-Readiness Checklist for CASPs
If you are a newly authorised or soon-to-be-authorised CASP, the following is the short, honest list of what a credible DORA posture looks like. Treat anything you cannot evidence as an open finding.
Governance & ICT risk management
- A board-approved ICT risk-management framework exists, with a defined ICT risk appetite and evidence of management-body oversight in minutes.
- Critical and important business functions, and their ICT dependencies, are mapped and kept current.
- If you rely on the
Article 16simplified framework, your micro-enterprise / eligibility assessment is documented and reasoned.
Incident management & reporting
- You have an incident-classification procedure aligned to DORA's major-incident criteria.
- Pre-built initial / intermediate / final report templates exist, with named owners and a known submission channel to your competent authority.
- You have tested the 24-hour initial-notification workflow under realistic, out-of-hours conditions.
Testing
- A documented, recurring resilience testing programme is in place (vulnerability assessments, scans, scenario tests, penetration testing of critical systems).
- You have assessed — and can justify — whether you fall in or out of the TLPT population, and have a plan if your NCA brings you in.
Third-party risk & the register
- A register of information covers every ICT third-party arrangement, flagging those supporting critical or important functions, and is ready to report to your NCA.
- ICT contracts meet the
Article 30mandatory clauses — audit rights, incident assistance, security, subcontracting and exit strategies — with a remediation plan for legacy agreements that do not. - Concentration risk across providers (including shared underlying infrastructure) is identified and managed.
DORA is not a one-off project that closes when the MiCA authorisation is granted; it is a continuing operating standard that runs for as long as the firm provides crypto-asset services. The firms that handle it well are those that build MiCA and DORA into a single compliance programme from the outset — and treat operational resilience as a board-level commitment rather than an IT line item. For where DORA sits in the wider 2026 obligations landscape, see our complete overview of EU crypto regulation in 2026.
Frequently asked questions
Does DORA apply to crypto firms and CASPs?
Yes. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) lists crypto-asset service providers authorised under MiCA, and issuers of asset-referenced tokens, among the "financial entities" in its scope under Article 2. Any firm that holds — or is applying for — a MiCA CASP authorisation is a DORA financial entity and must comply with DORA's ICT risk-management, incident-reporting, resilience-testing and third-party-risk requirements. DORA is a directly applicable EU regulation, so it binds CASPs in every Member State without national transposition.
When did DORA start applying to financial entities?
DORA entered into force on 16 January 2023 and has applied since 17 January 2025. There is no separate transitional period for crypto firms: a CASP that obtains its MiCA authorisation in 2026 is expected to be DORA-compliant from day one of authorised operation, not to treat DORA as a later add-on. Several national competent authorities now assess ICT/DORA-readiness as part of the CASP authorisation decision itself.
What are DORA's incident reporting deadlines for a major ICT incident?
DORA's technical standards set a three-stage reporting cadence to the competent authority for an incident classified as major: an initial notification (broadly within 24 hours of the firm becoming aware of and classifying the incident, and as little as 4 hours after classification), an intermediate report within 72 hours of that initial notification, and a final report no later than one month afterwards. The exact triggers and templates are fixed by the regulatory and implementing technical standards on incident reporting. Classification as "major" is itself rule-based, using criteria such as the number of clients affected, data losses, downtime, geographical spread and economic impact.
Do small CASPs and micro-enterprises get lighter DORA obligations?
Partly. DORA is built on proportionality: micro-enterprises (broadly, fewer than 10 staff and annual turnover or balance-sheet total not exceeding EUR 2 million) and certain small, non-interconnected entities may apply a simplified ICT risk-management framework under Article 16 and are not subject to the most advanced testing obligations. Proportionality reduces documentation and the depth of some controls — it does not exempt a small CASP from the core duties to manage ICT risk, report major incidents, manage third-party providers and maintain a register of information.
Is threat-led penetration testing (TLPT) mandatory for every CASP?
No. All financial entities must run a regular digital operational resilience testing programme (vulnerability assessments, scans, scenario tests and similar). Advanced threat-led penetration testing (TLPT) — at least every three years — applies only to entities that competent authorities identify on the basis of their impact, systemic importance and ICT risk profile. Most smaller CASPs will run the baseline testing programme rather than full TLPT, but every CASP must be able to evidence a structured, risk-based testing cycle.
How does DORA relate to a MiCA CASP authorisation?
They are two separate regimes that bind the same firm. MiCA governs whether you may provide crypto-asset services (authorisation, conduct, capital, client-asset safeguarding). DORA governs how operationally resilient your technology must be (ICT risk, incident reporting, testing, third-party oversight). A MiCA authorisation does not satisfy DORA, and DORA-readiness is increasingly examined as part of the MiCA authorisation file. With the MiCA transitional period ending on 1 July 2026, newly authorised CASPs inherit full DORA obligations immediately.
