Skip to main content

MiCA · DORA — for Crypto-Asset Service Providers in authorisation

One ICT control set for
MiCA and DORA

DORA-aligned ICT and security arrangements, documented once for both regimes — built for your MiCA CASP application, not a second framework. Authorisation and acceptance remain with your NCA.

  • No preparation required
  • Built around your transitional deadline
  • No commitment

Built for crypto-asset firms in authorisation

EU Crypto-Asset Service Providers CASP
Regime Markets in Crypto-Assets MiCA
Regime Digital Operational Resilience DORA

CyAdvisoled by Andrey Gubarev, Founder & vCISOCISM, CDPSE, SABSA

1 engagement, one ICT-risk owner across both submissions — controls tagged by regime
2 regimes MiCA-cyber and DORA mapped where they overlap and diverge
Sound Familiar?

Your MiCA timeline is running — and ICT-risk is a listed requirement

On the project

  • Compliance is working on MiCA authorisation. Your CTO handles “security.” No one owns the overlap between the two regimes.
  • You have a draft DORA ICT policy and a MiCA-cyber section in the legal package. They cover different controls. Neither is complete for both.
  • You assumed the legal advisor would cover the ICT section — until you read what the NCA actually requires of it.
  • Your transitional period is counting down, and you cannot do this sequentially: the NCA ICT-risk review typically happens during authorisation, not after.

On you personally

  • You are named as the point of accountability, yet cannot answer “who owns ICT risk under both regimes?” without hesitation.
  • You have no bandwidth to become an ICT-risk expert while running an authorisation.
  • The deadline is visible. The gap is visible. The fix is not yet in place.

If even one of these is you — see the gap in 15 minutes →

What We Do

MiCA requires ICT-risk evidence. So does DORA. They are not the same document.

CyAdviso builds one unified ICT-risk framework that satisfies both in a single engagement — not two tracks, not two control sets that contradict each other at the NCA. Four deliverables:

Start here
01

Regime overlap analysis

Where MiCA’s ICT systems, security and continuity requirements (DORA-linked, NIS2-aware where applicable) and the DORA Level 2 RTS overlap, where they diverge, and what your NCA checks — so you produce evidence once, not twice.

02

Unified ICT control register

One document, controls tagged by regime. No contradictory policies, no overhead on two separate frameworks.

03

NCA submission package

The ICT-risk section of your MiCA file — structured and evidenced to reduce review gaps; acceptance remains with the NCA.

04

ICT-risk accountability model

Who owns ICT risk internally, where external support fits, how evidence is maintained, and how the CASP demonstrates oversight across both regimes.

Value per step

What each part of the work actually gets you

Each of the four deliverables maps to an observable outcome before submission.

What we deliver What you get
Know what is missing You see what each regime expects before submitting — fewer review gaps for the NCA to find.
One document, both regimes A single control set answers MiCA and DORA — no contradictory policies to reconcile.
A coherent NCA section An evidenced ICT-risk section the NCA can review — acceptance remains its decision.
A documented owner Your answer to “who is responsible for ICT risk under both regimes?” is on record.
First step · Free

See what the gap looks like for your entity

15 minno preparationno commitmentno email required

MiCA×DORA Overlap Check

We map the three points where the two regimes diverge for a CASP

We identify which controls in your posture already close both regimes, and what the NCA submission still needs — so you see the gap before you decide anything.

Ready to see your overlap?

The result is yours to keep — no newsletter, no follow-up sequence.

How It Works

Four steps, sequenced to your transitional deadline

4 stepsweeks 1–8run during authorisation

The four deliverables above, sequenced against the clock — built once, in the order the authorisation needs them.

  1. 1
    Weeks 1–2

    Map the overlap

    Where the two regimes overlap and diverge for your entity — and what to evidence once versus twice.

  2. 2
    Weeks 2–6

    Build the control set once

    Each control tagged to its regime as it is written, so nothing is back-filled under deadline pressure.

  3. 3
    Weeks 6–8

    Assemble for the NCA

    The ICT-risk section of your MiCA package, evidence trail ready for review.

  4. 4
    Throughout

    Ownership on record

    Documented accountability — your answer to every NCA ownership question, on record.

What Changes

What changes at the three moments that keep you up now

  • NCA reviews your MiCA application The ICT-risk section is complete. Fewer ICT-related review gaps for the NCA to query.
  • The DORA supervisory review or internal audit arrives You open one document. Not a second engagement from scratch.
  • The NCA asks who owns ICT risk You answer without hesitation. Not “our CTO covers security.”
For the company

The NCA receives a complete ICT-risk section, and the same framework already covers DORA supervisory review and internal audit. No second engagement. No rebuilding from scratch.

For you personally

You answer the accountability question with documentation, instead of personally bridging compliance and engineering. It is owned, documented, and defensible.

Your position after this

What your regulatory position looks like once this is done

Three observable things are true once the engagement is done — each something the NCA, an internal audit or a DORA supervisory review can ask you to show.

  • MiCA ICT section: a coherent, evidenced document — fewer review gaps for the NCA to query; acceptance remains with the NCA.
  • DORA evidence trail: built from the same control set — ready for supervisory review or internal audit.
  • A documented answer to every accountability question either regulator can ask — ownership detailed in the scope below.
Proof

Already done — for CASPs in authorisation

Names and logos are withheld by NDA. The operating pattern is the part that matters: one ICT control set across both regimes, the legal and ICT work kept separate, evidence ready for the NCA.

CASP

MiCA authorisation work running beside DORA readiness

Situation
A CASP needed cybersecurity and operational-resilience evidence without mixing legal authorisation work and ICT-risk delivery.
What we built
Shared evidence model for governance, ICT risk, incidents, outsourcing, resilience and board reporting.
At the next review
The handover separated MiCA legal work from DORA operating evidence, with no dependency on one undocumented owner.
“Andrey handled the cybersecurity side; our law firm handled legal. We hit the deadline. No gaps in the handover.”

COO · Crypto Asset Service Provider

CASP

One control set instead of two frameworks

Situation
A MiCA-cyber section started by the legal advisor and a separate DORA policy started by the tech team — overlapping and contradictory.
What we built
A single ICT control register, each control tagged to MiCA and/or DORA, replacing the two parallel drafts.
At the next review
One evidenced control set maintained across both regimes instead of reconciling two.
“We were about to run two ICT frameworks in parallel. One register, tagged by regime, stopped us maintaining two sets of policies that disagreed with each other.”

CTO · Crypto Asset Service Provider

CASP

A clear answer to “who owns ICT risk?”

Situation
The CEO was named accountable but could not say who owned ICT risk across MiCA and DORA.
What we built
A documented ICT-risk accountability model — internal owner, where external support fits, escalation paths.
At the next review
The management body could point to a named owner and a current control story.
“Before, I couldn’t say who owned ICT risk under both regimes. Now it’s documented, with names against it — I can answer that without hesitating.”

Founder & CEO · Crypto Asset Service Provider

Direct references can be shared on a discovery call with mutual consent. Case details are anonymised to avoid naming clients, regulated entities or confidential supervisory context.

Common Questions

Why this is harder than it looks — and why that matters

The assumptions that stall authorisation

“MiCA authorisation is a legal matter. ICT risk can come after.”

NCA ICT-risk review is typically part of authorisation, not deferred to after it. The legal advisor structures the application; ICT-risk implementation produces the evidence the NCA inspects. Without both, the ICT section is incomplete at submission. The exact sequence varies by NCA — confirm with your legal counsel.

“Our MiCA legal advisor will handle the ICT section.”

Legal advisors know what the regulation requires. ICT-risk implementation — control registers, incident procedures, third-party risk assessments, evidence structure — is a separate function. The MiCA ICT Delegated Acts specify technical and operational controls; these are implementation requirements, not legal text.

“We covered this through MiCA — DORA is just a subset.”

In our reading, DORA Level 2 RTS adds ICT third-party risk management, incident classification and reporting, and resilience-testing requirements not fully replicated in the MiCA Delegated Acts. One effort may satisfy one regime; both require deliberate mapping. Confirm the control-by-control overlap against the current text with your legal counsel.

“We cannot trust an external advisor with no published client list.”

Experience in EU financial-sector ICT-risk frameworks is documented — anonymised engagement outcomes are in the Proof section above. Sample deliverables are available on request.

The highest-stakes question

“Will the regulator accept an external vCISO supporting MiCA ICT-risk compliance?”

A CASP cannot outsource its management responsibility for ICT risk — so the model is internal accountability with documented external specialist support. CyAdviso supports control design, evidence mapping and DORA alignment; the CASP keeps responsibility and decision-making. The scope section sets out exactly who owns what. Align the final model with your legal counsel and the relevant NCA.

Have a question this page does not answer? Ask on a 15-minute call — or email info@cyadviso.com.

Regulatory basis

The sources this page relies on

Last reviewed 12 Jun 2026. Every claim above maps to primary regulatory text — confirm the control-by-control reading with counsel and the relevant NCA.

Show the four sources
  • MiCA — Regulation (EU) 2023/1114, Articles 62(2)(j) and 68(7)–(8). The authorisation application must include technical documentation of the ICT systems and security arrangements (Art 62(2)(j)); CASP governance must run resilient, secure ICT systems as required by Regulation (EU) 2022/2554 (DORA) (Art 68).
  • CASP authorisation RTS — Commission Delegated Regulation (EU) 2025/305 (Art 9) and (EU) 2025/299. The technical standards specify the ICT systems, security arrangements and DORA-compliance description an applicant must provide (2025/305, Art 9) and the continuity and regularity of services (2025/299).
  • DORA — Regulation (EU) 2022/2554 + Level 2 RTS. DORA adds third-party ICT risk, incident reporting and resilience-testing requirements not fully replicated in MiCA — the divergence the overlap analysis maps.
  • ESMA — MiCA CASP-authorisation material + the systems and security-access-protocols guidelines. ICT-risk review sits inside authorisation; the management body retains accountability — the basis for the independent external-support model.

Subject matter, not a credential claim. CyAdviso is independent of, and not endorsed by, these bodies. Confirm the application to your entity with counsel and the relevant NCA.

Compare Options

Instead of what? — your alternatives, honestly

Each is a real route a CASP takes — and where each one leaves a gap the NCA can see.

Comparison of one unified CyAdviso engagement against two separate engagements, lawyer-only, CTO/compliance DIY, and sequential MiCA-then-DORA.
Criteria CyAdviso
one set
Two
vendors
Lawyer
only
CTO /
DIY
MiCA
then DORA
One coherent NCA narrativeYesTwo narrativesLegal onlyInternalSequential gaps
ICT-risk implementationFullTwo buildsOut of scopeOther workstreamsDeferred
Duplicate work avoidedYesPay twiceRe-done laterRe-done laterRebuild under audit
Named, defensible ownerDocumentedTwo ownersNone“CTO covers it”Later
Risk at NCA reviewManagedContradictionsIncomplete ICTNot independentStalled review
CyAdviso — one unified set Recommended
Helps
One NCA narrative, full ICT-risk build, no duplicate work, named owner.
Gap
Risk managed — but NCA acceptance is never guaranteed.
Choose if
You want both regimes built once, with one accountable owner.
Two separate engagements Two vendors
Helps
Deep, dedicated coverage of each regime on its own.
Gap
Two frameworks that may contradict; pay twice; nobody reconciles them.
Choose if
The workstreams are truly independent and you reconcile internally.
Lawyer only Legal only
Helps
Application structure and legal text — counsel's part.
Gap
No ICT implementation; the ICT section stays incomplete.
Choose if
As your legal track — alongside, not instead of, ICT work.
CTO / compliance DIY Internal
Helps
Your team knows the systems — useful context.
Gap
No independent ICT-risk function; NCA wants documented ownership.
Choose if
You have spare, independent ICT capacity not on the authorisation.
MiCA now, DORA later Sequential
Helps
Front-loads only the nearest deadline.
Gap
DORA needs the same evidence — rebuilt later under audit.
Choose if
Rarely — building once costs less than rebuilding under audit.
The engagement, in plain terms

What this engagement is — and what it is not

Fixed-scope, priced up front per entity. What you get, what you keep, and who it is not for.

In scope — CyAdviso owns

The four deliverables above: regime overlap analysis · unified ICT control register · NCA submission package (ICT-risk section) · ICT-risk accountability model (scope, RACI, escalation).

Out of scope

The legal application and its drafting; representing you before the NCA; acting as your management body or responsible person; penetration testing and tooling; any guarantee of the NCA’s decision — acceptance always remains with the regulator.

Who owns what

  • Your legal counsel owns application strategy, legal drafting, regulatory correspondence and the formal NCA submission.
  • CyAdviso owns the ICT-risk implementation — controls, register, evidence structure and accountability model — as external specialist support.
  • You retain management responsibility, oversight and final decision-making for ICT risk — it cannot be outsourced, and this engagement is built so it never is.
How we de-risk the start

Begin with the free 15-minute Overlap Check — no preparation, no email, no commitment. If you proceed, the programme is fixed-scope and priced before you sign — see pricing below.

Pricing

One fixed-scope programme — priced up front

Start with the free 15-min Overlap Check. If you proceed, the engagement is fixed-scope and priced before you sign — no day-rates, no open-ended retainer.

Step 1 · Entry

MiCA × DORA Overlap Check

See the gap before you commit.

Free
15 minutes · no preparation · no commitment
  • Where the two regimes overlap and diverge for your entity
  • What you can evidence once versus twice
  • A scoped view of the work against your deadline
Request the Overlap Check →

Final fee is set after the Overlap Check, based on your entity’s current control posture and timeline. We do not guarantee the NCA’s decision — acceptance always remains with the regulator.

Next step

One ICT control set for MiCA and DORA — authorisation-ready evidence, built before your milestone.

Start with the free 15-min MiCA×DORA Overlap Check — the first step, before you decide anything.

Or email info@cyadviso.com · No commitment. No sales pressure.

15-min Overlap Check