Is Your DDoS Response Runbook Ready for the First Hour?

What must a DDoS first-hour runbook accomplish?

A DDoS response runbook is ready for the first hour when it gives named people authority to confirm the outage, engage providers, protect critical services, preserve evidence, and communicate on timed checkpoints. It must also separate automatic mitigation from human decisions, because many attacks finish before a manual response can start.

Key takeaways

• A first-hour runbook must name decision owners, provider contacts, protected services, evidence sources, and communication channels.
• Automated detection and mitigation must operate before the incident commander begins the human coordination sequence.
• Each checkpoint must produce evidence that another team can verify, rather than a vague instruction to monitor the attack.
• A tabletop exercise must test provider escalation, degraded communications, secondary-attack monitoring, and recovery authority.

CISA defines a DDoS attack as multiple machines operating together against one target, often through compromised devices. That CISA page is explicitly archived and may not reflect current policy or programs, so this article uses it only for the DoS and DDoS definitions, not for current response advice.

The timing problem is measurable. Cloudflare reported for January through June 2026 that it mitigated 23.2 million network-layer DDoS attacks, about 5,343 per hour, and that 90.60% ended within 10 minutes. Those are observations from Cloudflare's network, not a forecast for every Philippine enterprise, but they show why a first-hour plan cannot begin with manual traffic filtering.

The Philippine governance anchor is Executive Order No. 58 (2024), which adopted the National Cybersecurity Plan 2023–2028 as the whole-of-nation cybersecurity roadmap and directed national government bodies to align their plans. NIST SP 800-61 Rev. 3 (2025) states: “Incident response is a critical part of cybersecurity risk management and should be integrated across organizational operations.” A DDoS runbook should therefore connect technical mitigation to business continuity, communications, and accountable command.

Who must act during the first 60 minutes?

The first 60 minutes need one incident commander, five functional owners, and pre-agreed authority boundaries. NIST SP 800-61 Rev. 3 assigns incident-response responsibilities across technology teams, legal, public affairs, leadership, and third parties; it also recommends defining who may disconnect or shut down technology assets. The table below converts those sourced role classes into a DDoS-specific operating model.

Owner	First-hour decision	Evidence to retain	Escalation trigger
Incident commander	Declare severity, set checkpoints, and approve recovery actions.	Timeline, decisions, and named owners.	Critical service remains unavailable at a checkpoint.
Network and security operations	Confirm the affected layer, validate automatic mitigation, and watch unaffected assets.	Traffic graphs, alerts, packet samples, route changes, and control actions.	Capacity, device, or attack-vector threshold is exceeded.
ISP, cloud, or mitigation provider	Confirm ticket ownership, mitigation state, route state, and next update time.	Ticket number, contact name, timestamps, and provider actions.	Provider misses an update or cannot contain the traffic.
Application and infrastructure team	Test critical user journeys and dependencies after each control change.	Synthetic-test results, error rates, dependency status, and rollback state.	Service remains impaired after traffic is controlled.
Communications, legal, and privacy	Approve messages for staff, customers, regulators, and partners when required.	Approved wording, audience, channel, approver, and send time.	Impact or reporting criteria cross the approved threshold.
Executive sponsor	Resolve business-priority conflicts and accept residual risk.	Priority decision and recorded risk acceptance.	Two critical services compete for scarce recovery capacity.

This is an original responsibility matrix built from NIST's role guidance and the interagency coordination direction in EO 58; the specific checkpoints are internal targets, not government-mandated deadlines. Your DDoS protection service requirements should identify which provider owns each network action. Your security services operating model should identify who confirms alerts and preserves evidence.

The runbook should also name alternates and an out-of-band channel. NIST recommends that incident-response plans be established, communicated, maintained, and improved, and that plans address dependencies on external parties. A contact name without authority, a ticket portal without an emergency path, or a conference bridge that depends on the affected identity service is not a usable first-hour control.

What should happen at each first-hour checkpoint?

Each first-hour checkpoint should pair a decision with an owner, a time target, and retained evidence. The sequence below is an original 60-minute operating target for tabletop testing; it is not a claim that every attack will be contained within one hour.

1. Minutes 0–10: confirm and command. The on-call lead correlates user impact, monitoring, provider status, and critical-service tests; declares severity; opens the timeline; assigns the incident commander; and confirms that automated mitigation is active. Cloudflare's H1 2026 finding that 90.60% of network-layer attacks ended within 10 minutes means detection evidence must survive even when traffic subsides before the bridge opens.
2. Minutes 10–20: engage external capacity. The provider owner supplies the ticket number, affected prefixes or applications, observed attack type, mitigation status, and next update time to the ISP, cloud provider, or mitigation service. The incident commander records exactly what the provider will do and what remains under enterprise control.
3. Minutes 20–40: protect services and watch for diversion. Network and application owners prioritize approved user journeys, validate route or policy changes, monitor unaffected assets, preserve telemetry, and assess whether another incident is occurring. NIST's Detect, Respond, and Recover functions cover discovery, management, prioritization, containment, eradication, recovery, notification, and incident communications.
4. Minutes 40–60: decide the next operating state. The incident commander chooses continued mitigation, controlled failover, restricted service, or recovery; assigns the next checkpoint; and approves a stakeholder message based on measured impact. The decision record states remaining risk, evidence gaps, owner, and review time.

This sequence complements, rather than replaces, a sourcing decision between always-on and on-demand DDoS protection. It also belongs inside the wider Infocentric services lifecycle, because provider selection, implementation, support, and managed operations determine whether the runbook's contacts and controls exist when needed.

What should your team test before approving the runbook?

Your team should approve the runbook only after a timed exercise proves that people can reach providers, make authorized changes, validate services, preserve evidence, and communicate while normal channels are degraded. NIST SP 800-61 Rev. 3 says documented procedures can be periodically tested or exercised to verify accuracy and train personnel.

How often should a DDoS runbook be exercised?

How often should a DDoS runbook be exercised?

NIST does not prescribe one universal DDoS exercise interval. Set a risk-based schedule, then run an additional exercise after material network, provider, application, or authority changes. Each exercise should record elapsed times, missed contacts, failed evidence collection, unclear decisions, and assigned corrections before the plan is approved again.

What evidence should the incident commander retain?

What evidence should the incident commander retain?

Retain the incident timeline, severity decision, traffic and service measurements, alerts, provider tickets, named contacts, route or policy changes, approvals, stakeholder messages, and recovery tests. NIST treats incident reporting, notification, and communications as part of Detect, Respond, and Recover, so technical and management records belong in one reviewable chronology.

Should the team wait for attack attribution?

Should the team wait for attack attribution?

No. Service protection and evidence preservation should proceed without waiting to identify the attacker. CISA's archived definition explains why attribution is difficult: DDoS uses multiple machines and may use compromised devices. Use that statement only as a definition-level observation; current operational decisions should follow your tested plan, providers, and current threat intelligence.

When should executives or communications teams join?

When should executives or communications teams join?

They should join at pre-approved impact thresholds, not after technical teams improvise a message. NIST includes leadership, legal, and public affairs among incident-response participants. The runbook should state who approves each audience, what evidence supports the message, which channel remains available, and when the next update is due.

What makes the runbook release-ready after a test?

What makes the runbook release-ready after a test?

The runbook is release-ready when every critical service has an owner, every provider path has been reached, every authority boundary has been exercised, every evidence source has been captured, and every failed step has a dated correction owner. NIST recommends maintaining and improving incident-response plans when significant improvements are identified.