Who should own customer communication during a DDoS attack?

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.

Why This Matters for Security Teams

During a DDoS attack, customer communication is not a public-relations side task. It is part of incident control. The owner needs enough authority to publish timely, accurate updates while drawing technical facts from incident response, network engineering, support, and executive stakeholders. If that role is unclear, messages drift across channels, support teams improvise, and customers lose trust faster than the service is restored.

NHI Management Group’s research shows how quickly identity and access weaknesses can compound under pressure, especially when response workflows are fragmented; see the Ultimate Guide to NHIs — Why NHI Security Matters Now. The same operating reality applies to communications: the first version of the message is rarely the hardest part, but the follow-up cadence and approval path often determine whether the organisation looks controlled or confused. External advisories from CISA cyber threat advisories reinforce that incident response depends on pre-defined roles, not ad hoc decision-making. In practice, many security teams encounter communication failure only after customers have already seen inconsistent outage updates across status pages, support scripts, and executive statements.

How It Works in Practice

The cleanest operating model is to assign one communications owner inside incident response leadership, then give support, PR, and executives a single source of truth to reuse. That owner should not invent technical detail. Instead, they should translate incident facts into customer-safe language, using regular check-ins with the incident commander, network operations, and legal or regulatory contacts where needed. The goal is speed with consistency, not committee-based writing.

Current guidance suggests that the communication owner should have pre-authorised publishing authority for time-sensitive updates, especially when the service state is changing rapidly. That reduces delay when a new mitigation step changes impact, ETA, or customer instructions. It also helps separate audience needs:

• Customers need clear impact, workaround, and restoration timing.
• Support needs approved talking points and escalation triggers.
• Executives need concise business impact and decision points.
• Security and operations need factual alignment before anything is published.

This approach works best when it is documented in the incident runbook, tested in tabletop exercises, and tied to a shared status workflow. The Top 10 NHI Issues research from NHI Management Group is relevant here because the same governance problem appears whenever multiple actors need to act from one trusted record. For communication, that record should be the approved incident brief, not informal chat threads. Public statements should also be aligned with threat guidance from CISA cyber threat advisories and, where adversary behavior is relevant, intelligence from the MITRE ATLAS adversarial AI threat matrix can help teams understand how attackers exploit disruption and confusion.

These controls tend to break down when legal review, executive sign-off, and operational validation are all required for every update because the communication owner loses the ability to publish during live service degradation.

Common Variations and Edge Cases

Tighter approval control often reduces legal and reputational risk, but it also increases the chance of stale updates, so organisations have to balance governance against speed. That tradeoff becomes sharper when the attack is prolonged, when multiple regions are affected, or when customers rely on the service for time-sensitive operations.

Best practice is evolving for scenarios where the incident includes suspected data exposure, extortion, or critical infrastructure impact. In those cases, the owner of customer communication may need a more formal coordination path with legal, privacy, and executive leadership, but the role should still remain singular. Shared authorship usually creates delay and inconsistency. The same is true when the status page, support desk, and social channels are all active at once: one owner should approve the message, while others adapt the same text for their channel.

For organisations that operate globally, local regulatory obligations can change what is disclosed and when. That does not remove the need for one owner; it makes the ownership clearer. The owner should coordinate a release sequence so that internal briefings, customer notices, and public updates do not conflict. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that fragmented governance increases exposure across technical and operational domains alike. During a DDoS event, the same pattern applies to communications: if the message cannot move at incident speed, customers will assume the worst before restoration is complete.

Related resources from NHI Mgmt Group

• What breaks when DNS becomes the choke point during an attack?
• How should security teams reduce DDoS risk for internet-facing services?
• Why does DDoS mitigation need DNS monitoring as well as traffic filtering?
• Who is accountable when DNS availability fails during a DDoS attack?