Case Study: MiCA and DORA Readiness for a CASP

In this article ↓

Short answer
Client context
The problem
Work delivered
Evidence produced
What changed
What was deliberately not claimed
Lessons for CASPs
Related reading
Primary sources
FAQ
Can MiCA and DORA evidence be reused?
Is this a public CASP authorisation result?
What is the biggest risk for CASPs?
What should the board see?
Does DORA apply to every CASP?

Last reviewed: 5 May 2026

This is an anonymised engagement note. Client identity, jurisdiction, platform architecture and commercial details are withheld. The note describes the operating pattern, not a public regulatory outcome.

Short answer

A crypto-asset service provider needed to avoid running MiCA authorisation work and DORA operational-resilience work as disconnected projects.

The practical result was a shared evidence model:

Evidence area	MiCA relevance	DORA relevance
Governance	Management, policies and control ownership	Management-body ICT risk oversight
ICT risk	Platform and operational risk narrative	ICT risk framework and risk register
Incidents	Client, market and operational impact handling	ICT incident classification and reporting
Outsourcing	Service-provider dependency and accountability	ICT third-party risk and Register of Information
Resilience	Continuity of critical crypto services	Testing, BCDR and recovery evidence
Board reporting	Authorisation and control maturity	Risk, remediation and decision evidence

The goal was not to merge MiCA and DORA. The goal was to avoid duplicate work where the same evidence could support both conversations.

Client context

The client was a CASP preparing for regulatory scrutiny while operating a lean technology and compliance function.

The main pressure points were:

MiCA authorisation expectations;
DORA ICT risk and operational resilience;
third-party technology and infrastructure dependencies;
incident escalation and management reporting;
board visibility over control gaps.

The client had several good artefacts, but they were not mapped into one coherent control story.

The problem

The risk was duplication.

MiCA work was being discussed through authorisation and compliance language. DORA work was being discussed through ICT risk, incidents and supplier evidence. Engineering saw both as additional documentation load.

That creates three problems:

teams answer similar questions twice;
board reporting becomes fragmented;
evidence becomes inconsistent across regulatory workstreams.

Work delivered

The engagement focused on aligning evidence across the two regimes without overstating equivalence.

Workstream	Output
Scope mapping	CASP services, DORA scope touchpoints, authority context
Control crosswalk	MiCA/DORA evidence map for governance, ICT risk, incidents and outsourcing
ICT risk register	Risks linked to crypto services, systems, providers and controls
Incident workflow	Single intake with separate MiCA/DORA decision points where relevant
Supplier oversight	ICT provider map, criticality rationale and contract gap view
Board pack	Combined remediation and decision summary

Evidence produced

The useful evidence was operational, not decorative:

Artefact	What it answered
Regulatory scope map	Which obligations apply to which entity and service
ICT risk register	What can disrupt critical crypto services
Incident classification matrix	Which events need management, customer, partner or authority escalation
Supplier dependency map	Which providers support key services and data flows
Control evidence index	Where supporting policies, records and approvals live
Board remediation view	Which gaps need funding, ownership or risk acceptance

What changed

The client moved from parallel compliance tracks to one operating evidence model.

That meant:

fewer duplicated questionnaires and spreadsheets;
clearer ownership for ICT risk and supplier evidence;
better board visibility over remediation;
a single incident intake with documented classification paths;
stronger answers for partner and regulatory due diligence.

What was deliberately not claimed

This case study does not claim MiCA authorisation, supervisory approval or audit certification. Those outcomes depend on the entity, jurisdiction, legal work, NCA process and broader operating facts.

The claim is narrower: the engagement improved evidence quality and reduced fragmentation across MiCA and DORA readiness work.

Lessons for CASPs

Lesson	Practical implication
Do not treat MiCA and DORA as one law	Keep legal mappings separate
Do not run two evidence systems	Reuse operational evidence where valid
Map suppliers early	Crypto services are usually infrastructure-dependent
Test incident classification	Product, client, ICT and security events can overlap
Give the board a single risk view	Fragmented reporting weakens oversight

Andrey Gubarev

Related reading