Does DORA Require DDoS Testing, and How Often?

DORA does not explicitly mandate standalone DDoS testing, and it prescribes no DDoS-specific schedule. What it requires is a risk-based digital operational resilience testing programme. For financial entities that depend on internet-facing services, a controlled DDoS simulation can provide direct evidence that availability protections perform as expected under attack.

That distinction decides how firms act on it. Read DORA as a DDoS mandate, and you test to satisfy a rule that was never written. Read it as silence, and you risk leaving out the scenario most likely to take the service down.

Here is what Articles 24, 25 and 26 actually say, which of them applies to you, and the testing frequency each one implies.

What DORA Actually Says – Articles 24, 25 and 26

The testing obligations in Regulation (EU) 2022/2554 sit across three articles, and they are not interchangeable.

Article 24 sets the general requirements: a sound, comprehensive, risk-based testing programme, tests carried out by independent parties – internal or external – and proportionality according to size and risk profile. It also sets the baseline cadence. Under Article 24(6), financial entities other than microenterprises test all ICT systems and applications supporting critical or important functions at least yearly.

Article 25 is the method list. It covers the test types a programme can draw on, including vulnerability assessments, network security assessments, scenario-based tests, performance testing, end-to-end testing and penetration testing. DDoS is not named among them — but two of them describe a DDoS simulation closely. Article 25 also carries its own provision for microenterprises, which are not exempt from testing as such.

Article 26 is the separate regime for advanced testing: threat-led penetration testing (TLPT) carried out against live production systems, at least every three years, by entities that a competent authority has identified for it.

Article	What it governs	Who it applies to	Cadence
24	The testing programme; independence; proportionality	In-scope entities. The yearly requirement and the independence requirement apply to entities other than microenterprises	At least yearly for systems supporting critical or important functions
25	The permitted test methods	In-scope entities, with a separate provision for microenterprises	As the programme defines
26	TLPT against live production	Only entities identified by a competent authority	At least every 3 years

The distinction matters. Article 25 lists testing methods for the broader resilience programme, while Article 26 establishes the separate TLPT regime. Being subject to DORA does not automatically mean an institution must perform TLPT – that depends on whether the competent authority has identified it for advanced testing.

How Often Does DORA Expect You to Test?

Before the frequency question can be answered, it helps to be precise about what DDoS testing means here: a controlled simulation against your own production or staging environment, run to observe how the mitigation behaves rather than to break the service.

Three clocks run at once, and only two of them are calendars.

The annual clock comes from Article 24(6) and covers every system supporting a critical or important function. For most financial entities, this is the clock that governs DDoS readiness, because availability is exactly what a DDoS attack removes.

The three-year clock comes from Article 26 and applies only to identified entities. It does not replace the annual requirement – a firm in TLPT scope still tests yearly under Article 24.

The third trigger is not a clock at all. DORA’s risk-based approach expects DDoS testing frequency to follow material change, not only the calendar. A protection stack that passed in March is an unverified stack in September if the topology moved in between. Measuring DDoS resilience once a year tells you what was true on the day of the test.

Annual is the floor. Risk sets the real frequency.

Which Article 25 Test Type Does a DDoS Test Fall Under?

A DDoS simulation is not a vulnerability assessment, and it is not a conventional penetration test. It maps to two of the Article 25 methods, and in some architectures a third.

It is a scenario-based test, because it reproduces a defined attack scenario rather than searching for unknown weaknesses. It is a performance test, because what it measures is behaviour under load: detection time, mitigation time, and whether legitimate traffic still gets through while the attack runs. Where the test crosses CDN, scrubbing, and origin in a single path, it also functions as an end-to-end test.

The classification helps define what the test should demonstrate. For a DDoS simulation, the evidence should connect the attack scenario to the expected protection behaviour, the observed impact on legitimate traffic, and any weaknesses identified. Unlike a conventional penetration test, the primary objective is to validate service availability under attack conditions.

Article 24(4) applies either way: for financial entities other than microenterprises, tests are undertaken by independent parties, internal or external. A DDoS resilience testing exercise run by the same team that configured the mitigation meets that only if the independence can be explained.

The classification also sets the limit of the claim. A DDoS test does not become TLPT because it ran against production — Article 26 carries its own requirements for scope, methodology, testers and authority involvement. What the test produces is a defensible record of a control working, which is a separate question from how to prove DDoS defences to a regulator.

Field example In one banking environment Red Button tested, AWS Shield Advanced was in place, but a Regional API Gateway sat outside the intended CloudFront path – leaving a route that bypassed the Layer 7 protection the bank believed it had. A controlled flood built from valid API requests reached the service and took it down. The protection had been bought and configured. It had never been validated across the full traffic path.

When Should You Retest After Infrastructure Changes?

The annual test describes the environment on the day it ran. The question worth asking is what has moved since.

Changes that reopen the question include replacing or adding a mitigation provider, moving between on-premises, cloud, and hybrid topology, a migration that exposes a new origin, a change to published address ranges or BGP announcements, and any new internet-facing service carrying a critical or important function.

DORA does not prescribe DDoS-specific retesting after these changes. Its risk-based testing requirements, however, make material infrastructure change an important reason to reassess earlier results. Article 11(6)(a) separately requires ICT business continuity plans and ICT response and recovery plans to be tested at least yearly, and again following any substantive change to ICT systems supporting critical or important functions.

For regulated entities, this is usually the practical argument against treating DORA compliance testing as a purely annual exercise, and for scoping DDoS testing for financial services around change events as well as the calendar.

Frequently Asked Questions

Is DDoS testing mandatory under DORA?

No. DORA does not name DDoS testing as a required test type. It requires a risk-based resilience testing programme and yearly testing of systems supporting critical or important functions. For availability-dependent services, a controlled DDoS simulation can provide direct evidence that availability controls perform as expected under attack conditions.

Does a DDoS test count as TLPT under Article 26?

Not automatically. Article 26 sets its own requirements for scope, methodology, testers, and competent-authority involvement. A DDoS simulation that does not meet them remains valid testing under Articles 24 and 25, but cannot be reported as advanced testing.

Should DDoS testing be repeated after cloud infrastructure changes?

Retesting is advisable when changes affect the attack surface, traffic path, or mitigation controls. A migration, a newly exposed origin, or a change to published address ranges can invalidate a result that was accurate weeks earlier.