.svg){kind=logo}
Related Articles
No items found.
A bank in Frankfurt asks its SaaS vendor for a DORA attestation. The vendor is based in Austin, has never operated in the EU directly, and has no idea what DORA even stands for. This conversation is happening constantly now, and it's why dora compliance search volume keeps climbing well past the regulation's own enforcement date.
DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It requires banks, insurers, investment firms, and other EU financial entities, along with the critical ICT providers that keep their systems running, to manage, test, and report on digital and cyber resilience. It has been mandatory since January 17, 2025.
Quick answer
DORA requires in-scope financial entities to run a documented ICT risk management framework, report major incidents on a strict clock, test their resilience regularly (including advanced red-team testing for larger entities), manage third-party ICT risk through a maintained vendor register, and share threat intelligence voluntarily. It is a regulation with real enforcement teeth, not a certification you can go get.
DORA reaches further than most people expect. It binds EU-licensed financial entities directly, and it reaches non-EU vendors, including US and UK companies, indirectly through the contracts those financial entities are now required to sign. If your customer is an EU bank, insurer, or investment firm, DORA is probably already showing up in your contract terms whether anyone's called it out by name yet or not.
This guide is scoped to what DORA actually requires and who it actually binds, not a ranked list of DORA compliance software. If that's what you're after, our best DORA compliance software roundup compares tools directly.
By the end of this, you'll know exactly who DORA applies to, what each of its five pillars requires in practice, what non-compliance actually costs, and where the real deadlines and misconceptions sit.
Here's what's ahead:
- What DORA is and why the EU built it
- Why DORA compliance matters even if you're not an EU company
- Who DORA actually applies to, including the UK/US question
- The five pillars of DORA compliance, cited to their real article ranges
- A practical compliance checklist
- What non-compliance actually costs (and a common misreading of the penalty figures)
- The deadline, and why "DORA compliance deadline" still gets searched
- How DORA relates to NIS 2, GDPR, and ISO 27001
- Common mistakes companies make
What Is DORA? The Digital Operational Resilience Act Explained
What is DORA compliance, in one sentence: meeting the requirements of an EU regulation, not chasing a certificate. DORA is an EU regulation, not a directive, which matters: a regulation applies directly and identically across all 27 member states, with no national transposition step needed. It entered into force in January 2023, following a two-year transition period before becoming enforceable on January 17, 2025.
The EU built it to close a gap that had been building for years. Financial-sector cybersecurity rules used to vary by member state and by sub-sector, which left supervisors with an inconsistent picture and financial entities with inconsistent obligations depending on where they were licensed.
At the same time, the sector had become quietly dependent on a small number of cloud and technology providers. One outage or breach at a single vendor could ripple across dozens of banks and insurers at once.
That second point isn't hypothetical. In November 2025, EU supervisors formally designated 19 companies as critical ICT third-party providers (CTPPs) under DORA, including AWS, Microsoft Azure, Google Cloud, Oracle, SAP, IBM, and SWIFT. Five of those 19 are generic cloud infrastructure providers alone. That designation puts them under direct EU-level oversight for the first time, which is exactly the concentration-risk problem DORA was written to address (source: Regulation-DORA.eu's CTPP designation tracker, November 2025).
Note
DORA is a regulation with supervisory enforcement, not a certifiable standard. There's no accredited "DORA certification" the way there is for ISO 27001. More on this in the FAQs below, since it's a genuinely common point of confusion.
Who Created DORA and Why It Exists
DORA came out of the European Commission, Council, and Parliament as part of the EU's broader Digital Finance Package, alongside MiCA (the EU's crypto-asset regulation). The two are deliberately linked: MiCA regulates what crypto-asset service providers can do, and DORA regulates how resilient their and every other financial entity's technology has to be while doing it.
Why DORA Compliance Matters Beyond the EU
Third-party concentration is the real stakes here, not abstract regulatory box-checking. A handful of cloud providers now sit underneath a large share of the EU's financial infrastructure. When one of them has a bad day, that bad day doesn't stay contained to one bank.
For a SaaS company outside the EU, the practical stakes show up earlier than a regulator ever does. An EU bank's procurement team increasingly won't sign a vendor contract until DORA-aligned clauses (audit rights, incident cooperation, exit provisions) are in place. That review happens before security due diligence starts, not after, which means a vendor without a DORA-ready posture loses the deal at the contracting stage.
Watch out
Waiting for a customer to specifically ask about DORA before preparing for it. By the time an EU financial entity's legal team is asking, they usually need the contractual language signed within weeks, not months.
Who Needs DORA Compliance? Financial Entities and Their ICT Vendors
DORA's scope is unusually broad for EU financial regulation. Article 2 lists roughly 20 categories of financial entities directly in scope: credit institutions, payment institutions, e-money institutions, investment firms, insurance and reinsurance undertakings, pension funds, crypto-asset service providers under MiCA, credit rating agencies, crowdfunding platforms, and several more.
Alongside those, DORA reaches critical ICT third-party providers, the cloud, software, and infrastructure vendors that keep those financial entities running. Some of those providers get formally designated as "critical" by EU supervisors, as the 19 companies named above were in November 2025, which puts them under direct oversight rather than only contractual pressure from their financial-entity customers.
That's what makes dora eu compliance reach further than the EU's own borders. Scope applies to entities licensed or supervised within the EU, and it reaches ICT third-party providers regardless of where they're headquartered, as long as they serve an in-scope EU financial entity. A US-based SaaS company with zero EU legal presence can still be pulled into DORA's requirements contractually, through the clauses its EU financial-sector customers are now required to include.
DORA Compliance for Banks, Insurers, and Investment Firms
The directly-regulated core is what you'd expect: banks and credit institutions, insurers and reinsurers, investment firms, payment and e-money institutions, and pension funds. These entities carry the full weight of DORA's five pillars, covered in detail below.
One layer worth naming separately: EU supervisory authorities can designate a specific ICT provider as "critical" based on its systemic importance to the financial sector. That designation brings direct EU oversight, on top of whatever contractual obligations the provider already has with its financial-entity customers.
Does DORA Compliance Apply to UK and US Companies?
Directly, no. DORA is an EU regulation, and it doesn't bind a UK or US company on its own. This is one of the clearest gaps in existing coverage of this topic: most guides don't answer the dora compliance uk question head-on at all.
In practice, it applies indirectly and often just as forcefully. A UK subsidiary of an EU banking group, or a US SaaS vendor selling into EU financial-services customers, frequently has to align with DORA's requirements contractually, even without being directly regulated by it. The UK also runs its own, separate operational-resilience regime through the PRA and FCA, which is a real framework in its own right and not the same thing as DORA, despite frequent confusion between the two.
The Simplified Regime for Smaller Financial Entities
DORA isn't one-size-fits-all. Article 16 sets out a simplified ICT risk management framework for a specific, narrower list of entities: small and non-interconnected investment firms, payment and e-money institutions operating under a regulatory exemption, credit institutions exempted under Directive 2013/36/EU (where the member state hasn't opted out of that exemption), and small institutions for occupational retirement provision (capped at 100 members total).
Those entities skip the detailed Article 5-15 requirements that apply to everyone else and instead follow Article 16's lighter framework. None of the five competitor pages we reviewed while researching this guide mention proportionality or the simplified regime at all, which leaves smaller in-scope entities assuming they're on the hook for the full framework when they may not be.
The DORA Compliance Framework: Five Pillars You Need to Cover
The dora compliance requirements break down into five distinct areas, and existing guides disagree on how many pillars there actually are. Some split it into nine domains, others into six.
The regulation itself, and the clearest guides we found while researching this, structure it around five: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. We're using that structure here and citing each pillar to its real article range, since that's the one device that actually helps a reader locate the underlying text later.
Pro tip
If a checklist or vendor pitch splits DORA into 9 pillars, look closely: it's usually the same five requirements with governance, asset inventory, and documentation pulled out as their own separate items. They're not wrong exactly, just organized differently than the regulation itself is.
Here's the same structure laid out visually, each pillar cited to its real article range:
Pillar 1: The ICT Risk Management Framework (Articles 5-16)
This is the foundation everything else sits on. In-scope entities need a board-approved digital operational resilience strategy, a documented ICT risk appetite, defined impact tolerances for disruption, and a current map of their ICT assets and dependencies. This is where DORA ICT risk management actually lives in practice: a board sign-off and a real impact-tolerance figure, not a policy document nobody outside compliance has read.
Pillar 2: ICT Incident Reporting on the Clock (Articles 17-23)
DORA runs incident reporting on a specific, three-stage clock once an incident is classified as "major":
| Stage | Deadline | What it covers |
|---|---|---|
| Initial notification | Within 4 hours of classification, no later than 24 hours after becoming aware | A brief, factual alert that a major incident has occurred |
| Intermediate report | Within 72 hours of the initial notification | Updated root-cause progress, actual (not estimated) impact, containment steps taken |
| Final report | Within 1 month of the intermediate report | Completed root-cause analysis and confirmed impact figures |
That 4-hour clock starts at classification, not at first detection, which is a distinction most guides on this topic blur. Getting the classification decision right, and fast, matters as much as the reporting itself.
Pillar 3: Digital Operational Resilience Testing, Including TLPT (Articles 24-27)
Every in-scope entity runs baseline testing: vulnerability assessments and scenario-based tests, at minimum annually. Entities identified as significant also have to run Threat-Led Penetration Testing (TLPT), an intelligence-led red-team exercise against live production systems, following the EU's TIBER-EU methodology, at least once every three years. The first TLPT deadline for significant entities lands before January 17, 2028.
TLPT is a meaningfully bigger exercise than an annual penetration test. It's scoped, intelligence-driven, and run against systems supporting critical functions specifically, not a general infrastructure scan.
Pillar 4: Third-Party ICT Risk and the Register of Information (Articles 28-44)
This is the pillar most SaaS vendors actually feel first. Financial entities have to maintain a Register of Information (RoI), a continuously updated inventory of every ICT third-party arrangement, not a spreadsheet built once for an audit and never touched again.
Contracts with critical ICT providers need specific clauses DORA itself requires: audit rights, defined service levels, and cooperation obligations with supervisors. This is the dora compliance for contracts and dora contractual compliance question that shows up in search: it's not boilerplate legal language, it's a defined set of mandatory clauses.
Financial entities also need a documented exit strategy for every critical ICT provider, covering what happens if that relationship has to end. That requirement is exactly why questions about escrow arrangements for critical vendors come up in negotiations: an exit plan for a critical cloud or software provider often needs some form of data portability or escrow commitment built in.
Note
The Register of Information is the one requirement in this pillar that gets treated as a one-time exercise most often, and it's the wrong way to treat it. It has to reflect the vendor relationship as it actually stands, on an ongoing basis.
Frameworks
DORA is one of 25+ frameworks ComplyJet supports
ComplyJet helps companies document ICT risk frameworks, keep vendor evidence current, and draft policy with AI assistance, at flat per-company pricing rather than a per-seat model.
Pillar 5: Voluntary Information Sharing (Articles 45-49)
The lightest of the five pillars. Financial entities can enter voluntary arrangements to share cyber threat intelligence with each other, on the reasoning that sector-wide visibility into active threats helps everyone respond faster. It carries the least practical weight of the five for most companies preparing for DORA.
A Practical DORA Compliance Checklist
This is the same DORA compliance framework from above, turned into something you can actually work through. Several existing guides pad this out to ten or more steps that mostly restate the same five requirements. Here's the same ground covered directly, mapped to the pillar it belongs to:
| Pillar | Checklist item |
|---|---|
| ICT Risk Management | Board sign-off on digital operational resilience strategy, risk appetite, and impact tolerances |
| ICT Risk Management | Current inventory of ICT assets and their dependencies |
| Incident Reporting | Incident classification criteria and a reporting runbook matching the 4hr/72hr/1-month clock |
| Resilience Testing | Annual baseline testing scheduled; TLPT scoped if your entity is designated significant |
| Third-Party Risk | Register of Information built and assigned an owner to keep it current |
| Third-Party Risk | Existing vendor contracts reviewed against DORA's mandatory clause requirements |
| Third-Party Risk | Documented exit strategy for every critical ICT provider |
Treat this as a starting scope, not a finish line. The depth each item needs depends on whether your entity qualifies for Article 16's simplified regime or carries the full requirements.
What Happens If You Miss DORA Compliance? Penalties and Enforcement
This is the section every guide we researched gets wrong, vague, or skips outright, and it's worth being precise about why. The figure most commonly repeated online, a 2% of annual worldwide turnover fine, does not come from DORA. It comes from NIS 2 (Directive (EU) 2022/2555), a separate EU cybersecurity law with its own, different scope. It gets pasted into DORA content constantly because the two regulations are often discussed together.
What DORA's own Article 50 actually says is narrower and, in a way, less predictable: it requires member states to establish administrative penalties and remedial measures that are "effective, proportionate, and dissuasive," but it leaves the actual ceiling, for both financial entities and the individuals responsible for them, to national law. There's no single EU-wide percentage or euro figure written into DORA for financial-entity fines. What a firm actually risks depends on how its own member state implemented Article 50.
Myth debunking
"DORA fines are capped at 2% of annual worldwide turnover." NO. That figure belongs to NIS 2, not DORA. DORA's Article 50 leaves financial-entity penalty amounts to national law, with no EU-wide percentage specified.
The one place DORA does set a specific, EU-wide percentage is narrower than most people assume: Article 35, covering critical ICT third-party providers under direct EU oversight. A designated CTPP that doesn't comply can face a periodic penalty payment of up to 1% of its average daily worldwide turnover from the preceding business year, charged daily until it complies, for no more than six months.
That's a coercive daily penalty to force compliance, not a one-time punitive fine. It only applies to the roughly 19 companies actually designated as critical, not to financial entities generally.
Put simply: if you're a financial entity, your real penalty exposure runs through your own country's implementing law, not a single EU number. If you're one of the small number of designated critical ICT providers, the 1%-per-day figure is the one that actually applies to you.
DORA Compliance Timeline: What the Deadline Actually Means Going Forward
DORA became fully enforceable on January 17, 2025, after entering into force in January 2023 and running a two-year transition period. That date is why "dora compliance deadline" still gets real search volume well over a year later: the deadline itself has passed, but the work triggered by it hasn't.
Supervisory activity is still ramping up past that date. The Register of Information submissions, the critical-ICT-provider designation process (the first 19 CTPPs were only named in November 2025), and the multi-year TLPT testing cycle for significant entities (first deadline before January 17, 2028) all continue well past the original enforcement date. Searches for the "deadline" today are usually about catching up on an obligation that's already active, not waiting for a future date.
Where DORA Compliance Overlaps With NIS 2, GDPR, and ISO 27001
A frequent question once the five pillars are clear is what frameworks align with DORA compliance. Most existing guides mention them only as a related-links footnote. Here's the actual relationship between each one and DORA:
| Framework | Scope | Relationship to DORA |
|---|---|---|
| NIS 2 | Cross-sector EU cybersecurity directive | DORA is the financial-sector-specific law; where both could apply, DORA takes precedence for in-scope financial entities as the more specific rule |
| GDPR | EU personal-data protection | Separate obligation. An ICT incident involving personal data can trigger both DORA's incident reporting and a GDPR breach notification at the same time; one doesn't substitute for the other |
| ISO 27001 | Certifiable information security management standard | A strong foundation for DORA's ICT risk management pillar, but certification alone doesn't satisfy DORA's incident-reporting, testing, or third-party-register requirements |
The mistake I see most often isn't misunderstanding DORA itself. It's assuming an existing ISO 27001 certificate already covers it, and finding out otherwise during a customer's DORA-specific due diligence review. — Upendra Varma, CTO at ComplyJet
Common DORA Compliance Mistakes to Avoid
- Assuming DORA works like ISO 27001 and looking for a dora compliance certification that doesn't exist. DORA has supervisory enforcement, not an accredited certification path.
- Treating the Register of Information as a one-time spreadsheet. It needs an owner and a real update cadence, not a document built once for an audit.
- Repeating the "2% of turnover" fine figure. That's NIS 2's cap, not DORA's; DORA leaves financial-entity penalties to national law.
- Assuming a US or UK headquarters means DORA doesn't apply. If you serve EU financial clients under contract, DORA's requirements often reach you anyway.
- Confusing DORA's incident reporting with GDPR's breach notification. An incident involving personal data can trigger both obligations at once, not either/or.
- Treating TLPT as equivalent to an annual pen test. It's a larger, intelligence-led exercise on a three-year cycle for significant entities, not a routine scan.
- Skipping the contract review with existing ICT vendors until an audit forces it. DORA's mandatory contract clauses apply to relationships you already have, not just new ones.
How ComplyJet Supports DORA Compliance
DORA is one of the 25+ frameworks ComplyJet supports, alongside SOC 2, ISO 27001, GDPR, and others. For a company juggling DORA alongside frameworks it already knows, that means one platform tracking evidence and policy work across all of them instead of a separate process for each.
Pricing is flat per company, not per seat, which matters for a growing team where DORA's third-party-register and contract-review work touches more people than a typical framework does. ComplyJet doesn't yet have a dedicated DORA landing page the way it does for SOC 2 or ISO 27001; the general frameworks page is the place to see current coverage.
DORA
One platform for DORA and everything else on your compliance roadmap
ComplyJet supports DORA alongside 25+ other frameworks, at flat per-company pricing, so a new EU-market requirement doesn't mean standing up a separate process.
FAQs
What Is DORA Compliance?
DORA compliance means meeting the requirements of Regulation (EU) 2022/2554, the Digital Operational Resilience Act: a documented ICT risk management framework, timely incident reporting, regular resilience testing, managed third-party ICT risk, and voluntary information sharing. It has applied to in-scope EU financial entities and their critical ICT providers since January 17, 2025.
What Are the DORA Compliance Requirements?
They break down into five pillars: an ICT risk management framework with board sign-off, incident reporting on a 4-hour/72-hour/1-month clock, regular resilience testing (including TLPT for significant entities), third-party risk management through a maintained Register of Information, and voluntary threat-intelligence sharing.
Which Organizations Does DORA Compliance Apply To?
Roughly 20 categories of EU financial entities directly, including banks, insurers, investment firms, payment institutions, and crypto-asset service providers, plus the critical ICT third-party providers, like certain cloud and software vendors, that serve them.
Is There a DORA Compliance Certification?
No. DORA is a regulation enforced through supervisory authorities and national law, not a certifiable standard. There's no accredited "DORA certification" to obtain the way there is with ISO 27001. Anyone selling one is describing an internal readiness assessment, not an official credential.
What Is a DORA Compliance Checklist?
A working list mapped to the five pillars: risk-framework sign-off, asset inventory, an incident-reporting runbook, a testing schedule, a maintained vendor register, and contract review against DORA's mandatory clauses. See the full checklist table above.
Does DORA Compliance Apply to UK Companies?
Not directly. DORA is EU-only. But a UK subsidiary of an EU financial group, or a UK vendor serving EU financial clients, often has to align with it contractually even without being directly regulated by it.
What Frameworks Align With DORA Compliance?
NIS 2 (a broader EU cybersecurity law DORA takes precedence over for financial entities), GDPR (a separate, sometimes overlapping breach-notification obligation), and ISO 27001 (a strong foundation for the risk-management pillar, but not a substitute for DORA's other requirements).
When Is the DORA Compliance Deadline?
DORA became enforceable on January 17, 2025. Supervisory work triggered by that date, including critical-provider designations and the multi-year TLPT testing cycle, is still ongoing well into the current dora compliance timeline.
Related Reading
- Best DORA Compliance Software, for a ranked comparison of tools once you've decided you need one.
- CCPA Compliance Guide, the same informational-guide format applied to a different regulation.
- PCI DSS Compliance: What It Is, Who Needs It, and How It Works, another regulation-driven obligation with a similar requirements-plus-enforcement shape.
- What Is Compliance Automation? How It Works, for how a platform actually helps satisfy requirements like DORA's risk framework and vendor register.
Sources: Regulation (EU) 2022/2554 (DORA), Articles 16, 19, 26-27, 35, 50; Regulation-DORA.eu, Critical ICT Third-Party Provider Designations, November 2025
