Itnetic TechnologiesWhat a DDoS response plan is — and is not
A DDoS response plan is a one-page operational document that says, in advance, what your team does when traffic stops being traffic. It is not a mitigation strategy and not a replacement for one. Filtering attack traffic is the job of your edge; the plan covers everything the edge cannot decide for you: who owns the incident, when you escalate, what you tell customers, what evidence you keep, and when you declare it over.
The distinction matters because the two get confused. If you are down right now, you want the ordered checklist in how to stop a DDoS attack. If you want the mechanics of filtering itself, read what is DDoS mitigation. This guide is for the calm afternoon before either is needed — the hour of preparation that makes the incident hour survivable.
Decide these five things before the attack
Every one of these is a decision someone will otherwise make under pressure, badly, while the site is down.
| Decision | Settle it now | What it costs to decide live |
|---|---|---|
| Who is incident lead | Name a person and a backup, with contact methods that work at 03:00 | Ten minutes of "has anyone told Petr?" while nobody acts |
| What counts as an incident | A threshold: error rate, origin saturation, or a mitigation alert firing | Arguing about whether this is "really" an attack |
| Who may change production | Pre-authorize the lead to tighten protection, enable challenge mode, cache harder | Waiting on an approval chain that is asleep |
| What customers are told | A holding statement, drafted and approved, with the channel it goes out on | Improvised wording you later have to correct |
| What evidence is kept | Log export, timestamps, targeted endpoints, sample request IDs | Reconstructing the incident from memory a week later |
Roles: who does what
Small teams do not need an org chart, they need two named roles and permission to act.
- Incident lead — owns the timeline, makes the calls, keeps a running log of actions and times. On a one-person team this is you, and the plan's value is that it tells you the order to work in.
- Communications owner — updates the status page and answers customers, so the lead is never writing tweets while debugging. On a two-person team this is the other person.
- Escalation contacts — your hosting provider's support path, your mitigation provider's support path, and, for extortion cases, the law-enforcement contact you would actually use. Put the account numbers and login paths in the plan; you do not want to be hunting for a customer ID mid-incident.
Write these as names, not job titles. "The on-call engineer" is not a person at 3am.
The first hour, minute by minute
The plan should hold a timeline this concrete. Adapt the times to your setup, but keep the shape.
| Time | Action | Owner |
|---|---|---|
| T+0 | Alert fires or an outage is reported. Incident lead acknowledges and starts the action log | Lead |
| T+5 | Confirm it is an attack, not a deploy or an outage: request volume against baseline, endpoint concentration, origin CPU versus bandwidth | Lead |
| T+10 | Tighten mitigation — strictest challenge mode, rate limits on the targeted endpoints, cache the pages under fire | Lead |
| T+15 | First customer-facing update goes out, even if it says only that you are investigating | Comms |
| T+30 | Verify the origin is not reachable directly, and that no unproxied DNS record is leaking it | Lead |
| T+45 | Capture evidence: export logs for the window, note targeted paths, sources and sample request IDs | Lead |
| T+60 | Second update: current state and next update time. Decide whether to escalate to your providers | Comms |
The single most common failure in this hour is not technical. It is that the diversion step — getting traffic through a filter at all — is being done for the first time, mid-incident, while DNS propagates. That is the argument for always-on protection made concrete: with Itnetic's DDoS protection already in front of the site, T+10 is a settings change rather than an onboarding project, and the first ten minutes of the attack are absorbed rather than spent.
Make the plan start itself
A plan that begins with "someone notices the site is slow" begins too late. Wire up three independent triggers:
- External uptime monitoring from outside your own network, checking a real page rather than a health endpoint that stays cheap under load.
- Mitigation alerts from the edge, which see the attack before your origin feels it. Itnetic sends real-time attack alerts to Discord the moment a domain enters attack mode, so the alert arrives on a channel your team already reads.
- Origin health signals — CPU, connection count and error rate on your own server, which distinguish a Layer 7 flood from a bandwidth event.
Define the threshold that turns a signal into an incident, and write it down as a number. "Error rate above 5% for two minutes" is a plan; "if it seems bad" is a group chat.
What to tell customers
Say something within fifteen minutes, and say it in plain language. Two rules keep you out of trouble: never promise a restoration time you cannot control, and never disclose defensive detail that would help the attacker tune the next wave.
A holding statement worth pre-approving reads roughly like this:
We are aware that [service] is slow or unreachable for some users, starting at [time, with timezone]. The cause is a surge of malicious traffic and mitigation is in progress. No customer data is affected. The next update will be posted by [time].
That last sentence is the one that stops the support queue from growing: an audience that knows when the next update lands stops asking for it. If the attack arrived with a payment demand attached, do not mention the ransom publicly and do not pay — the reasoning and the response are in ransom DDoS attacks.
Capture evidence while it is happening
Post-incident review, insurance claims, board questions and law-enforcement reports all need the same material, and all of it is easier to collect during the attack than after it:
- Start and end timestamps in UTC, plus the moment each mitigation change took effect.
- Which endpoints were targeted, and the request rate they took.
- Source characteristics: networks, countries, user agents and client fingerprints.
- Sample request IDs for both blocked and allowed traffic, so you can later show what got through.
- What the attack cost you — the arithmetic is in how much does a DDoS attack cost.
This is exactly what per-request evidence is for. Itnetic's request logs and analytics record status, latency, client fingerprint and WAF verdict for every request, so the review is an export rather than a reconstruction. Check your provider's retention window before you need it — evidence that ages out before your post-mortem is not evidence.
The runbook template
Keep the document to one page. Anything longer does not get read at 3am. The headings that earn their space:
- Trigger — the numeric thresholds that declare an incident, and who they page.
- Roles — incident lead, backup, communications owner. Names and phone numbers.
- First hour — the timeline table above, adapted to your stack.
- Access — where the mitigation dashboard, DNS registrar, hosting panel and status page live, and who holds credentials for each.
- Escalation — provider support paths with account identifiers, and the threshold at which you use them.
- Comms — the pre-approved holding statement, the channel, and the update cadence.
- Evidence — the list above, and where the export lands.
- All clear — what "over" means (traffic and error rate back to baseline for a defined period), who declares it, and who unwinds the emergency settings.
Store it somewhere reachable when your own site is down — a shared document, not your wiki behind the origin you are trying to defend. Print a copy if your team is small enough that this sounds reasonable rather than quaint.
Rehearse it, or it is fiction
Twice a year, walk the plan end to end: page the lead, open the dashboards, confirm the credentials work, post a test update to a staging status page. The point is not to simulate the flood — it is to discover that the alert goes to a former employee's address, or that nobody but one person can change DNS. Safe, legal ways to exercise the technical half are in how to test your DDoS protection.
Then close the loop on the part of the plan you can remove entirely: the steps that exist only because protection is not already on. With always-on edge filtering in place, an origin locked to your mitigation network, and attack traffic that is never billed back to you, the plan shrinks to observing, communicating and recording — which is a plan a small team can actually execute.