The first employee note and the first customer statement of a breach should be drafted and pre-approved before the breach occurs, not composed under pressure while an incident is live. Atlassian, which publishes the incident communication templates it uses internally, states the reasoning plainly: in the heat of a service outage the response team is under pressure and every second counts, and sitting down to a blank page to figure out how to update customers is harder than it seems. A breach communications plan that carries approved boilerplate for the earliest messages removes that blank page. The natural place to write and stress-test those messages is a tabletop exercise, where wording can be argued over and cleared by legal and leadership without a clock running.
What a breach communications plan actually has to answer
A cyber incident communications plan should define who speaks, who approves messages, what channels are used, and how updates are issued, according to Datapath's template guidance for regulated organizations. Those four questions map directly onto the first messages an organization sends. The employee note and the customer statement each need a named author, a named approver, a delivery channel chosen in advance, and a stated cadence for follow-up.
GitLab's Security Incident Communications Plan makes those assignments concrete. It maps out the who, what, when, and how of notifying internal stakeholders and external customers, and it applies to security events scored at high impact or greater under GitLab's risk matrix. GitLab designates a Security Communications Manager on Call to coordinate external communications and liaise across teams so all parties are activated, updated, and aligned. The team-appointed communications manager is the directly responsible individual for drafting the initial messages, identifying stakeholders for review, and routing approvals from support, security leadership, and legal. GitLab's separate external communications function is engaged only once first-draft content has been developed. That sequence assumes a draft already exists to react to, which is exactly what pre-drafting during an exercise produces.
Why the drafting belongs in the exercise, not the incident
NIST's incident-handling guidance places communications inside the preparation phase rather than treating it as an afterthought. Google Cloud, describing an incident response plan template aligned to NIST Special Publication 800-61 Revision 2 (the Computer Security Incident Handling Guide), lists building and maintaining an incident handler communications plan among the preparation-phase tasks, alongside contact information, an issue tracking system, a war room, and encryption software for communications. Red Canary notes that NIST has since published SP 800-61 Revision 3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management," which frames the response lifecycle through the six functions of the Cybersecurity Framework 2.0, including govern and identify. Communications work sits with preparation and governance, before detection.
Drafting the first messages during an exercise surfaces the disagreements that would otherwise stall a live response. The single hardest decision in early breach communication is how much to say when the scope is still unknown, and that decision is a tradeoff between speed and accuracy that legal and security leadership weigh differently. Atlassian's own template for a situation where impact and scope are unconfirmed says only that the team is investigating reports of a potential service interruption and will post another update as soon as more is known. That deliberately narrow wording is a choice about legal exposure and credibility. Making that choice in advance, and getting it approved, means the CMOC is not negotiating language with counsel while customers wait.
An incident communications template versus an incident response plan
The two documents are often conflated, but they do different work. Red Canary describes an incident response plan template as a structured blueprint an organization uses to systematically address and manage incidents across the full lifecycle. A communications template is narrower. It supplies the actual message language.
| Incident response plan | Incident communications template | |
|---|---|---|
| Scope | Detection, containment, eradication, recovery, and post-incident review | The wording of internal and external messages |
| Primary users | The full response team and its leadership | The communications manager and approvers |
| What it produces | Coordinated technical and organizational action | A message ready to send after placeholders are filled |
| When it is exercised | Across the whole scenario | At the moment a stakeholder must be told something |
Red Canary emphasizes that a plan template can and should be tailored to an organization's environment. The same holds for message templates. Atlassian ships its examples with bracketed placeholders such as impacted services, general impact, and time until next update, and instructs users to update the placeholder sections before posting and to edit the copy to make it their own. A template is a starting structure, not a finished statement.
The two messages worth pre-approving first
Two audiences receive word before almost anyone else: employees and customers. Both benefit from separate, pre-cleared drafts.
- The first employee note. Atlassian maintains a separate internal status page distinct from its public one, with its own message that an incident is under investigation affecting named products and that updates will follow via email and Statuspage shortly. An internal note keeps staff from speculating or freelancing to customers before facts are confirmed, and it can be cleared by leadership during an exercise without the legal sensitivity of an external release.
- The first customer statement. This is the message with the most legal weight, because it can be read as an admission or a promise. GitLab routes external drafts through security leadership and legal for approval before deployment. Pre-drafting a holding statement, of the kind Atlassian uses for an unconfirmed investigation, gives responders a legally reviewed baseline that can go out fast and be expanded as scope firms up.
Both drafts need the update cadence built in. Atlassian's outage templates each end with a "next update in" field, committing the organization to a rhythm rather than a single announcement. Setting that interval in advance is itself a decision that leadership can make calmly during preparation.
What leadership owns
Google Cloud's template guidance frames breach exposure as a board-level matter. It states that dismissing the current risk of an attack puts leaders at risk of breaching their fiduciary responsibilities to shareholders, customers, and business partners, and that no cybersecurity protection plan is complete without an effective incident response plan. It also stresses that the plan's sponsor must have the full support of leadership, because without leadership buy-in the plan is destined to fail.
That buy-in has a specific communications consequence. If the general counsel and senior leadership approve the first employee note and the first customer statement during a tabletop exercise, the approval authority that would otherwise become a bottleneck at 2 a.m. has already been exercised. The tradeoff a board faces is between the discomfort of pre-approving language for an event that has not happened and the delay and inconsistency that follow when no approved language exists. GitLab's model, in which the communications manager on call drafts first and pre-identified approvers from support, security, and legal review, only functions at speed if those approvers have seen and endorsed the message architecture beforehand. The exercise is where that endorsement is earned.
