DDoS testing that satisfies
SOC 2 Availability criteria
SOC 2 Availability criterion A1.3 requires testing that your recovery procedures actually work. DDactic validates your DDoS protection under real attack conditions and produces auditor-ready OPI evidence.
What SOC 2 Availability Requires
SOC 2 Type II Availability trust service criteria require organizations to demonstrate that systems are available for operation and use as committed. For web-facing systems, DDoS attacks are the primary availability threat.
"The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives."
"The entity tests recovery plan procedures supporting system recovery to meet its objectives."
"The entity selects, develops, and performs ongoing evaluations to ascertain whether the components of internal control are present and functioning."
SOC 2 auditors interpret A1.3 as requiring periodic tests of controls that protect availability. Having a CDN or WAF in place satisfies A1.2 (controls exist). A1.3 requires evidence that you have tested that those controls work under realistic attack conditions.
How DDactic Maps to SOC 2 Availability
| SOC 2 Criterion | Requirement | DDactic Feature |
|---|---|---|
| A1.2 | Monitor infrastructure protections continuously | DDactic passive scan continuously identifies new exposed assets, CDN bypass paths, and DDoS attack surface changes |
| A1.3 | Test recovery procedures under attack conditions | DDactic active DDoS simulation (L3/L4/L7, 213+ vectors) tests whether CDN, WAF, and scrubbing services hold under real attack load |
| CC9.2 | Ongoing evaluation that controls are functioning | OPI Validated score measures control effectiveness; repeat scans track improvement over time |
| CC7.2 | Monitor for anomalies in system components | DDactic identifies newly exposed origin IPs, WAF misconfigurations, and unprotected subdomains that create availability risk |
| CC6.1 | Implement logical access controls | DDactic tests rate-limiting and IP filtering controls under realistic bot traffic conditions |
Evidence DDactic Produces for Auditors
A SOC 2 Type II audit covers a period of 6-12 months. Auditors look for documented evidence that controls were tested and functioning throughout the period.
Quantified measure of DDoS resilience across 6 components: Defense Coverage, L7 Resilience, L3/L4 Resilience, Protocol Resilience, Operational Resilience, and Evasion Resistance. Directly maps to "availability control test result."
Documented methodology, test scope, attack vectors used, results per component, and vendor-specific hardening recommendations. Formatted for auditor review packages.
Full enumeration of exposed domains, origin IPs, and CDN bypass paths discovered during the assessment. Satisfies A1.2 infrastructure monitoring requirements.
All scan artifacts, test results, and reports retained for 12 months. Supports SOC 2 Type II audit periods and year-over-year comparison.
Executable CLI commands and configuration steps for Cloudflare, Akamai, Imperva, AWS Shield, and F5. Documents corrective action taken after testing.
Who Needs SOC 2 DDoS Testing Evidence
SaaS Companies
Any SaaS provider undergoing SOC 2 Type II audit needs to demonstrate that their platform's availability controls were tested. Customer-facing APIs and web applications are directly in scope.
Fintech and Financial Services
Banks, payment processors, and fintech platforms often carry both SOC 2 and PCI DSS requirements. DDactic evidence satisfies availability testing across both frameworks.
Healthcare Platforms
Healthcare SaaS platforms with SOC 2 requirements need availability evidence. DDoS attacks against healthcare infrastructure are a documented threat pattern.
Cloud Infrastructure Providers
Infrastructure and platform providers that provide availability SLAs to customers need to demonstrate that those SLAs hold under adversarial conditions.
See other standards: DORA, NIS2, PCI DSS, ISO 27001, Directive 361