DDoS communication planning is now a trust control, not a PR task

At a glance

What this is: This is a practical guide on communicating during a DDoS attack, with the key finding that messaging discipline can matter as much as technical mitigation.

Why it matters: It matters to IAM practitioners because outage communication, customer trust, and accountability patterns increasingly intersect with identity-adjacent governance such as access assurance, service reliability, and crisis response.

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.

👉 Read DigiCert's guidance on communicating with customers during a DDoS attack

Context

DDoS response communication is the discipline of telling customers what is happening, what is affected, and when they will hear from you again while service is under stress. In this article, DigiCert treats that communication as part of operational resilience, not a separate marketing exercise.

The primary governance gap is not whether the attack is real, but whether the organisation has a prepared, truthful, and externally reachable way to explain impact without overstating compromise. For identity and security leaders, that is the same kind of coordination problem that appears in incident response, status-page governance, and customer trust management.

Key questions

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. Avoid guessing at root cause, avoid implying data theft unless you have evidence, and keep the language consistent across support, PR, and leadership. The goal is to reduce uncertainty while the technical team works.

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. Public communication is also warranted if media coverage or attacker claims are circulating. Use predetermined thresholds so the decision is not improvised under pressure.

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. That delay creates suspicion, even when the technical response is sound. Teams also over-explain technical detail, which can help attackers and confuse customers. Clear, limited, and timely communication is usually the better control.

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.

Technical breakdown

DDoS is service disruption, not data compromise

A distributed denial of service attack overwhelms or degrades availability by flooding the target with traffic, often through botnets or weaponised proxies. The point is to deny access, not to exfiltrate data, although the business reaction can still resemble a breach if messaging is sloppy. DigiCert's article correctly separates outage from intrusion because that distinction determines legal, operational, and reputational response. If teams describe every outage as a leak, they create panic; if they downplay a severe attack, they lose credibility.

Practical implication: Classify the event correctly before issuing external statements so your customer message matches the actual failure mode.

Why holding statements and update cadence matter

A holding statement is the first public acknowledgement of an incident. It should state the visible symptom, confirm investigation, and promise the next update window without exposing exploit detail. In DDoS events, silence is often read as confusion or concealment, which increases support load and social speculation. The article's 30 to 60 minute update cadence reflects a communications control loop, not a technical one: frequent, consistent updates reduce uncertainty and keep the organisation in control of the narrative while mitigation continues.

Practical implication: Pre-approve customer-facing templates and update intervals before an outage so teams can speak quickly without improvisation.

Independent status infrastructure is part of resilience

If the website is down, the website cannot reliably serve as the source of truth. DigiCert recommends off-site channels such as social media, email, and a redundant status page hosted separately from the affected environment. That pattern matters because communications availability must survive the same traffic pressure that hits the primary service. The best crisis plan is not only about what to say but where to say it, so the status channel remains available when the production stack is not.

Practical implication: Maintain a separate status and notification path that can operate even when primary web infrastructure is unavailable.

Threat narrative

Attacker objective: The attacker aims to make the service unusable long enough to create operational disruption, reputational damage, and support overload.

1. Entry begins when a botnet or proxy network starts flooding the target with high-volume traffic, often using multiple distributed sources to evade simple blocking.
2. Escalation occurs as the service becomes intermittently unavailable, support tickets spike, and social speculation expands the operational impact beyond the technical layer.
3. Impact is customer distrust, service interruption, and possible regulatory exposure if the organisation fails to communicate accurately and promptly.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The real failure mode is not outage duration alone, but narrative ambiguity. Organisations lose trust when they blur the line between DDoS, breach, and general instability. That distinction matters because a service disruption does not imply data theft, and overstatement can be as damaging as delay. The practitioner implication is to map response language to incident type before any public statement leaves the organisation.

Independent communication channels are an availability dependency. If the website is the only customer-facing update path, the organisation has no resilient way to explain the outage while under attack. That creates a secondary failure outside the DDoS itself. The practitioner implication is to treat status infrastructure as a continuity asset, not a side project.

Customer expectation management: The article exposes a simple but often missed truth, which is that communication timing shapes perceived control more than technical detail does. In practice, a well-timed acknowledgement and update rhythm can reduce ticket volume and social escalation even while remediation continues. The practitioner implication is to rehearse message timing with the same seriousness as failover testing.

Identity and access teams should read this as adjacent to incident governance. Although the article is not about NHI or IAM, the same operational discipline applies when service state, support state, and approval state must remain consistent under stress. The practitioner implication is to align crisis messaging ownership with incident response roles before the next availability event.

From our research:

• 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.
• That pattern reinforces the need to study 52 NHI Breaches Analysis for how exposed credentials and access paths turn quickly into operational incidents.

What this signals

DDoS is a reminder that availability incidents become trust incidents when organisations cannot explain them quickly and consistently. For security and identity leaders, the practical lesson is to treat external comms as part of incident control, not as a postscript. The combination of a live status page, an approved message library, and a single communications owner should be tested alongside technical resilience.

message continuity gap: the failure mode is not only downtime, but the absence of a reliable external channel that can survive the outage. That is why a separate status service, backed by redundant hosting and an internal escalation path, belongs in resilience planning. Teams building incident playbooks should align this with NIST SP 800-207 Zero Trust Architecture so critical controls are not dependent on the attacked environment.

In a broader governance sense, the article shows that customer-facing communication has measurable operational value because it reduces ticket volume, confusion, and reputational drag. The organisation that can sustain clear updates every 30 to 60 minutes is usually the one that appears most in control. That is a programme-level capability, not just a crisis skill.

For practitioners

• 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.
• Train support and account teams on a shared script Give executives, support staff, and customer-facing teams the same approved language so they do not improvise conflicting explanations during the incident.
• Publish the all-clear in phases Move from active mitigation to monitoring before declaring resolution, and only close the incident after stability is confirmed across the affected service.

Key takeaways

• DDoS response is not only a traffic problem, because poor communication can turn availability loss into a lasting trust failure.
• The article's key evidence is that attack visibility, support load, and update cadence shape customer perception as much as the outage itself.
• Teams should pre-approve statements, own a separate status channel, and rehearse escalation thresholds before the next availability incident.

Key terms

• DDoS attack: A distributed denial of service attack uses many sources to flood a target and make a service slow, unstable, or unreachable. It targets availability rather than confidentiality. The practical problem is not only network load, but the business and communication failure that follows when users cannot reach the service.
• Holding statement: A holding statement is the first public message issued during an incident when the full facts are not yet known. It confirms that the issue is being investigated, describes the visible symptom, and sets expectations for the next update. In crisis operations, it reduces uncertainty and limits speculation.
• Status page: A status page is a separate customer-facing channel used to publish incident updates when the primary service may be degraded or unavailable. It should be hosted independently so it remains reachable during an outage. For resilience planning, it is part of the communications control plane, not a cosmetic add-on.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: How to communicate to customers during a DDoS attack. Read the original.