The decision table
A quick map of how directly each framework drives availability and DDoS resilience testing. "Explicit" means the text requires resilience testing; "expected" means auditors look for tested availability controls even though DDoS is not named.
| Framework | Who it applies to | Resilience-testing expectation |
|---|
| EU DORA | Financial entities & their critical ICT providers in the EU. | Explicit — resilience testing programme; TLPT for significant entities. |
| NIS2 Directive | Essential & important entities across 18 EU sectors. | Explicit — risk management, business continuity & testing of measures. |
| PCI DSS 4.0 | Anyone storing, processing, or transmitting card data. | Expected — validate the payment-perimeter defenses hold under attack. |
| SOC 2 (Availability) | Service orgs evidencing trust-service criteria. | Expected — tested availability & continuity controls. |
| ISO/IEC 27001 | Any organization certifying its ISMS. | Expected — tested continuity & capacity controls (Annex A). |
EU DORA
The Digital Operational Resilience Act (Regulation 2022/2554) is the most prescriptive of the set. In-scope financial entities must run a digital operational resilience testing programme, and significant entities must additionally perform Threat-Led Penetration Testing (TLPT) on a multi-year cycle. Staying available under denial-of-service conditions is squarely inside the resilience DORA expects you to test, evidence, and report. Full detail on DORA compliance & TLPT resilience testing.
NIS2 Directive
NIS2 (Directive 2022/2555) requires essential and important entities to adopt risk-management measures and to test them — including business continuity and crisis management. For internet-facing services, availability under attack is a core part of that risk picture, and a documented DDoS simulation is a direct way to evidence that the measures work. See NIS2 cyber resilience & DDoS testing.
PCI DSS 4.0
PCI DSS 4.0 does not print the phrase "DDoS test," but its requirements to test security controls and protect the cardholder data environment mean you must be able to show the payment perimeter — WAF rules, rate limiting, TLS termination, edge and origin defenses — holds under hostile load. An authorized simulation against those specific endpoints is the cleanest way to produce that proof. See PCI DSS 4.0 DDoS & stress-testing compliance.
SOC 2 & ISO 27001
Neither names DDoS testing, but both increasingly draw auditor questions about it:
- SOC 2 (Availability criterion): if you claim the Availability trust-service criterion, an auditor will ask how you know your availability controls work. "We have a WAF" is weaker evidence than "we ran an authorized DDoS simulation and here is how it held."
- ISO/IEC 27001: Annex A controls for business continuity, redundancy, and capacity management expect testing. A DDoS simulation exercises exactly those controls and produces the records an auditor can review.
In both cases the framework gives you latitude in how you test — and a bounded, health-monitored DDoS simulation is a defensible, low-risk way to generate real evidence.
What auditors want to see
Across every framework, the evidence request is remarkably consistent. A resilience test satisfies it when it produces:
- Authorized scope
- The signed Rules of Engagement — which targets, which vectors, which ceilings, which window, authorized by whom.
- What was done
- Timestamped records of the vectors and load actually applied, tied to the verified target.
- How it behaved
- Latency, error-rate, and availability time-series showing where thresholds were reached and how mitigation responded.
- What you fixed
- The remediation roadmap and, ideally, a re-test confirming the fix.
Our platform produces this automatically as a resilience scorecard and an audit-ready report. If you are not sure which framework drives your obligation, start with what DDoS simulation testing is, then pick your framework above.
← Back to Homepage