Most DDoS outages last longer than they need to because the work that matters was never done before the attack: the mitigation provider was never onboarded, the origin address was public, nobody knew the ISP's emergency number and the runbook had never been tested. This checklist records whether an internet-facing service is ready for a distributed denial-of-service attack, covering exposure and dependencies, provider onboarding and the choice between always-on and on-demand mitigation, DNS and origin protection, network and application hardening, monitoring baselines, runbooks, contacts and testing. It is written for network, platform and site reliability engineers, service owners and incident managers. Choosing a provider is covered in the DDoS Protection Buyer's Guide, attack mechanics in the DDoS Protection Guide and the actions during an attack in the DDoS Response Playbook; this page proves you are ready before any of those are needed.
How to use this template
Complete one checklist per internet-facing service or per shared edge (for example a CDN account that fronts several sites). Replace text in square brackets, such as [Organisation], [Network lead] and [15 minutes], with your own values. Bracketed numbers are suggested defaults.
Mark each check Pass, Fail or Not applicable and record where the evidence is kept. "We think the provider does that" is a Fail until a contract clause, portal screenshot or test result shows it.
Review the checklist at least [annually], after any change of provider, ISP, DNS host or hosting platform, and after every DDoS incident.
The CISA, FBI and MS-ISAC guide Understanding and Responding to Distributed Denial-of-Service Attacks (version 2.0, March 2024) groups attacks into volumetric, protocol and application attacks; the checks below cover all three.
1. Service record
Field
Entry
Service name, owner and business criticality
[Service] [Team, name] [Tier 1 / 2 / 3]
Public hostnames, IP prefixes and autonomous system numbers
[Own data centre / colocation / public cloud region / SaaS front end]
Upstream ISPs and circuit capacity
[ISP A, 10 Gbps] [ISP B, 10 Gbps]
Mitigation in place
[Always-on scrubbing / on-demand scrubbing / CDN with WAF / ISP service / cloud provider native protection / none]
Tolerable outage before material impact
[From business impact analysis, for example 30 minutes]
Review date, reviewer, result
[Date] [Name] [Ready / Ready with findings / Not ready]
2. Exposure and dependency mapping
#
Check
Result and evidence
2.1
A risk assessment identifies which services, networks and applications an attacker would target and the impact of each being unavailable, as the CISA guide recommends before choosing protections.
[ ]
2.2
Every public IP address and hostname for the service is in the inventory, including legacy hosts, test environments, mail and VPN gateways. Unknown exposed hosts are the ones attackers use to bypass protection.
[ ]
2.3
Hidden dependencies are listed: authoritative DNS, identity provider and single sign-on pages, payment gateways, third-party APIs, status page and customer contact channels. Each has its own DDoS position recorded.
[ ]
2.4
The most expensive operations per request (search, login, basket, report generation, uncached API calls) are known, because application-layer attacks target them first.
[ ]
2.5
Bandwidth, connection table, load balancer and firewall session limits are recorded, so the team knows which component fails first.
[ ]
2.6
Autoscaling limits and cost alarms are set, so an attack on cloud-hosted services cannot run up unbounded spend or exhaust account quotas.
[ ]
3. Provider onboarding and mitigation model
Choose the mitigation model per service from its tolerable outage and traffic profile, then prove onboarding is complete. The table is our editorial summary of typical behaviour, not a provider specification; confirm mitigation times and limits in each provider contract.
Model
How it works
Time to mitigate
Best fit
Watch out for
Always-on scrubbing or CDN proxy
All traffic passes through the provider's network all the time
Immediate for most attacks
Tier 1 web and API services with low outage tolerance
Origin must be hidden and locked to the provider, or attackers go round it
On-demand scrubbing (BGP or DNS diversion)
Traffic is diverted to scrubbing centres when an attack is detected
Minutes, depending on detection and diversion method
Diversion must be pre-tested; manual activation adds delay at night
ISP clean pipe or upstream filtering
The ISP filters or blackholes attack traffic before it reaches your circuit
Minutes to hours
Volumetric attacks that would saturate the link
Remotely triggered blackholing drops legitimate traffic to the target too
Cloud provider native protection
Platform protection for resources hosted in that cloud
Automatic for network-layer attacks
Workloads already in that cloud
Application-layer protection usually needs separate WAF rules and tuning
#
Check
Result and evidence
3.1
The contract states protected assets, mitigation capacity, time to mitigate, support hours, escalation path and whether attack traffic is billed.
[ ]
3.2
All hostnames and prefixes in section 1 are onboarded in the provider portal, with health checks and alert recipients configured.
[ ]
3.3
For on-demand BGP diversion: route objects, Letters of Agency or RPKI route origin authorisations allow the provider to announce your prefixes, and a test diversion has been performed. NIST SP 800-189 recommends RPKI and BGP origin validation for interdomain routing.
[ ]
3.4
For on-demand activation: who may activate it, through which channel (portal, phone, API), and how long it took in the last test are documented.
[ ]
3.5
Upstream ISPs have been asked what filtering, rate limiting and blackholing they offer, how to request it and how quickly, as the CISA guide advises. The answers are recorded. See the RTBH and BGP Flowspec DDoS Mitigation Guide.
[ ]
3.6
Accounts for the provider portal and DNS host use phishing-resistant multi-factor authentication, named users and least privilege, and API tokens used by automation are inventoried and rotated. An attacker who controls the portal can switch protection off.
[ ]
4. DNS and origin protection
#
Check
Result and evidence
4.1
Authoritative DNS is hosted on an anycast service with DDoS protection, or with at least two independent providers, so a DNS attack does not take every service down at once.
[ ]
4.2
DNS record time-to-live values for records that may need to change during an attack are short enough ([300 seconds] or less) for DNS-based diversion to take effect quickly.
[ ]
4.3
Origin servers accept traffic only from the provider's published address ranges or through an authenticated tunnel or mutual TLS, enforced at the firewall or security group.
[ ]
4.4
Origin IP addresses are not exposed through historic DNS records, mail headers, TLS certificates on the origin, subdomains that bypass the proxy, or error pages. Origins exposed in the past have been re-addressed.
[ ]
4.5
Your own recursive resolvers are not open to the internet, and authoritative servers use response rate limiting, so they cannot be used as amplifiers. NIST SP 800-189 lists response rate limiting among DDoS mitigation tools.
[ ]
4.6
Registrar and DNS host accounts are locked (registrar lock, multi-factor authentication, restricted users) so an attacker cannot redirect the domain during the confusion of an attack.
[ ]
5. Network and application hardening
#
Check
Result and evidence
5.1
Source address validation (ingress filtering, unicast Reverse Path Forwarding or access control lists) is applied at your network edges so your network cannot send spoofed traffic, as NIST SP 800-189 recommends.
[ ]
5.2
Unused UDP services commonly abused for reflection (for example NTP monlist, SSDP, memcached, open SNMP and CLDAP) are not reachable from the internet on your hosts.
[ ]
5.3
Rate limits are set per client and per expensive endpoint (login, search, API) at the CDN, WAF or gateway, in monitor mode first and then enforced.
[ ]
5.4
Challenge mechanisms (JavaScript or CAPTCHA challenges, bot management) can be switched on for specific paths within [15 minutes], and the procedure is documented.
[ ]
5.5
Static and cacheable content is cached at the edge, and an emergency static or reduced-function version of the site exists so core information stays online if dynamic services must be shed.
[ ]
5.6
Load balancing and redundant capacity exist across [two or more] sites, regions or circuits, with tested failover, matching the CISA guide's advice on redundancy.
[ ]
5.7
Web servers and proxies are patched for protocol-level denial-of-service flaws (for example HTTP/2 rapid reset) and use sensible timeouts and connection limits. See the HTTP/2, HTTP/3 and QUIC Security Guide.
[ ]
6. Monitoring and alerting baseline
#
Check
Result and evidence
6.1
A baseline of normal traffic (bits and packets per second, requests per second, top source countries and autonomous systems, error rates) exists per service, as the CISA guide recommends, so deviations stand out.
[ ]
6.2
Flow telemetry (NetFlow, IPFIX or sFlow) from edge routers, plus CDN, WAF and load balancer logs, reach the monitoring platform with retention of at least [30 days].
[ ]
6.3
Alerts fire on link utilisation above [80 percent], request rates above [3x baseline], origin error rates and provider attack notifications, and route to an on-call rota around the clock.
[ ]
6.4
External synthetic monitoring from several networks checks availability, so the team knows when customers are affected even if internal monitoring is also degraded.
[ ]
6.5
The security operations team watches for activity during the attack window, because DDoS is sometimes a distraction from intrusion or fraud.
[ ]
7. Runbooks, contacts and communications
Contact
Name or desk
Phone and portal
Account or circuit ID
Last verified
DDoS mitigation provider security operations
[ ]
[ ]
[ ]
[ ]
Upstream ISP A network operations
[ ]
[ ]
[ ]
[ ]
Upstream ISP B network operations
[ ]
[ ]
[ ]
[ ]
DNS host and registrar
[ ]
[ ]
[ ]
[ ]
Cloud or hosting provider support (with support tier)
[ ]
[ ]
[ ]
[ ]
National reporting point and law enforcement
[For example CISA and the local FBI field office in the US; the NCSC and Report Fraud (which replaced Action Fraud on 4 December 2025) in the UK; Police Scotland on 101 in Scotland]
[ ]
[ ]
[ ]
#
Check
Result and evidence
7.1
A DDoS runbook exists for the service with roles, decision points and pre-agreed mitigations (enable challenge, activate scrubbing, shed features, request upstream filtering), following the DDoS Response Playbook.
[ ]
7.2
The runbook and contact list are available offline and outside the affected service, since the intranet or ticketing system may be unreachable.
[ ]
7.3
Out-of-band communication (phone bridge, secondary chat platform) is set up for the response team.
[ ]
7.4
Customer and staff messages are pre-drafted, and the status page is hosted independently of the service it reports on.
[ ]
7.5
The evidence to collect (timestamps, attacking addresses, packet captures, logs) and who collects it are defined, so reporting to law enforcement is possible afterwards, as the CISA guide recommends.
[ ]
7.6
The handling of ransom demands and extortion threats is agreed with legal and executive leadership in advance. See the NoName057 DDoS Hacktivist Group Profile Guide for an example of a group that targets public services.
[ ]
8. Testing and sign-off
#
Check
Result and evidence
8.1
A tabletop exercise on a DDoS scenario was run in the last [12 months] with the provider and ISP contacts dialled for real. See the Tabletop Exercise Guide.
[ ]
8.2
On-demand diversion and failover were tested in a planned window, with time to mitigate recorded.
[ ]
8.3
Any load or attack simulation was authorised in writing by the asset owner, the hosting or cloud provider (under its testing policy) and the mitigation provider, and run against agreed targets in an agreed window. Unauthorised testing against third-party infrastructure is not acceptable.
[ ]
8.4
Findings have owners and due dates, and the runbook was updated after the test.
[ ]
8.5
The service owner and [Head of Network or CISO] signed off the result.
[ ]
Implementation guidance
Do the cheapest high-value work first. Inventory public addresses, collect ISP and provider emergency contacts, lock down origin access and move authoritative DNS to a protected anycast service. These take days, not months, and remove the most common reasons a DDoS outage drags on.
Match the model to the service. Put Tier 1 web and API services behind always-on protection; use on-demand scrubbing for whole prefixes and non-web protocols where a few minutes of disruption is acceptable. Small organisations with only a website often get enough from a CDN with DDoS protection and locked origins; organisations with their own prefixes need BGP diversion and upstream agreements as well.
Introduce limits safely. Deploy rate limits and WAF rules in log or monitor mode for [one to two weeks], compare with real traffic, then enforce. Keep previous edge configuration versioned so a rule that blocks customers can be rolled back in minutes.
Measure readiness. Track the share of internet-facing services with a completed checklist in the last [12 months], time to mitigate in the last test, share of origins that accept only provider traffic, contact list verification date, and mean time from alert to mitigation in real incidents.
Revisit after every attack. Feed each incident's timeline into this checklist; most findings are a missing contact, an unknown exposed host or a slow manual activation.
Avoid the common failure patterns. The same gaps recur: an always-on service whose origin still answers on its public address, an on-demand contract that was signed but never had a test diversion, contact lists that name people who have left, alerts that go to a mailbox nobody watches at weekends, rate limits that were left in monitor mode indefinitely, and a status page hosted on the very platform under attack. Each maps to a check above (4.3, 8.2, section 7, 6.3, 5.3 and 7.4); treat any of them as a high-severity finding.
Framework mapping
Checklist area
NIST SP 800-53 Rev. 5
NIST CSF 2.0
ISO/IEC 27001:2022 Annex A
Capacity, redundancy and mitigation (sections 2, 3, 5)
SC-5, SC-5(2)
PR.IR-03, PR.IR-04
8.6, 8.14
Origin and network boundary (sections 4, 5)
SC-7
PR.IR-01
8.20, 8.22
DNS (section 4)
SC-20
PR.IR-03
8.20
Monitoring (section 6)
SI-4
DE.CM-01
8.16
Runbooks, contacts and testing (sections 7, 8)
IR-4, CP-4
RS.MA-01, ID.IM-02
5.24, 5.30
MITRE ATT&CK maps these attacks as T1498 Network Denial of Service and T1499 Endpoint Denial of Service.
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.