Most crypto asset service providers (CASPs) spent 2024 preparing for MiCAR authorization. That was the right priority. But DORA — Regulation (EU) 2022/2554 — landed on 17 January 2025 with far less fanfare, and it imposes obligations that many VASPs haven't yet addressed.
This post covers what DORA means for crypto platforms operating in the EU, what operational resilience actually requires in practice, and how Arkē helps you cover the gaps before a regulator finds them first.
Why DORA Hits Crypto VASPs Harder Than Traditional Finance
The Digital Operational Resilience Act was designed for financial institutions, but it applies to crypto asset service providers by default. CASPs are classified as financial entities under DORA's scope, and the regulation's requirements for ICT risk management, incident reporting, and third-party oversight map awkwardly but directly onto how crypto platforms actually operate.
Here's the core problem: crypto platforms rely heavily on third-party infrastructure. Your wallet-as-a-service provider. The RPC node you're routing through. The exchange API that prices your execution. The custodian that holds your client assets. Each of these is an ICT third-party dependency, and DORA treats them as concentration risks.
A single cloud provider outage — or a regulatory action against a wallet infrastructure provider — can halt a VASP's entire operations. That's not hypothetical. It's happened. DORA's fifth pillar, on third-party ICT risk, is specifically designed to force firms to model these scenarios and hold exit plans.
The Five DORA Pillars for Crypto VASPs
DORA organizes its requirements around five pillars. Here's how they translate to a typical VASP:
| DORA Pillar | VASP-Specific Obligation | Arkē Coverage |
|---|---|---|
| ICT Risk Management | Maintain ICT risk register; conduct annual risk assessments; implement hardening policies | Arkē screens third-party ICT providers against sanctions, PEP, and adverse media as part of onboarding |
| Incident Classification & Reporting | Classify ICT incidents using DORA templates; report major incidents to national competent authority within prescribed timeframes | Arkē's SAR-format reporting engine generates DORA-compliant incident notifications adaptable to FIU templates |
| Operational Resilience Testing | Conduct TIBER-EU/Threat-Led Penetration Testing (TLPT) for significant entities; range of other resilience tests annually | Arkē screens full vendor register for concentration risk, supporting your resilience testing programme |
| Third-Party ICT Risk | Pre-contract due diligence on all critical ICT providers; contract clauses including audit rights and exit provisions | Arkē batch-screens wallet providers, RPC nodes, exchange integrations, and custodians for sanctions/PEP risk |
| Information Sharing | Participate in voluntary threat intelligence sharing; report near-misses to peer institutions | Arkē adverse media screening surfaces early-warning signals before they become reportable incidents |
What VASPs Need to Do Right Now
If you're operating a CASP in the EU and haven't mapped DORA obligations to your current posture, here's the priority list:
**1. Build your ICT risk register.** Map every third-party technology dependency — wallet providers, node operators, exchange integrations, cloud infrastructure, KYC vendors. Classify each as critical or non-critical. DORA requires this for every financial entity, and the national competent authority will ask for it in any supervisory engagement.
**2. Run pre-contract due diligence on critical ICT providers.** This means documented checks on your wallet-as-a-service provider, your exchange API counterparties, your custodians. The due diligence package should include sanctions screening (OFAC and EU consolidated lists), PEP checks, and adverse media review. If your custodian shows up in an adverse media story about a security incident, that's your early warning system.
**3. Implement a DORA-compliant incident classification template.** Not every ICT incident triggers a report to the NCA. DORA defines thresholds — based on impact, duration, and number of affected clients — that determine whether an incident is "major" and must be reported. Your incident response process needs to apply this classification within the first hours of an event, not after the reporting deadline has passed.
**4. Conduct TLPT testing.** Significant entities — and VASPs managing client assets at scale will likely qualify — must undergo threat-led penetration testing under TIBER-EU framework by January 2026. This is a mature, structured red-team exercise, not a basic penetration test.
**5. Audit your contract clauses.** Every critical ICT provider contract should include: audit rights for the VASP (or a right to mandate an independent audit), exit provisions (minimum 6 months' notice, with migration support), and a direct notification clause for security incidents affecting your data.
The Crypto-Specific Twist
Here's what most DORA guides won't tell you: DORA's third-party ICT provisions overlap significantly with MiCAR's white paper and safeguarding requirements. If you're a VASP, you're already required to maintain adequate systems and safeguards for client asset protection. DORA adds a layer of documentation — specifically, documented evidence that your third-party providers meet the same standards you're held to.
Regulators are paying close attention to VASPs that rely on a single exchange API or a single custodian without documented exit plans. The combination of MiCAR's investor protection requirements and DORA's resilience obligations creates a regulatory expectation that you can demonstrate, on demand, that you could migrate operations to an alternative provider within an acceptable timeframe.
This is where Arkē's screening layer adds value. We don't replace your vendor management process — but we give your compliance team the evidence trail they need: screens of every critical ICT provider against OFAC, EU, and UN sanctions lists; PEP checks on beneficial owners; adverse media monitoring across global sources. The Arkē screening report is your documentation that due diligence was conducted and risk was assessed before contracts were signed.
Arkē and DORA
Arkē's existing pillars map cleanly onto DORA requirements:
- **Counterparty screening** covers your third-party ICT providers. When you onboard a new wallet provider, exchange integration, or custodian, Arkē screens the entity name against 19,049 OFAC SDN entries and GPT-enriched PEP/adverse media checks in under 5 seconds.
- **Batch screening** handles your full vendor register. If you need to screen 40 critical ICT providers for concentration risk ahead of your annual DORA assessment, Arkē accepts a CSV and returns risk scores, flags, and recommendations in a single batch job.
- **SAR-format reporting** generates DORA-compliant incident notification drafts in FIU-adaptable format. When you classify a major ICT incident, Arkē produces a structured report template that maps to the NCA's reporting requirements under DORA Article 16.
- **Summary exports** include search time, risk level, and flags — giving your risk committee the documentation it needs for the ICT risk register.
Getting Started
The DORA obligations that apply to your VASP are already in force. The question isn't whether you need to comply — it's whether you can demonstrate compliance when your NCA asks.
Start with the ICT risk register. Map your dependencies. Screen them. Document the screens.
Arkē covers the screening layer. Everything else is your legal and engineering work — but the evidence trail we produce is designed to slot directly into a DORA audit package.
[Review your DORA obligations and map them to Arkē pillars →](/regulations#dora)