How to Read a DDoS Test Report Beyond Pass/Fail
Most DDoS test reports get treated like a security scan. A list of attack vectors, each one tagged as blocked or not blocked, and a verdict that reads like a grade. Pass means safe. Fail means fix it.
That framing misses what actually matters. The same attack vector can be a footnote in one environment and a customer-facing outage in another. Whether mitigation blocked the traffic eventually is less important than how the system behaved while the attack was running – what degraded, for how long, who saw it, and whether the response was automatic or someone had to fix it manually at 2 am.
Red Button simulation data shows that 68% of identified faults are severe or critical, with an average first-test DDoS Resiliency Score (DRS) of just 3.0 – well below the 4.5 – 5.0 baseline recommended for most industries. Those numbers come from environments that almost always had protection deployed. Deployment was not the problem. Interpretation was.
This post is about how to read a DDoS test result properly, what severity actually means once you account for service impact, and how the DDoS Resiliency Score gives you a frame of reference that goes beyond any single test.
Key Takeaways
- Pass/fail hides the answers that matter. A “blocked” vector can still cause minutes of degradation before mitigation kicks in.
- Severity is not a property of the attack vector. The same HTTP flood is low impact in one environment and critical in another, depending on what it hits.
- Duration, visibility, and recovery are part of the result. If the SOC didn’t see it or had to act manually, that’s a finding.
- The DRS gives you a baseline across tests. It is an open standard with seven levels, not an internal Red Button score.
- A finding is only closed after a retest. A configuration change is a plan, not proof.
Why Pass/Fail Hides the Real Story
A binary verdict makes a test result easy to skim and easy to misread.
Consider three scenarios involving the same Layer 7 attack against the same login endpoint:
- Mitigation activates within seconds. No user notices anything.
- Mitigation activates after four minutes. Some users get timeouts, some retry and succeed, the SOC opens a ticket after the fact.
- Mitigation never activates automatically. A senior engineer manually pushes a rate-limit rule after fifteen minutes of degraded login flow.
A pass/fail report might mark scenarios 1 and 2 as “blocked” and scenario 3 as “failed.” But scenario 2 is not really a pass. It costs real users real friction during a window when the protection was supposed to be doing its job, and nobody on the security side flagged it in real time. That gap – between technical mitigation and operational visibility – is exactly the kind of thing a real attacker would exploit a second time.
The better questions are:
- Did the protection detect the traffic, and how fast?
- Did mitigation activate automatically, or did someone have to push a rule?
- What did users actually experience – latency, errors, broken flows, False-Positive blockage, or nothing?
- Did the SOC or NOC see it clearly enough to act on it?
- Is the fix a configuration change, an architecture change, or a process change?
- Can you prove it works now by retesting?
A report that answers these questions becomes an action plan. A pass/fail summary just becomes a chart in a slide deck.
What Red Button Looks At During a Test
Across a white-box DDoS simulation, we evaluate findings across several dimensions that together describe how the environment actually behaves under pressure.
Detection. Did the protection stack – ISP, scrubbing center, CDN, WAF, bot management, internal SOC tooling – identify the traffic as abnormal? Detection can be automatic, delayed, noisy, or absent. All four matter for different reasons.
Mitigation. Did the relevant control actually reduce or block the traffic, or just generate alerts? Detection without mitigation is a monitoring tool, not a defense.
Service availability. Could legitimate users still log in, transact, or hit the API? Availability is the business outcome. A dashboard that shows “mitigation active” while customers see error pages is reporting the wrong thing.
Performance degradation. Many real DDoS incidents don’t produce a clean outage. They produce latency, intermittent errors, and partial degradation that’s harder to detect and much harder to explain to a CFO.
Duration. Time to detection. Time to mitigation. Time to recovery. Time to operational awareness. A ten-second spike and a twenty-minute degradation are not the same finding even if the vector is identical.
Operational visibility. Did the right teams understand what was happening while it was happening? A mature response depends on security, network, cloud, application, and vendor teams converging on the same picture quickly.
Recovery. Did the service come back automatically, or did someone have to intervene? Recovery behavior often exposes weaknesses in autoscaling, caching, session handling, or vendor escalation paths that nobody knew were brittle.
Remediation path. A useful finding ends with a clear next step – a rule tuning, an architecture change, an origin protection fix, a playbook update – not just a “failed” label.
These dimensions are what turn a list of attack vectors into something a SOC lead, a network architect, and an executive can each act on.
A Practical Framework for Severity
Severity is not a property of the attack vector. It’s a property of what happened when that vector hit your specific architecture/ attacked service, with your specific traffic profile, under your specific operational conditions.
Low
The test exposed a weakness, but no meaningful business impact occurred. Mitigation worked; degradation was brief or invisible to users. Findings at this level are usually about tuning, monitoring, alert routing, or documentation. They’re worth fixing, but not urgent.
Example: A vector-triggered mitigation correctly, but the alert took several minutes to reach the on-call SOC analyst.
Medium
The test caused measurable degradation or exposed a gap that would matter under different conditions. Mitigation is activated, but only after a delay. Users may have seen latency or intermittent errors. These findings often reveal the difference between “we have protection” and “our protection is tuned correctly for this traffic.”
Example: An HTTP/S flood was eventually mitigated, but response times rose and error rates spiked for several minutes before automatic mitigation engaged.
High
A critical business function was affected, or the attack bypassed expected protection. Mitigation did not activate automatically. The SOC didn’t have enough visibility to understand the root cause in real time. Manual intervention was required to stabilize the service. High-severity findings are realistic attack paths – the kind a competent attacker would replicate once they noticed it worked.
Example: A slow-rate Layer 7 attack didn’t trigger volumetric protection but exhausted backend resources and degraded a customer-facing API.
Critical
A major resilience failure. A production service went down, the attack bypassed core mitigation entirely, or the architecture had a structural gap – origin exposure, incomplete routing through scrubbing layers, an unprotected upstream link. Recovery required significant manual effort, and the affected service is revenue-generating, regulated, or mission-critical. These findings should drive immediate remediation, ownership assignment, and a retest before anyone considers them closed.
Example: A tested vector reached the origin directly, bypassed the cloud protection layer, and took down a customer-facing service.
Why the vector alone doesn’t tell you severity
A UDP flood against a well-protected edge is low severity. The same flood against an unprotected upstream link is critical. An HTTP flood against a cached static page is a nuisance. The same flood against an un-cached login path can take down a bank. A low-rate attack might be invisible in bandwidth graphs while it exhausts application threads, database connections, or session pools.
The vector is the input. Severity is the output of that input meeting your real architecture.
What to Actually Do With a Test Report
A test report should drive specific actions, not just generate awareness.
Prioritize by severity, not by vector count. Critical and high findings get owners and deadlines. Medium findings get scheduled. Low findings get tracked. A long list of low findings is not more important than two critical ones.
Separate technical fixes from process fixes. Some findings are solved by adjusting a WAF rule, closing an origin exposure path, or tuning rate limits. Others are solved by updating an escalation playbook, clarifying vendor responsibilities, or fixing how the SOC and NOC coordinate during an incident. A strong architecture with broken processes still fails under pressure.
Watch for repeat findings. If the same issue appears in test after test, you’re treating symptoms instead of root causes – or remediation isn’t being validated, or configuration drift keeps reintroducing the same gap.
Retest before closing anything. A configuration change is a plan. A passing retest is proof. This is non-negotiable for high and critical findings.
Use the DRS as a trend, not a single number. Track it across tests, especially after architecture changes, cloud migrations, vendor swaps, or major releases. A score that’s improving is a story you can tell. A score that’s flat after a remediation cycle is a story you need to investigate.
Common Mistakes When Reading DDoS Test Results
Treating every blocked vector as a success. Eventually blocked is not the same as cleanly mitigated. The window between attack start and mitigation activation is part of the result.
Ignoring partial degradation. A system doesn’t have to be down to be failing. Slow login, intermittent API errors, and broken checkout flows are real impact – and often more damaging than a clean outage because they’re harder to detect and explain.
Trusting vendor dashboards as the full picture. Vendor dashboards show what the vendor sees. They don’t show application behavior, internal response gaps, origin exposure, or how the user actually experienced the event.
Closing findings without retesting. A remediation plan is not proof of resilience. The only thing that proves resilience is reproducing the attack and watching it fail this time.
From Assumed Protection to Validated Resilience
The point of a DDoS test isn’t to grade the protection stack. It’s to figure out what would actually happen during a real attack and to close the gaps before someone forces the question under worse conditions.
If the only thing you know about your DDoS posture is that protection is deployed, your resilience is unproven. A controlled simulation shows what works, what fails, and what to fix – and the DRS gives you a way to track whether you’re actually getting more resilient over time or just generating reports.
Red Button helps enterprises move from assumed protection to validated resilience through expert-led DDoS simulations, prioritized remediation, and DRS-based scoring. If you want to see what a real report looks like, you can request a sample.
FAQs
What is a DDoS test result really measuring?
It measures how your system behaves under attack, including detection, mitigation speed, service impact, and recovery—not just whether traffic was blocked.
Why is pass/fail not enough for DDoS testing?
Because an attack can be “blocked” but still cause latency, degradation, or user impact before mitigation activates.
What is a good DDoS Resiliency Score (DRS)?
Most financial services environments should aim for a baseline of 4.5–5.0 or higher, depending on complexity and risk exposure.
What does severity mean in a DDoS test?
Severity reflects real-world business impact, including downtime, partial degradation, manual intervention, and recovery effort—not just the attack type.
Why is retesting important after remediation?
Because configuration changes are assumptions until they are validated under the same attack conditions again.
About the author
