What Is DORA Compliance? The Digital Operational Resilience Act Explained

The Digital Operational Resilience Act has applied to EU financial firms since 17 January 2025. The first year was mostly paperwork. In year two, supervisors want proof, and most of that proof sits with IT operations.

DORA joins the other rules on your cybersecurity compliance list, with much tighter clocks. A major incident needs its first report within 4 hours of classification.

In this blog, you will:

• See who DORA covers, including US and UK firms.

• Learn the five pillars and the articles behind each one.

• Follow the full incident reporting timeline, step by step.

• Map each IT duty to the evidence regulators ask for.

By the end, you will know what DORA compliance asks of your IT team and where to begin.

What Is the Digital Operational Resilience Act (DORA)?

The Digital Operational Resilience Act (DORA) is an EU regulation that sets one set of ICT risk rules for the financial sector. Its official name is Regulation (EU) 2022/2554.

It requires banks, insurers, investment firms, and other financial entities to withstand, respond to, and recover from ICT disruptions and cyberattacks.

The EU adopted DORA on 14 December 2022. It entered into force on 16 January 2023. It has applied since 17 January 2025.

Older financial rules mostly protected firms with capital. Capital does nothing for a payment system that goes dark for six hours. DORA fills that gap by turning IT risk management into a regulated duty, with named owners and fixed deadlines.

DORA compliance means meeting those duties every day and being able to prove it. You need four things in place. They are a documented ICT risk framework, an incident process that meets the clocks, a tested recovery plan, and a register of every ICT contract.

Who Needs to Comply With DORA?

DORA applies to 20 types of financial entities that operate in the EU, plus the ICT third-party providers that serve them. Article 2 lists them. Here they are, grouped by sector:

Firm size decides how deep the duties go. Article 16 gives a simpler ICT risk framework to a short list of smaller entities.

Small investment firms and exempted payment institutions are two examples. Microenterprises also skip some testing duties, such as threat-led penetration testing.

A few entities fall outside DORA completely. Pension schemes with 15 members or fewer are one group. Small insurance intermediaries are another.

Does DORA Apply to US and Other Non-EU Companies?

DORA reaches US companies in two ways, even though they are not EU financial entities. The first way is by contract. The second is by designation.

The contract route is the common one. Article 30 lists what EU firms must put in their ICT contracts. The list includes service levels, audit rights, incident support, and exit terms.

A US cloud vendor with EU bank customers will meet those clauses at its next renewal. Much like GDPR compliance, the rule follows the EU customer across the border.

The designation route is narrower. EU supervisors can name a provider as critical. That provider must then set up an EU subsidiary within 12 months (Article 31(12)). Several US hyperscalers are already on that list.

Does DORA Apply in the UK?

DORA does not apply in the UK, because it came after Brexit. UK firms follow their own operational resilience rules from the PRA and FCA.

The UK rules work in a similar way. Firms had until 31 March 2025 to show they can stay within impact tolerances. A separate regime for critical third parties started on 1 January 2025.

According to the FCA, HM Treasury named its first four critical third parties on 13 July 2026. They are AWS, Google Cloud, Microsoft, and Oracle.

A UK bank with an EU branch will often run both regimes side by side. We usually see those teams keep one control set and map it twice.

What Are the Five Pillars of DORA?

The five pillars of DORA are ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Each pillar is a chapter of the regulation. This table shows where each one lives and who usually owns it:

The diagram below shows how the five pillars rest on the board's accountability under Article 5.

Four of the five pillars land mostly on IT operations. So we read DORA as an operations rulebook with a legal wrapper. Here is what each pillar asks for in practice.

1. ICT Risk Management

ICT risk management is the largest pillar, and it starts at the top. Article 5 makes the management body ultimately responsible for ICT risk. Board members must also keep their ICT knowledge current through regular training.

Articles 8 to 14 then follow a familiar cycle. You identify every ICT asset and the business function it supports. Then you protect those assets, detect anomalies, and respond to incidents.

Backups must restore within set targets, such as a recovery point objective. Afterward, you learn from what happened.

The asset step is where gaps show up first. DORA expects you to know which servers, apps, and vendors sit behind each critical function. In our experience, few teams have that map written down before their first review.

2. ICT Incident Reporting

The incident pillar needs a written process to detect, log, classify, and report ICT incidents. Every incident gets recorded. Only major ones go to the regulator, on the clocks in the next section.

Firms can also report significant cyber threats by choice, under Article 19(2). A threat is a risk that has not yet become an incident. A phishing campaign aimed at your customers is one example.

3. Digital Operational Resilience Testing

DORA requires a yearly test of every system that supports a critical or important function. Microenterprises are exempt from this yearly rule. Tests can include vulnerability scans, network checks, scenario tests, and code reviews.

Some firms must also run threat-led penetration testing (TLPT) every three years. Supervisors decide which firms.

TLPT uses real threat intelligence to attack live systems under controlled conditions, in line with the TIBER-EU framework. Knowing the gap between vulnerability assessment and penetration testing helps you plan both layers.

4. ICT Third-Party Risk Management

The third-party pillar makes you answer for the risk your ICT vendors bring in. You can outsource a service, but the accountability stays with you. Article 28 requires a vendor risk strategy, a register of every ICT contract, and an exit plan for critical services.

Article 30 lists the clauses those contracts must contain. Contracts behind critical functions need more. They add service levels, notice periods, a role in your TLPT, and a tested exit plan.

5. Information Sharing

DORA encourages financial firms to share cyber threat intelligence with each other. This pillar is voluntary. Firms that join a sharing group must tell their supervisor. They must also protect any personal data they swap.

How Does DORA Incident Reporting Work?

DORA incident reporting works in two stages. First, you classify an ICT incident against fixed criteria. If it counts as major, you then send three reports to your supervisor on set deadlines.

This pillar sees heavy use. According to the ESAs' first annual report on major ICT-related incidents, EU financial firms reported 3,383 major incidents in 2025. About one in three crossed borders. Only about 10% were cybersecurity-related, so most were plain operational failures.

What Makes an ICT Incident Major Under DORA?

An ICT incident is major when it hits critical services and crosses set impact thresholds. Delegated Regulation (EU) 2024/1772 sets those thresholds. It uses six criteria:

1. Clients and transactions: More than 10% of clients, or more than 100,000 clients, are affected.

2. Reputational impact: The incident draws media coverage, complaints, or lost customers.

3. Duration and downtime: Critical services are down for over 2 hours, or the incident runs past 24 hours.

4. Geographical spread: The impact reaches two or more EU member states.

5. Data losses: Data availability, integrity, or confidentiality is harmed.

6. Economic impact: Costs and losses pass €100,000.

An incident is major if it hits critical services and meets one of two tests. Either it involved malicious unauthorized access that may lead to data loss, or it crossed two or more other thresholds.

Repeat incidents count too. Two incidents in six months with the same apparent root cause count as one major incident.

What Is the DORA Incident Reporting Timeline?

The DORA incident reporting timeline has three deadlines, set by Delegated Regulation (EU) 2025/301. Here is how the clock runs for a major incident:

The diagram below puts the same three deadlines on one timeline.

Reports due on a weekend or public holiday can often wait until noon the next working day. Some firms lose that relief for their first two reports.

Banks, central counterparties, trading venues, and NIS2 essential or important entities must still file on time.

We see the 4-hour clock as a detection problem first. The clock starts at classification, but classification needs facts.

You must know which services are down, how many clients are hit, and for how long. A team with a slow MTTD burns those hours just finding the fault.

What Is the DORA Register of Information?

The DORA register of information is a structured record of every contract you hold with an ICT provider. Article 28(3) requires one for each entity, and one for the group where a group exists.

Implementing Regulation (EU) 2024/2956 sets the templates. Every firm reports the same fields in the same format.

The register holds far more than a vendor list. Each contract row names the provider, the service, and the business function it supports. It also flags whether that function is critical or important. Subcontractors in the supply chain appear as well, and each provider carries its Legal Entity Identifier (LEI).

Supervisors use the registers to spot concentration risk across the market. The first round reached the ESAs by 30 April 2025, through national supervisors.

That data shaped which providers were designated as critical. Firms now keep the register current and report it at least once a year.

We find the register is where DORA work stalls most often. Procurement holds the contracts, and IT holds the asset data.

Nobody owns the link between a contract and the function it supports. Many of those contracts already act as an underpinning contract behind your own service levels, which is a useful place to start the mapping.

What Has Changed Since DORA Took Effect?

DORA has moved from setup to active supervision since January 2025. Here are the milestones that shape the work in 2026:

The designation list is the biggest change. According to ESMA's announcement of 18 November 2025, the first 19 critical providers include AWS, Google Cloud, Microsoft, IBM, SAP, and Oracle. Each one now answers to an EU lead overseer.

The Digital Omnibus is still only a proposal. It would send DORA incident reports through one EU entry point run by ENISA. NIS2 and GDPR reports would use the same channel. The reporting deadlines would stay as they are.

What Are the Penalties for DORA Non-Compliance?

Each EU member state sets its own DORA penalties for financial entities. Articles 50 and 51 require penalties that are effective, proportionate, and dissuasive. The regulation sets no fixed maximum fine for financial entities. We would not read that gap as good news, because your national supervisor decides the scale.

Supervisors have other tools as well. They can order you to stop a practice or make the breach public. Where national law allows, they can also hold managers personally responsible.

Critical ICT providers face one set EU penalty. A lead overseer can charge up to 1% of the provider's average daily worldwide turnover. The charge applies every day until the provider complies, for up to six months.

How Is DORA Different From NIS2?

DORA is a financial-sector regulation, while NIS2 is a cybersecurity directive for many sectors. Where both apply to a financial firm, DORA wins as the more specific law (Article 1(2)). Here is how the two compare:

For a bank, the effect is simple, and we see few teams struggle with it. DORA governs ICT risk and incident reporting, so NIS2 steps back for those duties.

What Evidence Do Regulators Expect for DORA Compliance?

Regulators expect DORA evidence that shows your controls running day to day. A policy on paper is the starting point. In year two, supervisors ask for records, test results, and timestamps, and most of those live in IT operations tools.

This table maps the IT-owned DORA articles to the evidence that usually proves them:

Timestamps carry the most weight. A supervisor checking your 4-hour clock will compare three times: the alert, the classification, and the report.

That trail is very easy to build on a unified observability and ITSM platform. The alert and the ticket then sit in one record.

Keep the raw records too. A raw log shows who changed what, and when. A summary report cannot answer that question on its own.

How to Prepare for DORA Compliance in Seven Steps

To prepare for DORA compliance, start with what you own and end with how you prove it. These seven steps follow that order.

1. Confirm Your Entity Type and Scope

Find your category in Article 2. Then check whether Article 16 or microenterprise relief applies. Your answer sets how deep every later step goes.

2. Map Critical Functions to ICT Assets

List your critical or important functions, such as payments or claims handling. Trace each one to the servers, apps, networks, and vendors behind it. We usually start with the three functions a regulator would ask about first.

3. Run a Gap Assessment Against Articles 5 to 15

Compare your ICT risk framework to the regulation, one article at a time. Give each gap an owner and a due date. Our advice is to rank gaps by the critical functions they touch.

4. Rehearse the Incident Reporting Clock

Update your incident process to classify against the six criteria. Then run a tabletop exercise and time it. If classification alone takes four hours, fix the process before a real incident tests it. ITIL incident management gives you a stable base for the DORA steps.

5. Build and Maintain the Register of Information

Pull every ICT contract into the register template. Link each contract to the function it supports. Then name someone to keep it current as contracts change.

6. Update Contracts With Critical ICT Providers

Check each contract against Article 30, and add missing clauses at renewal. Write an exit plan for every service behind a critical function.

7. Schedule Testing and Board Reporting

Book the yearly resilience tests, plus TLPT if your supervisor requires it. Report results and open gaps to the management body. The board carries the final responsibility.

None of this ends at go-live. DORA expects the register, tests, and incident records to stay current. In our view, each step needs a named owner for as long as the firm is in scope.

Turn DORA Requirements Into Daily IT Evidence

The Digital Operational Resilience Act asks IT teams to show their systems can take a hit and recover. Every pillar, deadline, and register serves that one goal.

DORA will not make a firm resilient on its own. A full register and a passed test still leave room for an outage nobody planned for. What the rules do well is expose weak spots before a real crisis does.

Teams that build DORA evidence into daily work spend far less time rebuilding it for each review. We would start with the asset map and the incident clock, because both feed every other pillar. The habits behind good incident management best practices will carry you most of the way.

FAQs