MiCA and DORA: How the Two Regimes Overlap for Crypto Firms

Firms preparing a CASP application often treat MiCA as the whole job. It is not. DORA applies to the same entities, covers different ground, and is increasingly reviewed alongside the authorisation file. Teams that budget for one and discover the other halfway through lose months.

Here is how the two fit together.

What each regime is for

MiCA is market conduct and prudential regulation. It governs who may provide crypto-asset services in the EU, what capital they hold, how they treat clients, how they safeguard client assets, and what they must disclose.

DORA is operational resilience. It governs how financial entities manage ICT risk — systems, incidents, testing, and dependence on third-party technology providers. It applies across financial services, and authorised CASPs are in scope.

Put simply: MiCA asks whether you should be allowed to operate. DORA asks whether your systems will hold up when something breaks.

Where they overlap

Governance

Both require a management body that understands and owns the risk. MiCA wants fit-and-proper directors with relevant experience. DORA wants that same body to approve and periodically review the ICT risk framework. One board, two sets of documented responsibilities — and the minutes need to show both.

Incident reporting

MiCA has disclosure obligations around operational events affecting clients. DORA imposes a specific, tightly timed regime for major ICT-related incidents, with initial, intermediate and final reports. If you build only to MiCA's expectations, you will miss DORA's clocks.

Third-party risk

This is the sharpest overlap for crypto firms, because the stack is almost entirely outsourced. Your custody technology, node infrastructure, KYC vendor, screening provider and monitoring tool are all ICT third-party providers under DORA. That means a register of information, contractual clauses on audit and exit, and concentration-risk assessment.

Firms are frequently caught out here: they have selected good vendors but have no register, no exit plan, and contracts that lack the required audit rights.

Business continuity

Both regimes want continuity and recovery plans. DORA is more prescriptive, requiring testing on a defined cadence and, for significant entities, threat-led penetration testing.

The ICT third-party register in practice

DORA requires a register of information on all contractual arrangements for ICT services. Teams read this as an IT asset list and produce something far too thin. What is expected is a structured record per provider covering the service, criticality, the entity contracting it, data locations, substitutability, exit arrangements and the contractual terms giving you audit and termination rights.

Two consequences follow, and both take longer than expected. First, the register drives contract remediation: existing supplier agreements frequently lack the audit, incident-notification and exit clauses DORA requires, and renegotiating them takes months you have not scheduled. Second, criticality assessment forces a judgement about which providers support critical or important functions — and that judgement drives the rest of your obligations, including testing scope.

For crypto firms, the providers that matter are usually the ones nobody thinks of as IT vendors: custody technology, node infrastructure, blockchain analytics, screening and monitoring providers.

Incident classification and the reporting clock

MiCA and DORA both require incident reporting, on different triggers and different timetables, and a single event can engage both. The failure mode is discovering mid-incident that nobody knows which clock is running.

DORA sets out a staged flow for major ICT-related incidents: an initial notification, an intermediate report as the picture develops, and a final report with root cause and remediation. The demanding part is not the reports but the classification — deciding whether an incident is major, against defined criteria, quickly enough to meet the first deadline. That decision needs a named owner and a documented threshold, agreed in advance.

Build one incident process that classifies against both regimes at the point of detection, rather than two parallel processes that argue during an outage.

Resilience testing obligations

DORA requires a digital operational resilience testing programme — vulnerability assessments, scenario testing and, for entities meeting the criteria, threat-led penetration testing. Two points are routinely missed: testing must cover critical third-party dependencies, not only systems you host; and results must feed a documented remediation cycle with tracked closure. An untracked penetration test report is not a testing programme.

Practical sequencing: identify critical functions, map the ICT assets and providers supporting them, then scope testing to that map. Firms that test what is easy rather than what is critical produce evidence that does not answer the question asked.

Where they diverge

• Capital. MiCA sets prudential minimums by service class. DORA sets none.
• Client asset safeguarding. Purely MiCA.
• Resilience testing. Purely DORA — MiCA has nothing equivalent.
• Passporting. A MiCA concept. DORA applies regardless.
• Whitepapers and marketing. MiCA only.

The practical sequencing mistake

The common failure is treating DORA as a post-authorisation project. Two reasons that backfires:

First, your CASP application describes your operational setup. If the ICT risk section is thin, you invite questions that stop the clock — and every round of questions adds weeks. See CASP licence cost in 2026 for how those delays compound.

Second, the third-party register requires contract terms you may not have. Renegotiating audit and exit clauses with an incumbent vendor after signing is slow and expensive. Get them in the first contract.

A combined checklist

1. One risk framework, two mappings. Write it once, map controls to both regimes, so evidence is not duplicated.
2. Build the ICT third-party register early. Every vendor touching production, with criticality, exit plan and substitutability.
3. Fix contracts before you sign. Audit rights, incident notification, exit assistance, subcontracting limits.
4. Set incident clocks in the runbook. DORA's timings are tight; discovering them during an incident is too late.
5. Schedule resilience testing. Put dates in the plan the regulator sees.
6. Name owners. Both regimes want a person, not a department.

What this means for vendor selection

Because vendors become your DORA third-party dependencies, procurement stops being purely a compliance-features question. When you evaluate KYC providers, sanctions screening software or transaction monitoring software, ask about uptime history, incident notification commitments, audit rights and what exit actually looks like.

A vendor that cannot give you an exit plan is a concentration risk you will have to document and justify.

Further reading

Our DORA compliance guide for crypto firms goes deeper on the ICT requirements, and the CASP and MiCA overview covers the authorisation side. If you are still choosing where to apply, jurisdictions compared sets out what actually differs.

Frequently asked questions

Does DORA apply to crypto firms?

Yes. CASPs authorised under MiCA fall within DORA's scope, so the same entity carries both sets of obligations. Treating MiCA as the whole compliance job is the most common and most expensive scoping error in crypto authorisation.

What is the difference between MiCA and DORA?

MiCA is market conduct and prudential regulation — who may provide crypto services, capital, governance, disclosure and client asset protection. DORA is operational resilience — ICT risk management, incident reporting, resilience testing and third-party risk. They overlap on governance, incident reporting, third-party risk and continuity, and diverge everywhere else.

Can I do MiCA first and DORA later?

You can, but it is usually the expensive path. ICT obligations are increasingly reviewed alongside the authorisation file, and retrofitting a third-party register and testing programme under authorisation time pressure costs more than building them in parallel. See CASP licence cost.

What counts as a major ICT incident?

Classification follows defined criteria covering client impact, duration, geographic spread, data losses and economic impact. The operational requirement is that someone owns the classification decision and can make it quickly, because the first reporting deadline runs from detection, not from the end of the incident.

Do my vendors need to be DORA-compliant?

The obligation sits on you, not on them — you must ensure contractual arrangements give you the required audit, notification and exit rights, and that critical providers are managed accordingly. In practice that means vendor selection and contract terms become a compliance matter, not just a procurement one.