What Is the DORA Regulation? EU Digital Operational Resilience Act Explained

The DORA regulation — the Digital Operational Resilience Act — is the EU law on cyber resilience for the financial sector. It tells financial institutions how to handle cybersecurity and IT risk. In simple terms, every bank, payment company, investment firm, insurer and crypto exchange in the EU must be able to keep working through a hack, a cloud outage or a broken software update, and must keep an eye on the IT vendors it relies on.

This guide is written for people without a legal or IT background. It covers who DORA applies to, what it requires, how fast an incident must be reported, how it differs from NIS2 and GDPR, what the penalties are and what the DORA requirements mean for fintech and crypto companies, and it ends with a short DORA compliance checklist.

What Is DORA in Simple Terms?

DORA — sometimes written EU DORA or the DORA Act — is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. “Digital operational resilience” sounds complicated, but it means one thing: can your company keep serving its clients when its IT goes wrong? A hacker gets in, an update fails, a supplier goes offline — do payments still go through, can customers still log in, is their data still safe? DORA turns that question from a good practice into a legal duty.

Before DORA, every EU country and every part of the financial sector had its own IT security rules and its own incident forms. DORA replaces that patchwork with a single rulebook for the whole EU financial sector. Because it is a regulation rather than a directive, it applies word for word in every Member State — no national law needed to switch it on.

The DORA compliance deadline has already passed. The two-year preparation period after adoption is over, all DORA obligations are in force, and national financial regulators are checking them. The DORA framework rests on five pillars, and the rest of this guide walks through each one:

• ICT risk management — a written plan for IT risk, owned by the management body (the board);
• ICT-related incident management and reporting — spotting, logging and reporting IT incidents to the supervisor;
• digital operational resilience testing — from routine vulnerability scans to full “red team” attack simulations;
• ICT third-party risk management — controlling the IT vendors the firm depends on, with a register of all of them;
• information sharing — voluntary exchange of threat intelligence between financial entities.

DORA Key Terms Explained

A handful of defined terms come up in every article of the DORA regulation, every supervisory form and every vendor contract. Once you know them, the rest reads much more easily.

Who Does DORA Apply To?

The DORA scope is set by Article 2, which lists twenty categories of financial entities. If a financial institution holds one of these licences anywhere in the EU, it is covered — no matter how small it is — unless a specific exemption applies. The main groups are below.

What about the IT companies themselves? Cloud platforms, data centres, software vendors and managed security firms are not financial entities, but DORA reaches them in two ways. First, every financial entity must write DORA-style terms into its contracts with them, so a vendor that refuses risks losing the client. Second, the biggest providers — major cloud, data-centre, telecom and financial-software vendors — are named critical ICT third-party providers and supervised directly at EU level; the list is updated every year.

Does DORA apply to non-EU companies? Directly, only to firms licensed in the EU — which includes the EU subsidiaries and branches of UK, US or Asian groups. Indirectly, it reaches any foreign vendor that serves an EU financial firm, because the mandatory contract clauses apply wherever the vendor is based. A non-EU provider that gets named critical must set up an EU subsidiary within twelve months.

Finally, DORA is proportionate: the obligations grow with the size and complexity of the financial institution. Microenterprises — fewer than ten staff and under two million euros in turnover or balance sheet — skip several requirements, including threat-led penetration testing and some governance and reporting duties. A defined group of smaller firms, such as small and non-interconnected investment firms and certain exempted payment and e-money institutions, follows a simplified ICT risk management framework under Article 16. Being small does not take a licensed firm out of DORA; it only lightens the load.

DORA Requirements: The Five Pillars Explained

The DORA compliance requirements fall into five groups. Together they form one cycle — prevent, detect, respond, recover, learn — and the regulator expects evidence for each step.

ICT Risk Management Framework (Articles 5–16)

In plain words: know what IT you have, know what could go wrong with it, and have a written plan for protecting it and getting it back. The framework must list IT assets and dependencies, set out how the firm prevents and detects problems, how it responds and recovers, and how it learns from incidents. It is reviewed at least once a year and after every major incident. The management body signs it off, decides how much risk is acceptable and provides the budget. Critical functions must be mapped, backups must actually be tested, and there must be an IT continuity plan that sits alongside the firm’s general continuity plan.

Incident Reporting: The 4-Hour, 72-Hour and One-Month Deadlines

Every ICT-related incident must be logged and graded using the same yardsticks across the EU: how many clients were affected, how badly the firm’s reputation suffered, how long it lasted, how far it spread, what data was lost, how critical the service was and how much money was at stake. An incident that crosses the thresholds is “major” and must be reported to the supervisor in three steps: a first notification within four hours of deciding it is major (and never later than 24 hours after the firm became aware of it), an interim report within 72 hours of that first notice, and a final report within a month of the interim one. Clients whose money or data is affected must be told without delay. Serious cyber threats that have not turned into incidents can be reported voluntarily.

Resilience Testing and Threat-Led Penetration Testing (TLPT)

Digital operational resilience testing is a yearly programme: every system that supports a critical or important function must go through vulnerability scans, gap analyses, source-code reviews, scenario tests, performance tests and penetration tests. Firms the supervisor considers significant — because of their size or the impact of their failure — must additionally run threat-led penetration testing at least every three years. That is a controlled attack on live systems by qualified ethical hackers, following a recognised framework. Microenterprises and firms under the simplified framework are exempt from TLPT and test on a lighter, risk-based schedule.

Third-Party Risk, Outsourcing and the Register of Information

Outsourcing IT — to a cloud service provider or anyone else — does not outsource responsibility. ICT third-party risk management starts with a written strategy for vendor risk; a firm must check vendors before signing, avoid depending too heavily on a single provider, and keep a register of information — a structured list of every IT contract — that goes to the supervisor at least once a year. The contracts themselves must contain a fixed set of clauses: what the service is and what level is promised, where data is stored, the right to inspect and audit, the duty to help during incidents, how the contract can be ended and how the firm would move to another provider if it had to. The firm stays fully responsible even when the vendor is a critical provider supervised at EU level.

Information Sharing on Cyber Threats

Financial entities may swap threat intelligence — attack patterns, indicators of compromise — inside trusted groups. Nobody is forced to join, but a firm that does must tell its supervisor, and the exchange must respect confidentiality and data-protection rules.

DORA vs NIS2 vs GDPR: How the Rules Fit Together

Three EU laws overlap on cyber resilience and incident reporting, and many financial institutions sit under more than one. The table shows who each one covers and how the reporting clocks differ.

In practice, a financial firm reports IT incidents to its financial supervisor, not to the national cybersecurity agency. GDPR runs alongside: if a cyberattack leaks customer data, the firm reports it twice — under DORA to the financial supervisor and under GDPR to the data protection authority — on two separate clocks.

DORA and Crypto: What It Means for CASPs and Token Issuers

For crypto businesses, the DORA regulation and the MiCA framework work as a pair. MiCA decides who may provide crypto services or issue tokens in the EU; DORA decides how the technology behind those services must be run. A crypto-asset service provider authorised under MiCA is a financial entity under DORA from the moment its licence is granted, and so is any issuer of asset-referenced tokens. MiCA itself points to DORA for IT and security requirements, so every supervisor reads the two together.

In practice, resilience is checked during the licensing process itself, not only afterwards. When a supervisor reviews a CASP application, the IT risk framework, business continuity plan, incident procedures and outsourcing arrangements are part of the file, and DORA is the yardstick they are measured against. A crypto exchange or custodian cannot get — or keep — its licence with a resilience plan that exists only on paper.

Crypto firms also have IT dependencies that a bank does not: private-key custody, blockchain node providers, third-party wallet infrastructure, smart-contract components, and markets that trade around the clock with no maintenance window. Under DORA each of these is an IT asset or a vendor relationship that must be listed, graded, contracted and tested. That is also how unlicensed suppliers of hosting, key management or blockchain infrastructure end up meeting DORA: through their clients’ contracts.

DORA Penalties, Fines and Sanctions for Non-Compliance

There is no single EU-wide table of DORA sanctions. Instead, Article 50 tells each Member State to set penalties that are “effective, proportionate and dissuasive” and gives supervisors the power to demand documents, run inspections, order fixes and publish warnings. The national competent authority of each Member State applies them under the sector’s own licensing law, so a bank, a payment company and a crypto exchange each face the sanction ladder of their own sector.

You may have seen a “DORA fine” of one per cent of average daily worldwide turnover. That figure is real, but it is aimed at someone else: it is the daily penalty the European Supervisory Authorities can charge a critical ICT third-party provider that ignores an oversight decision, for up to six months. It is not a fine for banks or crypto companies. The “2% of annual turnover” sometimes quoted alongside it is not in DORA either: it comes from NIS2, where it is the minimum cap countries must set for essential entities. For a financial firm the realistic consequences are:

• supervisory measures — orders to fix things, limits on activities and, in serious cases, suspension or loss of the licence;
• administrative fines under the national law of the sector;
• personal liability for board members, because DORA makes the board responsible for the IT framework;
• criminal liability in countries that have chosen to add it, which Article 52 allows;
• reputational and commercial damage — lost clients, banking partners and investors.

Who Supervises DORA? Regulators at National and EU Level

Day-to-day DORA supervision stays with the regulator that already licenses the firm — the central bank or financial supervisory authority of its home Member State. That competent authority receives the incident reports and registers of information, decides who must run TLPT and checks the IT risk framework as part of ordinary supervision. Most publish DORA guidance, templates and deadlines on their websites.

At EU level, three bodies share the work: the European Securities and Markets Authority, the European Banking Authority and EIOPA, the insurance and pensions authority. They write the technical standards that fill in the details and jointly designate the critical ICT third-party providers, each of which is then supervised by one of the three as its Lead Overseer.

DORA Compliance Checklist: How to Comply

Whether a firm is applying for a licence or is already supervised, the same set of documents proves DORA compliance during an audit. A practical starting point for a DORA implementation plan or gap analysis:

• Confirm your scope: which Article 2 category you fall into and whether the simplified framework or a microenterprise exemption applies.
• Map every IT asset, system and data flow that supports a critical or important function.
• Adopt an ICT risk management policy approved by the board, with named owners and an annual review.
• Set up incident grading, an incident log and reporting templates that match the statutory deadlines.
• Build a yearly testing calendar and check whether the supervisor has put you on the TLPT list.
• Compile the register of information on all IT providers and update their contracts with the mandatory clauses.
• Check concentration risk and write exit plans for providers that support critical functions.
• Test backups, restoration and the IT continuity plan at least once a year.
• Train the board and keep proof that the training happened.

Eesti Firma advises fintech and crypto companies on the legal side of DORA: working out which obligations apply, aligning the IT framework with MiCA licensing requirements, reviewing vendor contracts and preparing the documents a supervisor expects to see. Contact us to discuss how the regulation applies to your business.

Request a Consultation

Frequently Asked Questions about DORA