Digital Operational Resilience Act: 2026 Outlook for Financial Resilience

The Digital Operational Resilience Act defines resilience around whether financial entities can keep critical or important functions operating through ICT disruption and recover in a controlled way.

DORA, formally EU Regulation 2022/2554, applies from 17 Jan 2025 and creates a single EU framework for digital operational resilience in the financial sector. It requires firms to manage ICT risk, report major ICT-related incidents, test resilience, control ICT third-party risk, and share relevant threat information through appropriate arrangements.

Last updated: 2026. This article is informational and does not constitute legal advice. Financial entities and ICT service providers should confirm obligations against the regulation, regulatory technical standards, implementing technical standards, and guidance from the relevant competent authority.

What DORA changes in practice

DORA changes the treatment of technology risk from a supporting control topic into a board-level operational resilience obligation. The regulation does not ask financial entities merely to maintain policies; it expects them to show how ICT risk is governed, tested, evidenced, escalated, and improved over time.

The practical shift is visible in the language of the regulation. DORA repeatedly connects technology to business services, especially critical or important functions whose disruption would materially impair performance, financial soundness, continuity of services, or compliance. That link matters because a firm cannot define resilience around servers and applications alone. It must understand which business functions depend on which systems, vendors, data flows, people, and recovery procedures.

For many firms, this mapping exercise is harder than drafting the policy. Asset inventories often exist in technology teams, process maps sit with operations, outsourcing registers sit with procurement or legal, and incident records sit with security. DORA forces those views to be joined so that resilience decisions can be made against the services that matter most.

Who is in scope

DORA applies across a broad part of the EU financial sector, including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, trading venues, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, crowdfunding service providers, and other financial entities identified in the regulation. The exact application depends on the entity type and proportionality considerations, but the intent is clear: digital resilience is treated as a financial stability issue, not a narrow IT concern.

ICT third-party service providers are also central to the regime. Most vendors are affected indirectly through customer due diligence, contractual clauses, audit rights, incident cooperation, exit planning, and reporting expectations. A non-EU cloud, software, managed service, or security provider that supports EU financial entities may therefore face DORA-driven contractual obligations even if the provider is not itself a regulated financial entity.

DORA also introduces direct EU-level oversight for designated critical ICT third-party service providers. The European Supervisory Authorities operate through a Joint Oversight Forum and appoint a lead overseer for each designated provider. That lead overseer can issue recommendations to the provider, and those recommendations may cascade into remediation plans, contract changes, assurance requests, or exit considerations for the financial entities that depend on the service.

The five areas supervisors will expect firms to evidence

DORA is often described through five pillars: ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. These areas are useful because they help teams decide where to start. If the largest gap is governance and asset mapping, the first workstream should be ICT risk management. If classification and escalation are weak, incident reporting should come next. If outsourced dependencies are poorly understood, third-party risk and contract remediation may need to move ahead of broader testing.

ICT risk management is the foundation. Financial entities need a governance framework that assigns responsibility, identifies ICT assets and dependencies, classifies risks, protects systems, detects abnormal activity, responds to disruption, and learns from incidents. Existing ISO/IEC 27001, ISO 22301, ITIL, SOC reports, and internal control frameworks can help, but they do not automatically satisfy DORA. The regulation has distinct expectations around management body accountability, resilience testing, incident taxonomy, outsourcing oversight, and evidence of continuous improvement.

Incident reporting requires firms to classify and report major ICT-related incidents in a structured way. Under the DORA framework and the European Supervisory Authorities’ technical standards, classification considers factors such as affected clients, counterparties or transactions, service downtime, data losses, criticality of affected services, economic impact, geographical spread, and reputational impact. The reporting process is staged, typically covering an initial notification, intermediate reporting as the situation develops, and a final report once root cause and remediation are better understood.

A common implementation mistake is treating incident reporting as a template exercise owned only by security operations. In practice, the firm needs a shared taxonomy, decision criteria, escalation routes, legal review, communications input, and enough operational data to classify an incident quickly. During a payments outage, for example, a security team may know that a system is unavailable, but operations may hold the information needed to estimate affected transactions and customer impact.

Digital operational resilience testing ranges from vulnerability assessments and scenario-based testing to more advanced threat-led penetration testing. TLPT under DORA is not a routine vulnerability scan. For entities required to conduct it, the testing is scoped around critical or important functions, uses threat intelligence and realistic tactics, techniques, and procedures, and is commonly expected on a multi-year cycle, often every three years, subject to the applicable regulatory requirements and authority decisions.

This creates a capacity and planning issue. Qualified TLPT providers, internal purple-team participants, legal reviewers, business service owners, and third-party providers may all need to be coordinated. Firms that leave TLPT scoping until late often discover that contracts do not permit the level of testing required, or that a key vendor needs lengthy notice before any activity can touch production-like environments.

Third-party ICT risk management is another area where DORA is more demanding than many existing supplier processes. Firms need a register of contractual arrangements, risk-based due diligence, ongoing monitoring, exit planning, and contractual provisions covering security, availability, data location, access, audit, inspection, sub-outsourcing, incident notification, and cooperation with competent authorities where relevant. Contract renegotiation can take months, especially for large technology providers, so legal and procurement teams should be involved early.

Information sharing is the final pillar, but it should not be read as informal networking. DORA allows financial entities to exchange cyber threat information and intelligence within trusted communities, provided confidentiality, data protection, and competition considerations are respected. The operational value lies in turning intelligence into action: detection updates, supplier questions, risk reassessments, or scenario changes for testing.

A short vignette: when an outage becomes a DORA test

Consider a mid-sized payment institution that loses access to a customer-facing payment channel after a managed service platform experiences a configuration failure. The incident is not caused by a cyberattack, but the effect is similar for customers: failed transactions, delayed reconciliation, and rising call-centre volumes.

Under a DORA-ready operating model, the firm would not wait for a forensic conclusion before acting. It would classify the incident against its major ICT-related incident criteria, preserve decision logs, open communications with the provider, gather impact data from operations, notify the relevant authority if thresholds are met, and prepare updates as the incident develops. After service restoration, the final analysis would cover root cause, control weaknesses, contractual lessons, recovery performance, and any changes to monitoring, escalation, or exit planning.

The lesson is that DORA preparedness is tested during ordinary operational failures as much as during hostile attacks. The firms that respond well tend to have already rehearsed roles, evidence capture, supplier contacts, and reporting decisions before the incident begins.

A pragmatic 60–90 day starter plan

A short starter plan cannot deliver full compliance, but it can create momentum and reveal the areas that need deeper remediation. The first 60 to 90 days should focus on decisions, ownership, evidence, and dependencies rather than producing large volumes of documentation that no one uses.

The first priority is governance. The management body and senior owners should confirm how DORA accountability is assigned across risk, security, operations, compliance, legal, procurement, and business service ownership. They should agree which forums make resilience decisions, how issues are escalated, and how evidence will be maintained for supervisory review.

The second priority is mapping. Teams should identify critical or important functions and connect them to ICT assets, data, vendors, locations, recovery processes, and responsible owners. This does not need to be perfect on day one, but it must be good enough to support incident classification, testing scope, third-party risk decisions, and recovery planning.

The third priority is incident readiness. Firms should compare current incident categories with the DORA taxonomy and the ESAs’ reporting expectations, then update runbooks, escalation triggers, data collection steps, and communications pathways. A tabletop exercise using a realistic outage scenario can reveal gaps faster than a document review.

The fourth priority is contract and vendor review. Procurement and legal teams should identify ICT services supporting critical or important functions, then check whether agreements contain the rights and cooperation mechanisms needed for DORA: incident notification, audit and inspection, testing support, data access, sub-outsourcing transparency, and exit assistance. Where gaps exist, remediation should be prioritised by service criticality and renewal dates.

The fifth priority is testing and evidence. Firms should establish a forward testing plan, including which functions may require more advanced testing and whether TLPT could apply. Evidence should be lightweight but reliable: named control owners, approved runbooks, test results, remediation records, incident decision logs, supplier assurance files, and management reporting. The aim is to make supervisory conversations easier by showing how decisions were made and followed through.

Professionals who need a structured introduction can use a focused DORA Essentials course to align teams on the regulation’s core concepts before moving into entity-specific legal and implementation work.

Common implementation mistakes

One recurring mistake is treating DORA as a cybersecurity programme. Cybersecurity is central, but DORA reaches into operational continuity, outsourcing, governance, legal rights, incident reporting, testing, and board oversight. A security-only programme will usually miss contract clauses, business service mapping, regulatory reporting thresholds, or management body evidence.

Another mistake is reducing testing to vulnerability scanning. Vulnerability management is necessary, yet DORA’s testing expectations are broader and risk-based. For in-scope entities, TLPT requires careful scoping around critical or important functions and realistic threat scenarios. That work cannot be improvised after a regulator asks for a testing plan.

A third mistake is assuming vendor accountability transfers the risk. Outsourcing may transfer service delivery, but the financial entity remains responsible for managing the ICT risk arising from the arrangement. This is why DORA pays close attention to registers, due diligence, contractual rights, sub-outsourcing, concentration risk, and exit planning.

References to check against primary sources

Primary materials should guide implementation decisions. The most relevant sources are EU Regulation 2022/2554 on digital operational resilience for the financial sector, the European Supervisory Authorities’ regulatory and implementing technical standards under DORA, and TIBER-EU guidance for threat-led penetration testing where applicable.

Firms should also monitor communications from their national competent authority, because supervision, reporting channels, proportionality expectations, and practical filing arrangements may vary across member states. DORA is directly applicable EU regulation, but enforcement and supervisory engagement still happen through the relevant authorities and EU supervisory structures.

FAQ

What is DORA in simple terms?

DORA is an EU regulation that requires financial entities to prove they can withstand, respond to, and recover from serious ICT disruption. It covers governance, ICT risk management, incident reporting, resilience testing, third-party ICT risk, and information sharing.

When did DORA apply?

DORA applies from 17 Jan 2025. From that date, in-scope financial entities are expected to operate in line with the regulation and be able to evidence their approach to competent authorities.

Does DORA apply to ICT vendors outside the EU?

Non-EU vendors may be affected when they provide ICT services to EU financial entities. They may face DORA-driven contractual obligations around audit rights, incident cooperation, testing support, access, sub-outsourcing, data handling, and exit assistance. Designated critical ICT third-party providers may also come under EU-level oversight.

Is threat-led penetration testing required for every firm?

No. TLPT applies to in-scope entities identified under the DORA framework and relevant authority processes. Where required, it focuses on critical or important functions and uses realistic threat intelligence rather than a basic vulnerability scan.

Building resilience that can be evidenced

DORA rewards firms that can connect governance, operations, technology, vendors, and evidence into one working resilience model. Policies still matter, but supervisory confidence usually comes from clear ownership, tested runbooks, reliable incident decisions, realistic testing, and contracts that support oversight when a disruption occurs.

The most effective next step is to identify the firm’s critical or important functions, map the ICT dependencies behind them, and test whether incident reporting, supplier cooperation, and recovery evidence would stand up during a real disruption. Readynez can support that learning journey through focused DORA training, but the lasting value comes from embedding the regulation into day-to-day resilience decisions.