An Incident Playbook, Not a Dashboard: What CISOs Actually Need

A security dashboard is not a decision-making tool during an active DDoS attack. When an incident is in progress, the CISO and the operations team need predetermined decision trees, not graphs. Which WAF rule to enable first. Who has the credentials to log in to the Cloudflare dashboard. What constitutes acceptable degradation before declaring an incident. What the escalation path to the DDoS mitigation vendor looks like. These are the answers a playbook provides. No dashboard delivers them.

DDactic's assessment output includes a draft incident playbook alongside the findings report. The playbook is not a generic template -- it is derived from the specific vendor stack, attack surface, and organizational contacts discovered during the assessment. A playbook written for an Akamai customer at a financial services firm with a 30-minute RTO looks different from one written for a Cloudflare customer at a SaaS company with a 4-hour RTO.

What a Dashboard Actually Shows

Security dashboards show historical and real-time metrics: request rates, block counts, response time percentiles, and error rates. This information is useful for two purposes: confirming that an attack is occurring (diagnosis) and verifying that a mitigation action had an effect (verification). It is not useful for deciding what to do. The decision logic -- which rule to enable, when to call the upstream provider, when to failover to a backup site -- must be predetermined and documented before the incident. During an attack, the pressure is too high and the time window too short for original thinking.

The Anatomy of a DDoS Playbook

A functional DDoS incident playbook has five components. First, a detection threshold: the specific metric values (requests per second, error rate, response time) that trigger the playbook. Second, a classification decision tree: based on observed traffic characteristics (volumetric vs. L7, single-IP vs. distributed, specific endpoint vs. global), which attack type applies and which mitigation path follows. Third, a tiered response sequence: the ordered list of actions to take, starting with the fastest/safest and escalating to more aggressive measures. Fourth, contact and credential information: who to call, what credentials are needed, and where they are stored. Fifth, a rollback procedure: how to undo each mitigation action if it causes false positives or breaks production traffic.

Pre-Populated Playbooks from Assessment Findings

The value of grounding a playbook in assessment findings is specificity. DDactic's assessment identifies the actual high-risk endpoints for the specific organization -- not a generic list. The playbook's classification section can therefore reference real paths: "If request rate to /api/v2/search exceeds 80 rps, enable Rule ID X." The specific rule ID is the one DDactic identified as calibrated correctly for that endpoint's saturation threshold. This specificity reduces the cognitive load on the responder during an incident: they are executing a predetermined action with known parameters, not making configuration decisions under pressure.

Playbook Maintenance

A playbook becomes outdated the moment the infrastructure changes. API paths added after the playbook was written are not covered. Contact information for employees who have left is useless. The solution is to include playbook review as a deliverable in each DDactic reassessment cycle. Each cycle verifies that the playbook's referenced rules still exist in the WAF, that contacts are current, and that the detection thresholds are still calibrated to the current application's performance baseline. This keeps the playbook actionable rather than archival.