A DDoS test plan is the document you write while you are calm, so that no one has to make its decisions while the error rate is climbing.
It is a written artifact, authored before any traffic is generated, that fixes the parts of a DDoS test you cannot safely improvise: what is in scope, who authorized it, what the test is trying to learn, when it runs, how far it is allowed to go, and the exact conditions under which it stops. Everything in it is a decision that becomes harder to make well the moment adversarial traffic is flowing.
This post is about the plan itself, the sections it must contain and why each one exists, not the methodology behind the test or the order in which you execute it. The complete guide to DDoS testing covers the methodology; the step-by-step procedure covers the order you run it in. Here the subject is the document a competent team hands to its stakeholders before the first packet, and how to write one you can actually use.
What a DDoS test plan is
A DDoS test plan is a written specification of a controlled DDoS test, agreed before execution, that defines scope, authorization, success criteria, schedule, blast-radius limits, and abort conditions.
It is not a run-book of attack commands and it is not a report. It sits earlier than both: it is the contract that says what will happen, inside what boundary, measured against what, with whose sign-off, and how it will be stopped if it goes wrong.
The reason the artifact matters is timing. Most of the judgment in a DDoS test has to be exercised before the test, because the test itself is the worst possible moment to exercise it. You cannot negotiate a rate ceiling while a control is already saturating. You cannot obtain written authorization while the on-call engineer is paging the security team about traffic they were never told about. You cannot decide what "success" means after the fact without turning a lucky survival into a passing grade.
A plan pre-commits every one of those decisions to paper, while everyone can still think clearly.
The plan versus the test
A useful way to hold the distinction: the test generates traffic; the plan governs it. The generator is interchangeable, one team's hping3 and custom harness, another's commercial platform, and the traffic it produces is roughly the same. What separates a defensible engagement from an expensive risk is entirely in the governing document: the boundary, the authority, the measurement, and the stop line. Two teams can run the identical attack profile and produce opposite outcomes, one a clean characterization, the other a self-inflicted outage, purely on the strength of what they wrote down first.
The sections a plan must contain
A complete plan answers seven questions in order, and each section exists to foreclose a specific failure. The table is the plan's table of contents.
| Section | What it fixes in writing | The failure it prevents |
|---|---|---|
| Scope and targets | The exact assets in and out of scope, and named shared dependencies | Collateral damage to something the test never named |
| Authorization and RoE | Written sign-off, provider policy, notifications, who may continue | Running a test no one with authority approved |
| Success criteria | The questions the test will answer, as measured outcomes | Mistaking survival for a passing result |
| Schedule and window | The window, lead times, and who is notified | Tripping incident response, or an ISP black-holing you |
| Blast-radius limits | Rate ceilings, canary boundary, traffic caps | An escalation with no ceiling becoming the outage |
| Go/no-go gate | The pre-flight checklist that must be green to launch | Starting with a safeguard missing |
| Abort and rollback | The measured stop conditions and the kill switch | A stop decision made too late, under pressure |
The reporting section belongs in the plan too, defined up front rather than written afterward, for a mechanical reason covered at the end: you cannot report evidence you did not instrument for.
Scope and targets
Scope is the first section because it is the boundary every later section refers to. It names the assets under test, the hostnames, IP ranges, load balancers, API endpoints, and DNS zones that traffic may be directed at, and, just as importantly, the assets explicitly out of scope.
The out-of-scope list is not filler. In a shared environment, the asset you are attacking is rarely isolated. It sits behind the same edge, the same scrubbing tenancy, the same upstream link, or the same account-wide concurrency quota as systems you did not intend to touch. A flood aimed at one endpoint that saturates a shared load balancer has just tested three services, two of them without authorization.
So scope has a third, easy-to-omit part: the named shared dependencies. Before the test, walk the path from the attack ingress to the target and list every component that other systems also depend on, the anycast edge, a NAT gateway, a firewall's connection table, a database connection pool, a message bus. Each one is either brought into scope deliberately, with its own owner notified, or bounded away by the blast-radius limits. What you cannot do is discover it mid-test.
Authorization and rules of engagement
This section is the one that keeps the test legal and the team employed, and it has more parts than most first-time planners expect.
Written authorization from the asset owner. Explicit, in writing, from the party that legally owns the target infrastructure, naming the scope, the window, and the rollback procedure. Verbal approval and a Slack thumbs-up are not authorization; the plan carries the signed grant of authority, and the test does not begin without it.
Provider and platform policy. A test that runs inside a public cloud is also governed by that provider's simulated-DDoS policy, which typically gates high-intensity or volumetric testing separately from ordinary use, sometimes requiring advance notice or an approved testing partner above a threshold. The plan records which policy applies and that its requirements were met. Policies and thresholds change, so the plan cites the current published policy rather than a remembered number.
Third-party and carrier notification. Volumetric traffic does not respect your account boundary on the way in. It transits your ISP or transit provider, and an unannounced spike can trip their automatic mitigation, or worse, get your prefix black-holed, turning a test into a real outage delivered by your own upstream. Where the test intensity warrants it, the plan names who is notified and when: the carrier, the scrubbing provider, and any managed-security vendor whose detection would otherwise treat the test as a live incident.
Rules of engagement. The RoE state who may authorize continuation past a checkpoint, who is on the call, which vectors are permitted, and what is expressly forbidden. They exist so that decisions during the test route to a person with standing authority, rather than stalling while error rates climb.
Authorization framed this way is a boundary, not a formality. It is the difference between an adversarial test and an actual attack: the same packets, distinguished only by a documented grant of authority to send them.
Success criteria
This is the section that separates a test from a stunt, and it is the one most often left blank.
A stunt generates traffic and observes whether the site falls over. A test states, in advance, the specific questions it will answer and the measurements that answer them. "The site stayed up" is not a success criterion; it is the absence of one. A test whose only pass condition is survival cannot distinguish a stack that absorbed the attack from a stack that the attack simply did not reach.
Write success criteria as measurable outcomes tied to the controls under test. For example:
- The WAF rate limit fires against a distributed source and the enforced rate is within a stated tolerance of its configured value, in
BLOCKand not merelyCOUNTmode. - The detection-to-mitigation interval for the tested profile is measured, not assumed, and falls under a stated ceiling.
- The fraction of legitimate requests served, the goodput, holds above a floor throughout the attack window, so the false-positive cost of mitigation is quantified rather than ignored.
- Any mitigation cut-over window, the transient interval while a defense engages, is observed and its exposure measured.
Note what these have in common: each is a number the test is designed to produce, decided before the test so the instrumentation captures it. Criteria written afterward are indistinguishable from a description of whatever happened to occur.
Success criteria also depend on what the test is capable of proving, which is a function of the testing approach. A static, single-source script and a distributed, adaptive test answer different questions, so their criteria differ; the approaches compared treatment is worth reading before you commit to what a given plan can honestly claim to validate.
Schedule and the maintenance window
The schedule section fixes when the test runs and, critically, who knows it is running.
The window is normally off-peak, chosen to minimize the legitimate traffic that shares the blast radius, and long enough to include a low-intensity validation pass before the real escalation. But the load-bearing part of this section is notification, because an un-notified test is indistinguishable from a real attack to everyone who was not told.
The plan names the notification list and the lead time: the operations and on-call teams (so a real incident during the window is not mistaken for the test, and the test is not mistaken for a real incident), the security team and SOC (so detections are correlated, not escalated), the provider and carrier where their policy requires it, and any downstream partners whose monitoring watches your endpoints. The point is not ceremony. It is that a DDoS test exercises the technical stack, and the human incident-response path is not the thing under test; firing it by accident wastes the window and burns trust.
There is a subtle scheduling trap worth naming: the quietest window for legitimate traffic is often also the window with the thinnest on-call coverage. The plan resolves the tension explicitly rather than defaulting to whichever is convenient, because the abort path depends on someone being awake to walk it.
Blast-radius limits
The blast radius is how much can be affected if the test behaves worse than expected, and this section bounds it. It is where the plan's caution becomes numeric.
Blast-radius limits are three things written as values, not intentions:
- Rate ceilings. A hard cap on aggregate transmission rate, set below the level expected to cause uncontrolled failure, so that escalation has a top. The ceiling is decided here, while calm, because it is exactly the number nobody can set sensibly once a control is already bending.
- The canary boundary. Where production must be involved, the fraction of the fleet or the single region the test is confined to, with a documented way to drain it instantly. A finding confined to a canary is a finding; the same finding across the whole fleet is an incident.
- Traffic caps and shape. The per-source and per-vector bounds that keep the aggregate inside the ceiling and keep any single shared dependency from being driven past a point the plan did not intend.
These limits are what make the go/no-go and abort gates meaningful: a gate can only stop a test at a boundary that was defined in advance. The mechanics of keeping a test inside these limits, the canary methodology, the kill switch, the instrumentation, are their own discipline, worked through in running a DDoS test without disrupting production. The plan's job is to state the numbers; that post covers how to hold them.
The go/no-go gate
The go/no-go gate is a single pre-flight checkpoint: a checklist that must be entirely green before the first packet, and a named person who owns the decision to proceed.
It exists because the cheapest moment to stop a test is before it starts. Every item on the list is a precondition the earlier sections already defined; the gate is where you confirm they are actually true right now, not merely written down.
A workable go/no-go checklist:
- Written authorization is in hand and covers today's scope and window.
- Provider and carrier notifications required by policy have been sent and acknowledged.
- Monitoring and instrumentation for every success criterion are live and confirmed emitting.
- A baseline has been captured, so attack-condition deltas will be meaningful.
- The abort path has been tested end to end, the kill switch actually drops traffic, at low intensity, this session, not last month.
- The stakeholder and on-call notifications have gone out and the escalation contacts are reachable.
If any item is red, the answer is no-go, and "no-go" is a normal, cheap outcome. A test deferred because the kill switch was not verified is a plan working correctly. The gate's value is precisely that it makes stopping the default when a safeguard is missing, rather than something someone has to argue for while momentum is building.
Abort and rollback gates
If the go/no-go gate decides whether the test starts, the abort gate decides, continuously, whether it should keep going. It is the most operationally important section of the plan, and it must be written before anyone is under pressure, because its entire purpose is to remove judgment from the moment when judgment is worst.
Abort criteria are pre-agreed, specific, and preferably automated conditions that stop the test. They are measured, not felt: a threshold on error rate against legitimate traffic, a latency ceiling, a saturation signal on a shared dependency, a duration bound on any degradation. "Stop if it looks bad" is not an abort criterion, because under pressure everything looks bad and nothing does. A number that a monitor can evaluate is.
The kill switch is the mechanism the criteria trigger: a single action that drops all synthetic traffic to zero within seconds. The plan states what it is and records that it was tested during the go/no-go pass. An abort criterion with a slow or untested kill switch is a stop sign at the bottom of a hill.
Standing authority to abort. The people on the escalation path can halt the test without assembling a quorum. Routing every stop through a synchronous approval reintroduces exactly the latency the kill switch exists to eliminate. The plan names who holds this authority and makes clear that pulling the switch is never the wrong call.
Rollback. Anything the test changed, a WAF rule toggled for a scenario, a mitigation record's TTL lowered, a feature flag flipped, is returned to its prior state, and the plan lists those items so nothing is left drifted after the window closes. A test that ends but leaves the stack in a modified state has traded a controlled event for a latent one.
The reporting section, defined up front
The last section of the plan describes the first artifact of the aftermath, and it belongs in the plan for one mechanical reason: you cannot report a measurement you did not capture, and you capture what you instrument for before the test, not after.
Defining the report up front forces the success criteria and the instrumentation to agree. If the plan says the report will state the detection-to-mitigation interval and the goodput floor, then the monitoring for both has to be live at the go/no-go gate, which is exactly where the checklist confirms it. A report specified afterward, by contrast, routinely wants a number nobody was recording, and that number is gone.
The plan does not need the full report structure, that is the deliverable's concern, and it overlaps with what a packaged readiness assessment formalizes, but it should name the outcomes the test must produce evidence for, so the instrumentation is built to that specification rather than to hope.
FAQ
What is a DDoS test plan?
A DDoS test plan is a written document, authored before a controlled DDoS test, that defines the test's scope and targets, its authorization and rules of engagement, the success criteria it measures against, the schedule and notification list, the blast-radius limits, and the go/no-go and abort conditions. It is the artifact that governs the test, distinct from the traffic-generating tools and from the report produced afterward.
What should a DDoS test plan include?
At minimum: scope and explicitly out-of-scope assets with named shared dependencies; written authorization plus provider, carrier, and stakeholder notifications; measurable success criteria tied to the controls under test; the maintenance window and who is notified; blast-radius limits as concrete values (rate ceilings, canary boundary, traffic caps); a go/no-go pre-flight checklist; abort criteria with a tested kill switch and rollback steps; and the reporting outcomes the test must instrument for.
Why write a plan instead of just running the test?
Because most of the judgment a DDoS test requires has to be exercised before the test, when everyone can think clearly. Rate ceilings, authorization, notification, and the conditions to stop cannot be decided well once traffic is flowing and a control is already saturating. The plan pre-commits those decisions to paper so no one is improvising scope, authority, or the stop line under pressure.
Who needs to authorize a DDoS test?
The legal owner of the target infrastructure, in writing, covering the specific scope and window. Depending on intensity and environment, the cloud provider's simulated-DDoS policy may also apply, and the ISP or transit carrier and any managed-security vendor may need advance notice so the test is not mistaken for a real attack and mitigated or black-holed.
How is a test plan different from a runbook?
A runbook is a sequence of operational steps to execute; a test plan is the governing specification that says what may happen, inside what boundary, measured against what, with whose authority, and how it stops. The runbook operates inside the boundary the plan defines. One is the how; the other is the mandate and the limits.
The plan is where the test is won or lost
Nearly every failure mode of a DDoS test is authored, or foreclosed, before any traffic runs. The collateral outage is an unnamed shared dependency. The legal exposure is a missing signature. The meaningless result is an absent success criterion. The self-inflicted incident is an un-notified carrier. The runaway escalation is a rate ceiling nobody set. The late stop is an abort criterion phrased as a feeling instead of a number.
None of those is a failure of the attack traffic. Each is a failure of the document that was supposed to govern it, and each is cheap to fix on paper and expensive to fix at 3am.
That is the quiet inversion worth ending on. The instinct is to treat the plan as paperwork that precedes the real work of generating traffic. It is the reverse. The traffic is the commodity; the plan is the engineering. A test is only as good as the decisions made while everyone was still calm, and the plan is where those decisions live.