DORA Compliance Guide for Financial Entities and Their Vendors
DORA compliance Somewhere in the last five years, “our cloud provider had an outage” stopped being an IT problem and became a financial-stability problem. A payments processor going dark for three hours, a core-banking platform failing during a market swing, a single cloud region taking down half a country’s mobile banking apps — European regulators watched these events pile up and concluded that treating technology risk as a footnote to operational risk was no longer good enough.
That conclusion became the Digital Operational Resilience Act, or DORA. It is not a guideline or a voluntary standard. It is EU Regulation 2022/2554, binding and directly applicable in every Member State since 17 January 2025, and by the middle of 2026 it has moved firmly out of its “get ready” phase and into active supervision. Regulators are now checking whether what firms wrote in their policies actually matches what happens when a server falls over at 2 a.m.
This guide walks through what DORA covers, who has to comply, how the five pillars fit together, and — because this is the part that catches people off guard — how deep the regulation reaches into vendor contracts. If you sell software, infrastructure, or data services to a bank, insurer, or payment firm in the EU, DORA is very likely already sitting somewhere in your contract renewal paperwork, whether you’ve noticed it yet or not.
how it manages the vendors it depends on, and how it shares threat intelligence with peers. The diagram below gives the shape of the whole thing before we go pillar by pillar.
What Is DORA compliance Exactly?
DORA compliance stands for the Digital Operational Resilience Act. Its job is to make sure that when a financial entity’s technology breaks — through a cyberattack, a software bug, a hardware failure, or a vendor going down — the entity can keep operating, recover quickly, and tell regulators what happened without a six-week delay and a shrug.
Before DORA, ICT risk was scattered across different national rules and folded loosely into general operational-risk requirements. That patchwork made it hard for regulators to compare firms, and it left plenty of room for a well-documented risk policy to exist purely on paper. DORA consolidates all of that into one directly applicable EU regulation with specific, testable obligations — not principles to interpret, but articles with named deadlines, named report formats, and named penalties.
The regulation organizes itself around five connected areas of obligation, which the industry has settled on calling the “five pillars.” Together they cover how a firm manages ICT risk day to day, how it reports things when they go wrong, how it proves its systems can take a hit,
Who DORA compliance Actually Has to Comply?
DORA compliance casts a wide net. It applies to roughly twenty categories of EU financial entities — far more than just banks. If your organization touches EU financial services in almost any regulated capacity, it’s worth checking your entity type against the list rather than assuming DORA is “someone else’s problem.
| Entity Category | Examples | Typical Testing Burden |
|---|---|---|
| Credit institutions | Retail and commercial banks | Full programme, TLPT if significant |
| Payment & e-money institutions | Payment processors, digital wallets | Full programme |
| Investment firms | Brokerages, asset managers, trading venues | Full programme |
| Insurance & reinsurance undertakings | Insurers, reinsurers, intermediaries | Full programme |
| Crypto-asset service providers | Exchanges, custodians (under MiCA scope) | Full or simplified |
| Crowdfunding service providers | Investment and lending platforms | Simplified framework available |
✎ Proportionality isn’t an exemption -DORA compliance scales its requirements to a firm’s size, risk profile, and complexity (Article 16). Micro and small firms get a simplified ICT risk framework and lighter testing obligations — but every in-scope entity, regardless of size, must still comply with incident reporting, the Register of Information, and the core governance requirements. “We’re too small for DORA” is rarely a valid conclusion.
Pillar 1: ICT Risk Management
This is the foundation the other four pillars sit on. Articles 5–16 require every in-scope entity to build an internal governance and control framework for ICT risk — and critically, this isn’t something a firm can delegate entirely to its IT department. The management body has to define, approve, and actively oversee the framework, review it at least once a year, and be able to demonstrate that oversight to a supervisor who asks.
In practice, the framework needs to cover identification of ICT assets and dependencies, protective controls, detection capability, response and recovery plans, and a communication strategy for when something breaks. Firms also need a documented business impact analysis that identifies which functions are “critical or important” — a label that follows those functions through the rest of the regulation, including which vendor relationships get extra scrutiny.
Pillar 2: Incident Classification and Reporting
This is the pillar with the least room for improvisation, because it runs on a clock. Articles 17–23 require firms to classify ICT-related incidents and, once an incident is classified as “major,” report it to the competent national authority in three stages. Delegated Regulation 2024/1772 sets out six criteria — things like the number of clients affected, direct economic impact above roughly €100,000, service downtime, geographic spread, data loss, and the criticality of the affected function. Meeting any one of these thresholds is enough to trigger the major-incident clock.
The detail that trips up otherwise well-prepared teams: the 4-hour clock starts at the moment the incident is classified as major, not the moment it’s first noticed. That means classification itself has to happen fast — in practice, well inside the 24-hour outer limit — which only works if there’s a named decision-maker with authority to call an incident “major” at 3 a.m. without waiting for a committee meeting.
| Stage | Deadline | What Must Be Included |
|---|---|---|
| Initial notification | 4h from classification (24h outer limit from detection) | Incident type, affected services, estimated impact, first mitigation steps |
| Intermediate report | 72h from the initial notification | Root-cause analysis if available, full impact scope, recovery status |
| Final report | 1 month from the last intermediate report | Complete root-cause analysis, total impact, remediation taken, lessons learned |
The detail that trips up otherwise well-prepared teams: the 4-hour clock starts at the moment the incident is classified as major, not the moment it’s first noticed. That means classification itself has to happen fast — in practice, well inside the 24-hour outer limit — which only works if there’s a named decision-maker with authority to call an incident “major” at 3 a.m. without waiting for a committee meeting.
Pillar 3: Digital Operational Resilience Testing
Article 24 requires every in-scope entity to run a testing programme covering vulnerability assessments, scenario-based tests, and other exercises appropriate to its risk profile, on at least an annual basis. This isn’t a one-off penetration test filed away and forgotten — it’s meant to be a standing programme with results that feed back into the ICT risk framework.
For the largest and most systemically important entities, Article 26 adds Threat-Led Penetration Testing, or TLPT — a much more intensive exercise modeled on the TIBER-EU framework, run against live production systems by accredited testers simulating real adversary behavior, at least once every three years. TLPT tests aren’t purely internal; they need to be recognized and, in cross-border cases, coordinated across the relevant national authorities, which makes scheduling and scoping a genuinely cross-functional project rather than a line item on a security team’s calendar.
- Standard testing: vulnerability scans, scenario-based exercises, network security assessments — annual, all entities.
- TLPT: live, adversary-simulation testing against production — every 3 years, large/significant entities only.
- Independence matters: testers, whether internal or external, must operate independently of the systems they’re testing.
- Findings have to close the loop back into the ICT risk framework, not sit in a report nobody re-reads.
Pillar 4: ICT Third-Party Risk Management
This is the pillar vendors need to read most carefully, because DORA compliance reach doesn’t stop at the financial entity’s own walls. Articles 28–44 require firms to maintain a full Register of Information covering every ICT third-party contractual arrangement, apply strict due diligence before onboarding a provider, and build specific mandatory clauses into every relevant contract under Article 30.
The Register of Information is due annually, and the 2026 cycle has already shown how unforgiving the data-quality bar is: in the European Supervisory Authorities’ dry-run exercise, only a small fraction of firms passed every one of the 116 data-quality checks on the first attempt. National deadlines vary by regulator, but the ESAs’ consolidated deadline for the 2026 submission cycle sits at the end of April, covering third-party arrangements as they stood on 31 December 2025.
Then there’s the part that genuinely changes vendor relationships: in November 2025, the European Supervisory Authorities designated the first cohort of Critical ICT Third-Party Providers, or CTPPs — nineteen providers, concentrated among major cloud infrastructure and core financial-technology platforms. Designation isn’t symbolic. It puts the provider under direct oversight from a Lead Overseer (one of the EBA, EIOPA, or ESMA), with the power to request information, run on-site inspections, and issue binding recommendations — the first time EU financial regulators have gained direct supervisory authority over companies that aren’t themselves financial institutions.
| Article 30 Contract Element | What It Requires |
|---|---|
| Service description & SLAs | Clear, complete description of the ICT service and measurable performance levels |
| Audit & inspection rights | Financial entity (or its delegate) can access, audit, and inspect the provider's premises and systems |
| Sub-outsourcing controls | Prior notification or consent required before the provider sub-contracts material functions |
| Data location & security | Where data is processed and stored, and how it's protected, must be specified |
| Incident cooperation | Provider must support the financial entity's own incident classification and reporting duties |
| Exit & termination rights | Documented, testable exit strategy with a realistic transition period, typically 12 months+ |
✎ Concentration risk is now a board-level metric – Article 29 requires firms to formally assess how dependent they are on any single ICT provider — what share of critical functions that provider supports, how long a genuine exit would realistically take, and whether contractual exit and data-portability rights would actually hold up under pressure. If your entire critical-function stack sits on one cloud region with one vendor, expect that fact to surface in board-level ICT risk reporting, not just in a procurement spreadsheet.
Pillar 5: Information Sharing
The final pillar, covered in Articles 45–49, is the lightest-touch of the five — and the only one built on voluntary participation rather than mandatory reporting. DORA encourages financial entities to join trusted information-sharing arrangements, exchange threat intelligence about indicators of compromise, tactics, and vulnerabilities, and take part in sector-wide exercises.
The logic is straightforward: a cyberattack technique used against one bank this month is very likely to be reused against another bank next month. Firms that share early warning signals reduce the chance that the same attack cascades quietly across the sector before anyone connects the dots. It won’t show up in an audit the way incident reporting will, but supervisors increasingly view active participation as a sign of a mature resilience culture rather than a box-ticking exercise.
What supervisors are actually checking in 2026
- Whether the board can explain the ICT risk framework in its own words, not just sign off on a document someone else wrote.
- Whether the business impact analysis lines up with what the firm actually reported in its Register of Information.
- Whether ICT risk appetite is expressed in measurable terms rather than vague language like “low tolerance for disruption.”
- Whether the framework has been tested against a real scenario in the last twelve months, not just reviewed on paper.
Penalties and the 2026 Enforcement Reality
DORA doesn’t set one uniform EU-wide fine schedule for financial entities — instead, it requires each Member State to establish penalties that are “effective, proportionate, and dissuasive,” which means the exact number depends on national law and the competent authority handling the case. What is uniform is the exposure for firms found in serious breach: fines running as high as 10% of annual global turnover or €10 million, whichever figure is larger, are within reach for the most serious violations under several national regimes.
Critical ICT third-party providers face a different, EU-level penalty structure entirely. Where a designated CTPP fails to cooperate with its Lead Overseer — ignoring information requests, blocking an inspection, or not implementing required remediation — Article 35 allows periodic penalty payments of up to 1% of the provider’s average daily worldwide turnover, charged for every day of non-compliance, for up to six months.
| Breach Type | Who's Exposed | Penalty Exposure |
|---|---|---|
| General DORA non-compliance | Financial entities | Up to 10% of annual global turnover or €10M (varies by Member State) |
| Failure to report a major incident on time | Financial entities | Sanctionable under Article 19 as a standalone breach |
| Non-cooperation with Lead Overseer | Designated CTPPs | Up to 1% of average daily worldwide turnover, per day, up to 6 months |
| Ignored ESA remediation recommendations | Financial entities using a flagged CTPP | Escalation to national competent authority under Article 42 |
✎ 2026 is the enforcement year, not the grace-period year There is no remaining implementation deadline left to plan around — DORA compliance has applied in full since January 2025. What’s changed in 2026 is posture: national competent authorities have moved from reviewing whether policies exist to testing whether they hold up in practice, and the Register of Information submission is now the primary data source regulators use to cross-check a firm’s stated risk profile against its actual vendor footprint.
Building a Realistic Compliance Roadmap
Firms that treat DORA compliance as a single project with an end date tend to struggle, because the regulation is designed to be a permanent operating rhythm, not a one-time certification. A more workable approach breaks the work into four overlapping phases, each of which keeps running even after the next one starts.
The gap analysis phase is where most of the surprises turn up — not because firms lack policies, but because the business impact analysis on paper rarely matches the actual dependency map once someone traces every critical function back to its underlying vendors. Getting that mapping right early saves a lot of rework later, particularly in the Register of Information, which is unforgiving about inconsistencies between what a firm says is critical and what it reports as its vendor footprint.
Building and documenting comes next: the ICT risk framework itself, incident classification playbooks with a named decision-maker for the 4-hour clock, the Register of Information, and updated Article 30 clauses across every material vendor contract — which, realistically, means a full contract review cycle rather than a quick addendum. Testing and validation follows, proving the framework works under simulated pressure rather than just existing on paper. And then the work becomes permanent: continuous monitoring, annual Register submissions, and periodic vendor re-assessment as the ICT vendor landscape and the CTPP designation list both keep evolving.
DORA compliance & Resources
Start here for anything that needs to be legally authoritative — policy text, technical standards, and regulator guidance, straight from the source:
- EUR-Lex — Full text of Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554
- European Banking Authority (EBA) — Operational Resilience & DORA — https://www.eba.europa.eu/regulation-and-policy/operational-resilience
- EIOPA — DORA Oversight Framework — https://www.eiopa.europa.eu/digital-operational-resilience-act-dora/dora-oversight_en
- ESMA — Joint ESAs Guide on DORA Oversight Activities — https://www.esma.europa.eu/sites/default/files/2025-07/JC_2025_29__DORA_Guide_on_oversight_activities.pdf
- European Central Bank — TIBER-EU Framework (basis for TLPT testing) — https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
The Bottom Line
DORA is unusual among compliance frameworks in how directly it reaches past the financial entity and into the vendor relationship itself. A bank can write a flawless ICT risk policy and still fail an audit if its cloud contract is missing an exit clause, or if a critical vendor can’t produce evidence of the audit rights it agreed to. That’s the real shift here: resilience isn’t something a firm can achieve alone anymore — it has to be built jointly with every provider that sits inside the critical-function chain.
For financial entities, that means treating vendor due diligence, contract language, and concentration-risk assessment as core compliance work, not procurement housekeeping. For ICT vendors serving the EU financial sector — whether or not you expect to be named a CTPP — it means getting comfortable with audit rights, incident-cooperation clauses, and documented exit paths well before a customer’s compliance team asks for them during a renewal. The firms handling this well in 2026 aren’t the ones with the thickest policy binder; they’re the ones who can produce evidence, on short notice, that the binder reflects what actually happens when something breaks.
DORA compliance Frequently Asked Questions
Q. Does DORA apply to companies outside the EU?
- Directly, no — DORA applies to EU-authorized financial entities. Indirectly, yes: a non-EU ICT vendor serving an EU bank, insurer, or payment firm will be pulled into Article 30 contract obligations by that customer, and could even be designated a Critical ICT Third-Party Provider if its scale and systemic role warrant it.
Q. What counts as a “major” ICT incident under DORA?
A. An incident that trips at least one of six thresholds set out in Delegated Regulation 2024/1772: a large share of clients or transactions affected, economic impact above roughly €100,000, meaningful downtime to a critical function, cross-border geographic spread, data loss, or high criticality of the disrupted service.
Q. Is DORA the same as NIS2?
- No. Both are EU cybersecurity-adjacent regulations, but DORA is financial-sector-specific and takes precedence over NIS2 for in-scope financial entities under the lex specialis principle. A firm subject to both still needs to coordinate reporting, since the underlying incident data often overlaps.
Q. Do small firms get any relief from DORA's requirements?
- Yes, through the proportionality principle in Article 16 — micro and small entities can apply a simplified ICT risk management framework and face lighter testing obligations. That relief doesn’t extend to the core obligations: incident reporting, the Register of Information, and basic governance still apply regardless of size.
Q. What is the Register of Information, and who has to file it?
- It’s an annual inventory of every ICT third-party contractual arrangement a financial entity holds, submitted at entity, sub-consolidated, or consolidated group level. Every in-scope financial entity has to maintain and submit it — there’s no size-based exemption for this particular obligation.