DORA in 2026: the grace period is over, and the clock starts at four hours.
DORA went live in January 2025 and 2025 was the year supervisors looked the other way while firms caught up. That year is gone. In 2026 the technical standards are in force, the critical providers are named, the registers are due, and a late incident report is read as evidence that you have lost control. Here is what binds you, what the clock demands, and where it stacks with the rest of the European compliance constellation.
DORA, the Digital Operational Resilience Act, is the European Union's regulation for making the financial sector able to withstand, respond to and recover from technology failures, whether a cyberattack or a cloud outage. It is Regulation (EU) 2022/2554, it has applied since 17 January 2025, and it binds around twenty types of financial entity along with the ICT providers they depend on. It works through five pillars: how you manage ICT risk, how you classify and report incidents, how you test your resilience, how you govern your third-party providers, and how you share threat intelligence. The defining features in 2026 are that the preparation period is over and the obligations are operational rather than aspirational. A major incident must be notified within four hours of classification. A machine-readable register of every ICT contract is due to your regulator each year. The cloud and infrastructure providers the sector leans on are now directly supervised by EU authorities for the first time, and the board carries personal, untransferable accountability for all of it. DORA is where European financial regulation stops asking whether your technology is compliant and starts asking whether it holds up under attack.
A regulation, applied directly, to the whole financial sector.
The shape of the law tells you how seriously to take its uniformity, and DORA is shaped to leave very little room for local interpretation.
DORA is a regulation, not a directive, which means it applies directly and word-for-word across every member state without each one passing its own version, the same legal form as the GDPR and unlike NIS2, whose national transpositions vary. That uniformity is deliberate: the financial sector is cross-border by nature, and a bank operating in eight member states needed one rulebook rather than eight. The scope is correspondingly broad. Around twenty categories of financial entity are caught, banks and credit institutions, insurers and reinsurers, investment firms, payment and electronic-money institutions, crypto-asset service providers, central counterparties and trading venues, fund managers, credit rating agencies and more, and the reach extends past the financial firms themselves to the ICT third-party providers that serve them.
Two consequences follow that catch people out. The first is extraterritorial reach: a non-EU group is bound by DORA wherever it runs an EU-authorised entity, so a US or UK bank's European subsidiary is fully in scope, and a technology provider serving EU financial entities is pulled in regardless of where it is based. The second is that DORA is lex specialis to the broader NIS2 framework for the financial sector, meaning its more specific rules take precedence for the entities it covers. A bank does not get to choose between DORA and NIS2; for its ICT resilience, DORA is the governing text, while a single incident can still trigger reporting under several regimes at once, a tangle the final section returns to.
Where the regime stands in 2026.
DORA is not new this year, but 2026 is the year it changed character, from a framework being assembled to one being enforced, and the distinction is the whole story.
The regulation was adopted in 2022 and applied from 17 January 2025, after a two-year preparation window. Through 2024 the European Supervisory Authorities, the EBA, EIOPA and ESMA, drafted the regulatory and implementing technical standards that fill in the detail, the criteria for classifying incidents, the templates for reporting, the requirements for testing and for third-party contracts, and most were finalised across 2024 and early 2025. The framework was considered complete by mid-2025. Supervisors openly treated 2025 as a transition year, reviewing the frameworks firms had built, identifying gaps and setting expectations rather than reaching for penalties.
2026 is where that posture ends. The technical standards are in force, including the joint standards on major incident reporting that have applied since March 2025 and the oversight standards harmonising how supervisors conduct inspections. In November 2025 the European Supervisory Authorities designated the first nineteen critical ICT third-party providers, putting the cloud hyperscalers and key market-infrastructure suppliers under direct EU oversight. Competent authorities have signalled plainly that enforcement is now proactive, and they have reframed what a late incident report means: no longer a missed administrative deadline but a signal that the firm may be losing control of its digital perimeter, an immediate trigger for deeper scrutiny. The grace period is the thing that ended, and a firm still operating as though 2026 looks like 2025 is operating on a misread of the calendar.
| When | What happened | What it means |
|---|---|---|
| 2022 | Regulation (EU) 2022/2554 adopted | Two-year prep window opens |
| 17 Jan 2025 | DORA enters into application | Obligations live; treated as transition |
| Mar 2025 | Incident-reporting standards apply | The four-hour clock is binding |
| Nov 2025 | 19 critical ICT providers designated | EU directly supervises the suppliers |
| 2026 | Proactive enforcement; registers due | The grace period is over |
The five pillars, and what each one demands.
DORA is usually described as five pillars, four mandatory and one voluntary. The framing is useful because each pillar maps to a distinct body of work with its own owner.
The first pillar, ICT risk management, is the governance backbone: a documented framework of strategies, policies, tools and procedures for protecting all the information and ICT assets the firm relies on, owned ultimately by the management body. The second, incident management and reporting, requires firms to detect, classify against defined thresholds, and report major incidents on the strict clock, the pillar that turns governance into operations. The third, resilience testing, runs from routine vulnerability assessment up to threat-led penetration testing on live systems for the most significant entities. The fourth, ICT third-party risk management, governs the contracts, the register and the oversight of the providers the firm depends on, and is for many firms the heaviest single pillar. The fifth, information sharing, encourages but does not compel the exchange of cyber threat intelligence between firms, the one pillar that is a recommendation rather than a requirement.
| Pillar | Articles | Core demand |
|---|---|---|
| ICT risk management | Art 5–16 | Board-owned framework and controls |
| Incident management | Art 17–23 | Classify and report on the clock |
| Resilience testing | Art 24–27 | TLPT every 3 years for significant entities |
| Third-party risk | Art 28–44 | Contracts, register, provider oversight |
| Information sharing | Art 45 | Encouraged, voluntary |
Inside the first pillar: the framework everything else hangs from.
The incident clock and the register get the attention, but they rest on the first pillar, and a firm whose underlying risk-management framework is thin will fail the visible obligations for invisible reasons.
The ICT risk management framework that Articles 5 to 16 require is the firm's whole apparatus for keeping its technology resilient, and DORA is prescriptive about its parts. It must identify and document all ICT-supported business functions, the information assets behind them, and the dependencies between them, the asset inventory that everything downstream relies on. It must protect those assets through security policies, access control, encryption and network segmentation, and detect anomalies through continuous monitoring with defined thresholds for what triggers an alert. It must provide for response and recovery through business continuity and disaster recovery plans that are tested rather than filed, including the backup and restoration procedures that decide whether a firm recovers from an incident in hours or weeks. And it must close the loop by learning, feeding the lessons from incidents and tests back into the framework so it improves rather than ossifies.
The framework is where DORA's pillars connect into one system rather than five separate checklists. The asset inventory built here is what the Register of Information draws on and what incident classification depends on, because you cannot judge whether an incident affects a critical function without knowing which assets support it. The monitoring built here is what makes the four-hour clock survivable, because detection is the framework's job before it is the incident pillar's deadline. The continuity testing built here is what the resilience-testing pillar evidences. A firm that treats the framework as documentation, a binder of policies that describes controls the infrastructure does not in fact deliver, will find the visible obligations failing in ways that trace back to the foundation: an incident it cannot classify because the asset map is wrong, a register that does not match reality because the inventory was never maintained, a recovery that does not work because the plan was written but never run. The first pillar is unglamorous, and it is the one whose weakness shows up everywhere else.
The four-hour clock, and the trap inside it.
If one number defines DORA in practice, it is four hours. Understanding exactly when it starts is the difference between compliance and a sanctionable breach.
When a financial entity suffers a major ICT-related incident, the reporting runs in stages defined in Articles 17 to 23. An initial notification is due within four hours of classifying the incident as major, and in no case later than twenty-four hours after detection. An intermediate report follows within seventy-two hours of that initial notification, and if the incident is unresolved at that point, the intermediate report must carry an action plan and expected timeline. A final report is due within one month of the last intermediate report. The reports go to the firm's competent authority through harmonised templates set by the technical standards, submitted with qualified electronic certificates, and the portal returns an acknowledgement with a unique incident number to retain as evidence.
The trap is the relationship between detection and classification, and it sinks firms that have not rehearsed it. The four-hour clock starts at classification, the moment you judge the incident major against the materiality thresholds, not at detection, the moment you first became aware. That sounds like breathing room and is not, because classification itself must happen without undue delay, with a hard ceiling of twenty-four hours after detection. A firm that treats classification as a leisurely seventy-two-hour triage has already breached, and a firm that has never run the detect-classify-notify sequence against a stopwatch will discover under real pressure that gathering the timestamps, impact assessment and classification rationale the template demands takes longer than four hours when nobody has done it before. There is a further subtlety the thresholds force: recurring related incidents must be aggregated when judging economic impact, so a series of smaller events that individually look minor can cross the major threshold collectively, and a firm assessing each in isolation underreports. The clock is not the hard part; being ready to act on it without notice is.
What makes an incident "major", and why the threshold is a system.
The four-hour clock only starts for major incidents, so the classification thresholds are not a footnote, they are the trigger, and they are deliberately quantitative so two firms judge the same event the same way.
DORA does not leave "major" to judgement. The technical standards define quantitative and qualitative criteria a firm assesses every incident against: the number of clients or financial counterparts affected and whether they include critical ones, the geographic spread across member states, the volume and value of transactions hit, the duration and the service downtime, any data losses touching availability, authenticity, integrity or confidentiality, the reputational impact, and the economic cost. An incident that crosses the defined thresholds on these dimensions is major and reportable; one that does not is logged, classified and reviewed internally but not notified. The criteria exist so that classification is a calculation rather than an argument, which matters when the clock is running and a defensible rationale has to accompany the notification.
Two features of the threshold system catch firms out. The first is the aggregation rule: recurring incidents that are individually minor but share a root cause must be assessed together when judging economic and operational impact, so a drip of small failures that each fall below the line can collectively cross it, and a firm assessing each in isolation underreports a major incident without realising. The second is that significant cyber threats, not just realised incidents, have a voluntary notification path under the same framework, so a firm that detects a serious threat before it materialises can, and often should, flag it. The practical consequence is that classification cannot be a manual judgement made under pressure for the first time during a crisis; it has to be a pre-built decision rule, the thresholds encoded into the incident process, the aggregation logic understood in advance, so that when an event lands the question "is this major?" has a fast, documented, repeatable answer rather than a meeting.
The Register of Information: the filing supervisors read most.
Quieter than the incident clock but just as consequential, the register is the annual document through which the regulators see the whole sector's dependencies at once.
Under Article 28, every financial entity must maintain a Register of Information, a machine-readable register of all contractual arrangements for ICT services provided by third parties, including the subcontractors involved and the links between each service and the firm's critical or important functions. It is submitted to the national competent authority annually, with most 2026 deadlines falling at the end of the first quarter and a common date of 30 April, in the mandated xBRL-CSV format using the fifteen standardised templates set by the implementing technical standards. It is a separate filing from incident reporting, not bundled with it, and the format is not optional, a register kept in a spreadsheet of the firm's own design does not satisfy the obligation.
The register matters more than its administrative appearance suggests because of what supervisors do with it. The European Supervisory Authorities aggregate the registers across the whole sector to see where the financial system is dangerously concentrated on a small number of ICT providers, which is precisely the data that drives the designation of critical providers, and to understand the substitution constraints a firm would face if a provider failed. For the individual firm, the register is also the backbone of its own third-party risk management, the single inventory linking every provider and subcontractor to the functions they support, which is why getting it accurate is a resilience exercise rather than a compliance chore. Engaging the national authority early on the exact content and identifiers it expects is the practical advice every adviser repeats, because a register that does not match the supervisor's expected fields is a register filed late.
Testing: from routine scans to live-fire red teams.
The third pillar is where DORA insists resilience be demonstrated rather than asserted, and it scales the demand to how systemic the firm is.
Every covered entity must run a digital operational resilience testing programme, a structured cycle of assessments proportionate to its size and risk: vulnerability assessments and scans, network security assessments, gap analyses, penetration testing, and the review of source code and configurations where relevant, with the findings fed into a remediation cycle and the lessons documented. This baseline is not exotic, it is the testing a mature security programme already performs, but DORA makes it a continuous, evidenced obligation rather than an occasional project, and supervisors expect to see the programme, the schedule, the results and the remediation as a demonstrable whole rather than a folder of one-off reports.
For the most significant entities, those whose failure would matter most to the system, the requirement steps up to threat-led penetration testing. TLPT is advanced red-teaming conducted on live production systems, using genuine threat intelligence to simulate the tactics, techniques and procedures of real adversaries, performed at least every three years and coordinated with authorities under a framework aligned to the European TIBER-EU model. It is a different order of exercise from a routine penetration test: it targets the systems that matter most, it runs against production rather than a lab, it uses intelligence about who would realistically attack this firm and how, and it involves external testers and supervisory coordination. The point is to prove that the firm's resilience holds when a capable attacker is genuinely trying to break it, which is the only test that distinguishes a resilience framework that works from one that merely reads well. For a firm in scope for TLPT, the operational reality is that production systems will be attacked by design, on a cycle, with the results visible to a regulator, which concentrates attention on whether the monitoring and response that the rest of DORA assumes can really see and stop a determined adversary in the firm's own live environment.
The third-party regime, and the contracts written before the rules.
For most firms the heaviest pillar is the fourth, because it reaches outside the organisation into every vendor relationship, and many of those relationships were papered before DORA existed.
DORA requires written contracts with ICT third-party providers that include a defined set of minimum provisions, sharpest for the services supporting critical or important functions: rights of access and audit for the firm and its supervisors, clear security requirements, defined service levels, obligations to assist during incidents, and crucially, exit strategies and termination rights so a firm is never trapped with a provider it can no longer rely on. The regulatory technical standard on contractual policy spells out the minimum requirements, and a parallel standard governs subcontracting, the elements a firm must assess before a provider is allowed to subcontract a service supporting a critical function. The register and the contracts are meant to align, each register entry corresponding to an arrangement whose contract carries the mandated clauses.
The practical problem is legacy. A large share of ICT contracts in force when DORA applied were signed years earlier, without audit rights, without exit provisions, without the security and incident clauses the regulation now demands, and many required renegotiation that ran well past the January 2025 date. Reopening a contract with a dominant cloud provider to insert audit and exit rights is not a quick legal task, and it is one of the places where firms remain exposed in 2026, holding register entries that point at contracts which do not yet contain the clauses the register implies. This is also where DORA's concentration concern becomes concrete for the firm: the harder a provider is to exit or substitute, the more the missing exit clause matters, and the more a supervisor reading the register will want to know what happens if that provider fails. The contract work is unglamorous, slow, and the part of DORA most likely to be quietly incomplete behind an otherwise tidy framework.
The new thing DORA does: supervising the suppliers.
DORA's most genuinely novel feature is that, for the first time, the EU directly oversees the technology providers behind finance rather than only the financial firms.
The logic is concentration risk. The financial sector now depends on a small number of cloud, infrastructure and data providers so heavily that the failure of one could ripple across many institutions at once, a systemic exposure no individual firm's contract management can address. DORA's answer is an EU-level oversight framework for critical ICT third-party providers. The European Supervisory Authorities assess providers against criteria of systemic importance and the degree of the sector's reliance on them, and in November 2025 they designated the first nineteen, including the major cloud hyperscalers and key market-infrastructure and financial-technology suppliers. Each designated provider is assigned a lead overseer, one of the EBA, EIOPA or ESMA, and the oversight is real: the lead overseer can request information, conduct on-site inspections, issue recommendations, and require remediation.
The obligations on critical providers are correspondingly heavier than on the firms they serve. They face a tighter incident clock, notification within two hours rather than four, and penalties for non-compliance reaching up to one percent of average daily worldwide turnover, a recurring figure designed to apply continuous pressure rather than a single fine. Most strikingly, a lead overseer can forbid a critical provider from entering into contracts with financial firms, or with other ICT providers serving them, until it complies, a power that turns a regulatory finding into a commercial consequence the provider cannot ignore. For a financial entity, this oversight layer is partial reassurance, the providers it most depends on are now watched at the source, but it does not transfer the firm's own responsibility, which remains squarely with the entity even when it relies on a supervised provider. The supervision is additive, not a substitute for managing your own third-party risk.
The board cannot delegate this away.
DORA, like NIS2, deliberately puts operational resilience on the board's desk, and it uses the mechanisms that reliably change behaviour at that level.
Article 5 places ultimate responsibility for the ICT risk management framework on the management body. The board must approve and oversee the digital operational resilience strategy, allocate adequate budget to it, define clear roles and responsibilities for ICT functions, assign someone to monitor the arrangements with third-party providers, and designate an independent control function to oversee ICT risk with appropriate segregation from the functions it checks. The provision that concentrates minds is the training duty: board members must themselves undergo specific ICT risk training, and DORA is explicit that ignorance is not a defence. Supervisors have made clear they will read board minutes to confirm that digital resilience is a standing agenda item rather than an annual afterthought, which means the governance has to be visible and documented, not merely asserted. The effect is to remove the option of treating ICT resilience as a technical matter delegated wholly to a CIO or a vendor; under DORA it is a board responsibility with personal accountability attached, and the same shift toward management liability that runs through the EU's NIS2 regime.
Where DORA sits in the compliance constellation.
DORA does not arrive alone, and the firms it covers are usually juggling several overlapping regimes whose clocks all start from the same event.
Consider one incident: an attacker exfiltrates customer data from a bank and takes a payment service offline for hours. That single event is a major ICT-related incident under DORA, a significant incident under NIS2, and a personal data breach under the GDPR, three obligations to three different authorities, each with its own templates and its own clock. DORA's notification clock starts first, at four hours from classification; NIS2's early warning is due within twenty-four hours; the GDPR's breach notification within seventy-two. A firm that has built three separate, uncoordinated reporting processes will find them colliding under pressure, racing the same facts to different regulators in different formats. The volume is not hypothetical: with DORA and NIS2 now operational alongside the GDPR, the total number of incident reports filed across the three frameworks is estimated to exceed two hundred thousand a year across the EU, and supervisors have fined firms specifically for late notification, which makes a coordinated reporting workflow a genuine risk control rather than a tidiness preference.
The relationship between the regimes is layered rather than flat. DORA is lex specialis to NIS2 for the financial sector, so where they overlap DORA's more specific rules govern the covered entities, while the GDPR sits alongside both whenever personal data is involved, and the EU AI Act adds a further layer for firms deploying AI in regulated functions. The competent reading is to treat incident response as one capability serving several regimes, with a classification and notification workflow that knows which obligations a given incident triggers and routes the right report to the right authority on the right clock, rather than three teams discovering the overlap mid-incident. This is the same principle, that detection and response is one operational capability the compliance regimes all draw on, that runs through the NIS2 obligation to report in twenty-four hours and the wider compliance and sovereignty work: you cannot report, to any regulator on any clock, an incident your monitoring never caught.
What to prioritise in 2026, from people who run the monitoring.
The regulation is large, and a firm can drown in its forty-five articles. The triage that matters separates the obligations with hard clocks from the ones with calendar deadlines, and starts with the part that is operational rather than documentary.
Three priorities order the work. First, make the incident process function under time pressure, because the four-hour clock is the obligation most likely to produce a visible, sanctionable failure, and most firms have a written process they have never run against a stopwatch. Rehearse the detect-classify-notify sequence as a drill, with the real templates, the real authority channel, and the real twenty-four-hour classification ceiling, and you will find the gaps, the missing timestamps, the unclear classification authority, the person who has to be woken at three in the morning, before a regulator does. Second, get the Register of Information accurate and submitted in the correct xBRL-CSV format by the deadline, engaging your national authority early on the fields it expects, because it is a separate annual filing the supervisors actively use and a late or malformed register is an early red flag. Third, close the third-party contract gaps, prioritising the providers linked to your critical and important functions, since many legacy agreements still lack the mandated audit, exit and security clauses.
Underneath all three sits a capability question that the article-by-article guidance tends to skip, and it is the one we care about most as operators. Every clock in DORA, the four hours, the twenty-four, the seventy-two, starts at an event you have to detect and characterise, which means the regulation is, beneath the governance language, a detection-and-response requirement wearing a financial-supervision coat. A firm cannot classify within twenty-four hours what its monitoring never surfaced, cannot describe an incident's impact at seventy-two hours without the logs and telemetry to reconstruct it, and cannot demonstrate to a lead overseer that its controls work without the evidence that continuous monitoring produces. The same is true for the critical-provider relationships: knowing a major incident has occurred at a provider, on the provider's two-hour clock, depends on the visibility your contracts and your own monitoring give you into that dependency. That is the lens we bring, because we build and run the detection that these clocks assume rather than only advise on the policy above it, and DORA, NIS2 and the GDPR turn out to be three regulatory views of the same operational question. Where it helps to have the monitoring, the incident workflow and the evidence trail built by people who run them daily, that is the work our managed security and compliance and sovereignty practices exist to do, with the resilience itself resting on the infrastructure you can see into and control.
Questions firms are asking in 2026.
What is DORA and who does it apply to?
When did DORA take effect, and is it being enforced now?
What are the five pillars of DORA?
What is the DORA incident reporting timeline?
What is the difference between detection and classification under DORA?
What is the Register of Information?
What is a critical or important function under DORA?
What is threat-led penetration testing under DORA?
How are critical ICT third-party providers overseen?
What are the penalties for breaching DORA?
Does DORA apply to ICT providers like cloud and software vendors?
How does DORA interact with NIS2 and the GDPR?
What does DORA require of the management body?
We use ISO 27001 and already comply with NIS2. Are we DORA-ready?
What should a financial entity prioritise for DORA in 2026?
Does DORA apply to non-EU firms?
The clock starts whether or not you were watching.
We map your DORA gaps against the five pillars, rehearse the four-hour incident process until it works under pressure, get the Register of Information into the format supervisors accept, and build the monitoring that every clock in the regulation quietly assumes. Resilience you can evidence, on infrastructure you can see into, by people who run detection rather than only document it.