DORA DDoS Testing: What the Regulation Actually Requires
DORA has been in force since January 2025, and a good deal of what is sold against it is aimed at an obligation most firms do not have. This sets out where availability testing genuinely fits, where it does not, and what evidence a supervisor is likely to want.
The distinction most of this market blurs
DORA contains two testing obligations that are routinely spoken about as one. Article 26 requires threat-led penetration testing, an intelligence-led red-team exercise against live production systems, scoped with your competent authority, at least every three years. It applies to entities whose failure could destabilise the EU financial system, and they are told by their authority that they are in scope. The technical standards governing it only became applicable in July 2025.
Articles 24 and 25 are the ones that apply to everyone in scope: a testing programme, with systems supporting critical or important functions tested at least annually, drawing on a range of test types rather than a single one.
A DDoS test belongs to the second, not the first. It is not TLPT, it does not satisfy Article 26, and any vendor implying otherwise is either confused or selling you an exercise you may not be required to buy. What it does contribute is the answer to a question no vulnerability scan or code review reaches: whether the service stays available when the traffic arriving at it is hostile.
Where the obligations sit
Articles 24 and 25
Every financial entity in scope
A digital operational resilience testing programme, with ICT systems supporting critical or important functions tested at least once a year. The regulation deliberately does not give an exhaustive list of test types: vulnerability assessments, network security testing, penetration testing and scenario-based testing are all named as examples rather than a menu to pick one from.
This is where availability testing sits for the overwhelming majority of firms. A DDoS test answers a question the other test types do not: whether the service stays reachable when traffic turns hostile.
Article 26
Systemically important entities only, identified by their competent authority
Threat-led penetration testing at least every three years, covering several or all critical or important functions, carried out on live production systems, with scope approved by the authority. The regulatory technical standards supplementing it only became applicable in July 2025.
TLPT is a red-team exercise built on threat intelligence about a specific adversary. It is not a DDoS test and a DDoS test does not satisfy it. If a vendor tells you their DDoS simulation makes you Article 26 compliant, that is a reason to ask harder questions.
Article 28 and onward
Entities relying on critical ICT third parties
Obligations around third-party risk, including the ability to include a provider in testing where they support a critical function, and to take the measures needed to secure their participation.
Relevant in practice because most availability now depends on someone else: a CDN, a scrubbing provider, a cloud platform. A test scoped only to what you host misses the parts of the path you do not own.
Common questions
Does DORA require DDoS testing specifically?
Not by name. DORA requires a testing programme covering ICT systems that support critical or important functions, and it lists test types as examples rather than a closed set. Availability under adversarial load is squarely within what that programme is meant to establish, which is why DDoS testing is a normal component of it. A firm that tests for vulnerabilities and never tests whether the service stays reachable has a gap it will struggle to defend.
Is a DDoS test the same as threat-led penetration testing?
No, and the distinction matters commercially as well as legally. TLPT under Article 26 is an intelligence-led red-team exercise against live production systems, scoped with your competent authority, required of systemically important entities every three years. A DDoS test measures how defences behave under hostile traffic volume and shape. They answer different questions, they are procured differently, and one does not substitute for the other. Most firms in scope of DORA are not subject to TLPT at all.
Who is actually in scope for DORA?
It applies broadly across EU financial entities: credit institutions, payment and e-money institutions, investment firms, insurers and intermediaries, crypto-asset service providers, trading venues and others, plus designated critical ICT third-party providers. Scope for the Article 26 TLPT obligation is much narrower and is determined by your competent authority rather than self-assessed.
We are a UK firm. Does DORA apply to us?
DORA is EU law, so it does not apply to UK-only operations. It can reach a UK group through EU-authorised subsidiaries or branches, and through provision of critical ICT services into EU entities. The UK runs its own operational resilience regime under the FCA and PRA, with impact tolerances and severe-but-plausible scenario testing, and CBEST as the Bank of England threat-led testing framework. The testing work overlaps heavily even where the legal instruments do not.
Can a DDoS test be run against production without causing an outage?
It has to be designed for it, and DORA itself assumes production is where meaningful testing happens: Article 26 requires TLPT on live production systems. For availability testing the controls are scoping, agreed windows, staged rates with defined abort thresholds, and a named person on both sides who can stop the test. The point of a controlled test is to find the limit before an attacker does, not to demonstrate it by crossing it.
What evidence should we come away with?
Something an auditor and an engineer can both use: what was in scope and why, the vectors exercised, the rates reached, where mitigation engaged and what it let through, what failed first, the remediation in priority order, and a retest showing the fix held. A result that cannot be handed to an engineer as a work list is not finished, and one that cannot be handed to a supervisor as evidence has not done its regulatory job.
Testing that produces evidence
We are an independent testing company, tied to no mitigation vendor. Our method is simultaneous multi-vector testing that adapts in real time to your defences rather than replaying a script, which is Patent-Pending, and the output is built to serve two readers: an engineer who has to fix something, and a supervisor who has to see that you looked.
This page describes our reading of the regulation as at August 2026 and is not legal advice. Scope, and in particular whether Article 26 applies to you, is a matter for your competent authority and your own counsel.