DORA Compliance Explained: What Crypto Firms Must Do
DORA compliance explained for crypto and fintech: who is in scope, the five pillars, the third-party register, incident reporting deadlines, and how it interacts with MiCA.
Last updated: 29 July 2026
Most crypto firms in Europe spent 2024 and 2025 focused on MiCA. Meanwhile a second regulation was quietly imposing a different kind of obligation, one that has nothing to do with crypto specifically and everything to do with whether your systems stay up.
DORA, the Digital Operational Resilience Act, is the EU's framework for ICT risk in the financial sector. It applies to crypto-asset service providers alongside banks, insurers and payment institutions, and it treats an outage or a compromised supplier as a supervisory matter rather than an engineering inconvenience.
This guide covers who is in scope, the five pillars, what the third-party register actually requires, incident reporting deadlines, and how DORA sits alongside MiCA. Educational only, not legal advice.
What is DORA?
DORA is Regulation (EU) 2022/2554. It entered into application on 17 January 2025 and creates a single, harmonised set of requirements for managing information and communication technology risk across EU financial entities.
Its premise is straightforward. Financial regulation has traditionally concentrated on financial risk: capital, liquidity, conduct. But a firm with a pristine balance sheet is still unable to serve customers if its systems are down or its critical cloud provider fails. DORA makes operational resilience a regulated obligation with named accountability rather than an internal engineering standard.
The scope is deliberately broad. It covers roughly twenty categories of financial entity, and it explicitly includes crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens. If you hold or are seeking a CASP authorisation, DORA applies to you.
The five pillars
| Pillar | What it requires |
|---|---|
| ICT risk management | A documented framework covering identification, protection, detection, response and recovery, owned by the management body |
| Incident reporting | Classify ICT incidents and report major ones to your competent authority on a defined timetable |
| Resilience testing | Regular testing, with threat-led penetration testing for significant entities |
| Third-party risk | Register of all ICT providers, mandatory contract terms, exit strategies |
| Information sharing | Voluntary exchange of cyber threat intelligence between firms |
The part firms underestimate
DORA places ultimate responsibility for ICT risk on the management body, and members are expected to maintain sufficient knowledge to discharge it. This is not a control you can fully delegate to a CTO or an outsourced provider. Boards are required to approve the strategy, understand the risks, and be able to demonstrate that they did.
In practice that means ICT risk needs a standing agenda slot, documented board training, and minutes that show genuine engagement rather than a rubber stamp.
The third-party register
If DORA has one requirement that consumes more time than firms expect, it is the register of information on contractual arrangements with ICT third-party providers.
You must maintain a structured record of every ICT service you rely on, identifying which support critical or important functions. That last classification drives most of the downstream obligations, and it is where judgement is required. Your cloud host is obviously in scope. Your blockchain node provider, your KYC vendor, your market data feed, your custody technology, your alerting tool: each needs assessing rather than assuming.
Contracts with providers supporting critical functions must include specific terms: service level descriptions, data location, access and audit rights for you and your regulator, incident notification obligations, termination rights, and exit arrangements.
That last one is the genuinely hard part. DORA expects a documented, tested exit strategy: how you would move off a provider without interrupting service. Many firms discover during this exercise that they could not realistically leave their primary cloud or custody provider at all, which is precisely the concentration risk the regulation is designed to surface.
Incident classification and reporting
DORA requires classifying ICT-related incidents against criteria including clients affected, duration, geographic spread, data losses, criticality of services affected, and economic impact. Incidents crossing the thresholds are major and must be reported to your competent authority.
Reporting runs in three stages: an initial notification, an intermediate report as the picture develops, and a final report with root cause and remediation. The deadlines are tight, and the initial notification in particular is measured in hours rather than days.
The operational implication is that classification cannot be improvised during an incident. You need the criteria mapped in advance, a named person able to make the call at 2am, and a template ready. Firms that treat reporting as a post-incident exercise routinely miss the first deadline.
Resilience testing
All in-scope entities must run a testing programme covering vulnerability assessments, scenario-based testing, and business continuity exercises, at least annually for critical systems.
Entities designated as significant face an additional requirement: threat-led penetration testing, modelled on the TIBER-EU framework, conducted at least every three years using realistic adversary tactics against live production systems. This is materially more demanding than a standard penetration test and requires accredited testers.
How DORA and MiCA interact
They are complementary and independent. Meeting one does not satisfy the other.
- MiCA governs authorisation, conduct, client asset safeguarding, disclosure and market abuse. It answers: are you permitted to offer this service, and are you treating clients properly?
- DORA governs the technology underneath. It answers: will your systems keep working, and can you recover when they do not?
A CASP applying for authorisation will find that competent authorities examine ICT resilience as part of the application. In practice the two are assessed together even though they are separate instruments. Our guide to verifying MiCA authorisation covers the licensing side, and top blockchains for Europe under MiCA covers the ecosystem context.
DORA is also part of why the mid-tier exchange model has come under pressure. Compliance cost here is largely fixed: the register, the testing programme, the board governance and the exit strategies cost roughly the same whether you serve fifty thousand users or five million. That arithmetic contributed to the 2026 wave of exchange wind-downs.
Where to start
- Confirm scope. Are you an in-scope financial entity, and are any of your group companies?
- Build the register. Inventory every ICT provider and classify which support critical or important functions. This takes longer than anticipated and everything else depends on it.
- Gap-check contracts. Review agreements with critical providers against DORA's mandatory terms. Renegotiation takes months.
- Write and test exit strategies for critical providers. Untested plans do not count.
- Set incident classification criteria and rehearse the reporting timeline before you need it.
- Give the board its role. Documented training, standing agenda item, approved strategy.
Does DORA apply to DeFi?
DORA applies to defined categories of financial entity, principally those authorised under EU financial services legislation. A genuinely decentralised, non-custodial protocol with no authorised entity behind it does not fit those categories.
JewelSwap is non-custodial across MultiversX, Sui and Radix, with users interacting directly with smart contracts from their own wallets. It is not a CASP and does not hold client assets, so the DORA obligations described here do not attach to the protocol. As with MiCA, that reflects the architecture rather than an exemption anyone granted: a business that operates a front end commercially, holds client assets, or seeks CASP authorisation will find DORA applies alongside it.
Frequently asked questions
What is DORA compliance?
Meeting the requirements of the EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554, which sets harmonised rules for managing ICT risk across financial entities. It covers ICT risk management, incident reporting, resilience testing, third-party risk and information sharing.
When did DORA come into force?
DORA entered into application on 17 January 2025, following a two-year implementation period after its adoption in 2022.
Does DORA apply to crypto companies?
Yes. Crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens are explicitly within scope, alongside banks, insurers, payment institutions and around twenty other categories of financial entity.
What is the DORA register of information?
A structured record of all contractual arrangements with ICT third-party service providers, identifying which support critical or important functions. That classification determines which contractual terms, oversight and exit-strategy requirements apply.
How quickly must a major ICT incident be reported under DORA?
Reporting follows a three-stage process of initial, intermediate and final reports to your competent authority. Deadlines are tight, with initial notification measured in hours, so classification criteria and templates need to be prepared in advance rather than during an incident.
Is DORA the same as MiCA?
No. MiCA governs authorisation, conduct and client asset protection for crypto services. DORA governs the operational resilience of the technology underneath. They apply independently, and complying with one does not satisfy the other.
Keep reading
