What it is

A staged set of communications templates for responding to a security incident. It covers every audience you’ll need to reach — internal teams, affected customers, all customers, media, and regulators — in the order you’ll need to reach them.

The templates are deliberately minimal and legally cautious. In a security incident, your biggest comms risk is saying too much, too early, with too much certainty. These drafts give you a defensible holding position at each stage while investigations are ongoing, then a fuller communication once facts are confirmed.

Each stage has a separate approval requirement, because the sign-off chain for a holding line is different from the sign-off chain for a customer notification that may trigger regulatory obligations.

This is a B2B SaaS context playbook. It assumes you have customers whose data may be involved, a product or platform that may have been compromised, and regulatory obligations under GDPR or similar frameworks.

When to use it

Use this template when:

A security incident has been confirmed (or is highly suspected) and you need to communicate before all facts are known
Customer data, personal data, or system access may have been compromised
You need regulatory notification (ICO 72-hour window under GDPR Article 33 is a common trigger)
You’re preparing communications in the first hours of response before the facts are fully established
You’re doing incident response preparation before anything has happened (adapt into playbook format)

Do not use this template if:

The incident is purely internal and involves no customer data or regulated information
The incident is contained, fully investigated, and you’re ready to communicate complete facts — use a standard customer email template instead
This is an operational outage with no security element — use a service status/incident update format

Inputs needed

Before starting, confirm:

Incident classification: What type of incident is this? (Data breach / unauthorised access / ransomware / credential stuffing / third-party compromise / other)
Affected scope: How many customers or users are affected, and what data is involved?
Containment status: Is the incident ongoing, or has it been contained?
Discovery timeline: When was it discovered, and what actions have been taken so far?
Regulatory threshold: Is personal data involved in a way that triggers GDPR Article 33 notification to ICO within 72 hours?
Legal status: Is Legal/DPO looped in? Have they confirmed what can and can’t be said?
Approval chain: Who needs to approve each stage? What is their contact and availability?

The template

Stage 1 — Internal holding statement (Hours 0–4)

Purpose: Align internal teams on what has happened, what is known, and what people should/should not say externally. Send to all employees before any external communication goes out.

INTERNAL — NOT FOR EXTERNAL DISTRIBUTION

Subject: Security incident — internal update [Date/Time]

We are aware of [a security incident / an issue affecting our systems / an incident under investigation] and our response team is currently investigating.

What we know: [State only confirmed facts. E.g.: “At [time] on [date], we identified [specific issue]. Our security team is currently investigating the scope and cause.”]

What we don’t yet know: [E.g.: “We are still determining whether customer data was affected and the full scope of the incident.”]

Actions taken so far: [List specific steps: systems isolated, external security firm engaged, regulatory body notified, etc.]

What NOT to do:

Do not discuss this incident on social media or with anyone outside the company
Do not respond to media enquiries — direct all to [press contact name and email]
Do not reassure customers or partners that their data is safe until this has been confirmed by the investigation
Do not speculate on cause or responsibility

Next update: [Time] or sooner if new information is available.

Contact for questions: [Name, role, direct channel — e.g. Slack channel #incident-response]

Stage 2 — Customer notification — affected users (Hours 4–48, once scope confirmed)

Purpose: Notify the specific customers whose data or accounts were affected. Requires Legal and DPO sign-off before sending. Triggers GDPR Article 34 obligations if there is high risk to affected individuals.

Subject: Important security notice about your [Company] account

Dear [Customer name / [FIRST NAME]],

We are writing to inform you that [Company] recently experienced a security incident that may have affected your account.

What happened

On [date], we [discovered / were notified of] [brief, factual description of incident — e.g. “unauthorised access to a subset of our customer database”]. We immediately [took containment action — e.g. “took the affected systems offline and engaged an independent security firm to investigate”].

What data was involved

The following information associated with your account may have been accessed: [list specific data types — e.g. name, email address, encrypted password hash]. [If applicable: Your payment details are stored separately with our payment provider and were not affected.]

What we have done

[Action 1 — e.g. “Contained the incident and taken the affected system offline”]
[Action 2 — e.g. “Engaged external forensic security specialists to conduct a full investigation”]
[Action 3 — e.g. “Notified the Information Commissioner’s Office (ICO) as required by GDPR”]
[Action 4 — e.g. “Reset affected account passwords as a precautionary measure”]

What you should do

[Recommended action 1 — e.g. “Change your [Company] password immediately, even if we have already reset it”]
[Recommended action 2 — e.g. “If you use the same password elsewhere, change those accounts too”]
[Recommended action 3 — e.g. “Be alert to any suspicious emails claiming to be from [Company]”]

Our commitment to you

We take the security of your data seriously. [One sentence on what you are doing structurally — e.g. “We are conducting a full review of our security practices and will implement additional measures as a result of this investigation.”]

If you have questions, please contact [dedicated incident contact — e.g. security@company.com or a specific DM channel]. We will provide further updates as the investigation progresses.

[Name] [Title] [Company]

Stage 3 — All-customer notification (Hours 24–72, if appropriate)

Purpose: Notify your full customer base, even those not directly affected, if the incident is significant enough to affect trust. Use judgement — not every incident requires all-customer communication. Requires CEO/senior leadership approval.

Subject: A message from [Company] about our security

Dear [Customer name / [FIRST NAME]],

I want to share an important update about a recent security incident at [Company] and what we are doing about it.

What happened

On [date], we [brief factual summary]. Your account data [was / was not directly affected], but I want to be transparent with you about what occurred and how we have responded.

What we have done

[3–4 bullet points on concrete actions taken — be specific, not vague]

What this means for your account

[If not affected: “Your account data was not accessed in this incident.” / If affected: Direct them to the separate notification sent to affected accounts]

Our commitment going forward

[Specific structural changes you are making — not generic platitudes. E.g. “We have commissioned an independent security review and will share the findings with customers by [date].”]

I am personally available to answer questions. Please write to [email] or [channel].

[CEO name] [Company]

Stage 4 — Press/media holding statement

Purpose: A brief statement for any media enquiries during the active investigation. Authorised by Legal and CEO. Do not expand this until the investigation is complete.

[Company] is aware of a security incident affecting [scope — e.g. “a subset of our systems”] and is conducting a full investigation with the support of external security specialists. We are in contact with relevant regulatory authorities and are notifying affected customers directly. We will provide further information as the investigation progresses.

[Do not add speculative detail. Do not name the cause, method, or suspected source. Do not state data is “safe” until confirmed.]

Stage 5 — Post-incident summary (Once investigation complete)

Purpose: A transparent public summary of what happened, how you responded, and what you are doing to prevent recurrence. This is your reputation-restoring document.

Subject: [Company] security incident — final update

Overview

On [date], [Company] experienced [brief description]. The incident has now been fully investigated and resolved. This is our complete account of what happened, what we did, and what we are changing.

The timeline

Date/Time	Event
[Date]	Incident first detected
[Date]	External investigation engaged
[Date]	ICO notified
[Date]	Affected customers notified
[Date]	Incident contained and systems restored
[Date]	Investigation complete

Root cause

[Plain-language explanation — cleared by Legal — of the technical or procedural cause. Avoid jargon. Avoid blame. Be specific enough to be credible but not so specific as to invite copycat attacks.]

Impact

Accounts affected: [Number or “none confirmed”]
Data types involved: [List]
Duration of exposure: [Timeframe]

Changes we are making

[Specific, named commitments — e.g. “Implementing mandatory multi-factor authentication for all accounts by [date]”, “Engaging [firm type] for annual penetration testing”, “Completing third-party security audit by [date]”]

Regulatory outcome

[Brief statement on regulatory engagement — e.g. “We have worked with the ICO throughout the investigation and have received confirmation that [outcome or that it remains under review].”]

If you have any remaining questions, contact [email].

[CEO name]

AI prompt

Base prompt

I need to draft communications for a security incident. Please help me create a staged set of messages for different audiences.

Incident details:
- What happened: [Describe the incident]
- When discovered: [Date/time]
- Systems or data affected: [What was compromised or potentially compromised]
- Affected user scope: [All users / subset — how many / internal only]
- Containment status: [Contained / ongoing / under investigation]
- Regulatory notification required: [Yes — ICO within 72hrs / No / Unknown]
- Current approved actions taken: [List steps taken so far]

Please draft:
1. An internal holding statement for employees (not for distribution)
2. A notification to directly affected customers
3. A press holding statement (2–3 sentences maximum)

For each draft:
- State only confirmed facts
- Avoid speculating on cause or responsibility
- Include specific actions taken (not vague reassurances)
- Include clear next steps for the recipient
- Flag any [REQUIRES LEGAL REVIEW] moments where language is legally sensitive

Prompt variations

Variation 1 — GDPR-specific notification:

I need to draft a customer notification that satisfies GDPR Article 34 requirements for a high-risk breach. The incident involved [data types]. Draft a notification that:
- Identifies the nature of the breach in plain language
- Lists the categories and approximate number of individuals concerned
- Names the Data Protection Officer or contact point
- Describes likely consequences of the breach
- Lists the measures taken or proposed to address the breach, including to mitigate its possible adverse effects
Flag where legal review is mandatory before sending.

Variation 2 — Third-party supplier incident:

Our data was potentially compromised not by us, but by a third-party SaaS tool we use: [Tool name/type]. We don't control what happened, but our customers' data was at risk through our use of that supplier. Help me draft communications that:
- Are honest about the third-party nature of the incident without deflecting responsibility
- Explain what data we shared with that supplier and why
- Describe what we have asked the supplier to do and their current response
- State what we are doing to protect our customers going forward
- Avoid language that sounds like blame-shifting to the supplier

Variation 3 — Low-severity incident (precautionary notification):

We have experienced a security incident that we have contained and investigated. There is no confirmed evidence that any customer data was accessed or exfiltrated, but we cannot rule it out with 100% certainty. Help me draft a precautionary customer notification that:
- Is honest about the uncertainty without being alarming
- Explains what we investigated and how
- Recommends precautionary actions (password reset, etc.)
- Does not make definitive statements we cannot support
- Strikes a tone that is transparent and responsible without causing undue panic

Variation 4 — Internal comms for team under pressure:

We're in the middle of a security incident response. Our team is under enormous pressure and I need to send an internal update that:
- States clearly what we know and what we don't (no speculation)
- Reminds people of their specific responsibilities during the incident
- Clarifies the media and customer comms protocol (all enquiries to [name])
- Provides emotional support without minimising the severity
- Sets clear expectations for the next update
Keep it factual, calm, and short. This is for engineers, product, and support staff.

Variation 5 — Post-incident summary for board/investors:

Our security incident has now been resolved. I need to write a post-incident summary for our board and investors that covers:
- What happened (clear, factual, without unnecessary technical detail)
- Timeline of response (showing we acted promptly)
- Regulatory outcome (ICO engagement and outcome)
- Customer impact (numbers, scope, churn risk)
- Structural changes we are making to prevent recurrence
- Reputational risk assessment and our recovery plan
Tone: responsible, not defensive. Clear-eyed about what went wrong. Specific about remediation.

Human review checklist

Before any external communication is sent:

Content quality checks:

Does the communication specify what data was or was not affected (not vague “information”)?
Are recommended actions for customers specific and actionable?
Does the timeline in the post-incident summary accurately reflect actual events?
Have you listed specific structural changes — not generic “we take security seriously” language?
Is the tone appropriate — serious without being catastrophising?

Example output

Stage 1 internal holding statement — SaaS company, B2B data breach (illustrative)

INTERNAL — NOT FOR EXTERNAL DISTRIBUTION

Subject: Security incident — internal update, 14:30 Thursday

We have identified unauthorised access to a subset of our customer database and are currently investigating the scope. This is an active incident.

What we know: At 11:47 this morning, our monitoring systems detected unusual query patterns on the customer accounts database. We have isolated the affected system. An external security firm (Incident Response Partners) has been engaged and work begins this afternoon.

What we don’t yet know: Whether customer data was accessed or exfiltrated. This is the priority question our investigation will answer.

Actions taken:

Affected database server isolated at 12:05
External IR firm engaged at 13:00; on-site by 15:00
DPO notified; ICO notification assessment underway (72-hour clock started)
Passwords for all admin accounts reset as precaution

What NOT to do: Do not discuss this with anyone outside the company, including via personal social media. Do not reassure customers or partners about data safety — we do not yet know the facts. Direct all media enquiries to Sarah Collins (sarah@company.com, 07XXX XXXXXX).

Next update: 18:00 today, or sooner if scope is confirmed.

Questions: #incident-response Slack channel only.

This illustrative example shows a holding statement 2–3 hours into a confirmed incident. Note: specific facts (time, firm name), clear unknowns, and unambiguous instructions for staff. No reassurances about data safety until confirmed.

Crisis Content Pre-Approval Pack — Pre-approve holding statements and response formats before an incident occurs
Approval Workflow Mapper — Map your multi-stage sign-off chain for incident communications
Claims Substantiation Checklist — Verify factual accuracy of all statements before release
Stakeholder Mapping Matrix — Identify all stakeholders who need to be informed

Tips for success

Prepare this before you need it. The worst time to design your security comms playbook is during an incident. Complete the sign-off chain section in advance, identify your DPO and external IR firm, and pre-approve holding language with Legal so you can move in minutes not hours.

Confirm facts before stating them. In a fast-moving incident, initial reports are often wrong. “We believe X” and “our investigation suggests Y” are acceptable in early comms. “No customer data was affected” is only acceptable when you can prove it. Overstating certainty early creates a much worse correction problem later.

Treat the 72-hour GDPR clock as real. The ICO clock starts from when you become aware of a probable breach — not when it’s confirmed. Log the exact time of discovery and track it. Notification that is technically late but substantively identical to an on-time one still incurs enforcement risk.

Separate customer-facing from press-facing drafting. These audiences have different needs and the same draft rarely serves both. Customers need specifics about their data. Media need headline facts and a responsible response narrative. Write them separately and approve them separately.

Don’t outsource empathy to AI. AI is useful for structuring communications and ensuring factual completeness. The human element — the acknowledgement of impact, the genuine commitment to change — should be written and owned by a person. The post-incident summary especially should read like it came from a real human who cares about what happened.

Common pitfalls

Using vague language that sounds reassuring but says nothing. “We take the security of our customers’ data extremely seriously” is meaningless. Every company says it. Specific actions (“We engaged an external forensic firm within two hours of detection”) are credible. Generic platitudes are not.

Sending an all-customer notification when a targeted one is sufficient. Not every incident warrants telling everyone. If only 200 accounts were affected, an all-customer email may cause more alarm and reputational damage than the incident itself. Work with Legal to determine the appropriate scope.

Approving draft language before the investigation confirms the facts. Sending a customer notification that says data “was accessed” before this is confirmed — or “was not accessed” before you’re certain — creates a worse situation than a brief delay. The first communication must be accurate.

Making public commitments you cannot keep. “We will never let this happen again” is a commitment you cannot make. “We are implementing multi-factor authentication and commissioning an annual third-party penetration test” is specific, real, and verifiable. Only commit to what you will actually do.

Forgetting that your employees are also customers and community members. Your staff will see the external communications. Internal comms must go out before or simultaneously with external. If your team hears about the breach from a customer before you’ve told them, you’ve compounded the problem.

Security Incident Communications Playbook