A penetration test and a DDoS test are both authorized attacks on your own infrastructure, run by someone you hired, inside a scope you signed. That shared shape is why the two are constantly filed as one engagement, with the DDoS test treated as the availability chapter of the pentest.
They are not one engagement. They answer opposite questions, carry opposite risk, and produce findings for different teams. A penetration test asks whether an adversary can get in. A DDoS test asks whether an adversary can keep everyone else out. Those are two different failures, and buying them as one guarantees that one of the two questions gets asked carelessly, or never.
That the two answer different questions is the line the pillar guide draws. This post is about the operational consequence of that line: where a DDoS test actually sits in a security assessment, why it belongs beside the penetration test rather than inside it, and the single place the two genuinely connect.
The clearest evidence that the industry already knows they are different is sitting in most penetration-testing contracts: a clause that explicitly puts denial-of-service out of scope. That exclusion is not an oversight. It is the correct answer to a question people keep getting wrong.
At a glance: two authorized attacks, two different tests
| Axis | Penetration test | DDoS test |
|---|---|---|
| Question it answers | Can an adversary get in? | Can an adversary keep legitimate users out? |
| Security property | Confidentiality and integrity | Availability |
| Method | Find and exploit a flaw (code, config, access) | Exhaust a resource or saturate a control with traffic |
| What a finding is | A vulnerability and the path to reach it | A breaking point and the control behavior around it |
| Attacker's success | Unauthorized access, escalation, exfiltration | Legitimate traffic stops being served |
| Blast radius by design | Surgical, meant to leave the system running | Disruptive, meant to push a control to its limit |
| Authorization | Owner sign-off; standard testing agreement | Owner sign-off plus a separate, stricter platform gate |
| Primary deliverable, and who acts on it | Prioritized vulnerabilities, for appsec and remediation | Behavioral characterization, for infra, SRE, capacity |
The two columns barely touch. Different question, different method, different definition of a finding, different reader for the report. Everything below is a consequence of that.
Two questions, not one test
The distinction is easy to state and easy to underestimate. The reason it forces two separate engagements is that the two tests have opposite designs, not just different subjects.
A pentest is engineered to be quiet
A competent penetration test is surgical. The goal is to prove a path to access and document it, ideally without the target noticing and without breaking anything on the way. A pentester who takes production down has failed at the craft, not demonstrated it. Low blast radius is a design goal, not a courtesy.
A DDoS test is engineered to be loud
A DDoS test has the opposite design goal. You cannot characterize how a control behaves at its limit without driving it toward that limit. The entire value is in finding the knee: the level where a rate limiter starts shedding, where a connection table fills, where goodput bends away from the request rate. Reaching that point means generating disruptive, attack-shaped traffic on purpose, inside a boundary you built. Disruption is not a side effect of the test. It is the instrument.
Two engagements with opposite blast-radius designs cannot share a window. Run them together and each contaminates the other's readings, which is the first reason the standard scope keeps them apart.
Why the standard pentest scope says "no DoS"
The exclusion is correct for four concrete reasons, and reading them is the fastest way to see why "where does DDoS testing fit" is a real question with a real answer.
1. Opposite blast radius
A surgical access test and a disruptive availability test interfere with each other directly. When the pentester's session drops mid-engagement, was it a WAF rule, a flaky code path, or the DDoS traffic saturating the same load balancer? You cannot tell. Attribution requires isolation, across engagements as much as within one, and two overlapping tests destroy it for both.
2. Different method and tooling
Exploiting a flaw and exhausting a resource are different crafts. One is about logic: a parameter that is not validated, a token that is not checked, a trust boundary that is not enforced. The other is about volume and state: traffic generation at scale, distributed sources, and careful blast-radius control with a kill switch. A team strong at one is not automatically strong at the other, and the tooling does not carry over.
3. A separately gated authorization
The authorization for a DDoS test is not just owner sign-off. On cloud platforms, simulated DDoS is gated separately and more strictly than ordinary penetration testing: high-volume simulated attacks commonly need advance approval, or an approved testing partner, once traffic crosses defined thresholds, because the platform's own detection cannot tell an authorized test from a real attack. The fact that platforms draw their own line between the two is external confirmation that they are different activities. The authorization and containment discipline that governs a DDoS test is a body of work the pentest does not need.
4. A different success criterion
A penetration test ends with a list of vulnerabilities ranked by exploitability. A DDoS test ends with a characterization: which control engaged, at what threshold, how long until mitigation, and what a real user experienced throughout. One deliverable is a to-fix list; the other is a behavior map. They are not interchangeable, and a report template built for one cannot hold the other.
Where the two genuinely touch: reconnaissance
For all the separation, there is one phase the two disciplines share, and it is worth naming because most assessments handle it badly.
Both begin with reconnaissance: mapping the attack surface. Subdomain enumeration with subfinder or amass, certificate-transparency logs at crt.sh, historical DNS records, exposed services, IP addresses leaking in JavaScript bundles or email headers. A pentester runs this to find a way in. A DDoS attacker runs the same playbook to find the origin behind the edge.
The handoff most assessments miss
Here is the connection. The same reconnaissance can produce a finding that means one thing to a pentester and something else entirely to the availability side. A penetration test that discovers the origin IP address behind a CDN has, incidentally, found the single most useful precondition for a DDoS: a way to send traffic straight to the origin and walk around every edge control the organization is paying for.
If the penetration test and the DDoS test are run as sealed workstreams that never compare notes, the assessment holds both halves of that finding and connects neither. The pentester logs an information-disclosure issue and moves on; the availability side never hears about a bypass it should have tested. The reconnaissance overlap is exactly where an assessment either compounds its two halves or wastes them.
Where DDoS testing fits in the assessment lifecycle
A security assessment is not one test. It is a portfolio of workstreams, each with its own scope, authorization, and audience: vulnerability scanning, penetration testing, configuration and architecture review, sometimes a red team, and resilience or DDoS testing. They run on different schedules and report to different owners.
DDoS testing is one leg of that portfolio, the availability leg. It is not nested inside the penetration test any more than the configuration review is. Placing it correctly comes down to three things.
Give it its own window
Because the DDoS test is disruptive by design, it runs in its own change-controlled window, coordinated with the people who need to be watching, rather than layered on top of the pentest. This is the cross-engagement form of a rule that already governs a single test: change one variable at a time so the result is attributable. Two engagements running at once is the largest uncontrolled variable there is.
Point its findings at the right team
The DDoS characterization is an infrastructure and capacity document. Its natural readers are SRE, network, and platform engineering, the people who tune autoscalers, size connection tables, and configure the edge. That is a different audience from the application-security team that receives and acts on a penetration test report. Routing matters: a finding delivered to a team that cannot act on it is not a finding, it is a filed document.
Connect it to the broader readiness picture
The controlled-traffic DDoS test is the technical core of a wider DDoS readiness assessment, which also exercises the human response loop: detection, escalation, decision authority, and whether the runbook still matches the stack. A penetration test has no equivalent to that operational layer, which is one more sign the two are measuring different properties of the organization, not two views of the same one.
Red team engagements and the availability objective
There is a legitimate case where offensive availability work appears inside a broader engagement, and it is worth handling directly rather than pretending the boundary is never crossed: a red team.
A red team models a full adversary against a goal, and that goal can include denial of service. But even then, the DDoS component is run as a controlled, separately scoped sub-exercise with its own caps and abort criteria, not as free-form flooding dropped into the middle of an adversary-emulation exercise. The blast-radius reasons do not disappear because the engagement has a different name on the cover.
Emulation is not characterization
It is worth being precise about what a red team's availability objective proves versus what a DDoS test proves, because they are easy to conflate.
A red team is goal-driven and narrow. It looks for one credible path to the objective and demonstrates it. If the goal is denial, a red team might prove a single way to take a service down, which is a real and useful result.
A DDoS test is systematic and broad. It characterizes the availability posture across the surface, per control and per layer, with the thresholds and the layer that fails first. One demonstrates a path; the other maps the terrain. An organization that has a red-team denial finding still does not have a DDoS characterization, and one that has a DDoS characterization has not had a red team. They answer different halves of the availability question.
Two reports, two audiences
The most practical reason not to fold a DDoS test into a penetration test is what comes out the far end.
The penetration test report
A prioritized list of vulnerabilities, each with a reproduction path, an exploitability rating, and a remediation. Its consumer is the team that patches code, tightens access, and corrects configuration. Its unit is the finding-to-fix, and its measure of success is that the list gets shorter over time.
The DDoS characterization
A behavior map: which control engaged and in which mode, the time to mitigation per vector, the goodput floor a real user experienced, the false-positive cost at the mitigating threshold, and the layer of first failure. Its consumer is infrastructure and capacity planning. Its unit is the threshold and the behavior around it. Whether that characterization can be trusted at all is its own evaluation problem, separate again from anything the pentest report raises.
Fold the DDoS test into the pentest and its findings land in the application-security queue, addressed to a team that cannot act on a load-balancer connection-table ceiling. The report structure follows the discipline. Two disciplines produce two reports for two readers, and forcing them into one template loses information at both ends.
FAQ
Is DDoS testing part of penetration testing?
No. They are separate disciplines that share a shape (authorized, scoped, offensive testing) but answer different questions. A penetration test targets confidentiality and integrity: can an adversary get in. A DDoS test targets availability: can an adversary keep legitimate users out. Most penetration-testing agreements exclude denial-of-service explicitly for that reason.
Does a standard penetration test include DDoS or DoS testing?
Usually the opposite: the standard scope explicitly excludes it. That exclusion is deliberate, not a gap. A DoS test is disruptive by design and would contaminate the surgical, low-impact work a pentest is built to do, and cloud platforms gate simulated DDoS under a separate, stricter authorization in any case.
Do compliance frameworks require DDoS testing?
It varies, and availability and vulnerability testing are usually addressed separately. Frameworks such as PCI DSS require regular penetration testing of the in-scope environment, but that requirement is about exploitable vulnerabilities, not availability, and satisfying it does not mean a DDoS test has been performed. Availability and operational-resilience expectations tend to come from separate regulatory or business requirements. Confirm what each obligation actually asks for rather than assuming a pentest covers resilience.
Can the same vendor run both?
Yes, and many do, but as two engagements with two scopes, two authorizations, and two reports, not one blended test. The advantage of a single vendor is that the reconnaissance overlap gets connected on purpose: an origin-exposure finding from the pentest side becomes an input to the DDoS side instead of being lost in the gap between two reports.
Should a DDoS test and a penetration test run at the same time?
No. Overlapping a disruptive availability test with a surgical access test makes each other's findings unattributable: when a session drops, you cannot tell whether it was a vulnerability, a defensive control firing, or the test traffic saturating shared infrastructure. Run them in separate windows.
Two ways to fail
A penetration test and a DDoS test are reached by the same road, authorized attack traffic against your own systems, and that shared road is the whole source of the confusion. They set out the same way and arrive at different places.
One buys down the chance that someone gets in. The other buys down the chance that everyone else cannot. Those are not two views of one risk. They are two different risks, and the only thing they have in common is the method used to probe them.
Which is why the "no DoS" line in a penetration-testing scope is not a hole in the assessment. Read correctly, it is a signpost. It points at the door to the room next door, the availability workstream, and tells you to go test that separately, on its own terms, with its own runbook and its own report. The mistake was never running a penetration test without a DDoS test. The mistake is assuming the first one was ever supposed to contain the second.