DORA and DDoS Resilience Testing for EU Financial Entities

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act, DORA — is a regulation rather than a directive. That single structural fact does more work than most summaries give it credit for. There is no transposing statute standing between the European text and the entity: the words that bind a bank in one member state bind an investment firm in another, without a national legislature in between reinterpreting them. For anyone who has tried to run a DDoS defence programme across several European subsidiaries under NIS2, where scope, reporting recipient and supervisory practice all vary nationally, this is a substantive simplification.

DORA also never mentions denial-of-service attacks. Like every modern resilience regime it is written at the level of outcomes and processes, not at the level of packet rates. What it does contain is a set of duties — around ICT risk management, resilience testing, incident classification and reporting, and above all the governance of ICT third parties — that have sharp and specific consequences for how an availability defence must be built, tested and evidenced.

This guide performs that translation. It deliberately avoids article-by-article citation, partly because the technical detail is elaborated in instruments the European Supervisory Authorities maintain and update, and partly because clause-level recitation reliably produces a compliance document that no engineer ever opens. The parts of DORA that change engineering decisions are thematic. Our companion translation of NIS2’s duties into DDoS architecture covers the general regime; this one covers the financial-sector rules that sit alongside it, and concentrates on the place where DORA is genuinely distinctive rather than merely more specific.

A regulation, not a directive — and what that changes operationally

The practical differences are three, and they are all about evidence rather than about architecture.

The reference text is stable across the Union. A group operating in five member states runs one interpretation of the resilience-testing duty, not five. Where variation remains it is supervisory rather than legislative: competent authorities differ in what they ask for and how often. That is a programme-management difference, not a design difference.

Sectoral rules stack rather than replace. A financial entity does not stop being subject to national cybersecurity law, to data protection law, to payment-services supervision or to its own prudential regime because DORA applies. The engineering consequence is that a single DDoS event can trigger more than one notification obligation on more than one clock. An entity that runs three independent incident processes will discover them colliding during its first significant event; the workable design is one internal trigger that fans out to whichever notifications apply.

Proportionality is built in, but it is your proportionality to justify. DORA scales its expectations to the size, risk profile and complexity of the entity. That is not a discount counter. It means the entity chooses the level, and the choice is the thing that has to be defensible.

Where DDoS sits in DORA’s structure

Strip the regulation down to what bears on availability under deliberate attack and four themes carry all the weight.

ICT risk management. Financial entities must have an internal governance and control framework for ICT risk, with the management body carrying ultimate responsibility for it. Availability of the services an entity provides is not a subsidiary concern within that framework; for a firm whose customer channel, market connectivity or payment interface is reachable over the internet, it is one of the principal ways ICT risk actually materialises.

Digital operational resilience testing. Entities must establish and maintain a testing programme covering the ICT systems supporting critical or important functions, with tests carried out by suitably independent parties and findings addressed. There is a second, more demanding level of advanced testing based on threat-led penetration testing, applied to entities identified by their authorities. Both levels are examined below, because DDoS fits them unevenly.

ICT-related incident management, classification and reporting. Entities detect, manage and classify incidents; those classified as major are reported to the competent authority through a staged process — an initial notification, intermediate reporting as the picture develops, and a final report.

ICT third-party risk. This is the theme where DORA is genuinely distinctive, and it is treated at length below.

A fifth theme, arrangements for sharing cyber threat information among financial entities, sits slightly outside the DDoS question but is worth knowing exists.

Underneath all four sits one concept that determines how much of the regulation applies to any given system: the critical or important function. Almost every heightened expectation in DORA — contractual content, testing scope, exit strategies — attaches to functions in that category. Deciding which of your functions qualify is therefore not a paperwork step preceding the real work; it is the step that determines what the real work is.

Translating the themes into DDoS engineering questions

The mapping below is not a compliance checklist in the regulatory sense. It is the set of engineering questions each theme forces, and the artefact that answers each one.

DORA theme	The DDoS question it forces	What “done” looks like
ICT risk management	Where is the ceiling of our own defence, and who accepted the residual risk?	Plausible attack volume compared against access-circuit capacity, the gap named, and a decision recorded at management level
Resilience testing	How do we know the diversion trigger, the fail-back and the thresholds work?	Measured outcomes from controlled exercises, with findings, owners and closure evidence
Incident classification	Is this attack a major incident, and who decides while it is running?	Written classification criteria expressed in observable service metrics, applied by a named, reachable person
Incident reporting	Can we produce the forensic detail the staged reports require?	Attack telemetry the entity itself holds, with a known retention window and a tested export path
Third-party risk	What does this provider actually do for us, and what happens if it stops?	A register entry, a concentration assessment and a documented, executable exit strategy

The first row is where regulatory language and network physics meet most directly. No on-premise device can filter traffic that has already saturated the circuit delivering it; above that line, only capacity closer to the source helps. A risk assessment that does not state where that line sits for your organisation has not assessed the risk — it has described a product. Our comparison of cloud, on-premise and hybrid architectures works through the trade-off in detail.

What a DDoS resilience test programme should actually contain

Most DDoS “tests” commissioned by financial entities are volumetric floods run against a staging environment in a Sunday-night maintenance window. They generate a certificate and almost no information. The four tests below generate information, and each maps onto a question a supervisor or an internal audit function can reasonably ask.

Diversion and fail-back, timed end to end

The diversion trigger is the most-documented and least-exercised component in a two-tier architecture. The measurement that matters is not “did the upstream provider mitigate” but the full elapsed sequence: attack onset, detection, decision, signal, provider action, routing convergence, return-path establishment, and the point at which legitimate traffic is demonstrably being served through the scrubbed path.

Then time the other half. Fail-back — returning traffic to the normal path once the attack subsides — is where the second outage of the day happens, and it is routinely absent from continuity plans that stop at the diversion trigger. A defensible test records four numbers: time to divert, service impact during diversion, time to fail back, and service impact during fail-back. Two supporting properties belong in the same exercise. The escalation path must not traverse the circuit under attack, because a procedure that depends on the saturated link is not a procedure. And an independent trigger must exist on the upstream side, because when the circuit fills completely the entity may be unable to send the signal at all.

State exhaustion while the circuit is healthy

This is the test almost nobody runs, and it is the one that most often changes a design.

Construct an attack that stays comfortably below access-circuit capacity — a fraction of it — but is engineered to consume session state: high connection-establishment rates, half-open connections, connections opened and held, TLS handshakes abandoned at the expensive moment, long-lived requests trickled out slowly. Then watch the stateful devices in the path: the firewall, the load balancer, the TLS terminator, the API gateway, the application servers’ own connection pools.

The reason this test is diagnostic is that it separates two failure modes that volumetric testing conflates. A volumetric test tells you about your circuit and your upstream provider. A state-exhaustion test tells you whether your perimeter falls over long before your circuit does — and in financial estates, with their layered inspection stacks and their session-heavy authenticated traffic, it very often does. An entity that has only ever tested volumetrically has evidence about the failure mode it is least likely to meet first.

Record the point at which each device’s session table, connection rate limit or CPU budget becomes the binding constraint, and express it as a fraction of circuit capacity. That single ratio is the most useful line in a DDoS test report, and it is the one that tells you whether your upstream contract is protecting anything that was actually going to fail.

False-positive rate at business peak

Mitigation that is never wrong is mitigation that is never aggressive enough. The question is not whether a defence produces false positives but how many, against which traffic, and at what moment.

Testing at 02:00 answers none of that. At 02:00 there is no legitimate traffic for the mitigation to misclassify, so the measured false-positive rate is a number about an empty network. The measurement a financial entity needs is taken against a traffic profile that resembles the business peak: market open, the payment cut-off, salary day, the settlement window, the hour before a card scheme’s processing deadline. Whether you reach that profile by replaying captured production traffic, by generating synthetic load matched to a real peak, or by running the exercise during a controlled live window is an engineering choice; not reaching it at all is a gap in the evidence.

Two refinements make the result usable. First, measure at percentiles rather than averages — a mean latency figure and a mean rejection rate both conceal exactly the tail behaviour that determines whether a payment fails. Second, measure per business flow rather than in aggregate, because losing one per cent of general web traffic and losing one per cent of authentication attempts are not the same event.

There is a structural point underneath this that bears on architecture. Two mitigation layers in series accumulate false positives: a single false positive in either layer is sufficient to block legitimate traffic. That is the intrinsic cost of layer count, and the design answer is to make the two layers independently tunable — conservative, volumetric thresholds upstream, fine-grained decisions taken by the layer that understands the application.

The log pipeline under an event storm

The fourth test is the one that connects resilience testing to incident reporting, and it is almost always missing.

A single attack packet does not produce a single log line. It produces a flow record at the edge router, a deny log at the firewall, a signature alert at the IPS, a rule block at the WAF and an error entry at the application. Multiply by attack rate and the logging infrastructure — collectors, forwarders, message bus, indexing tier, the SIEM itself — meets a load profile it was never sized for.

What fails is rarely dramatic and almost always damaging. Collectors begin sampling. Queues back up and forwarders drop. Indexing falls behind, so the data exists but is not searchable during the incident. Retention policies designed around steady-state volume roll the window forward faster than expected, and the earliest hours of the event — the part that establishes onset and therefore the timeline — age out first.

The test is straightforward to specify: generate the event rate an attack would generate, then verify that the pipeline neither drops nor samples, that events remain searchable throughout, and that an incident export covering the whole event can still be produced afterwards. Two questions from the same exercise deserve their own answers. Is the clock synchronised across every source you would reconstruct a timeline from? And if mitigation happens entirely in a provider’s scrubbing centres, who holds the packet-level or request-level evidence, in what format, on whose export schedule?

This is also the clearest illustration of why absorbing an attack at your own perimeter is a reporting property and not only an availability one. Downstream devices never log what never arrives.

Threat-led testing, and where DDoS fits awkwardly

DORA’s advanced testing regime is threat-led: intelligence-driven red-team engagement against live production systems, conducted by testers meeting defined requirements, for entities identified by their authorities. It is a powerful instrument, and denial-of-service fits it badly.

The mismatch is practical rather than legal. A genuine volumetric flood against production infrastructure is a blunt instrument that a red team cannot control at the boundaries, that affects shared upstream infrastructure belonging to other parties, and that produces a small amount of information at a high risk. The consequence is not that availability under attack escapes testing. It is that most of it belongs on a separate track — the general testing programme, run as controlled exercises with the four tests above, coordinated with the upstream provider and contractually authorised.

Where the two tracks genuinely meet is at the seam: application-layer and API attacks engineered to stay below volumetric thresholds. Browser-grade requests, plausible session behaviour, traffic aimed at authentication, payment initiation or account-enumeration endpoints. These are within a red team’s reach, they are the vectors financial entities actually meet, and they are invisible to detection logic tuned to bandwidth saturation. Specifying them into a threat-led engagement is one of the few ways to obtain evidence about low-volume availability attacks against production.

ICT third-party risk: where DORA is genuinely distinctive

Everything so far has a rough analogue in other regimes. This does not.

DORA builds an explicit framework around ICT third-party service providers. Financial entities maintain a register of information on their contractual arrangements for the use of ICT services. Arrangements supporting critical or important functions carry heightened contractual expectations — service descriptions and locations, service levels, access, inspection and audit rights, assistance during incidents, termination rights and exit provisions. Entities assess, before entering into an arrangement and on an ongoing basis, whether the arrangement concerns a critical or important function and what risk it carries, including concentration risk. And there is a Union-level oversight framework for providers designated as critical, with a lead overseer drawn from the European Supervisory Authorities.

Read that list against how DDoS mitigation is typically bought and three uncomfortable observations follow.

It is a third-party service sitting in the traffic path. Unlike most controls, upstream mitigation is not something you operate; it is something a provider does to your traffic before you see it. The provider decides what is dropped. The provider holds the record of what was dropped. During an incident, your visibility into your own service is mediated by their platform.

Availability defence usually supports critical or important functions by definition. If a function is critical or important and it is reached over the internet, the control keeping it reachable is difficult to place anywhere else.

The register makes dependency visible in a way architecture diagrams do not. An entity that lists its providers, the functions each supports, and the criticality of each will frequently discover something a diagram had concealed for years.

Concentration risk and the single-vendor two-tier architecture

Here is the specific concentration finding that DDoS architectures produce, and it is the reason this regulation is worth an article of its own.

The mature architecture is two-tier: upstream scrubbing capacity that can absorb what would otherwise saturate the access circuit, and an on-premise layer that sees session state and application behaviour at line rate. This is correct, and it is what most financial entities build. The procurement reflex, however, is to source both tiers from one manufacturer, or to take the carrier’s platform upstream and buy the same family for the edge. Integration is easier, there is one support contact, there is a bundle discount.

What that buys is two tiers sharing a codebase, a detection logic, usually a management plane, and one commercial relationship — a defence that looks like two layers and behaves like a single failure cause deployed twice.

Reliability engineering has called this common-mode failure for decades: if two components share a failure cause, the probability of both failing is not meaningfully lower than the probability of either failing alone. What DORA adds is not a new engineering insight but an obligation to look. Concentration risk is a named category that has to be assessed, and the register is the instrument that surfaces it. An entity that records “both tiers of our availability defence for a critical function depend on one provider” and acts on it is doing exactly what the regulation asks.

Two cautions keep this argument honest. DORA does not mandate a multi-vendor DDoS architecture, and any rationale claiming that it does will not survive audit. And vendor diversity is not free: two layers in series accumulate false positives, two contracts create operational load, and the diversion trigger and return path require real design work. Our executive assessment of sourcing the two tiers from different manufacturers develops both sides properly. What DORA supplies is the vocabulary and the obligation to reach a documented conclusion — not the conclusion itself.

Exit strategies for a control that sits in the traffic path

The exit-strategy duty is where the third-party regime turns from documentation into engineering, and it is the part financial entities most often satisfy on paper only.

For arrangements supporting critical or important functions, an entity must have exit strategies capable of being executed without disruption to its business activities and without prejudice to regulatory compliance. Applied to a control that intercepts traffic before the entity sees it, this is a demanding requirement, and the honest test of an exit strategy is not whether the document exists but whether anyone has costed the transition in weeks.

A DDoS exit strategy that would survive scrutiny contains at least the following. An identified alternative, with the realistic lead time to procure, install and tune it — for inline equipment that is months, not weeks. The routing and signalling changes required to move: BGP sessions, prefix advertisement and community schemes, return-path tunnels, and the addressing constraints that govern them, since most carriers will not accept advertisements of prefixes below a certain size and that constraint shapes what diversion is even possible. The configuration and telemetry you would need to take with you, and the export format you can obtain it in — attack history, tuned thresholds, application baselines and traffic profiles represent years of accumulated tuning, and their portability is a contractual question that must be answered before signature rather than during termination. The interim posture: what you run on during the transition, and whether it is adequate for the function’s criticality. And a tested statement of what continues to work with no vendor reachback at all.

That last item is where the architecture answers back. A layer whose detection engine runs entirely on equipment the entity owns, whose telemetry is retained locally, and whose commercial relationship is separate from the upstream tier’s produces a very different dependency map from one whose core decision-making depends on a vendor cloud. Appliances built to operate fully on-premise with their own detection engine and full L3–L7 coverage in a single device sit on the favourable side of that map by design. The criteria are vendor-independent and belong in the questionnaire in that form; the point is that they are answerable with documents rather than assurances, which is what an exit strategy needs.

Where the provider is located adds a further dimension that DORA’s contractual expectations around service locations make explicit, and which our analysis of vendor jurisdiction risk treats separately.

Classification, reporting and the evidence you must already hold

Reporting obligations are data obligations, and the sequencing is unforgiving: the evidence has to exist before the event, because it cannot be created afterwards.

Three things determine whether an entity can actually file. Whether classification criteria exist in advance, written in observable service metrics rather than regulatory language, and owned by someone reachable at any hour — because an incident that is being classified by whoever happens to be on shift is being classified inconsistently. Whether the telemetry supporting the initial, intermediate and final stages is held by the entity, retained long enough, and exportable on your timetable rather than a provider’s. And whether the clocks across every source you would reconstruct a timeline from are synchronised, because a timeline assembled from drifting sources is not a timeline.

One caution on root cause. For a DDoS event the tempting answer is “a third party attacked us”, which is true and analytically empty. The honest root cause is usually architectural: the stateful firewall exhausted its session table before the circuit filled; the payment initiation endpoint had no rate limit; the diversion trigger existed but had never been exercised, so the operator hesitated. Reports that name the external actor and stop there demonstrate that the entity has not asked why the attack worked, which is the question supervisory follow-up is built around.

Financial entities operating in Türkiye will find a parallel treatment of the same architecture under a different supervisory regime in our Turkish-language guide to DDoS protection for banks.

Testing and evidence checklist

The following is the DDoS-relevant subset of what an EU financial entity should be able to put in front of a supervisor, an internal auditor or a large counterparty without preparing it first.

Testing evidence

1. A diversion and fail-back exercise record with four measured numbers: time to divert, service impact during diversion, time to fail back, service impact during fail-back — and the date of the most recent run.
2. A state-exhaustion test result expressing, as a fraction of access-circuit capacity, the point at which each stateful device in the path becomes the binding constraint.
3. A false-positive measurement taken against a peak-like traffic profile, reported at percentiles and broken down per business flow rather than in aggregate.
4. A log-pipeline load test demonstrating no drop, no sampling and continued searchability at attack-level event rates, plus a successful incident export covering the full event window.
5. An out-of-band escalation test, confirming the path to the upstream provider does not depend on the circuit under attack, with the date of the last test.
6. Evidence of an independent upstream trigger, so mitigation does not depend on the entity’s ability to send a signal while its circuit is saturated.
7. A findings register with owners, closure dates and evidence that the previous cycle’s findings were actually closed — the element that distinguishes a programme from an annual event.
8. Independence evidence for who conducted the testing, and the scope statement tying it to the systems supporting critical or important functions.

Third-party and governance evidence

9. A register entry for every ICT provider in the availability defence, stating the function supported and whether it is critical or important.
10. A concentration assessment stating explicitly whether both mitigation tiers depend on one provider, one codebase or one commercial counterparty, with the conclusion recorded either way.
11. A documented exit strategy per critical arrangement: alternative identified, lead time costed, routing and addressing changes specified, telemetry and configuration portability confirmed contractually, interim posture defined.
12. A dependency map stating, for each provider, what stops immediately, what degrades and over what period, if the relationship ends.
13. Contractual evidence for arrangements supporting critical or important functions, including service locations, service levels, incident assistance, audit and access rights, and termination provisions.
14. Written incident classification criteria, expressed in service metrics, with a named decision authority and a documented deputy.
15. Telemetry evidence: retention period, storage location, and the tested export mechanism you would use to assemble a reporting package.
16. Management-body evidence: approval of the ICT risk framework, and records showing the residual availability risk was accepted at that level rather than assumed at engineering level.

An entity holding those sixteen artefacts has done the substantive work. One holding a vendor’s compliance datasheet has not — and no product, service or certification confers DORA compliance, because the regulation places the obligation on the financial entity and its management body carries it.

Sources and further reading

The legal texts. Regulation (EU) 2022/2554 is the primary source and should be read directly rather than through a secondary summary; it is available in all official EU languages on EUR-Lex. Read it together with the technical standards and guidance developed by the European Supervisory Authorities — the European Banking Authority, the European Insurance and Occupational Pensions Authority, and the European Securities and Markets Authority — which carry much of the operational detail, including the content of the register of information and the mechanics of incident reporting. Because those instruments are amended and supplemented over time, check the authorities’ own publication pages and the consolidated EUR-Lex text for what currently applies to you. Directive (EU) 2022/2555 (NIS2) is the general cybersecurity regime running in parallel; our NIS2 translation treats it in the same terms as this article. Your own competent authority’s guidance is frequently the most operationally useful document available.

Testing and incident-handling references. NIST SP 800-61, Computer Security Incident Handling Guide, remains the standard external reference for the incident lifecycle that staged reporting assumes. NIST SP 800-84 covers test, training and exercise programmes for IT plans and capabilities, which is the discipline the resilience-testing duty is asking for. NIST SP 800-115 covers technical security testing and assessment. NIST SP 800-34 covers contingency planning, and NIST SP 800-161 addresses cybersecurity supply chain risk management — the closest technical analogue to the third-party limb. The NIST Cybersecurity Framework 2.0 works well as an organising structure for the evidence set above. ISO/IEC 27001 and ISO 22301 are the management-system standards European supervisors most commonly recognise as supporting evidence.

DDoS-specific technical references. RFC 4732 (Internet Denial-of-Service Considerations) remains the clearest statement of the problem class. BCP 38 (RFC 2827) and BCP 84 (RFC 3704) cover ingress filtering. RFC 5635 covers remotely triggered black hole filtering; RFC 8955 and RFC 8956 define BGP FlowSpec; RFC 9132, RFC 8783 and RFC 8811 define DOTS, the standards-based signalling interface between an entity and an upstream mitigator — the narrow interface that makes a multi-vendor two-tier architecture practical. RFC 7011 (IPFIX) is the relevant standard for the flow telemetry your reporting will depend on, and RFC 5424 for syslog transport in the pipeline whose behaviour under event storm you should be testing. NIST SP 800-189 covers resilient interdomain routing.

ENISA materials. The annual ENISA Threat Landscape is the standard open reference for European threat context and tracks denial-of-service as a category in its own right. ENISA guidance is not law and does not speak to DORA’s financial-sector specifics, but it is the closest thing to a shared technical baseline across European supervisors.

A closing caution. This article translates themes into engineering; it does not state the current text of any obligation, and it deliberately avoids reciting provisions whose detail changes. The binding source is the regulation itself, together with the instruments the European Supervisory Authorities maintain — and how any of it applies to your entity is a question for the regulation, your competent authority and your compliance function, in that order.