The Digital Operational Resilience Act (DORA) extends EU financial regulation into territory many crypto-asset service providers haven't formally documented before: how you manage the technology risk sitting underneath your product. For CASPs authorised under MiCA, DORA isn't optional reading | it's a second regulatory framework running in parallel, and it needs to agree with the first one.

1. Build an ICT risk management framework

At its core, DORA requires a documented framework for identifying, protecting against, detecting, responding to and recovering from ICT-related risk. For a crypto business, this typically means formalising things that may already happen informally: access controls, system change management, backup and recovery procedures, and a clear ownership structure for technology risk at board level.

2. Map and assess your critical third parties

Few crypto businesses run entirely on in-house infrastructure. Cloud providers, custody technology, node infrastructure and monitoring tools all typically count as ICT third parties, and the more critical they are to your operations, the more scrutiny DORA expects you to apply. A documented register | what each vendor does, how critical it is, and what happens if it fails | is the practical starting point.

A useful test: if a given provider went down tomorrow, would you know within the hour what breaks, who's accountable for the response, and what your contractual recourse is? If not, that's the gap DORA's third-party provisions are designed to close.

3. Define incident classification and reporting thresholds

DORA sets out criteria for what counts as a "major" ICT-related incident, with reporting obligations attached. Getting the classification thresholds right matters | both to avoid under-reporting a genuine major incident, and to avoid flooding your own process with reports that don't meet the bar.

4. Put a resilience testing plan in place

Testing requirements scale with the criticality of your systems. At minimum, this means a documented testing programme | vulnerability assessments, scenario-based testing | with a clear cadence and ownership. Larger or more systemically important entities face more advanced testing expectations.

5. Keep DORA and AML/CTF governance aligned

DORA and your AML/CTF programme are separate regulatory obligations, but they shouldn't be governed as if they exist in different companies. Incident reporting lines, vendor risk ownership and board-level accountability should tell one consistent story | not two documentation trails that quietly contradict each other under examination.

The bottom line

DORA compliance for a crypto firm isn't about buying new technology | it's about documenting, testing and being able to evidence the operational discipline that a serious financial services business should already have. Treated early, it's a relatively contained documentation and process exercise. Left until a regulator asks for it, it becomes a much bigger one.