# Case Study: MiCA and DORA Readiness for a CASP

Source: https://www.cyadviso.com/casp-mica-dora-readiness-case-study
Last reviewed: 2026-05-05
Tags: Case Study, MiCA, DORA, vCISO

Anonymised CASP case study: how a MiCA authorisation aligns with DORA ICT risk, incident readiness, supplier oversight and board-ready evidence today in 2026.

---

**Last reviewed: 5 May 2026**

**Key takeaways**

- CASPs need to connect MiCA authorisation work with DORA operational resilience, not run them as separate tracks.
- DORA has applied since 17 January 2025, so ICT risk, incidents and third-party evidence need to be live.
- Partners ask for proof that custody, trading, outsourcing and incident workflows have owners and records.
- Fastest path for a CASP: map regulated services -> identify ICT dependencies -> close evidence gaps -> prepare board-ready status.

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.

This is the same reconcile-once pattern behind the [MiCA × DORA control-set engagement for CASPs →](/mica-dora-casp).

## 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:

1. teams answer similar questions twice;
2. board reporting becomes fragmented;
3. 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 |

## Related reading

- [DORA vs MiCA: 2026 Compliance Guide for EU Fintechs and CASPs](/dora-vs-mica)
- [DORA Compliance Guide for EU Fintech SMBs: 2026 Evidence Roadmap](/comprehensive-guide-dora-compliance-fintech-smb)
- [DORA Incident Reporting 2026: Timeline, Classification and Evidence](/dora-incident-reporting)
- [DORA Register of Information: 2026 Guide for ICT Third-Party Risk](/dora-register-of-information)
- [vCISO for EU Fintechs: 2026 Guide to Scope, Evidence and Retainers](/vciso-everything-you-need-to-know)
- [See all CyAdviso case studies — EMI, PI and CASP engagement proofs](/case-studies)

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [Regulation (EU) 2023/1114 — MiCA, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/1114/oj)
- [European Securities and Markets Authority — MiCA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica)

## FAQ

### Can MiCA and DORA evidence be reused?

Some evidence can be reused, especially governance, ICT risk, incident, outsourcing and resilience evidence. The legal analysis should remain separate because MiCA and DORA have different purposes and obligations.

### Is this a public CASP authorisation result?

No. This is an anonymised readiness case study. It does not disclose or claim a public authorisation outcome.

### What is the biggest risk for CASPs?

A common risk is fragmented evidence: MiCA materials, DORA artefacts, supplier reviews and board reports tell different stories. That makes review harder.

### What should the board see?

The board should see the key operational risks, supplier dependencies, incident readiness, remediation priorities, risk acceptances and decisions needed for regulatory readiness.

### Does DORA apply to every CASP?

DORA scope depends on the entity and regulatory status. CASPs authorised under MiCA are included in DORA's financial entity scope, but entity-specific scope and local authority context should be confirmed.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/casp-mica-dora-readiness-case-study