DDoS Response Plan: The First 30 Minutes of an Attack

A DDoS response plan defines who confirms an attack, who controls mitigation and who communicates internally and externally. During the first 30 minutes, clear ownership and reliable measurements matter more than frantic individual changes.

Prepare before an attack

• 24/7 contacts for the upstream, mitigation provider, data centre and internal decision makers.
• A current inventory of critical prefixes, services, ports, protocols and dependencies.
• Baselines for bandwidth, packets per second, connections and response times.
• Pre-agreed procedures for scrubbing, BGP FlowSpec and remote-triggered blackholing.
• Templates for the status page, customer communication and internal updates.
• A named incident commander with a deputy and decision authority.

Minutes 0 to 5: confirm the situation

First verify that a DDoS attack is actually taking place. Compare monitoring, NetFlow or sFlow, router utilisation, packet loss and application metrics. At the same time, do not dismiss obvious alternatives such as a routing fault, failed deployment or upstream outage.

1. 1Record the start time, affected services and visible symptoms.
2. 2Classify the rough vector: bandwidth, packet rate, protocol or application.
3. 3Alert the incident commander and technical contacts.

Minutes 5 to 10: escalate

Contact the upstream through the agreed emergency channel. Provide the ASN, prefix, start time, observed volume, protocols and actions already taken. A precise first report substantially reduces the time required to apply the right filter.

Minutes 10 to 20: control mitigation

Activate or verify the planned mitigation. Volumetric attacks must be filtered before the saturated link. Avoid uncoordinated ACL changes across many devices. Every change needs an owner, a timestamp and a measurable purpose.

• Verify scrubbing diversion or the always-on policy.
• Use targeted FlowSpec rules only for clearly identified patterns.
• Use blackholing only as a last resort and as narrowly as possible.
• Check stateful firewalls and load balancers for exhausted tables.

Minutes 20 to 30: verify and communicate

Assess the result from a real user's perspective. Falling attack volume is not enough when DNS, login or the API still fails. Update the status page with confirmed facts, a timestamp and the next planned update. Avoid speculation about attackers or causes.

After the attack

• Preserve the full timeline, attack vectors, volume and filter actions.
• Identify alerts that arrived too late or did not trigger a clear action.
• Remove temporary rules and deploy permanent improvements in a controlled way.
• Update the runbook, contacts and communication templates from the experience.
• Review the response with engineering, support, management and relevant providers.

Conclusion

A good DDoS response plan reduces decisions under pressure. Teams that clarify measurements, contacts, approvals and mitigation paths in advance gain the minutes that separate a short incident from a prolonged outage.