In the first hours of a security incident, you can’t complete a technical picture of what happened. Your team may still be trying to understand which account was compromised, what data was accessed, how far the attacker got, or whether the incident is still active.
Alongside your investigation, the pressure to act starts immediately. Employees hear fragments and need to know what to do. Meanwhile, customers may notice service disruption, suspicious activity, or unusual password reset requests. Business partners may ask whether their systems or data are involved, and leadership needs to decide who speaks, what can be confirmed, and when silence becomes a risk of its own.
Security incident communication is difficult because a business has to be transparent before it has every answer, but informed enough not to guess. Communications sent too early can create confusion, but if they’re sent too late they can damage trust, slow down protective action, and raise regulatory questions.
It’s unlikely that small and mid-sized businesses have created or rehearsed their incident response plan, and this can cause additional chaos. Even for larger businesses with a plan, the technical steps may be documented: contain the incident, reset access, preserve evidence, restore systems. Communication may be left for later, until suddenly the incident escalates or changes.
Part of preparing for an incident means knowing who needs to hear from you, what they need to know, who approves the message, and how to communicate facts clearly while the investigation is still moving.
Communication planning belongs inside incident response
The two-track structure for your response
Start with the audience, not the announcement
What to communicate internally
How to notify customers of a breach
When to notify regulatory agencies
Prepare messages before you need them
How Proton Pass for Business can help
Communication planning belongs inside incident response
Incident response is often described as a technical process, but a real incident quickly becomes cross-functional. IT teams may contain the threat, but leadership, legal, customer support, HR, communications, and operations all need to know what is happening and what they are allowed to say.
The NCSC’s guidance on effective communications in a cyber incident(fereastră nouă) — general best practice that applies well beyond the UK — makes this point clearly: organizations often prioritize technical response and push communication into the background, even though communication shapes how staff, customers, stakeholders, and the media perceive the organization during a crisis.
Not every incident needs a public statement. But the business should know in advance who decides what to communicate, who approves external messages, who speaks to customers, and who handles regulatory reporting.
A strong data breach response plan needs to include a communication layer. This should include practical details:
- Contact lists
- Draft templates
- Approval routes
- Legal review
- Customer support talking points
- Regulator notification responsibilities
- Records of what was sent, when, and to whom.
The two-track structure for your response
Incident response needs two tracks: technical response and communication response. They run parallel to each other and the incident lead/ response owner connects them both.
| Left track: Technical response | Right track: Communication response |
| Contain the incident | Update the internal team |
| Secure affected accounts | Notify affected customers or partners |
| Preserve evidence | Assess regulator notification |
| Restore systems | Keep messages consistent as facts change |
This allows you to structure your response and ensure that collaboration continues as team members take on different tasks.
Start with the audience, not the announcement
Security incident communication fails when one message tries to serve everyone. Employees, customers, partners, and regulators need different levels of detail because they have different decisions to make.
Your internal team needs clarity first
They don’t need every detail — especially while the investigation is ongoing — but they do need clarity on what’s confirmed, what to do right now, and who’s leading the response. That means knowing which systems or accounts to avoid, what action to take immediately, and which questions are still open.
Employees also need to know what not to do. For example:
- Do not discuss the incident publicly
- Do not reset credentials outside the approved process
- Do not contact customers with improvised explanations
- Do not forward suspicious messages without guidance.
Customers and partners need to know how they’re affected
They want to know whether their data, access, payments, service, or operations are affected. A good customer notification should explain:
- What is known
- What type of data may be involved
- What the business is doing
- What customers should do now, if anything
- Where they can get updates.
The tone should be plain and direct. A customer also doesn’t need forensic detail, they only need enough information to protect themselves.
Regulators need a factual record
A GDPR breach notification to the relevant supervisory authority (the ICO(fereastră nouă) in the UK, the national data protection authority in each EU member state) is not a marketing message or a customer reassurance note. Instead, it needs to be a factual record of what happened, who is affected, and what you’re doing about it. We cover exactly what to include in the section on notifying regulators below.
What to communicate internally
Your employees are part of the response, even when they aren’t on the incident team. A confused team can accidentally create more noise, share inaccurate information, or slow down containment. On the other hand, a well-informed team can help protect accounts, direct customers to the right channel, and avoid speculation growing.
An internal security incident announcement should cover:
- A clear summary of what has been confirmed so far, in plain language
- Which systems, accounts, teams, or data are potentially affected
- What the business is doing now
- What employees should do immediately
- Who is allowed to communicate externally
- Where updates will be posted
- How to report related suspicious activity
There are aspects that shouldn’t be included: attack vectors, root cause analysis, and specific vulnerabilities are generally not shared internally while an incident is live, and often not afterwards either, since those details can help other attackers, create legal exposure, or expose gaps that have not yet been closed.
The first internal message doesn’t need to answer every question, it needs to create order. For example, employees may need to reset passwords only through an approved process, avoid using a specific system, preserve suspicious emails, or stop using shared credentials until the response team finishes review.
Assessing your existing access controls against best practices for password management is also essential. During an incident, outdated or informal credential sharing can make it harder to understand what was exposed.
Proton’s guides to data breach protection and data breach prevention for businesses explains how layered controls reduce exposure before a breach occurs. Secure credential management is one of those layers because it helps the business know which accounts exist, who can access them, and what needs to be changed quickly.
How to notify customers of a breach
A data breach notification to customers is harder because it carries reputational and legal weight. People may be worried about identity theft, account takeover, financial fraud, or exposure of private information. They may also be frustrated that the company did not prevent the incident.
A good customer message should be honest without being alarming. It should avoid technical jargon, but be clear. Customers need to understand what data was involved, what risk that creates, and what they should do next.
A useful structure is:
- What happened, at a level of detail appropriate for customers
- When the business became aware
- What information or services may be affected
- What steps the business has taken
- What customers should do now
- How the business will provide updates
- Who customers can contact with questions
Where the investigation is still active, this should be disclosed. Accuracy and transparency help restore trust. Being open about impact doesn’t require disclosing technical detail that would help someone repeat the attack.
For serious incidents, customers may need practical instructions: change a password, enable MFA, watch for phishing emails, contact their bank, and ignore messages claiming to be from the company unless they come through an official channel. The notification should make those steps easy to understand.
When and how to notify regulatory agencies
Not every security incident needs to be reported to the supervisory authorities. A reportable breach under UK and EU GDPR depends on whether a personal data breach is likely to result in a risk to people’s rights and freedoms.
The ICO’s personal data breach guidance(fereastră nouă) reflects a requirement common to both UK and EU GDPR: organizations must report a notifiable breach without undue delay and no later than 72 hours after becoming aware of it. A late report needs reasons for the delay.
That 72-hour window can create pressure, especially when the investigation is still incomplete. The GDPR recognizes that organizations may not have every detail within the first 72 hours, so information can be provided in phases, as long as further updates are given without undue delay.
A notification to the relevant supervisory authority (the ICO in the UK, or the national data protection authority in the EU) should usually include:
- The nature of the personal data breach
- The categories and approximate number of individuals affected
- The categories and approximate number of personal data records affected
- The name and contact details of the DPO or another contact point
- The likely consequences of the breach
- The measures taken or proposed to address it
The ICO also provides a central page to report a breach(fereastră nouă) and route organizations to the appropriate reporting process.
For affected individuals, the threshold is different. Where a personal data breach is likely to result in a high risk to people’s rights and freedoms, they must be informed without undue delay. This is a situation in which legal, privacy, and leadership teams should be involved early, even in a small business.
Prepare messages before you need them
The worst time to design a communication process is during an incident. It’s not helpful to issue statements or guidance that need to be updated and changed.
That is why it’s helpful to prepare the structure of your messages before you need them. Not the final wording, because every incident will be different, but the structure: who needs to approve the message, which details must be included, where updates will be recorded, and who is responsible for each audience.
A simple communication kit is enough to make the first hour less chaotic. It can include:
- An internal incident announcement template
- A customer notification template
- A partner or vendor update template
- Customer support talking points
- Supervisory authority notification checklist
- Approved spokesperson list
- Escalation contacts for legal, IT, privacy, leadership, and communications
- A place to record all updates and decisions
Preparation gives a team a safe starting point when speed and accuracy are both important. A prepared template leaves more attention for the facts of the incident: what happened, who is affected, what has already been done, and what people need to do next.
How Proton Pass for Business can help
Security incident communication depends on facts. The more clearly a business manages access before an incident, the easier it is to explain what happened, what may be affected, and what has been changed.
A business password manager like Proton Pass for Business helps teams reduce credential-related exposure. Employees can generate strong passwords, store them in encrypted password vaults, use autofill, share credentials securely, manage passkeys, and use built-in two-factor authentication. Admins can apply password policies, review activity logs, manage access with role-based controls, and support provisioning through SCIM and SSO integrations.
During an incident, these features can help businesses act with more confidence. If an employee account is compromised, admins can review access, identify shared credentials that may need rotation, enforce stronger authentication, and reduce reliance on passwords copied through chat or spreadsheets.
Be ready to respond before a breach happens with a business password manager.
