A distributed denial of service attack is decided in the first thirty minutes, and most of that time is lost finding the right person at the right provider. This template gives [Organisation] a ready-to-adopt playbook for detecting, mitigating and recovering from volumetric, protocol and application-layer DDoS attacks against internet-facing services. It is written for network and security operations, site reliability engineers, service owners and the managers who must decide on trade-offs such as geo-blocking or taking a service offline. Replace every [bracketed] placeholder, complete the provider contact table before you need it and test it at least yearly. For architecture and protection choices, see the DDoS Protection Guide.
How to use this template
- Adopt, then tailor: copy sections 1 to 8 into your incident response plan and fill in the provider names, contract numbers and escalation paths for each protected service.
- Prepare upstream: CISA, the FBI and MS-ISAC, and the UK NCSC all stress that most volumetric attacks cannot be absorbed on your own link; mitigation happens at your ISP, CDN or scrubbing provider. Section 2 is the most important part of this playbook.
- One playbook per service tier: a customer website behind a CDN and a VPN concentrator on a single ISP link need different steps. Duplicate section 4 per tier.
- Treat DDoS as possible cover: keep watching identity and endpoint alerts during an attack.
- Review annually and after every attack or provider change. Owner: [Head of Network Operations].
1. Scope and triggers
1.1 This playbook applies to attacks that originate online and aim to degrade the availability of [Organisation] services, networks or APIs. Physical disruption (power, radio interference) is handled under business continuity, as the NCSC guidance also scopes it.
1.2 Attack classes covered.
| Class | Typical forms | ATT&CK | Where it is best mitigated |
|---|---|---|---|
| Volumetric | UDP floods, reflection and amplification via DNS, NTP, CLDAP or memcached | T1498.001 Direct Network Flood; T1498.002 Reflection Amplification | ISP, scrubbing centre or CDN, before traffic reaches your link |
| Protocol | SYN floods, fragmented packets, state exhaustion of firewalls and load balancers | T1498 Network Denial of Service | Scrubbing provider, SYN cookies, stateless filtering ahead of stateful devices |
| Application layer | HTTP GET/POST floods, expensive search or login requests, TLS handshake exhaustion | T1499.002 Service Exhaustion Flood; T1499.003 Application Exhaustion Flood | CDN or WAF rate limits, bot challenges, caching, application changes |
1.3 Triggers: provider DDoS alert; link utilisation above [80]% for [5] minutes; synthetic monitoring failures from several regions; a spike in requests per second or new-connection rate above [x] times baseline; a ransom DDoS (RDoS) demand; or credible threat intelligence naming [Organisation] or its sector.
2. Roles and contacts
| Role | Named owner | Responsibilities |
|---|---|---|
| Incident Lead | [Security Operations Manager] | Declares the incident, owns the decision log and timeline |
| Network Lead | [Network Operations Lead] | Traffic analysis, provider escalation, routing changes, filters |
| Application Lead | [Service Owner or SRE on call] | Application-layer rules, caching, feature degradation, scaling |
| Business Owner | [Head of Digital] | Approves trade-offs: geo-blocks, disabling features, maintenance pages |
| Communications Lead | [Head of Communications] | Status page, customer and staff messages |
| Legal Counsel | [General Counsel] | Extortion demands, law enforcement, contractual and regulatory notices |
2.1 Provider escalation sheet. For every ISP, CDN, cloud and scrubbing provider record: 24/7 NOC and security phone numbers, the portal and API for emergency mitigation, account and circuit IDs, the authentication the provider will ask for, contracted mitigation capacity and time to mitigate, whether BGP diversion is always-on or on-demand, and the prefixes covered. Store a copy offline: during an attack your own email, chat or VPN may be down.
2.2 Keep an out-of-band communications channel (for example a conference bridge or messaging group on a separate provider) so responders can coordinate if corporate services fail.
3. Detection and triage
- Confirm it is an attack, not a surge: compare with marketing events, releases, upstream outages and certificate or DNS errors. Legitimate surges usually share normal referrers, user agents and session behaviour.
- Classify: from NetFlow/IPFIX, provider dashboards and load balancer logs identify the layer, the targeted IP, port or URL, protocols, packet rates, top source ASNs and countries, and whether source ports indicate reflection (for example UDP source port 53, 123 or 11211).
- Size the impact: which services are degraded, which customers affected, whether shared infrastructure (DNS, VPN, email) is collateral damage.
- Set severity: Critical when a revenue or safety service is down; High when degraded beyond SLO; Medium when absorbed by existing protection; Low for attempts with no user impact.
- Check for a second front: ask the security operations centre to watch authentication, privileged access and data egress alerts more closely during the attack.
Decision point A: if the attack saturates your link or exceeds on-premises device capacity, escalate to the upstream provider immediately; do not spend time tuning local filters first.
Evidence to preserve: flow records, packet captures (short samples are enough), WAF and CDN logs, provider attack reports, any extortion emails with full headers, and the timeline of every change you made.
4. Containment
4.1 Network and protocol attacks.
- Call the provider on the 24/7 number and open a priority ticket; give the target prefixes, attack type and start time.
- Activate on-demand scrubbing or BGP diversion for the affected prefixes, or confirm always-on mitigation is engaged.
- Ask the ISP for upstream ACLs dropping traffic that the service never needs, such as inbound UDP from reflector ports to web servers.
- As a last resort, request remotely triggered black hole routing (RTBH) for a single targeted IP. This drops all traffic to it, legitimate included, so the Business Owner must approve it.
4.2 Application-layer attacks.
- Tighten CDN or WAF rate limits on the targeted paths, keyed on client IP, session or API key. See the Rate Limiting and API Abuse Guide.
- Enable challenge or "under attack" modes for suspicious clients; block signatures shared by attack requests (user agent, header order, query pattern).
- Serve cacheable content from the edge and switch expensive endpoints (search, report generation) to a lighter mode.
- Scale out horizontally where cost limits allow, with a ceiling agreed in advance to avoid runaway cloud spend.
Decision point B: geo-blocking or disabling a feature trades availability for some users against availability for most. The Business Owner decides, and the Incident Lead records the decision and its review time.
Decision point C: do not pay a ransom DDoS demand. Legal Counsel handles any contact and the report to law enforcement.
5. Eradication
5.1 DDoS traffic has no foothold to remove, so eradication means removing the conditions that made the attack effective: exposed origin IPs reachable without the CDN, unauthenticated expensive endpoints, open resolvers or NTP services of your own being used as reflectors, and single points of failure.
5.2 Restrict origin servers to accept traffic only from the CDN or scrubbing ranges, and rotate origin IPs if they were exposed.
5.3 If the attack accompanied an intrusion attempt, run the relevant playbook (see the Incident Response Guide) to completion.
6. Recovery
- Keep mitigation in place for at least [24] hours after traffic returns to baseline; attacks often return in waves with changed vectors.
- Withdraw emergency rules in stages, starting with the ones that hurt legitimate users most (geo-blocks, challenges), while watching error rates.
- Return BGP routing to normal only after agreeing with the provider; confirm no RTBH routes remain.
- Verify service health with synthetic tests from several regions, and check queued jobs, payment callbacks and integrations that may have failed silently.
- Record cloud scaling and provider overage costs for the insurance claim and post-incident review.
7. Communication and notification
| Audience | When | Owner | Content |
|---|---|---|---|
| Providers | Immediately | Network Lead | Targets, attack type, mitigation request |
| Customers | Within [30] minutes of user impact | Communications Lead | Status page update; no detail on defences |
| Executives | Critical or High within [1] hour | Incident Lead | Impact, actions, decisions needed |
| Law enforcement and national CERT | For extortion, persistent or sector-wide attacks | Legal Counsel | Indicators, demands, timeline |
| Regulators and key customers | As contracts and rules require | Legal Counsel | Outage notice, for example under sector resilience or NIS2 incident reporting where applicable |
| Information sharing groups | After stabilisation | Incident Lead | Attack signatures and source data |
7.1 Status page and support tooling should be hosted on infrastructure separate from the attacked service.
8. Post-incident review
8.1 Within [10] business days, review: time to detect, time to provider engagement, time to mitigation, total user-impact minutes, peak bandwidth and requests per second, and cost.
8.2 Ask: did the provider escalation sheet work; were any contacts or credentials out of date; was the origin bypassable; which rule changes harmed legitimate traffic; and does contracted capacity still match observed peaks.
8.3 Update this playbook, the provider contract if needed, and the next exercise. See the Tabletop Exercise Guide.
Implementation guidance
Choosing mitigation models.
| Model | Strength | Trade-off | Fits |
|---|---|---|---|
| Always-on CDN or reverse proxy | Immediate application-layer and volumetric protection for web | Covers only proxied HTTP(S) services; origin must be hidden | Public websites and APIs of any size |
| On-demand BGP scrubbing | Protects whole prefixes and non-HTTP protocols | Minutes of impact before diversion; needs a /24 or larger and tested runbooks | Larger organisations with their own address space |
| ISP clean pipe | Simple, contractual, no routing changes | Capacity tied to one ISP; limited application-layer help | Small and mid-sized organisations |
| Cloud provider native protection | Integrated with cloud load balancers and autoscaling | Scope limited to that cloud; scaling costs | Cloud-hosted workloads |
| On-premises appliances | Fast local response to protocol and application attacks | Cannot stop floods larger than the link | Complement to upstream mitigation, never a replacement |
Rollout.
- Inventory internet-facing services, their IPs, DNS, hosting and dependencies; rank them by business impact (the NCSC's first step: understand your service).
- Confirm upstream defences and contracted capacity with each provider; fill in the escalation sheet.
- Agree graceful degradation options per service: static fallback pages, read-only modes, disabling heavy features.
- Test: a tabletop first, then a provider-supported diversion drill in a maintenance window. Use only an authorised testing service, and inform providers beforehand.
- Rollback: document how to withdraw every emergency rule and routing change, and test that too.
Small vs large organisations. A small organisation usually relies on a CDN plan and its ISP; its key work is hiding the origin and holding the provider contacts. A large or regulated organisation needs multi-provider coverage, BGP diversion drills and DNS hosted with resilient anycast providers.
Metrics. Mean time to detect; mean time to mitigate after detection; user-impact minutes per incident; percentage of internet-facing services behind upstream mitigation; days since the escalation sheet was last verified; false-positive blocks during mitigation.
Framework mapping.
| Framework | References |
|---|---|
| NIST CSF 2.0 | PR.IR-04 capacity; DE.CM-01 network monitoring; DE.AE-02 event analysis; RS.MA-01 coordination with third parties; RS.MI-01 containment; RS.CO-02 notification; RC.RP-01 recovery |
| NIST SP 800-53 Rev. 5 | SC-5 Denial-of-service Protection; SC-7 Boundary Protection; SI-4 System Monitoring; IR-4 Incident Handling; IR-8 Incident Response Plan; CP-2 Contingency Plan |
| ISO/IEC 27001:2022 Annex A | A.5.24 incident management planning; A.5.29 security during disruption; A.8.6 capacity management; A.8.20 networks security |
| MITRE ATT&CK | T1498, T1498.001, T1498.002, T1499, T1499.002, T1499.003 |
Where identity fits. Mitigation portals, BGP and DNS consoles and CDN API tokens can redirect or disable all your traffic. Protect them with phishing-resistant MFA and short-lived, scoped API credentials, and keep break-glass access that works when single sign-on is down.
Standards and references
- CISA, FBI and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks
- NCSC: Denial of Service (DoS) guidance
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1498 Network Denial of Service
- MITRE ATT&CK: T1499 Endpoint Denial of Service
- IETF: RFC 7999 BLACKHOLE Community
Related NHI Mgmt Group resources: DDoS Protection Guide · Rate Limiting and API Abuse Guide · DDoS Protection Buyer's Guide · Incident Response Guide