Does an authorized DDoS stress test count toward DORA's testing requirements?

It can count toward DORA Article 24's annual digital operational resilience testing programme, as a form of the performance testing or scenario-based testing named in Article 25's toolkit. It is not a substitute for threat-led penetration testing (TLPT) under Article 26/27, which only applies to entities identified as systemically important by their competent authority, runs on a three-year cycle, and covers a broader live-production, multi-vector scope than a DDoS-only test. Confirm applicability with your DORA compliance lead — this describes the regulation's testing categories, not a determination of your entity's specific scope.

Who inside a digital bank needs to sign off before test day, beyond the cloud/edge provider?

At minimum: the person who owns Rules of Engagement and abort authority (usually the CISO or Head of Infrastructure), the payments or core-banking operations lead who can confirm the test window doesn't collide with a settlement batch or reconciliation run, and whoever owns the relationship with any registered third-party providers (TPPs) whose polling traffic could be mistaken for the test itself. None of these appear in a cloud provider's DDoS testing policy — they're internal, and confirming them is what turns a clean provider approval into a test day that actually runs on schedule.

Can a DDoS stress test eat into our 99.5% quarterly uptime budget?

Only if it isn't scoped correctly. A properly run test measures mitigation performance without pushing the origin into a real outage — the abort condition exists specifically so a test doesn't become the incident it's trying to prevent. But a test that isn't aborted in time, or one scheduled during a window that overlaps planned maintenance already drawing down the same budget, can consume real minutes against the quarterly KPI. Scheduling the test in a low-traffic window with a fast, unambiguous abort trigger is what keeps the test itself off the downtime ledger.

How is this different from the AWS vs Cloudflare sign-off process for a crypto exchange?

The external, provider-side mechanics are the same regardless of vertical — AWS gates by a technical volume threshold, Cloudflare gates by ownership of the target, not a permission form. What changes for a digital bank is the internal sign-off chain and the regulatory context: a crypto exchange's internal risks center on custody and settlement windows, while a bank's center on core-banking batch cycles, TPP traffic patterns, and where the test fits DORA's testing programme — a compliance question a crypto exchange's DORA-equivalent obligations don't raise the same way.

How often should a digital bank run a DDoS stress test?

Twice a year at minimum, and after any material change to the edge stack — new CDN, new WAF ruleset, new origin architecture, or a new registered TPP integration that changes the traffic-shape baseline. This is the same cadence that applies across every vertical; DORA's Article 24 annual minimum is a floor under that, not a ceiling.

DDoS Stress Testing Sign-Off for a Digital Bank

The short answer

An authorized DDoS stress test against a digital bank's production edge needs two sign-off tracks — the cloud/edge provider's approval (or lack of one) and an internal chain specific to a regulated bank, covering payments operations, TPP-relationship ownership, and RoE/abort authority. It can also count toward DORA's Article 24 annual testing programme as a form of Article 25's performance or scenario-based testing — but it is not, and does not replace, the threat-led penetration testing (TLPT) required every three years from systemically important entities under Article 26/27.

Who this is for

This is written for a CISO or Head of Infrastructure at a digital bank, e-money institution, or fintech payment platform who already has DDoS protection in place and is scoping an authorized DDoS stress test against production — and has two open questions at once: who internally has to say yes before test day, and whether the test does any compliance work toward DORA. It assumes the provider-side mechanics (what AWS Shield Advanced or Cloudflare require before treating your own traffic as legitimate rather than an attack) are already understood in general; see DDoS testing sign-off: AWS vs Cloudflare for that mechanism, which does not change by vertical and is not repeated here. It also assumes the bank already has a DDoS architecture and a quarterly uptime KPI to protect; see DDoS protection for digital banks: the uptime-budget problem for that. This post is specifically about the sign-off chain and the DORA classification question — neither of which the two posts above cover.

Two sign-off tracks, same structure as any authorized test

The shape doesn't change by vertical: an authorized DDoS test always has an external track (what the provider requires) and an internal track (who inside the organization has to approve the window). What changes for a digital bank is who sits on the internal track and what else is riding on the outcome.

External, provider-side. AWS Shield Advanced gates by a technical volume threshold (a partner-run simulation needs no separate approval under roughly 20 Gbps / 50,000 requests per second; above that, an exception request needs 14 days' lead time). Cloudflare gates by ownership — no permission needed for your own, non-shared property. This mechanism is identical for a bank, a casino, or a crypto exchange; full detail in the AWS vs Cloudflare sign-off post.
Internal, bank-side. Three roles come up consistently in scoping these engagements for regulated payment platforms, and none of them show up in a provider's testing policy.

Internal track: the three sign-offs a bank needs that a provider's policy won't mention

RoE and abort authority. One named person — usually the CISO or Head of Infrastructure — who can halt the test immediately by phone, not a ticket. This is unchanged from any other vertical.
Payments and core-banking operations lead. The person who can confirm the test window doesn't overlap a settlement batch, a reconciliation run, or a scheduled core-banking maintenance window. A test that degrades the payment-initiation API during a batch cycle turns a controlled exercise into a real incident against systems with regulatory reporting obligations attached.
TPP-relationship owner. Registered third-party providers under the open-banking framework poll account and payment APIs on their own schedules, sometimes in synchronized bursts. If a TPP's legitimate traffic spikes during the same window as the test, distinguishing "test load," "attack load," and "TPP load" after the fact gets genuinely hard — and if a TPP's own monitoring flags degraded API performance during your test window, that can trigger their own incident-reporting process independent of yours. Looping in whoever owns the TPP relationships before test day, not after, avoids a second organization's incident process starting because of your test.

This mirrors the pattern for a crypto exchange's internal sign-off chain — RoE owner, an operations lead who protects a sensitive processing window, and a relationship owner whose stakeholders could be affected — with the specific roles and windows swapped for what a regulated payments business actually runs.

Does the test count toward DORA?

This is the question a crypto exchange's sign-off scoping doesn't raise, because DORA doesn't apply the same way outside EU financial entities. For a digital bank, e-money institution, or fintech payment platform in scope of the Digital Operational Resilience Act (Regulation (EU) 2022/2554), it's worth being precise about where a DDoS stress test fits.

DORA Article 24 requires financial entities (other than microenterprises) to run a digital operational resilience testing programme covering all ICT systems and applications supporting critical or important functions, at least yearly. Article 25 names the toolkit available to satisfy that programme: "vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing." An authorized DDoS stress test — measuring whether infrastructure holds under hostile load — reads naturally as performance testing or a scenario-based test within that list.

That's a materially different tier from Article 26/27's threat-led penetration testing (TLPT): a three-year-cycle, live-production, broad-scope red-team-style engagement that only applies to entities their competent authority identifies as systemically important (with significant credit institutions required to use external testers). A DDoS test satisfies the annual Article 24/25 programme; it does not satisfy — and isn't meant to satisfy — a TLPT obligation if one applies to your entity. For the TLPT cost and cadence detail, see NIS2 + DORA without the consultant theatre, which covers that requirement in full and isn't repeated here.

DORA tier	What it covers	Cadence	Who it applies to
Article 24/25 general testing programme	Vulnerability scans, performance/scenario-based tests, penetration testing, etc. — a DDoS stress test fits here	At least yearly	All in-scope entities except microenterprises
Article 26/27 TLPT	Broad, live-production, multi-vector red-team-style test	At least every 3 years	Entities identified as systemically important by their competent authority

Confirm with your own DORA compliance lead whether your entity has been identified for TLPT scope — that determination sits with your competent authority, not with a testing vendor.

Scheduling without spending the uptime budget on the test itself

A digital bank's DDoS architecture already answers to a fixed regulatory ceiling — a 99.5% quarterly uptime KPI under the EBA's Open Banking operational guidelines, worked out in full in the uptime-budget post. A test that runs long, or that isn't aborted the moment mitigation genuinely fails, spends real minutes against that same budget. Two things keep the test off the downtime ledger:

A fast, unambiguous abort trigger, agreed with the RoE owner before test day — not "call someone and discuss," but a pre-defined threshold that halts traffic generation immediately.
A scheduling window chosen against real traffic patterns, including TPP polling cycles, not just human customer traffic. The quietest hour for retail logins is not necessarily the quietest hour for TPP batch polling — check both before picking the slot.

What this doesn't cover

This post is specifically about the sign-off chain and the DORA classification question. It doesn't cover how to scope which layers, endpoints, and vectors belong in the test itself — RoE mechanics, baseline capture, and ramp-up discipline are covered generally in scoping DDoS stress testing for an online casino, which applies unchanged regardless of vertical. It doesn't cover the DDoS protection architecture itself — see DDoS protection for digital banks for the four-layer build and the uptime-KPI math. And it doesn't cover the API gateway's authentication layer (QWAC/QSeal, mTLS) — a separate control from availability, detailed in hardening a fintech payment platform.

Getting the sign-off chain scoped

If you already know your provider's requirements but haven't mapped the internal chain — or you're not sure whether your entity sits in TLPT scope — tell us your setup and we'll help sequence the provider conversation, the internal sign-offs, and the DORA classification question so none of them blocks test day.

Sources and review

DORA (Regulation (EU) 2022/2554) Article 24, 25, and 26/27 text is drawn from the regulation's official text via the digital-operational-resilience-act.com reference mirror, cross-checked against the article structure published by the European Banking Authority. The EBA Open Banking 99.5% quarterly uptime KPI figure is reused from AnySec's own prior publication (linked above), not re-derived here. AWS and Cloudflare provider mechanics are reused from AnySec's own prior publication on that topic, not re-derived here. Internal sign-off roles and scheduling guidance reflect AnySec's own engagement-scoping methodology; no third-party numbers are cited for that section. Author: AnySec Engineering. Published 2026-09-04.