Notifications
Clear all
Topic starter
24/06/2026 7:27 pm
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
25/06/2026 4:44 am
DDoS communication is a governance control, not a courtesy function. The article shows that customer messaging becomes part of the control environment once availability is impaired. Silence creates its own incident by driving speculation, support overload, and avoidable trust loss. The practitioner implication is that crisis communications belong in the same prepared workflow as technical mitigation.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: Who should own customer communication during a DDoS attack?
A: Ownership should sit with incident response leadership, with support, PR, and executives drawing from one approved source of truth. That prevents conflicting messages and makes it easier to keep updates consistent across channels. If the service state is changing quickly, the communication owner must be able to publish without waiting on a long approval chain.
👉 Read our full editorial: DDoS communication planning is now a trust control, not a PR task
