DORA and Digital Operational Resilience Testing – Does your testing prove you can withstand a real attack on a critical service

In our previous DORA blog article, we covered classifying and reporting an incident once it happens. This blog article looks at the requirement built to reduce how often an incident occurs, proving, before an attacker does, that a critical service can withstand one.

Most financial services firms already run a testing programme. Vulnerability scans happen on a schedule. Penetration tests get commissioned, findings get logged, and a report gets filed somewhere a board member could locate it if asked. On paper, that looks like compliance. Under DORA, it is not.

A distinction worth making immediately, because it shapes everything that follows: DORA requires basic resilience testing of critical and important functions from every in-scope firm. Threat-led penetration testing (TLPT) is a separate, additional obligation that applies only to a targeted set of larger and more systemically important entities, identified by their competent authority.

NOTE: If you are a smaller regulated firm reading this, the testing obligations below still apply to you; the TLPT-specific sections further down may not, unless your authority has told you otherwise.

DORA’s testing regime is built on a different question to the one most testing programmes answer. It does not ask whether you tested something. It asks whether your testing demonstrates that a critical or important function can withstand a realistic attack, and for the firms in scope for the highest tier, whether an independent, authorised attacker has actually tried to break it under conditions that mimic a genuine adversary.

This is a materially higher standard than an annual scan and a penetration test tucked into a compliance folder.

Testing already happens, and happens well

So let’s start with what is working, because it is most of the picture. Financial Services firms have run vulnerability management and penetration testing for years, often to a higher standard than many other regulated sectors. Annual and quarterly scanning cadences are common. External penetration testing against internet-facing infrastructure is standard practice, and many firms already run it more frequently than any regulation requires. Security teams in this sector are not short of testing experience, testing tooling, or testing discipline.

That maturity is real, and it matters. It means the foundation DORA is building on, a technically capable, well-resourced security testing function, is already in place across most of the sector. The gap is not in the testing itself. It is in what the testing is aimed at, how it is structured, and what happens with the result.

DORA tests the business service, not the system

Most existing penetration testing programmes are scoped around infrastructure. An external perimeter, a set of applications, a network segment. That scoping makes sense operationally, but it answers a narrower question than DORA is asking. DORA’s testing framework is explicitly structured around critical and important business functions, the actual services the entity delivers, and the ICT systems that support them end to end, including the third parties involved in delivering them.

This distinction is not superficial. A penetration test that confirms a payment gateway’s external interface is well defended tells you very little about whether the payment service as a whole would survive a coordinated attack that also touches a cloud provider’s authentication layer, an outsourced settlement process, and an internal system nobody thought to scope in. Scenario-based testing – tabletop exercises and live simulations that follow a business service through a plausible failure chain, rather than testing a system in isolation, is a specific DORA requirement precisely because infrastructure-scoped testing misses this.

Then there is TLPT which sits in a different category altogether. TLPT is not a bigger penetration test. It is a live, red-team-style exercise conducted against live production systems, built around real threat intelligence about the actors most likely to target the entity, and run under a formal methodology (in the EU, TIBER-EU) that requires coordination with the entity’s competent authority throughout. For firms in scope, this is required at least every three years, and it requires a level of internal governance, legal preparation and stakeholder buy-in that most organisations have never had to build, because nothing in their existing testing programme has ever demanded it.

The honest complication for most security leaders reading this is your current programme is probably testing the right systems well. It may not be testing the right services at all, and if TLPT applies to you, it is very unlikely to already be structured for it.

So what does this actually mean?

If you run a strong vulnerability and penetration testing function already, the natural instinct is to treat DORA testing as a scope extension, test a few more things, a little more often. That instinct will leave gaps in three specific places which we highlight below:

Remediation evidence – DORA does not just want a list of findings. It wants demonstrable closure. Evidence that every finding was actually resolved, by whom, and by when, tracked with the same discipline as the testing itself. A penetration test report with an unclosed high-severity finding from eighteen months ago is not a testing gap under DORA. It is a governance gap, and it is one of the first things a supervisor will ask to see.

Co-ordination – If threat-led penetration testing applies to your organisation, it cannot be run the way a standard penetration test is commissioned – scoped internally, executed, and reported. TLPT requires engagement with your competent authority before testing begins, a threat intelligence provider to build the scenario, a specialist testing provider accredited to run it, and internal stakeholders – legal, operations, the board, briefed on what a live attack against production systems actually means in practice. None of that exists in a standard testing budget or timeline, and building it under time pressure, close to a deadline, is where firms lose control of the process.

Business service framing – If your testing programme cannot currently produce a mapped inventory of critical and important functions with the ICT systems and third parties that support each one, you cannot yet scope scenario-based testing correctly. Because you do not yet know what a realistic failure chain for that service looks like. This is a dependency most firms do not realise their testing programme has until they try to build a test plan against it.

Where should the focused priorities be

From our experience at Cyberfort when we surface the gaps above, we recommend a four step sequence, so testing is built outward from the business, not inward from the infrastructure you already know how to test.

How do you know if your resilience testing is effective

Testing generates a lot of activity. From our experience at Cyberfort we believe the following measures tell you whether the activity you are undertaking is reducing risk, not just producing reports.

Finding closure rate within agreed remediation deadlines – This is the single clearest signal of whether testing changes anything. A programme that generates findings faster than it closes them is not building resilience, it is building a backlog. Aim for the large majority of findings – vulnerability, penetration test and scenario-based alike, closed within the deadline originally agreed for each severity level.

Time to close critical and high-severity findings specifically – Averages hide the risk that matters most. A programme can look healthy overall while a critical finding on a payment system sits open for months. Track this separately, and aim for critical findings closed in days, not the weeks or months that a blended average might allow.

Proportion of critical and important functions covered by scenario-based testing in the last cycle – This tells you whether your testing programme has actually been reframed around business services, or whether it is still infrastructure-scoped with a new label. Full coverage of the mapped critical function inventory is the target; a partial programme signals scoping work still to do.

Recurrence rate of previously closed findings – A finding that reappears after being marked closed means the fix did not address the underlying cause. This matters more than raw finding volume, because it tells you whether remediation is real or cosmetic. Aim for this to be close to zero, any meaningful recurrence rate is worth investigating on its own.

TLPT and rehearsal governance readiness, if in scope – This is less a number and more a status check. Is your competent authority relationship established, is your threat intelligence input current, and has your board actually been briefed on what the exercise involves. Readiness here should be continuous, not built in the months before the test is due. A programme that starts governance work only when the three-year deadline approaches is already behind.

DORA itself does not prescribe numeric thresholds for any of the measures above; there is no rule stating a specific closure percentage or a specific number of days. The benchmarks here are directional good-practice targets, reflecting what a mature testing programme should be capable of, not figures lifted from a named regulatory standard or study. Set your own thresholds against your risk appetite and the criticality of the function in question and expect a critical payment or settlement service to warrant a tighter target than a lower-tier internal system.

Where you may need further support

Two areas consistently sit beyond what an internal team can build alone, whatever its testing maturity.

The first is threat-led penetration testing itself. Working with an accredited testing provider brings you the outcome that matters. A scenario built on threat intelligence current enough to be credible, and a testing process that has already navigated the competent authority coordination process, rather than one your team is assembling for the first time under deadline pressure, with the governance risk that carries.

The second is business function mapping done to the standard that scenario-based testing needs. The outcome here is a genuine, evidenced understanding of which ICT systems and third parties sit behind a specific critical service, and how a failure would propagate through it, not a list of applications with a criticality label attached. Getting this right is what determines whether everything that follows in the testing programme tests the right thing at all, and it is a different discipline to running the test itself.

A useful first move costs nothing but honesty. Take your current testing calendar and, service by service, ask whether it was built around what the business actually delivers or around the systems your team happens to own. For most firms, that single exercise will surface the gap faster than any external assessment could.

The sequence from there matters. Mapping before testing, testing before remediation evidence, remediation evidence before TLPT governance. Each step makes the next one meaningful, and skipping ahead tends to produce activity without proof. Building that sequence properly, before a supervisor or a real incident forces the pace, is the difference between a testing programme that demonstrates resilience and one that only demonstrates effort.