What is DORA Compliance and Why is It Mandatory for Crypto Businesses?

DORA compliance means fully adhering to Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It requires financial entities to build, document, and maintain the ability to withstand and recover from ICT-related disruptions like cyberattacks, system outages, data breaches, and third-party vendor failures.

Before DORA, the EU had no unified document governing cybersecurity in the financial sector. Different countries followed different standards. Cybersecurity rules were scattered across multiple regulations, causing compliance headaches and uneven resilience across the financial system.

High-profile cyberattacks and IT outages exposed how fragile things were. Traditional tools like capital buffers under Basel III couldn't solve the problem. You can't balance-sheet your way out of a ransomware attack.

So in 2020, the European Commission drafted DORA. It was adopted in 2022, entered into force in January 2023, and gave businesses two years to prepare before the January 17, 2025, compliance deadline.

The goal was to replace the fragmented patchwork with one coherent, enforceable standard across all 27 EU member states. It applies not just to traditional banks but also to payment firms, crypto exchanges, insurance companies, investment funds, and the tech vendors that power them.

The five pillars of DORA compliance

The DORA compliance framework is built around five core areas. Each one carries its own documentation, testing, and reporting requirements.

1. ICT risk management framework

This is the foundation. Every in-scope entity must build a comprehensive framework to identify, classify, and mitigate ICT risks. This includes mapping critical system dependencies, setting recovery time objectives, and assigning clear ownership for risk items. Staff training is also required. The board and senior management are explicitly accountable for the strategy, not just the IT department.

2. ICT incident reporting

DORA sets strict timelines for reporting ICT-related incidents to regulators. For major incidents, an initial notification must be made within four hours of detection, a detailed report within 72 hours, and a final post-incident report within one month. Major incidents are those with significant adverse impact on networks and systems supporting critical or important business functions. The regulator you report to depends on the EU country that issued your operating license.

3. Digital operational resilience testing

Organizations must conduct regular cyber resilience testing. For most entities, this means vulnerability assessments and standard penetration testing. Larger or higher-risk institutions must perform Threat-Led Penetration Testing (TLPT) aligned with the TIBER-EU framework, which uses real-world threat intelligence to simulate advanced attacks. TLPT must occur at least every three years, though regulators can require more frequent testing if the risk profile warrants it.

4. ICT third-party risk management

This is the pillar most businesses underestimate. Financial entities must assess and monitor the resilience of every third-party ICT provider they rely on, from cloud hosting and payment processors to KYC tools and blockchain analytics. Contracts must include clauses on security standards, audit rights, incident reporting obligations, and exit strategies. If a vendor is compromised, you are responsible for managing it.

5. Information sharing

DORA encourages financial entities to share cyber threat intelligence with each other and authorities. The reasoning is straightforward: coordinated defense is stronger than isolated efforts. Chapter VI of the regulation outlines how these sharing arrangements should be structured to enable transparency and collective risk reduction without creating new vulnerabilities.

Why is DORA compliance mandatory

The short answer is that a cyberattack on one institution can cascade across the entire financial system. The EU decided it could not leave that risk to voluntary best practices.

DORA compliance is mandatory because the financial sector depends heavily on digital infrastructure, which is now a target. According to a study, total losses from hacks in the Web3 space alone have approached $10 billion in 2022. Traditional financial institutions face equally significant threats. Because institutions are interconnected, a failure at one node can ripple outward quickly.

The DORA compliance timeline reflects how seriously the EU treats this. Businesses had two years from the regulation's entry into force to prepare. The European Supervisory Authorities (ESAs), which include ESMA, the EBA, and EIOPA, published technical standards and a roadmap for oversight of third-party providers throughout that window.

As of July 2025, financial entities must submit Registers of Information documenting all contracts with ICT third-party service providers. The ESAs have begun developing tools to monitor compliance, so enforcement actions are likely soon.

Who must comply with DORA

DORA casts a wide net. Article 2 lists over 20 categories of financial entities subject to its requirements. These include banks and credit institutions, insurance and reinsurance companies, investment firms and asset managers, payment institutions and e-money institutions, trading venues, clearing houses, central securities depositories, credit rating agencies, crowdfunding platforms, and data reporting service providers.

Crucially, crypto-asset service providers (CASPs) authorized under the EU's MiCA regulation are explicitly in scope. This includes crypto exchanges, custodial wallet providers, stablecoin issuers, and crypto lending platforms. Other blockchain-adjacent services like staking-as-a-service providers, wallet infrastructure firms, and blockchain analytics companies are likely in scope depending on their interaction with regulated financial entities.

DORA has extraterritorial reach. Like GDPR, it does not matter where your business is headquartered. If you provide critical ICT services to EU-based financial institutions, you must meet DORA's standards. A US cloud company serving an EU bank, for example, may face pressure to align with DORA requirements. If designated as a Critical ICT Third-Party Provider (CTPP), EU regulators can directly oversee parts of its operations.

There are a few narrow exemptions, mostly for microenterprises with fewer than 10 employees and under €2 million in annual turnover, as well as certain very small insurance intermediaries. These carve-outs are tight. If you are unsure whether they apply to your business, the safer assumption is that they do not.

What the penalties for non-compliance actually look like

The penalties are serious. For financial entities, fines for DORA breaches can reach up to 2% of total worldwide annual turnover. For a large institution, that means potentially tens of millions of euros. For critical ICT third-party providers, the ceiling is €5,000,000 per violation. Additionally, DORA allows daily penalty payments of up to 1% of average daily global turnover for each day of continuing non-compliance, for up to six months.

To put a real number on it: if a critical ICT provider has an average daily turnover of €10,000,000 and remains non-compliant for 180 days, the cumulative penalty could hit €18,000,000.

Beyond fines, regulators can impose operational restrictions, suspend business activities, revoke authorizations, or ban a financial entity from engaging a specific non-compliant ICT vendor. For a crypto firm relying on its MiCA license, that is existential.

There's also the reputational dimension, as non-compliance actions under DORA are expected to be publicized. In a space like crypto or fintech where trust is everything, that's a cost that can't be easily quantified.

Some EU member states may even introduce criminal liability for willful or grossly negligent non-compliance at the national level. DORA requires member states to establish their own penalty regimes, and some are expected to go further than the regulation's baseline.

DORA compliance requirements in practice

Meeting the DORA compliance requirements demands work across legal, operational, and technical functions simultaneously. It's not just an IT project, and it's not just a legal box-ticking exercise.

On the legal and governance side, the management body must formally approve and review the ICT risk management strategy. All contracts with technology vendors must be reviewed and updated to include DORA-mandated clauses such as audit rights, security requirements, incident notification duties, and exit strategies. For many companies, this is a significant contract renegotiation effort.

On the operational side, firms need documented processes for detecting, classifying, escalating, and reporting ICT incidents. Business continuity plans and disaster recovery procedures must be formalized and tested. A complete register of all ICT third-party providers, including the critical business functions they support, must be maintained and kept current.

On the technology side, firms must implement technical controls like encryption, access management, and systematic vulnerability patching. Monitoring infrastructure for anomaly detection must be in place. Backup systems should be geographically distributed and tested regularly. Larger firms need advanced penetration testing capabilities, either built in-house or contracted to qualified providers.

The proportionality principle in DORA's Article 4 gives smaller firms some breathing room. A two-person fintech startup is not expected to match a tier-one bank's compliance apparatus. But proportionality does not mean doing nothing. It means showing that you have assessed your risks and taken reasonable measures for your size and risk profile.

How DORA works with MiCA and other crypto regulations

The relationship between DORA and MiCA is important to understand clearly because the two regulations work together in a way that is easy to miss.

MiCA defines what crypto businesses can do in the EU. It covers licensing, token issuance requirements, white paper obligations, and oversight of stablecoins. Getting a CASP license under MiCA is the entry ticket to legally operating in the EU crypto market.

DORA governs how crypto businesses operate at the infrastructure level. It does not duplicate MiCA's licensing requirements. Instead, it goes deeper on the operational and security side, setting standards for ICT risk management, incident reporting, resilience testing, and third-party oversight that exceed MiCA's cybersecurity provisions.

For practical purposes, if your crypto business is authorized under MiCA, you must also comply with DORA. The two are complementary, not interchangeable. Losing DORA compliance can put your MiCA license at risk because DORA non-compliance can trigger operational restrictions affecting your authorization to operate.

DORA also interacts with other existing frameworks. The NIS2 Directive covers similar ground on risk management and incident reporting, but with a different sector scope. ISO 27001 remains a relevant information security standard, and many organizations map their existing ISO 27001 controls to DORA's requirements as a starting point. The TIBER-EU framework, developed by the European Central Bank for threat-led penetration testing, is explicitly referenced in DORA's resilience testing requirements.

For DeFi specifically, the picture is less settled. Fully decentralized protocols without a central operator do not fit neatly into DORA's framework, which assumes an identifiable entity that can be held accountable. Regulators have not resolved this cleanly yet, and businesses in that space should seek legal advice rather than assume they are out of scope.

The practical reality of getting this done

DORA compliance is not a one-time project. It is an ongoing operational commitment. You do not complete it and then move on.

Most organizations start with a gap analysis, mapping current ICT policies and controls against DORA's requirements and identifying shortfalls. From there, they build a remediation roadmap prioritizing the highest-risk gaps first. Then comes implementation: updating contracts, building monitoring and incident response capabilities, engaging third-party vendors in due diligence, and beginning testing cycles.

For businesses already operating in the EU financial sector, the clock is running. The ESAs have started building oversight infrastructure, and the first enforcement actions are a matter of when, not if. Starting with a gap analysis now, even a basic one, puts you in a stronger position than waiting for a regulator to knock.

‍