How to Prove DDoS Defences to a Regulator

To prove DDoS defences to a regulator, show how they perform – not simply what was purchased or configured. Credible evidence connects each critical service to a documented risk, protection control, realistic test scenario, and measured outcome, then records any failure, its owner and remediation, and whether controlled retesting verified that the gap was closed.

 

Key Takeaways

• Procurement records are not evidence of resilience. A contract proves purchase and a dashboard proves deployment; only observed behaviour under controlled conditions demonstrates operating effectiveness.
• DORA requires independence, not outsourcing. Article 24(4) allows internal testers, provided they are properly separated and conflicts of interest are managed.
• Traceability matters more than attack volume. A large test that excluded a critical API proves less than a smaller one that exposed a real control failure.
• The evidence pack should preserve failures, not hide them. Regulators need to see the progression from expected behaviour to observed failure, remediation, and retest.
• Not every DDoS attack is reportable. The incident must first be classified against the criteria in Delegated Regulation (EU) 2024/1772.

A Purchased DDoS Defence Is Not a Validated Control

An organisation may have Cloudflare, AWS Shield or a dedicated scrubbing provider and still be unable to demonstrate that its critical services are resilient. Contracts, invoices and dashboard screenshots confirm that protection has been purchased and configured. They do not show that every relevant asset is covered, that traffic will follow the expected mitigation path, or that legitimate users will retain access during an attack.

The gap is measurable. Across Red Button’s engagements, 68% of the protection faults identified were rated severe or critical – in organisations that had already deployed DDoS protection. Those are Red Button’s own findings rather than an industry benchmark, and they describe environments whose procurement records were entirely in order.

Evidence therefore becomes more credible as it moves from showing what the organisation owns to demonstrating how the complete control behaves:

Evidence level	What the organisation can show	What remains unproven
Purchased	Contract, licence or service agreement	Whether the protection covers the required services
Configured	Policies, thresholds and architecture records	Whether the configuration works under attack conditions
Exercised	Alerts, tabletop results or provider-generated tests	How the complete service behaves under realistic traffic
Validated	Controlled test results and measured service impact	Whether identified failures have been corrected
Retested	Remediation records and repeat-test results	Whether the evidence remains current after later changes

Existing protection is therefore the starting point for validation, not a substitute for it. A credible test examines the provider alongside the organisation’s routing, cloud configuration, exposed assets, application controls and response process. It should establish whether attack traffic was diverted or filtered as intended, whether monitoring and escalation worked, and whether legitimate users could continue accessing the critical service. Protection and validation are different disciplines, and buying the first does not deliver the second.

A licence proves procurement. A configuration proves deployment. Only observed behaviour under controlled conditions demonstrates operating effectiveness.

Independence Is a Requirement, Not a Preference

“Financial entities, other than microenterprises, shall ensure that tests are undertaken by independent parties, whether internal or external.” – DORA Article 24(4)

The distinction between independent and external matters. DORA does not require every resilience test to be outsourced. An appropriately separated internal team may perform the work, provided it has sufficient resources and conflicts of interest are avoided. What matters is whether the test can challenge the assumptions behind the control rather than simply confirm that the expected configuration is present.

A report from a DDoS protection provider can form part of the evidence. It may show which traffic reached the provider, which rules triggered, and what the platform detected or blocked. However, it does not necessarily prove that every critical asset was routed through the service, that attackers could not bypass it, or that dependencies outside the provider’s platform remained available. It may also omit the effect of mitigation on legitimate users and the performance of the organisation’s escalation process.

The closer the tester is to selling, configuring or operating the control being assessed, the more clearly the report should explain its methodology, scope, assumptions, limitations and potential conflicts.

Red Button’s tests are led by DDoS specialists rather than delegated to a self-service platform. Its human-led approach allows scenarios to be adapted as results emerge and control behaviour to be interpreted in context. The company has focused exclusively on DDoS since 2014, across more than 2,000 controlled simulations. That experience strengthens the assessment, but it does not replace transparency: the resulting report must still show exactly what was tested, how conclusions were reached, and where evidence remains incomplete.

Build an Evidence Chain, Not a Document Pile

An audit folder may contain contracts, architecture diagrams, provider alerts, test logs, and remediation tickets, yet still fail to demonstrate that a critical service is protected. The problem is not necessarily missing documentation. It is the absence of a clear relationship between the business service, the risk being tested, the control expected to respond, and the evidence showing what actually happened.

This chain gives an auditor a traceable route from regulatory obligation to technical evidence. Rather than asking the reviewer to interpret a collection of disconnected files, it shows why each test was performed and what conclusion the results support.

For every critical service, the organisation should be able to answer six questions:

• What must remain available? Identify the business service, its users and its availability requirements.

• What could make it unavailable? Map its public assets, traffic routes, infrastructure dependencies and plausible DDoS exposures.

• Which controls should protect it? Name the mitigation provider, routing controls, WAF policies, rate limits and other relevant defences.

• How was that protection challenged? Document the authorised scope, attack vectors, traffic profile and expected control behaviour.

• What happened during the test? Record both the treatment of attack traffic and the experience of legitimate users.

• What happened after a failure? Connect each finding to an owner, remediation action, deadline, and controlled retest.

 

The chain should remain intact even when evidence comes from different teams or suppliers. A provider dashboard might show that malicious traffic was blocked, while application monitoring shows whether customers could still log in or complete transactions. Change records establish which configuration was active, and the retest demonstrates whether the remediation produced the intended result.

A 500 Gbps test may sound impressive and still provide weak regulatory evidence. It proves little if a critical API was excluded, the origin could be reached outside the mitigation path, DNS dependencies were not assessed, or nobody measured whether legitimate users could complete a transaction. Conversely, a lower-volume test targeting a real application constraint may expose a control failure with far greater relevance to service availability – which is also why the largest available test is rarely the most useful one.

Regulatory credibility comes from traceability, not the largest attack number.

What Goes in the Evidence Pack

The evidence pack should let a reviewer reconstruct the test without searching across unrelated systems or relying on a provider’s summary. A practical index keeps the material traceable and keeps the next audit cycle from starting with a rebuild:

File	Evidence included
01 – Scope	Critical services, assets, dependencies and exclusions
02 – Authorisation and safety	Provider approvals, rules of engagement, ramp-up plan, stop conditions and named decision authority
03 – Test design	Scenarios, vectors, traffic profiles and expected control behaviour
04 – Execution	Timestamps, generated traffic, relevant logs and dashboard records
05 – Service impact	Availability, latency, errors and legitimate-user journeys
06 – Findings	Control failures, severity, root cause and business impact
07 – Remediation	Corrective action, accountable owner and completion date
08 – Retest	Repeat-test results showing whether each correction worked
09 – Review and sign-off	Independent review, limitations, approvals and evidence-pack version

The pack should preserve failures rather than replace them with a clean final result. A regulator needs to see the progression from expected behaviour to observed failure, remediation and retest. A green provider dashboard is not sufficient if the protected service was unavailable or an asset sat outside the mitigation path. Red Button’s guide to reading a DDoS test report beyond pass/fail sets out how findings and severity are derived.

Can the evidence be produced safely in production?

Production testing is not risk-free, but the risk can be controlled. Written authorisation, a verified target list, hard traffic limits, live monitoring, agreed stop conditions and an authorised client decision-maker should be established before traffic begins. Red Button is an authorised AWS and Microsoft Azure DDoS testing partner, and its tests remain human-led so that traffic can be adjusted or stopped when service behaviour changes – the customer’s team can require an immediate stop at any point. The evidence pack should record these safeguards and any intervention made during execution. The full set of controls is covered in is DDoS testing safe in production.

In one of our tests at a banking environment, DDoS protection appeared to be correctly deployed, with AWS Shield Advanced protecting the application stack. Testing revealed otherwise: a configuration issue meant the Regional API Gateway was not behind CloudFront, effectively bypassing the intended Layer 7 protection. A simulated GET flood using a valid API request subsequently bypassed the remaining protection layers and took down the service.

 

A good evidence pack is therefore not an archive of everything generated during the engagement. It is a controlled record showing what was authorised, what was tested, what happened, and what changed as a result.

When DDoS Evidence Goes Stale

A test report does not remain credible simply because it is less than a year old. Its conclusions rest on assumptions about the services, architecture, controls, and threats that existed on the day it was produced. Evidence stops being reliable at the point where one of those assumptions no longer holds – which is a different question from whether the environment has changed in general.

Four situations break the chain directly:

• The tested scope no longer matches the service. A new public asset, API, domain or cloud region means the evidence describes an estate the organisation no longer runs.
• The validated control is not the control now running. Replacing a CDN, WAF, scrubbing provider or routing path leaves findings that relate to something that has since been swapped out.
• A finding was closed without a retest. Remediation records show that somebody made a change; only a retest shows the change produced the intended result. The chain breaks at its last link.
• The scenario set no longer reflects current techniques. Evidence remains credible only while the scenarios continue to represent the threats relevant to the tested service.

 

The operational counterpart to this list – what to reconfirm before each scheduled test – is the delta checklist in our guide to running a recurring DDoS testing program.

This is consistent with DORA’s requirement to “follow a risk-based approach” while considering “the evolving landscape of ICT risk”. Article 24(6) also requires financial entities, other than microenterprises, to ensure “at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions”. The annual requirement is a baseline, not a reason to ignore material changes between scheduled tests.

The fourth trigger is the one organisations notice last. The HTTP/2 Bomb, disclosed in 2026 by the California research firm Calif, achieves disruption at negligible bandwidth – a class of technique that a scenario library written a year earlier would not contain. Repeatedly running yesterday’s attack patterns cannot establish readiness against today’s.

A practical audit schedule creates time to find and correct failures:

Timing	Activity
9-12 months before the audit	Review critical services, material changes, and test scope
6-9 months before	Conduct the principal controlled test
3-6 months before	Remediate findings and complete missing documentation
1-3 months before	Retest material findings and complete independent review
Throughout the year	Maintain change records and trigger scoped validation when required

 

Keeping evidence current does not mean repeating the largest possible test every quarter. Continuous coverage checks, focused exercises, and change-triggered validation can maintain confidence between broader tests.

Testing immediately before an audit may produce recent evidence, but it leaves no time to remediate and retest a failed control.

When and How a DDoS Attack Must Be Reported

A DDoS attack is not automatically reportable under DORA. The financial entity must first assess the incident against the applicable classification criteria, including the critical services affected, number of clients or transactions impacted, duration and downtime, geographical spread, data loss and economic impact. The relevant thresholds are defined in Delegated Regulation (EU) 2024/1772.

Once an incident is classified as a major ICT-related incident, the entity must report it to its relevant competent authority using the prescribed process:

• Initial notification: as early as possible, within four hours of classification as major and no later than 24 hours after becoming aware of the incident
• Intermediate report: within 72 hours of the initial notification, with updates when material information changes or regular activities recover
• Final report: no later than one month after the intermediate or latest updated intermediate report

 

The reporting content and deadlines are set out in Delegated Regulation (EU) 2025/301, while the standard forms, templates and procedures appear in Implementing Regulation (EU) 2025/302.

Teams should preserve timestamps, affected services, classification decisions, mitigation actions, recovery evidence, root-cause findings and costs while the incident is unfolding. The correct reporting route depends on the entity and its competent authority, so legal and compliance teams should confirm the applicable obligations.

If an attack is already affecting your services, follow our guide on how to respond to a DDoS attack and preserve the records needed for subsequent assessment.

What a Regulator Is Actually Looking For

A regulator is not asking for more documents. It is asking whether a specific critical service was exposed to a credible test, whether the controls behaved as the organisation expected, what failed, who owned the correction, and whether a controlled retest confirmed the gap was closed. Every element of the evidence pack exists to answer one of those questions.

That standard is easier to meet when validation is planned as part of the audit cycle rather than assembled in the weeks before it. Red Button works with regulated organisations on DDoS testing for financial services, including the scoping, authorisation and retesting that make the resulting evidence usable in an audit.

Frequently Asked Questions

Do regulators accept vendor-supplied DDoS test reports?

A vendor-supplied report can contribute useful evidence, including the traffic observed, protections activated and attack traffic blocked. It does not automatically establish independent validation of the organisation’s complete service. Auditors may also need evidence of asset coverage, user impact, dependencies, remediation and retesting. DORA permits independent internal or external testing, but the organisation must be able to explain the tester’s role and any potential conflicts.

How far back should DDoS evidence be retained?

DORA does not prescribe one universal retention period for every DDoS test artefact. The appropriate period depends on the entity, competent authority, audit cycle, internal record-retention policy and any overlapping regulatory obligations. The retained evidence should be sufficient to show continuity across test cycles: what was previously tested, which findings remained open, when remediation occurred, and whether later changes affected the conclusions. Legal and compliance teams should confirm the applicable period.

Are there DORA-specific DDoS testing templates?

There is no universal DORA template for a standalone DDoS resilience test. Delegated Regulation (EU) 2025/1190 specifies documents and required information for threat-led penetration testing, including test reports, remediation plans and attestations. Those requirements may provide useful reference points, but a DDoS test does not automatically qualify as TLPT or satisfy Article 26 unless the complete regulatory scope, methodology, tester and authority requirements are met.

Do we need a full-scale DDoS test every quarter?

DORA does not state that organisations must conduct a full-scale DDoS test every quarter. Article 24 requires a risk-based testing programme and appropriate testing at least yearly for systems and applications supporting critical or important functions. Between broader tests, evidence can be maintained through coverage reviews, monitoring, tabletop exercises, scoped technical validation and retesting after material changes or remediation. Test frequency should reflect service criticality, current risks, and supervisory requirements.

Is DDoS testing a paid service, and what determines the cost?

Yes. Red Button provides DDoS testing as a paid, expert-led engagement rather than a self-service platform, and scope drives the cost: the targets, the vectors in play, the environments covered, and whether retesting after remediation is included. For an evidence pack intended for an audit, the retesting question matters most – a finding closed without a verified retest leaves the chain incomplete.