Table of Contents
The EU's Digital Operational Resilience Act goes by DORA for short. You'll also see it cited as Regulation (EU) 2022/2554. It was signed off in December 2022, and firms then had until 17 January 2025 to comply.
Around 22,000 financial firms are in scope, by industry estimates. Banks and insurers are on the list, and so are crypto exchanges. The core idea is that a firm should be able to take a tech failure and carry on, or get back up quickly. The rules go into real detail on this. Some incident reports are due within four hours.
Here's how the regulation words it:
“...the ability of a financial entity to build, assure and review its operational integrity and reliability [...] including throughout disruptions.” Regulation (EU) 2022/2554, Article 3(1)
Picture a server failing at 3am. The app should still open. If it doesn't, it should be back within hours, and your balance should read exactly what it did before.
What Does DORA Actually Regulate?
DORA is about ICT risk. ICT is information and communication technology. On a crypto app, think login servers and the engine that matches orders. Add in the databases that hold everyone's balances, plus the network connecting it all.
A buggy update counts as ICT risk. So does a server outage, a cyberattack or a power cut at a data centre two countries away. For a crypto platform, any of these can stop users trading or withdrawing.
Before 2025, the rules on this were scattered across different sectors and countries. Banks faced detailed expectations, while other financial firms often faced very few. The new regulation replaced that patchwork with one set of rules built around five areas:
- ICT risk management: knowing your systems and protecting them
- Incident management and reporting: handling problems and telling supervisors about serious ones
- Digital operational resilience testing: checking defences before a real failure
- ICT third-party risk: managing the outside companies a firm depends on
- Information sharing: exchanging intelligence on cyber threats with other firms
The DORA requirements also apply proportionately. Article 4 lets a five-person start-up work at a different scale from a global bank. Article 26, for example, exempts microenterprises from the threat-led penetration testing covered further down.
Which Crypto Companies Are Covered by DORA?
Crypto is named directly. Article 2(1) runs through 20 types of financial entities. Point (f) is the crypto one, covering crypto asset service providers (CASPs) authorised under MiCA, the EU's Markets in Crypto-Assets Regulation. An exchange counts as a CASP. So does a custody service holding coins for clients, or a broker executing orders for them.
Issuers of asset-referenced tokens (ARTs) sit in the same point. Picture a token backed by a mix of euros, dollars and gold. That's the sort of thing MiCA classes as an ART.
E-money tokens (EMTs) follow one official currency, like a euro stablecoin. Under MiCA, they can only be issued by credit institutions or electronic money institutions. Both of those already sit inside DORA's scope, so EMT issuers are covered through their banking or e-money licence.
Timing matters here. MiCA's transition period, which let some firms keep operating under older national registrations, ended on 1 July 2026 at the latest (earlier in some member states). Any crypto firm still serving EU clients now needs MiCA authorisation, and with it come the operational resilience rules.
Venga is one example. In July 2026, Venga announced that Spain's National Securities Market Commission (CNMV) had granted the licence leaving it authorised under MiCA. DORA applies to Venga as a result.
What Does Digital Operational Resilience Mean for a User?
Picture a normal ten minutes on a crypto app. You log in and check your balance. Maybe you cancel an order, withdraw €200 and scroll back through last month's transactions.
Behind every one of those taps there's a stack of servers, databases, cloud hosting and payment links. Operational resilience is the platform's ability to keep that stack running, or get it back up, when one piece falls over.
A fire drill is a decent comparison. Offices run them on quiet Tuesdays with no smoke anywhere, and a real alarm then goes a lot more smoothly. DORA wants the same habit for digital systems.
How DORA connects to everyday user experience
How Must Companies Prepare for Technology Failures?
Step one is a map. Article 8 is the starting point. Firms have to write down every system and information asset they use, along with each outside service they rely on. The list can't just sit in a drawer, either. It has to be kept up to date. For an exchange, it runs from the wallet systems to the company that sends out two-factor login codes. This inventory is the base layer of the firm's ICT risk management framework.
Why bother? The weak point is often something nobody remembered was there. An old test server that's still hooked up to live data is a classic example. So is a supplier's plug-in nobody switched off when the contract ended.
Next comes protection. Most of the measures here won't surprise anyone who's worked in IT, starting with limits on who can reach which systems. Patching is in there, as is encryption of client data, along with ordinary good security practices. Detection matters as well. A problem caught within minutes is far easier to contain than one discovered on Monday morning.
Then comes the plan for when prevention fails. Firms are expected to have:
- a business continuity policy for critical functions
- response and recovery plans
- backup and restoration procedures, with backups restored on systems kept separate from the originals
Backups also have to be tested. A backup nobody has ever tried to restore is more of a hope than a plan.
Responsibility sits at the top. Article 5 puts "the ultimate responsibility" for ICT risk on the management body. The board owns this one, and the IT team can't be left holding it alone.
What Happens When a Major ICT Incident Occurs?
Firms have to log ICT-related incidents as they happen, small ones included, and then grade how serious each one is. A login page that's slow for five minutes is one thing. A two-hour outage hitting thousands of clients is another.
Article 18 lists what goes into that call. Firms look at the number of clients affected, how long it lasts and how many EU countries it reaches. Data loss counts, as do the criticality of the services hit and the cost.
Once an incident is classed as major, the firm reports it to its competent authority. For a Spanish CASP, that's the CNMV. The reporting requirements run in stages under the EU's technical standards:
- Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after the firm became aware of it
- Intermediate report: within 72 hours of the initial notification, updated as the situation develops
- Final report: within one month of the latest intermediate report, including the root cause
Users get a look-in too.
Article 19(3) says clients must be told "without undue delay" when a major incident affects their financial interests, along with what's being done to limit the damage.
Why this matters: Anyone who's stared at a frozen app during a price swing knows the worst bit is not knowing. Under DORA, a regulated platform has a deadline for briefing its regulator and a duty to keep affected users in the loop.
Why Does DORA Regulate Cloud and Other Technology-Provider Risks?
Open up a typical crypto platform and you'll find other companies' technology all the way down. The servers might be rented from a cloud provider, identity checks handled by a verification specialist and customer emails sent through yet another service, with security tools licensed from someone else.
Each of those is a link in a chain. If a link further down fails, the outage surfaces at the platform the user actually sees, even though the platform itself did nothing wrong.
Outsourcing doesn't let a firm off the hook.
Article 28 says it stays "fully responsible" for compliance, whoever runs the servers.
There's paperwork too. Every contract with an outside ICT supplier goes into a register. Risks get assessed before signing. Contracts have to meet specific requirements, and critical services need a tested exit strategy. An exit strategy is the plan for switching suppliers or bringing a service in-house if a provider fails or stops performing.
There is a wider concern as well. Plenty of financial firms rent from the same handful of cloud companies. When one of those companies has a bad day, banks, brokers and crypto apps can all wobble on the same afternoon.
So DORA puts the biggest suppliers under the direct watch of the European Supervisory Authorities (ESAs). That's the umbrella name for EBA, ESMA and EIOPA, the EU agencies that look after banking, securities markets and insurance. The first list landed on 18 November 2025, when the ESAs designated 19 critical ICT third-party providers. Big cloud and data centre companies are on it. Their risk management and governance now get examined at EU level.
How Are Systems Tested Before a Real Failure Happens?
Waiting for an attacker to find the gaps is the expensive way to learn about them. Under DORA, firms test on a fixed routine and go hunting for problems themselves.
Each covered firm other than a microenterprise needs a written testing programme for digital operational resilience. Article 24 sets the minimum pace at once a year for systems behind critical or important functions.
Article 25 gives a menu of tests. Vulnerability scans are on it. So are network security reviews and scenario-based tests, where a team plays out something like a data centre fire on paper. Compatibility and performance tests appear too, along with penetration testing, which pays specialists to break in like a real attacker would. A small firm won't use the whole menu. Size and risk profile decide how much applies.
Some larger firms go further. Those selected by their supervisor must run threat-led penetration testing at least every three years, which simulates the tactics of real criminal groups against live systems.
Real incidents show why this matters. Take the September 2026 Bitget hack. Investigators suspect the attackers got in through a zero-day flaw, a bug nobody knew about, in a security product Bitget bought in from another company. No test catches everything. Regular testing does cut down the vulnerabilities sitting there unnoticed.
The rules also support information sharing on threats. Firms can exchange intelligence on cyberattacks, such as warning signs and attacker techniques, within trusted groups, so one firm's bad day can help others prepare.
How Is DORA Different From MiCA From a User's Perspective?
From the user's side, MiCA and DORA answer two different questions.
MiCA's question is who gets to offer crypto services in the EU, and on what terms. It covers CASP authorisation, conduct towards clients, custody of client assets, crypto-asset white papers and the rules for ARTs and EMTs.
DORA's question is narrower. Say a licensed exchange goes offline for six hours. MiCA's concern is whether that exchange deserved its licence and treats clients fairly. DORA's concern is what its systems, backups and suppliers did during those six hours.
MiCA vs DORA at a glance
There's a direct bridge between the two. MiCA's Article 68(7) tells crypto-asset service providers to use "resilient and secure ICT systems" as required by DORA.
Liability shows where the line falls. Under MiCA's custody rules, a CASP holding crypto for clients is liable for losses from an incident attributable to it, capped at the market value of the assets when they were lost. DORA has no compensation rules of its own.
Why this matters: MiCA decides who's allowed to run the shop. DORA cares whether the tills still work when the power flickers. A regulated platform answers to both.
Practical Example: A Third-Party Outage Takes a Crypto Platform Offline
This one's made up. The steps, though, track what DORA actually asks for. An EU-authorised crypto exchange runs its account access and transaction processing on an external cloud provider.
- 09:12, the outage begins. A fault at the cloud provider knocks out part of the exchange's infrastructure. Logins fail for some users. Orders hang. Withdrawals pile up in a queue.
- 09:15, detection and classification. Monitoring alerts fire within three minutes and the incident team gathers. They run the incident against the official criteria: around 40,000 clients affected, core services down, no fix in sight. At 09:50 it's classified as major.
- 10:05, users are told. A status page goes up and an in-app banner explains what's down. It confirms client assets are safe and says when the next update is due.
- 13:30, the regulator is notified. The initial notification reaches the national competent authority inside the 4-hour window.
- 14:40, service is restored. The continuity plan moves critical services to a backup environment. Before withdrawals reopen, the team checks balances and order records against its data.
Within 72 hours. An intermediate report goes in.
Within a month. The final report names the root cause (a faulty configuration change at the provider, say) and what has changed since.
Afterwards. The exchange goes back to its cloud contract to check what the provider promised on recovery times, then runs a test move of its order engine to a second provider. Its recovery plans get rewritten with what the team learned.
Why this matters: Users still couldn't trade for five and a half hours, and DORA did nothing to prevent that. What it did was make sure the backup environment, the status page and the regulator's deadline were all sorted out months before 09:12.
What Does DORA Not Guarantee for Users?
DORA cannot make technology fail-proof. Cloud regions go down and software has bugs. Attackers also keep changing their tactics. A regulated platform can still have an outage.
It also doesn't create a compensation scheme. Say bitcoin drops 8% while the app is down and you can't sell. DORA has nothing to say about that loss. MiCA's custody liability covers lost assets, not missed trades, so any claim would rest on the platform's terms or national law.
Its reach has limits too. Self-custody wallets sit outside it. So do unregulated platforms based outside the EU.
For regulated firms, the bar has moved. Outages are expected to be planned for in advance. While one is under way, there's a process to follow. And the route back to normal service has to have been tested before anyone needs it.
Disclaimer: The content provided in this article is for educational and informational purposes only and should not be considered financial or investment advice. Interacting with blockchain, crypto assets, and Web3 applications involves risks, including the potential loss of funds. Venga encourages readers to conduct thorough research and understand the risks before engaging with any crypto assets or blockchain technologies. For more details, please refer to our terms of service.