A data breach can escalate quickly for a small or mid-sized business (SME). What begins as a suspicious login, a misdirected file, a compromised mailbox, or a minor ransomware incident can turn into operational disruption, customer concern, and urgent legal questions in a matter of hours.

For many businesses, the pressure is both technical and regulatory. In most jurisdictions, a personal data breach may trigger decisions about internal escalation, evidence preservation, customer communication, and whether notification to a data protection authority — such as the ICO in the UK or an EU supervisory authority under GDPR — is required within a limited timeframe.

A practical data breach response plan gives SMBs something much more useful than a long document full of abstract policy language: A clear working guide that helps them assess what happened, contain the incident, communicate with the right people, and document each step properly.

This article is designed to be that kind of reference: something your team can build on, save, and return to when you’re under pressure.

What a data breach response plan should do

A data breach response plan is different from a broader incident response document. An incident response plan may cover a wide range of cybersecurity events, including malware(nytt fönster) infections, service outages, insider misuse, and business continuity issues.

By contrast, a data breach response plan is more specific. It focuses on incidents involving personal data and on the actions required when that data is lost, exposed, altered, accessed without authorization, or made unavailable in a way that creates risk for individuals.

A generic cybersecurity incident response plan can help teams stabilize systems, but it may not provide enough guidance on what to do when the event involves personal data, potential harm to individuals, and reporting obligations. 

Many privacy regulations define personal data breaches broadly enough to include not only deliberate attacks, but also accidental disclosure, loss, destruction, and availability failures. For example, the ICO and GDPR both recognize that breaches can result from malicious incidents as well as human error or system failures. 

In practice, a strong data breach response plan should help your business do six things well:

  • Identify whether a personal data breach may have taken place
  • Assess the likely risk to individuals
  • Contain further exposure quickly
  • Coordinate internal, regulatory, and external communication
  • Investigate the cause and preserve evidence
  • Recover safely and improve the plan afterwards

It should also make ownership clear. In a real incident, confusion around roles wastes time. Your plan should dictate who leads technical containment, who assesses reporting thresholds, who approves notifications, who communicates with customers or partners, and who keeps the breach log and documentation up to date.

1. Detect the breach and make an initial assessment

The first step is to establish whether a personal data breach has actually occurred and whether the regulatory clock may already be running.

Under the GDPR, the 72-hour window starts when an organization becomes aware of a reportable personal data breach, rather than when the underlying incident first occurred. Regulators such as the UK’s ICO also recommend starting a breach log immediately, even before it is clear whether notification will ultimately be required.

A business data breach response plan should tell staff exactly what to do when they spot something suspicious. That might be an employee reporting a phishing-related account takeover, a cloud folder shared publicly by mistake, a lost laptop, ransomware affecting file access, or a processor warning you about potential customer data exposure.

At this point, you need to collect enough information to classify the event without wasting time trying to get situated.

At this stage, your plan should prompt a short initial assessment:

  • What happened, and how was it detected?
  • What systems, accounts, or devices are affected?
  • What categories of personal data may be involved?
  • How many individuals may be impacted?
  • Is the data encrypted, pseudonymized, or otherwise protected?
  • Is the data merely at risk, or is there evidence of access, exfiltration, alteration, or loss of availability?
  • What immediate harms could follow for individuals?

Regulators consistently emphasize that breach risk should be assessed in terms of the potential negative consequences for individuals, including identity theft, fraud, financial loss, reputational damage, and loss of confidentiality. This is the framework your plan should use from the beginning.

2. Contain the breach before it spreads

Once there is a credible indication that personally identifiable data may be exposed, containment becomes the priority. Containment is simple: the aim is to stop further unauthorized access, disclosure, or loss.

Your containment actions will depend on the breach type. Usually, they should include:

  • Disabling compromised accounts
  • Revoking shared or exposed credentials
  • Forcing password resets
  • Rotating admin credentials, API keys, and access tokens
  • Isolating affected endpoints or servers
  • Removing malicious forwarding rules or persistence mechanisms
  • Locking down file-sharing permissions
  • Suspending risky integrations or third-party access
  • Preserving affected systems in place when forensic review is likely

Credential security is often central to managing a breach and preventing further events. Proton’s 2026 Data Breach Observatory update found that passwords were exposed in 47% of incidents, while names and email addresses appeared in nearly 9 out of 10 breaches. Many breaches create a follow-on credential risk even when the original attack path is still being investigated.

A strong plan should separate “containment” from “recovery.” Containment is about shutting down the breach, and recovery comes later. If teams rush straight into cleanup without preserving what happened, they may lose evidence, miss the root cause, or make regulatory reporting more difficult.

3. Communicate internally, externally, and to regulatory agencies

Even when the technical response is moving in the right direction, communication can still break down quickly. Usually this is because different teams have different levels of visibility into the incident.

In addition, leadership may need answers before the facts are fully confirmed. Legal and privacy leads may be assessing reporting thresholds while customer-facing teams are already being asked for reassurance. Without a clear structure, the result is often delay, inconsistency, or messaging that creates more confusion than clarity.

During an incident, the aim is to give stakeholders, customers, and regulators the information they need in a timely and responsible way, without sharing unnecessary details that could increase risk.

In practice, your plan should separate communication into three distinct tracks:

Internal communication

Start with a clear escalation path. As soon as a potential breach is identified, the right people must be informed quickly and aligned on the same facts. In most SMBs, that usually includes the incident lead, IT or security, senior management, the legal or privacy owner, as well as any operational lead responsible for the affected data. At this stage, the priority is clarity: what is known, what is still uncertain, what is already being done, and what decisions need to happen next.

Regulatory communication

If the breach is likely to result in a risk to individuals’ rights and freedoms, it needs to be reported to the relevant data protection authority. Under the GDPR, for example, this notification generally must be made within 72 hours of becoming aware of the breach. 

Many supervisory authorities also recognize that organizations may provide additional information in phases if all the facts are not yet available at the time of the initial notification. Your plan should make ownership clear here: who assesses the reporting threshold, who prepares the notification, and who approves it before submission.

Communication with affected individuals

Some breaches also require direct communication with the people affected. When the incident is likely to result in a high risk to individuals’ rights and freedoms, they must be informed without undue delay.

That communication should be clear, direct, and practical, explaining:

  • What happened
  • What are the likely consequences
  • What the organization is doing in response

Templates can save time and help keep messaging consistent under pressure.

4.  Investigate the cause and preserve evidence

Once the incident is stabilized, the investigation needs to begin properly. Aim to answer three questions:

  • How did the breach happen?
  • What data was affected?
  • Is the threat still present?

Privacy regulations generally require organizations to maintain effective breach detection, investigation, and internal reporting procedures. Under the GDPR, organizations must also document personal data breaches regardless of whether notification is ultimately required. 

Your investigation doesn’t always mean conducting a full-scale forensic engagement from the first hour. However, your plan should define when outside expertise is needed. This may include:

  • Ransomware or suspected exfiltration
  • Compromise of privileged accounts
  • Uncertainty over the volume or type of data accessed
  • Incidents involving regulated or especially sensitive data
  • Third-party processors or cloud providers with incomplete visibility
  • Any event likely to draw regulatory scrutiny or legal claims

Evidence preservation is especially important at this stage. Any data pertaining to the breach may become relevant later, so preserve:

  • Logs
  • Affected endpoints
  • Email headers
  • Authentication records
  • Firewall data
  • Screenshots
  • Access-control changes
  • Vendor communication
  • Evidence of internal decisions

If teams wipe devices, rebuild servers, or rotate everything without recording what changed, they may make it harder to prove the scope of the breach or demonstrate that the response was appropriate.

5. Recover and reduce the chance of repeated exposure

Recovery is the stage where operations start moving back towards normal, but it should not mean simply turning systems back on. A breach that is technically “over” can still create ongoing risk if stolen credentials remain valid, weak controls stay in place, or exposed data is already being misused elsewhere.

Your recovery plan should cover:

  • Restoring systems from clean backups where appropriate
  • Confirming that malicious access has been removed
  • Rotating credentials across affected users, admins, shared accounts, integrations, and service accounts
  • Reviewing MFA enforcement
  • Tightening access controls based on actual job needs
  • Checking logging and alerting gaps
  • Validating third-party remediation where processors or vendors were involved

This is also a good moment to revisit credential hygiene at a broader level. Proton’s Data Breach Observatory exists partly because many breaches never become public promptly, even though leaked data may already be circulating on the dark web. Its 2026 analysis found that contact information appeared in 75% of breaches and passwords in 47%, which shows how often a single incident can create broader account compromise risk.

Recovery should include checking whether exposed credentials, reused passwords, or unmanaged shared logins could turn one breach into several more. A secure business password manager can support recovery and long-term control by making credential rotation, access review, and secure sharing more manageable at scale.

6. Run a post-incident review and update the plan

A breach response plan is only useful if it improves after real use. Even just practicing your response plan can help you understand how it will work during a real breach, because both exercises and real incidents reveal gaps that documents alone will not show. 

Your review should be honest and specific. Start with questions like these:

  • How quickly was the breach detected?
  • When did the business become aware?
  • Was the reporting threshold assessed correctly and quickly enough?
  • Did roles and approvals work in practice?
  • Were customers or staff left waiting because templates or ownership were unclear?
  • What evidence was challenging to gather?
  • Did credential management slow down containment or recovery?
  • What controls, training, or vendor requirements now need to change?

You should also document the rationale behind your decisions, especially if you decided not to notify individuals or report to the relevant supervisory authority. Record-keeping is required for all personal data breaches, not just notifiable ones.

Over time, this review process should turn your plan into a living document: clearer thresholds, better contacts, better templates, better logging, better credential controls, and more realistic playbooks for the incidents your business is actually likely to face.

Keep your breach response practical before you need it

A data breach response plan is meant to help your team make better decisions under pressure. For SMBs, the difference usually comes down to preparation: knowing how to recognize a reportable breach, who owns the first response, how to contain it, what applicable data protection regulations require, and how to communicate clearly while facts are still developing.

A plan built in advance will not remove the pressure in case of a breach, but it can make the response faster, clearer, and easier to defend when time is limited.

The more your business depends on digital systems, shared access, cloud apps, and customer data, the less room there is for improvised credential management during an incident. 

Proton Pass for Business can support your data breach response plan with:

  • Enhanced visibility into employee activity with detailed reporting and logs
  • Enforceable, customizable team policies to ensure 2FA and strong passwords protect your business network
  • Secure data storage with end-to-end encryption
  • Dark web monitoring that actively scans for your business data
  • Proton Sentinel, a high security program that prevents account takeovers.

Protect your credentials before a breach happens — try a business password manager like Proton Pass for Business.