Digital operational resilience testing stopped being a best practice and became a binding legal requirement across the EU financial sector on January 17, 2025. Deloitte surveyed the institutions actually subject to it. Just 8% called themselves fully compliant, the lowest score of any requirement in the regulation. Six findings on what the law actually demands, how far short most organizations sit, and what closing that gap really takes.

Resilience testing stopped being optional on January 17, 2025

DORA didn’t quietly add resilience testing as a recommendation buried in an appendix. It named the practice as one of the regulation’s core structural pillars, with its own compliance bar to clear.

The regulation entered into force for roughly 20 categories of financial entity

The European Insurance and Occupational Pensions Authority states plainly that DORA “entered into application on 17 Jan 2025” and is “applicable to 20 different types of financial entities and ICT third-party service providers.” That scope runs from banks and insurers to payment institutions, investment firms, and the critical ICT vendors those institutions depend on.

Resilience testing is listed among EIOPA’s own six named pillars of the regulation, described specifically as covering “basic and advanced testing.” That’s not vague guidance tucked into a preamble. It’s a named, structural requirement with its own compliance bar, sitting alongside ICT risk management and incident reporting as one of the regulation’s core pillars, not an optional add-on a security team can defer to next year’s budget cycle.

The other five pillars, ICT risk management, incident reporting, information sharing, third-party risk, and oversight of critical providers, all get their own dedicated compliance expectations too. Resilience testing is simply the one this piece is built around, because it’s the one the data below shows organizations are furthest from clearing.

Resilience testing isn’t a recommendation inside DORA. It’s a named, structural pillar.

“Basic and advanced” means two very different bars to clear

The basic tier covers standard vulnerability assessments and scenario-based testing that most mature engineering organizations already recognize in some form. The advanced tier is a different animal entirely, reserved for institutions whose functions are deemed critical or important, and it’s the tier the next signal is built around.

Both tiers fall under the same resilience testing pillar, and DORA doesn’t let an institution choose which one applies to it. Scope is determined by whether an institution’s functions are classified as critical or important, not by internal appetite for how rigorous its resilience testing program should be.

Only the basic tier is achievable with the kind of testing most engineering teams already run. The advanced tier is a different commitment entirely, and it’s the one the rest of this piece focuses on.

Only 8% of financial entities say they’re actually ready

Knowing resilience testing is now mandatory says nothing about how prepared the organizations subject to it actually are. Deloitte went and measured that directly.

A 36-entity survey found resilience testing as the weakest pillar of the entire regulation

Deloitte’s Wave 3 DORA survey, fielded in March 2025 across 36 financial entities in 28 European countries, with CISOs, CROs, and DORA program managers as respondents, found only 8% of surveyed entities describe themselves as fully compliant with Pillar III, Digital Operational Resilience Testing. Another 25% report their roadmap up to 75% complete, 46% sit at roughly the halfway point, and 17% are still at an early stage.

Pillar IV, ICT third-party risk management, scored the same 8%. Every other pillar in the regulation scored meaningfully higher, which makes resilience testing and third-party risk management the two clear laggards among institutions that, by their own account, have otherwise made real progress on DORA overall.

That pairing isn’t a coincidence. A meaningful share of what advanced resilience testing actually has to simulate is a critical third-party provider failing, which means the two hardest pillars in the survey are measuring closely related capability gaps rather than two unrelated problems.

The contrast with incident management makes the testing gap harder to explain away

The same survey found 48% of entities already fully compliant with Pillar II, ICT incident management and reporting, the highest score of any pillar Deloitte measured. That’s six times the completion rate resilience testing managed in the same survey, among the same 36 institutions, answering the same questionnaire.

Institutions that have clearly invested real effort into DORA compliance overall are still landing at single digits specifically on resilience testing. That’s not a story about organizations ignoring the regulation. It’s a story about one particular pillar being structurally harder to satisfy than the rest, and it lines up exactly with what the next signal explains about why.

Incident management, by comparison, maps onto capabilities most regulated financial institutions already had reasons to build well before DORA existed: logging, alerting, and reporting pipelines. Resilience testing at DORA’s advanced tier maps onto a capability far fewer institutions had any reason to build until the regulation made it mandatory.

The pillar regulators can now check in real time is the one furthest from done.

The advanced tier isn’t a test, it’s a live red-team operation

Understanding why resilience testing lags starts with understanding what the advanced tier of it actually requires, because “testing” undersells what DORA means by it.

Once the notification lands, every deadline that follows is fixed.

Threat-Led Penetration Testing runs on the European Central Bank’s own red-team framework

For institutions identified as critical or important, DORA’s Article 26 requires Threat-Led Penetration Testing, TLPT, at least once every three years. The European Central Bank’s own TIBER-EU framework, described as “a European framework for threat intelligence-based ethical red-teaming,” was updated specifically for “full alignment with the Regulatory Technical Standards on threat-led penetration testing… of DORA,” and the ECB now positions it as the accepted way to help satisfy those requirements.

TIBER-EU tests don’t produce a pass or fail. They mimic “the tactics, techniques and procedures of real-life threat actors” against an institution’s actual critical functions, with most of the institution’s own defenders kept unaware the test is running.

That design choice is deliberate, and it’s what separates TLPT from the resilience testing most engineering teams are used to. A scheduled game day where the on-call team knows a failure is coming measures something real, but it doesn’t measure whether a defensive team can actually detect and respond to a threat it doesn’t know to expect. TLPT measures exactly that, on an institution’s live production estate, which is a materially higher bar than any internally-run resilience testing program most teams have built.

The process runs on fixed deadlines once an entity is notified

The regulation’s own published timeline shows a five-phase process modeled directly on TIBER-EU: initiation information due within three months of notification, a scope specification document due within six months, a minimum twelve-week active red-team testing phase, and a final remediation report due within eight weeks of the whole exercise closing. External testers are mandatory for the threat intelligence phase on every cycle, and institutions classified as significant credit institutions must use external testers for the red-team phase entirely, every time.

That’s a specialized, deadline-driven engagement, not a checklist a general security team runs internally alongside its regular sprint work. Every one of those deadlines is fixed the moment a competent authority sends its notification, which means an institution that waits until notification to start building resilience testing capability is already behind before the clock even starts.

Generic resilience testing tooling wasn’t built for this bar

Most organizations already running some form of resilience testing are running the kind DORA’s advanced tier explicitly doesn’t count.

The default practice targets infrastructure, not adversarial scenarios

A 2026 academic study mining GitHub for chaos and resilience testing tool adoption found network faults and dead-instance simulation accounted for roughly three-quarters of all fault-injection activity across validated repositories, while faults at the application-logic level, closer to what a genuine adversary or a failed third-party provider would actually trigger, accounted for barely 1 in 40. Deloitte’s own survey found 25% of respondents specifically named testing business continuity plans against scenarios like third-party provider insolvency or political risk as among DORA’s hardest requirements to satisfy.

Those two findings describe the same gap from opposite directions: the resilience testing most teams already do is aimed at a different failure mode than the one the regulation is actually worried about. Killing a pod or dropping a network link tells a team little about whether it can detect a critical vendor quietly failing, or an adversary moving laterally through a system nobody flagged as a likely entry point.

Neither failure mode is hypothetical for a financial institution specifically. Both sit squarely inside what DORA’s advanced resilience testing tier exists to surface before a regulator, or an actual attacker, finds it first.

The default testing practice and the regulation’s actual concern point in different directions.

TLPT specifically requires expertise most internal platform teams don’t carry

DORA’s own rules require accredited external threat-intelligence and red-team providers for the advanced tier, not internal engineers running an open-source fault-injection tool against a staging environment. That’s a deliberate design choice in the regulation, not an oversight: the skill set involved, adversary emulation against live, critical financial infrastructure, is narrow enough that even large institutions are expected to bring in outside specialists for it.

An internal platform or SRE team can be excellent at the kind of resilience testing that covers uptime, failover, and recovery time objectives, and still have nobody on staff who has run an accredited, adversary-emulation engagement against a live financial system. Those are adjacent skills, not the same skill, and DORA’s rules are written around that distinction rather than around the assumption that a strong internal engineering culture is sufficient on its own.

Missing the window carries real financial exposure

None of this compliance gap is free to leave unresolved. DORA built enforcement into the regulation from the start, and 2026 is the year that enforcement stopped being theoretical.

The penalty structure escalates fastest for the third parties institutions depend on

DORA’s Article 50 leaves general penalty amounts to national law, so there’s no single EU-wide fine for a financial entity itself. Article 35 is more specific: designated critical ICT third-party providers face periodic penalty payments of up to 1% of their average daily worldwide turnover for continued non-compliance, a figure that compounds the longer a gap stays open.

For a large ICT provider, a daily penalty pegged to worldwide turnover adds up fast, which is exactly the design intent. The regulation isn’t structured as a one-time fine an institution can budget for and absorb. It’s structured to make an unresolved resilience testing gap more expensive with every day it stays unresolved.

A penalty that compounds daily changes the urgency math considerably.

2026 marks the shift from paperwork review to real-time evidence

The regulation’s own tracking site describes 2026 supervisors moving from “reviewing documentation to demanding real-time evidence of resilience,” using “automated tools that cross-reference ICT registers across the EU” that flag inconsistencies immediately rather than at the next audit cycle. A resilience testing program that exists mostly on paper is exactly what that shift is designed to catch. Documentation that described a credible roadmap in 2025 doesn’t hold up the same way in 2026, once the expectation is a live, demonstrable program rather than a plan still being executed.

The cost and timeline are already public knowledge

Every organization weighing how urgently to close this gap can see roughly what closing it costs, because the institutions already doing it have been transparent about their own numbers.

The first deadline on this chart has already come and gone.

Most institutions are budgeting millions, not thousands

Deloitte’s same survey found 96% of respondents already have a cost estimate for full DORA compliance, with 64% landing between €2 million and €5 million and another 8% above that range. Only 17% still have no estimate at all, which itself says something about how far the rest of the market has already moved past the planning stage. A resilience testing budget in the millions is now a known, published quantity across the sector, not a number an institution has to derive from scratch.

Half the market expected to be done by the end of 2025, and clearly wasn’t

Fifty percent of surveyed entities expected full compliance by the end of 2025, a deadline that has now passed. Another 38% pushed their target into 2026, and the remaining 12% pushed past that entirely. Set against resilience testing’s 8% completion rate specifically, a meaningful share of that first 50% almost certainly missed their own target on this pillar even where they hit it elsewhere. An institution can be honestly compliant on five of DORA’s six pillars and still be exposed on the one regulators are now positioned to check for in real time.

What actually closes the resilience testing gap

Six findings, one consistent shape: resilience testing is the pillar DORA treats as most demanding, the one Deloitte’s own data shows organizations are furthest from finishing, and the one that specifically requires expertise, accredited external threat-intelligence and red-team providers, that most institutions don’t carry in-house by design. None of that is likely to change on its own between now and an institution’s next TLPT notification.

That combination makes this less a tooling gap and more a capacity gap. An institution can adopt every open-source fault-injection framework available and still not satisfy TLPT, because the regulation explicitly wants outside, accredited specialists running the advanced tier, not an internal team marking its own homework. Buying another resilience testing platform doesn’t solve a problem that was never about tooling in the first place. 

For institutions and the vendors serving them whose resilience testing roadmap is stalled specifically because that external expertise is hard to source on a three-year cycle, IT Outsourcing and Nearshore exist to add exactly that kind of specialized capacity without a permanent search. Landskill’s own Developer Productivity piece and OpenTelemetry piece both touch the same observability foundations a real resilience testing program depends on. Get in touch to talk through where your own resilience testing roadmap actually stands against DORA’s bar.