TL;DR: Customer communication during a DDoS attack can shape trust, support load, and compliance outcomes more than the outage itself, while stressing that a DDoS event is usually service degradation, not data theft, according to DigiCert. That makes crisis messaging a governance control, not just a public-relations function.
NHIMG editorial — based on content published by DigiCert: How to communicate to customers during a DDoS attack
By the numbers:
- Mega-attacks over 100Gbps and tsunami attacks over 1Tbps remain relatively infrequent.
- Communications teams should expect update cadences every 30 to 60 minutes during an incident.
- DigiCert cites a 10 to 15 minute duration threshold before escalating a public communication plan.
Questions worth separating out
Q: How should organisations communicate during a DDoS attack without causing panic?
A: Start with a holding statement that names the symptom, confirms investigation, and sets the next update window.
Q: When should a DDoS incident be escalated to customers publicly?
A: Escalate when the outage is visible to users, support demand spikes, or the disruption persists long enough to become a business event rather than a transient glitch.
Q: What do security teams get wrong about DDoS response communication?
A: They often treat messaging as a PR afterthought and wait too long to tell customers what is happening.
Practitioner guidance
- Pre-write holding statements Draft short, accurate customer statements for DDoS, outage, and suspected compromise scenarios so the team can publish immediately without inventing language under pressure.
- Separate the status channel from production Host the public status page and notification path on independent infrastructure so it stays reachable when the primary website or application is under load.
- Define escalation triggers in advance Use objective triggers such as visible degradation, ticket spikes, and sustained duration to decide when internal triage becomes public communication.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Exact customer messaging examples for the first acknowledgement and subsequent updates
- Decision thresholds for moving from internal triage to public incident communication
- Recommended channel mix for keeping customers informed when the primary site is unavailable
- Guidance on avoiding disclosure that could help attackers fine-tune their methods
👉 Read DigiCert's guidance on communicating with customers during a DDoS attack →
DDoS response messaging: what IAM and security teams miss?
Explore further