What Is DORA and Why It Applies to Crypto
The Digital Operational Resilience Act (DORA) is an EU regulation that harmonises how financial entities manage information and communication technology (ICT) risk. Its goal is simple: make sure that a cyberattack, a cloud outage, or a failed software update at a regulated firm — or at one of its IT suppliers — cannot threaten the stability of the financial system or harm clients.
DORA entered into force on 16 January 2023 and has applied since 17 January 2025. Crucially for the crypto sector, it does not sit beside MiCA as a separate optional regime — it is the operational-resilience layer that every authorised CASP must satisfy. Where MiCA tells you who can provide crypto-asset services and how they must conduct business, DORA governs how resilient the technology behind those services has to be.
For a crypto exchange, custodian, or broker, that means your ICT risk framework, incident response, resilience testing, and supplier oversight are now examinable by your National Competent Authority (NCA) in the same way as your AML programme or capital position.
Does DORA Apply to Your CASP?
Almost certainly, yes. Article 2 of DORA sets out an exhaustive list of in-scope financial entities, and it explicitly names crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens (ART). If you hold — or are applying for — a CASP authorization, you are inside DORA.
DORA does, however, scale to your size. Under the proportionality principle, the depth of your obligations depends on your size, risk profile, and the nature of your services:
- Microenterprises (Art. 16) may apply a simplified ICT risk-management framework — fewer formal functions, lighter documentation.
- Standard CASPs apply the full ICT risk-management framework but are not subject to advanced threat-led penetration testing.
- Significant entities face the complete regime, including mandatory threat-led penetration testing (TLPT).
Proportionality reduces the paperwork — it does not exempt you. Even the smallest CASP must have an ICT risk framework, an incident-classification process, and a register of its IT suppliers. Our MiCA compliance consultants map your specific profile to the right DORA tier during authorization.
The Five Pillars of DORA
DORA is structured around five interlocking pillars. A compliant CASP needs evidence under each one:
| Pillar | Articles | What it requires |
|---|---|---|
| 1. ICT risk management | 5–16 | A documented ICT risk framework owned by the management body: asset inventory, protection & prevention, detection, response & recovery, backups, and continuous review. |
| 2. Incident management & reporting | 17–23 | Process to detect, classify, and report major ICT-related incidents to the NCA on a strict timeline (see below). |
| 3. Resilience testing | 24–27 | A testing programme — vulnerability scans, penetration tests, and, for significant entities, threat-led penetration testing (TLPT). |
| 4. ICT third-party risk | 28–44 | Due diligence, contractual safeguards, exit strategies, and a register of information for every ICT supplier (cloud, custody tech, KYC vendors). |
| 5. Information sharing | 45 | Voluntary sharing of cyber-threat intelligence with other financial entities. |
The management body — not the IT department — bears ultimate responsibility under Pillar 1. Directors must approve the framework and can be held accountable for failures.
The Incident-Reporting Clock
This is the obligation that catches firms out. When an ICT-related incident is classified as major, DORA Article 19 and the implementing technical standards (Commission RTS (EU) 2025/301) impose a three-stage reporting cascade with hard deadlines:
| Report | Deadline | Purpose |
|---|---|---|
| Initial notification | Within 4 hours of classifying the incident as major (and no later than 24 hours after becoming aware) | Alert the NCA that a major incident has occurred. |
| Intermediate report | Within 72 hours of the initial notification | Provide status, impact, and remediation progress. |
| Final report | No later than 1 month after the intermediate report | Root-cause analysis and corrective measures. |
Four hours is not long when systems are down and your team is firefighting. The only way to meet it is to prepare in advance: a documented classification matrix, a named incident lead, pre-drafted notification templates, and the NCA's reporting channel tested before you ever need it. Custody operators in particular should align this with the safeguarding duties on our crypto custody license page.
Resilience Testing & TLPT — Who Is In Scope
Every CASP must run a digital operational resilience testing programme proportionate to its risk: vulnerability assessments, network security testing, source-code reviews, and penetration testing on critical systems, at least annually for important functions.
Threat-led penetration testing (TLPT) under Articles 26–27 is a higher bar — advanced red-team testing modelled on the TIBER-EU framework, conducted at least every three years. TLPT applies only to entities identified by NCAs as significant based on systemic importance and risk profile. The large majority of small and mid-size CASPs are not in TLPT scope, but they still owe the baseline testing programme. Don't assume you are exempt from testing altogether — that is a common and costly misreading.
ICT Third-Party Risk & the Register of Information
Crypto businesses are deeply dependent on third parties — cloud hosting, custody technology, node infrastructure, KYC and blockchain-analytics vendors. DORA Pillar 4 makes that supply chain your responsibility.
You must maintain a register of information documenting every contractual arrangement for the use of ICT services, and be able to submit it to your NCA on request. Contracts with ICT providers must include mandatory clauses: service levels, access and audit rights, incident-cooperation duties, data location, and clear exit strategies so you are never locked in to a failing supplier.
At EU level, the most systemically important suppliers are designated critical ICT third-party providers (CTPPs) and overseen directly by the European Supervisory Authorities under a Lead Overseer model. For most CASPs the practical task is simpler but non-trivial: inventory your suppliers, fix the contracts, and keep the register current.
How DORA Stacks on Top of MiCA CASP Duties
MiCA already requires CASPs to maintain sound ICT systems and business-continuity arrangements. DORA does not replace those duties — it specifies them in far greater detail and adds the incident-reporting clock, the testing programme, and the third-party register. In practice, a CASP authorization file built today should treat MiCA and DORA as a single operational-resilience workstream rather than two separate projects.
This is why we recommend addressing DORA during authorization, not after. Retrofitting an ICT risk framework and supplier register onto a live operation is slower and more expensive than building them into your CASP application from the start. For the dedicated engagement, see our DORA compliance service.
DORA Compliance Checklist for CASPs
A condensed readiness checklist for a crypto-asset service provider:
- ☐ Board-approved ICT risk-management framework with named ownership
- ☐ Complete ICT asset inventory and risk assessment
- ☐ Incident classification matrix aligned to the major-incident criteria
- ☐ Incident-response playbook with a 4-hour initial-notification capability
- ☐ Tested reporting channel to your NCA
- ☐ Annual resilience-testing programme (and TLPT if significant)
- ☐ Register of information for all ICT third-party arrangements
- ☐ DORA-compliant contractual clauses and supplier exit strategies
- ☐ Business-continuity and disaster-recovery plans, tested
- ☐ Backup, restoration, and data-integrity procedures
If you cannot tick every box, you have a gap an NCA can act on. A structured gap analysis — paired with your AML/KYC programme — closes them before they become enforcement findings.
