How to Create a Data Breach Response Plan (Before You Need It)

A data breach response plan is a written, step-by-step playbook that tells your business who does what, in what order, and how fast when you suspect customer, employee, or company data has been exposed. Creating a plan before an incident occurs can help you cut downtime, reduce legal risk, and avoid panic-driven mistakes that make breaches worse.

The Verizon 2025 Data Breach Investigations Report reports that ransomware is a component of 88% of SMB breaches, compared with 39% in larger organizations. The lesson for SMBs is clear: be prepared and survive, or be attacked anyway and face the consequences.

In this article, we'll explore:

• Why your business needs a response plan
• What your data breach response plan should contain (including a free downloadable template)
• How to communicate the breach to all stakeholders
• How to contain and recover from the breach
• How to comply with data privacy legislation in various jurisdictions

Why SMBs Need A Response Plan

Small and medium-sized businesses (SMBs) need a plan because when personal data is exposed, speed matters. Research commissioned in 2020 by cybersecurity firm BullGuard suggests that many small businesses take a lax approach to the risk of cyberattacks.

The report revealed that:

• 1 in 3 small UK and US businesses (50 employees or less) used free, consumer-grade cybersecurity
• 1 in 5 such companies used no cybersecurity at all
• 43% have no cybersecurity response plan

BullGuard also stated that:

The report revealed that:

• 60% of SMB owners did not believe they were likely to face cyberattacks
• 18.5% have faced a cyber attack or data breach in the last year
• 50% said it took them more than 24 hours to recover

Confusion Causes Delays

Without a clear plan in place, small businesses often lose the most time due to confusion. What that means in practice:

• Every hour of downtime costs money (lost sales, missed deadlines, idle staff, reputational damage).
• The longer the breach continues, the more data may be leaked.
• Notification clocks can start immediately in some jurisdictions (for example, GDPR Article 33's 72-hour rule, shown below, that once you are aware of a personal data breach, you must inform the supervisory authority, unless it's "unlikely to result in a risk to the rights and freedoms of natural persons").

GDPR/UK GDPR timing in plain English: the 72-hour deadline runs from when the controller becomes 'aware' of a personal data breach (not when the attacker first got in). If you don't have all facts within 72 hours, you can notify in phases, but you must explain any delay beyond 72 hours.

If the breach is likely to result in a high risk to individuals, GDPR also requires communication to affected individuals without undue delay.

Also log every breach: GDPR expects controllers to document personal data breaches (facts, effects, and remedial action) even when you decide they are not notifiable. Your plan should include a breach log template so you can prove your decision-making later.

No SMB can handle a data breach alone, but when you start asking for help, your vendors and insurer will ask for your plan (or at least your process). That moment of crisis is not the time to start putting one together. Even creating a basic plan prevents the most common failure – wondering who's in charge.

If you do nothing else, write a one-page first hour checklist plus a contact list. Even better, use our free downloadable template and the guidance in this article to create a comprehensive response plan.

Understanding a Security Incident vs. a Data Breach

Before preparing your breach response plan, it's important to understand the difference between a security incident and an actual data breach. Each is significant, but they require tailored responses that must be reflected in your planning documentation.

• A security incident is any event that could compromise your systems (like phishing, malware alerts, or a lost device).
• A data breach is a security incident where personal data is actually accessed, acquired, or disclosed by an unauthorized party (or is reasonably believed to have been).

Business takeaway: your plan should triage incidents fast, then escalate to 'breach workflow' when personal data exposure is confirmed or reasonably suspected.

This distinction matters because breach laws usually apply only when certain kinds of data are involved and when the incident meets a legal trigger.

For example, as the National Conference of State Legislatures (NCSL) notes, all US States and territories have laws requiring businesses to notify individuals of security breaches of information involving personally identifiable information. As definitions differ depending on the legislation in place, your business must ensure its breach response plan meets the requirements of any jurisdictions in which it does business.

Therefore, your plan should treat incidents involving credentials (passwords/tokens), financial or health data, or unusually broad access as high-severity and run a breach triage immediately.

If you can't confidently rule out personal data exposure, treat it as a likely breach until your investigation proves otherwise.

Essential Components of a Breach Response Plan

You need to pack a lot of information into a breach response plan, but the key is making it accessible. Remember, this is not going to be studied at leisure. Cybercriminals tend to strike at the most inconvenient times, so make sure it's easy to read and follow, even at 2 am on a Sunday morning.

It needs the following 10 essential components:

1. Scope and Definitions: What incidents the plan covers and what a breach means for your business.
2. Roles and Decision Authority: Who is in charge, who is backup, and who can approve major decisions.
3. Triage and Severity Levels: How you classify incidents so you do not treat everything as critical.
4. Evidence Preservation: What to capture before anyone fixes anything or reboots systems.
5. Containment, Eradication, and Recovery Steps: The technical playbooks for stopping the damage, removing the threat, and restoring operations.
6. Communication Plan: Who communicates what to employees, customers, regulators, and the media.
7. Legal Notification Workflow: A jurisdiction-based decision tree for determining if, when, and how notices must be sent in the jurisdictions in which your business operates.
8. Vendor and Cyber Insurance Procedures: Who to call first, how to open a claim, and which vendors are approved.
9. Documentation and Post-Incident Review: How you maintain a timeline, confirm root cause, and document improvements.
10. Testing and Annual Updates: How you run tabletop exercises and update the plan at least once a year.

Here's what to keep in mind for the first 24 hours:

1. Confirm incident channel + out-of-band comms
2. Isolate affected assets
3. Preserve evidence
4. Begin scope assessment (what systems/data/people)
5. Decide whether legal notification clocks may be running
6. Prepare a holding statement for customers/partners
7. Engage insurer/forensics if applicable.

Incident Response Team Roles

As the scope and frequency of cyberattacks have increased, it's rare for small businesses to have a full internal security team that can handle a data breach. As the National Institute of Standards and Technology (NIST) points out in its Incident Response Recommendations and Considerations for Cyber Risk Management, collaboration with a range of external and internal parties is key to successfully managing serious security incidents.

Ideally, your plan should name the individual assigned to each role and a backup, so you know exactly who to contact when a breach occurs.

Core Roles

Your plan must identify each core role, outline their responsibilities, and name the person or persons responsible. The table below is based on NIST recommendations, plus a couple of extra key contacts you will need to involve when handling the breach.

Depending on the size of your organization, some may not be required or can be filled by parties outside of your organization. For example, in businesses with fewer than 10 employees, one person may fill multiple roles. However, you should never combine the Technical Lead and Communications Lead roles, as they require simultaneous action during active breaches.

Your data breach response plan must include:

• An actual name and backup contact for each role
• At least one phone number per contact

Ensure that you have after-hours cell numbers available for each one, as breaches often arise outside of business hours. Review and update this list quarterly to account for staff changes. This will prevent your team from wasting time during an incident digging through their email for contacts.

Communication Protocols

Your breach response plan should include a communication protocol: who speaks internally, who speaks externally, what gets approved by counsel, and how you avoid contradictory statements while facts are still changing.

Your communication plan specifies exactly who says what to whom, in what order, during and after a breach. Poor communication has the potential to cause more reputational damage than the breach itself.

In the U.S., Uber agreed to a $148 million settlement with 50 states and Washington, D.C. over its delayed disclosure of the 2016 breach, which exposed data relating to about 57 million riders and drivers

Your business can avoid fines and reputational damage by getting its internal, customer, and media communication plan in order now.

The lesson for SMBs is that regulators treat delay + poor transparency as aggravating factors, even when the underlying intrusion is caused by criminals.

Internal communication

Your plan must include clear steps for internal communication, starting with the incident responders, who will likely be the first people to become aware of the breach. Here's a potential internal communication sequence:

• Incident Responders alert Technical Lead immediately upon detecting a suspected breach (within 2 hours of detection)
• Technical Lead alerts Incident Response (IR) Lead immediately upon confirming a suspected breach (within 2 hours of initial detection)
• IR Lead notifies the full incident response team within 4 hours (Technical Lead, Legal Counsel, Communications Lead, Documentation Officer, Customer Service Lead, and Cyber Insurance Contact)
• Documentation Officer begins the incident timeline immediately upon notification
• Legal Counsel provides a preliminary assessment of notification obligations within 8 hours
• IR Lead briefs executive leadership (if not serving as IR Lead themselves) within 12 hours

Notify only the people who must act right now, using a prewritten script, and instruct them not to change systems unless directed.

It's essential to document the exact time each notification occurs. This timeline proves you took immediate action if regulators investigate later, and can also help in lessons learned exercises. The Documentation Officer should maintain this log from the moment the breach is detected.

External and media communication

To manage legal risk and minimize reputational damage, your external communication must be part of your response plan. Communicating in this specific order could help to manage the impact of the data breach:

• Law enforcement (if the breach involves criminal activity): Contact immediately. For example, in the United States, you should contact the FBI's Internet Crime Complaint Center (IC3) or local FBI field office for US businesses. In other jurisdictions, find the appropriate agency's contact details and include them in your plan.
• Regulators (within legally required timeframes): Submit formal notifications to data protection authorities as required by applicable laws. Keep copies of all submissions with proof of delivery.
• Affected individuals (as quickly as possible after regulatory notification): Send direct notification via mail or email, depending on your jurisdiction's requirements. The FTC encourages businesses to take fast action and inform customers how they can reduce the likelihood of their personal data being misused.
• Business partners and vendors (whose data may be affected or who need to know for security reasons): Ensure you carry notification requirements through from your contracts to the response plan, based on their potential exposure.
• Cyber insurance carrier (if you have a policy): Notify within the timeframe specified in your policy, typically 24-72 hours.
• Media and public: If legally required or beneficial for protecting your reputation, prepare a brief press release focusing on actions taken to protect customers and prevent future incidents. The example below from the HIPAA shows a scenario in which a media notification would be required – when a breach affects more than 500 residents of a State or jurisdiction. Your legal counsel should review relevant legislation to ensure you are prepared to satisfy all media notice requirements.

Relaying consistent messages to all stakeholders is key to reducing panic and strengthening confidence in your response. As the Cybersecurity & Infrastructure Security Agency (CISA) Cybersecurity Incident & Vulnerability Response Playbooks highlight, your business should "communicate [the] updated scope to all stakeholders to ensure a common operating picture."

The key lesson is to do more than just note in your data breach response plan who you need to communicate with; pre-write holding statements for both internal staff and external stakeholders to save time and prevent agonizing over wording when the pressure is on. If you don't have full information to share, commit to providing regular, consistent updates to keep all stakeholders in the loop.

How to Contain and Recover From the Breach

Your plan needs to include your containment strategy: how you'll stop the breach from spreading, while also preserving evidence for investigation and potential law enforcement involvement.

Get your Technical Lead involved in the planning, as they are the subject matter expert and can advise on which other internal or external experts you may need to involve, depending on the nature and extent of the breach.

Containment strategy

Your plan should include the following containment steps:

1. Isolate affected systems quickly. If feasible, keep systems powered on long enough to capture volatile evidence (e.g., memory, active connections). If you cannot isolate a device from the network and the attack is actively spreading (e.g., ransomware encryption), power it down as a last resort to prevent further damage, and document the decision.
2. Preserve all relevant logs from before the suspected intrusion window through recovery (authentication, firewall, endpoint, cloud audit logs, and database access). If your retention is short, immediately extend retention and export copies to write-protected storage.
3. Documenting the current system state with screenshots, photos of physical evidence, and notes about what you observe before making any changes.
4. Capturing incident data early is key because many logs are only kept for a defined retention period. Unless you extend it, your plan should specify which logs and artifacts to preserve before remediation begins, in line with NIST's expectation that incident handlers collect and analyze evidence.
5. Enabling enhanced monitoring on all systems to detect lateral movement if attackers maintain access through secondary pathways.

Initiate the recovery

Your plan should make it clear that only after you have contained the breach can the recovery stage begin. Recovery procedures will vary according to your business needs, but the NIST recommends:

• Clearly outlining how the technical response will be performed
• Periodically testing and verifying procedures remain up to date
• Using the response plan to train new staff

NIST recommends creating a playbook with actionable steps or tasks for named parties to perform in different scenarios. Playbooks are particularly helpful as they are easy to use in high-pressure situations when the stakes are high.

In line with NIST guidelines, consider including the following in your response plan:

• Rebuilding compromised systems from clean backups or fresh installations
• Restoring data from the most recent verified-clean backup
• Applying all security patches and updates before reconnecting to the network
• Implementing additional security controls that would have prevented this specific breach
• Running penetration tests to verify the attack pathway is closed

The National Institute of Standards and Technology (NIST) Computer Security Incident Handling Guide provides detailed technical procedures you can adapt to your specific environment. It's best practice to reference this standard in your plan and train your IT team on NIST incident response methodology.

Legal Compliance Requirements by Jurisdiction

Your notification obligations depend on three possible factors:

• Where your affected customers live
• Where the incident occurred
• Where your organization is based

In reality, most businesses, even SMBs that target customers in several jurisdictions, must comply with multiple overlapping requirements. This is why it's critical to involve legal counsel in data breach response planning, so that you do not miss any of your reporting obligations.

In some regulated sectors (e.g., finance, essential services, telecoms), you may also have incident reporting duties beyond privacy law, so your decision tree should include a "sector rules apply?" checkpoint.

Understanding notification requirements

Not all data privacy laws apply to all businesses. Some have employee count or turnover requirements. However, SMBs should be aware that under some data privacy laws, they are required to report data breaches regardless of their size or turnover.

For example, the UK Information Commissioner's Office notes that all organizations must "report certain personal data breaches to the relevant supervisory authority." They are also obliged to notify affected individuals under certain circumstances.

If you are a vendor/service provider: if you act as a GDPR/UK GDPR processor (handling personal data for a client), you must notify the client (the controller) without undue delay after becoming aware of a personal data breach. In practice, many DPAs require notice in hours (not days) so your breach plan should include your contractual notification deadlines as a separate checklist.

The following summary provides an overview of data breach notification requirements in several key jurisdictions worldwide.

To make things even more complex, if you operate in all 50 US states, there are varying notification requirements for each state to fulfil. Work with your legal counsel to ensure your response plan includes a decision tree that assists you in notifying all relevant authorities within the required timescales.

What to include in a breach notification

Requirements vary depending on the jurisdiction, but plan to share the following:

• Description of what happened in plain language
• Types of personal information involved
• Date or time period of the breach
• Steps you're taking to investigate and address the breach
• Specific actions individuals should take to protect themselves
• Contact information for questions

As shown below in the GDPR Article 33, you must also outline the "likely consequences of the personal data breach" and what you're doing to mitigate potential adverse effects.

To speed up notifications, draft template notification letters for each applicable jurisdiction in advance. Store these templates in your breach response plan so you can customize and send them quickly.

Testing and Updating Procedures

To keep your breach response plan up to date and fresh in the minds of all relevant parties, your business should plan annual testing. One of the most effective testing methods is a tabletop exercise, also known as a TTX. These attack simulation exercises are recommended by authorities such as the US's CISA and the UK's National Cyber Security Centre (NCSC).

Conducting tabletop exercises

Tabletop exercises simulate real breach scenarios without affecting production systems, giving your incident response team an opportunity to walk through a hypothetical breach scenario and roleplay their response.

Effective scenarios include:

• Ransomware scenario: Customer database encrypted, attackers demand payment, backups potentially compromised
• Insider threat scenario: Employee downloads customer list before resigning, competitor announces similar service
• Vendor breach scenario: Third-party payment processor notifies you of unauthorized access to transaction data
• Lost device scenario: Laptop containing unencrypted employee and customer data stolen from a vehicle

During the 2-hour exercise, present the scenario in stages and have team members describe their specific actions. The Documentation Officer should record gaps in the current plan, ambiguous procedures, and missing information. Update your plan immediately after each exercise to address identified gaps.

Quarterly review triggers

Annual testing is good, but in the fast-paced world of cybersecurity, it may not be regular enough to ensure your plan is robust. Therefore, it makes sense to schedule quarterly reviews, which will allow you to check whether any of the following is true:

• New data privacy regulations have taken effect in jurisdictions where you operate
• You have added new data collection practices or systems
• Key personnel in incident response roles have changed
• You have engaged new third-party vendors who handle customer data
• Previous breaches (your own or in your industry) have revealed response plan weaknesses

So, if you do not have an annual tabletop exercise already on your calendar, it pays to schedule one right away. Block 3 hours (2-hour exercise plus 1-hour debrief and plan updates). There are a number of guided scenarios available online that can help your team ensure your data breach response plan is ready for a real-world attack.

Free Template: Data Breach Response Plan for Small Businesses

This document serves as a starting point to help you quickly establish a basic data breach response plan. It incorporates principles from NIST SP 800-61r3, CISA Cybersecurity Incident & Vulnerability Response Playbooks, and CISA Incident Response Plan (IRP) Basics. Review your plan with an attorney and include specific requirements based on the jurisdictions in which you operate.

How to Use This Template

• Replace bracketed placeholders like [Company Name] and [Incident Response Lead].
• Insert your critical system list, vendor contracts, and cyber insurance policy as appendices.
• Keep one printed copy in a secure location and one offline copy, such as an encrypted drive.
• Ensure each stakeholder has a printed copy that they keep accessible at all times in case systems cannot be accessed during a breach.
• Review contact details quarterly and run an annual tabletop exercise, then update this plan based on what you learn.

Template

1. Purpose and Scope

• Purpose: This plan explains how [Company Name] prepares for, responds to, and recovers from a suspected or confirmed security incident involving data.
• Scope: Applies to employees, contractors, and service providers who handle [Company Name] systems or data, including cloud services.

2. Key Definitions

• Security incident: Any event that threatens the confidentiality, integrity, or availability of your systems or data, such as phishing emails, malware alerts, or lost laptops.
• Data breach: A security incident where data is actually accessed, exposed, stolen, altered, or lost without authorization.
• Personal information or personal data: Information that identifies a person or can reasonably be linked to them, such as account credentials, government IDs, or health information.

Decision rule: If you cannot confidently say the data was not accessed or exposed, treat the event as a likely breach until your investigation proves otherwise.

3. Triage and Severity Levels

• Severity 1 (Critical): Confirmed compromise of sensitive data, ransomware, widespread outage, or clear signs an attacker is active in the environment.
• Severity 2 (High): Likely compromise of sensitive data or critical systems, or unusually broad access.
• Severity 3 (Medium): Contained malware or phishing with limited impact and no evidence of data access yet.
• Severity 4 (Low): Benign event or false positive.

Escalation rule: Treat incidents involving credentials (passwords, API keys, access tokens), financial data, health data, or large-scale access as high severity and escalate immediately.

4. Incident Response Team Roles (Who Does What)

Name a primary owner and a backup for each role. In very small organizations, one person may fill multiple roles. However, do not combine the Technical Lead and Communications Lead roles, because they require simultaneous action during active breaches.

Add at least one phone number per contact, including after-hours cell numbers, and update these details quarterly to account for staff changes.

• Incident Response (IR) Lead: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Owns the response, approves major business-impact decisions, and ensures resources are allocated.

• Incident Responders: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Detect and validate incidents, gather and review data, prioritize tasks, reduce harm, and support restoring normal operations.

• Technical Lead: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Leads containment, log collection, recovery, restores, and endpoint actions, and coordinates with any outside technical experts.

• Legal Counsel: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Assesses legal obligations, determines notification requirements, and reviews regulator-facing and customer-facing notices.

• Communications Lead: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Coordinates messaging to customers, partners, and the public when needed, using prewritten scripts and holding statements.

• Documentation Officer: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Records actions and decisions, maintains the incident timeline, and preserves the evidence chain.

• Customer Service Lead: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Handles inbound questions, uses approved scripts, and tracks customer impact and escalations.

• Cyber Insurance Contact: [Primary Contact Name] ([Primary Phone]) | [Secondary Contact Name] ([Secondary Phone])

  • Role: Opens the claim and coordinates insurer-required steps and approved vendors.

5. Additional Contacts (Fill In)

Specifics will vary depending on the business, but may include:

• Key vendors:

  • Managed Service Provider (MSP) [#]
  • Cloud host [#]
  • Email provider [#]
  • Payment processor [#]
  • Backup provider [#]

• Critical accounts: Domain registrar, DNS, identity provider, backup admin.

  • Law enforcement and cyber crime reporting: Include name, contact numbers, and website of all relevant local agencies.

• Data protection and regulatory authorities: As above

  • External incident response support: Any organizations that can provide additional support if managing the breach exceeds your team's capacity.
• Store credentials in a password manager and maintain a break-glass process.

6. Evidence Preservation (Do This First)

• Start an incident log immediately, including date and time discovered, who discovered it, and what systems appear to be affected.
• Preserve volatile and time-sensitive evidence before making changes, such as authentication logs, endpoint logs, firewall logs, cloud audit logs, and relevant email headers.
• Do not wipe or reimage systems until you have confirmed evidence collection is complete and any forensics guidance has been followed.
• Capture screenshots or photos of attacker messages, ransom notes, unusual console prompts, or key alerts.

Capturing incident data early matters because many logs are only retained for a defined period unless you extend retention. Specify what to collect and where to store it before remediation begins.

Key Personnel

• Technical Lead: Owner
• Documentation Officer: Support
• Legal Counsel: Advisor

7. Containment Strategy (First Hours)

• Isolate affected systems without powering them down when possible. Disconnect network cables or disable network interfaces.
• Preserve logs from before the suspected intrusion window through recovery, including authentication systems, firewalls, endpoints, cloud audit logs, and database access logs. If retention is short, extend it immediately and export copies to write-protected storage
• Document the current state before making changes, including screenshots, notes, and observable indicators of compromise.
• Enable enhanced monitoring to detect lateral movement and secondary attacker pathways.
• If credentials may be compromised, plan a controlled reset and rotation process after evidence capture, including MFA enforcement and rotating high-risk keys and tokens.

Key Personnel

• Technical Lead: Owner
• Incident Response Lead: Approver
• Incident Responders: Support
• Legal Counsel: Support
• Documentation Officer: Support

8. Communication Protocols

Your plan should specify who communicates what, to whom, and in what order. Use prewritten scripts and avoid speculation.

8A. Internal Communication Sequence

• Incident Responders alert the Technical Lead immediately upon detecting a suspected breach, ideally within 2 hours of detection.
• Technical Lead alerts the IR Lead immediately upon confirming a suspected breach, ideally within 2 hours of initial detection.
• IR Lead notifies the full incident response team within 4 hours, including Legal Counsel, Communications Lead, Documentation Officer, Customer Service Lead, and Cyber Insurance Contact.
• The Documentation Officer begins the incident timeline immediately upon notification.
• Legal Counsel provides a preliminary assessment of notification obligations within 8 hours.
• IR Lead briefs executive leadership within 12 hours if leadership is not serving as the IR Lead.

Notify only the people who must act right now, using a prewritten script, and instruct them not to change systems unless directed.

8B. External and Media Communication Order

• Law enforcement, when criminal activity is suspected, using the appropriate agency contacts for your jurisdiction.
• Regulators within legally required timeframes, keeping copies of submissions and proof of delivery.
• Affected individuals as required, using plain-language notices that explain what happened, what data was involved, and what they can do next.
• Business partners and vendors, when contracts require notice or when they need to act for security reasons.
• Cyber insurance carrier within the timeframe in your policy, commonly 24 to 72 hours.
• Media and public communications, when legally required or beneficial, using a short holding statement reviewed by Legal Counsel.

Plan for consistent updates as facts evolve so stakeholders all receive the same understanding of scope and impact.

9. Investigation and Impact Assessment (First 24 Hours)

• Confirm what happened, including the suspected entry point, timeline, and attacker actions.
• Identify the data involved, whose data it is (customers, employees), and where the data is stored (systems and vendors).
• Assess likely harms, such as identity theft risk, financial risk, or reputational harm.
• Decide whether to engage outside forensics and counsel for high-severity incidents.

Key Personnel

• Incident Responders: Owner
• Technical Lead: Owner
• Legal Counsel: Advisor
• Incident Response Lead: Approver
• Documentation Officer: Support
• Asset Owners: Support
• Cyber Insurance Contact: Support

10. Recovery and Technical Playbooks

• Clearly outline how the technical response will be performed and who owns each task.
• Rebuild compromised systems from clean backups or fresh installations when needed.
• Restore data from the most recent verified-clean backup and validate integrity before reconnecting to production.
• Apply security patches and updates before reconnecting systems to the network.
• Implement additional controls that would have prevented this incident, such as MFA, least-privilege access, and improved monitoring.
• Run validation steps to confirm the attacker pathway is closed.

11. Legal Compliance Decision Tree (High Level)

• Step 1: Identify where affected individuals live, where your organization is based, and where the incident occurred.
• Step 2: Confirm what data types are involved, including whether personal information or personal data is implicated.
• Step 3: Determine whether the facts indicate a reportable breach under applicable laws, including any sector rules.
• Step 4: Identify deadlines, notice recipients, and required content. Prepare jurisdiction-specific templates in advance.

Create a simple decision tree so responders can distinguish routine security incidents from likely reportable breaches based on the facts, the data involved, and the affected individuals' locations. Your legal counsel must review this to ensure you do not miss any jurisdiction's notification requirements.

12. Testing and Updating Procedures

• Run an annual tabletop exercise using realistic scenarios, such as ransomware, vendor breach, insider download, or lost device.
• Record gaps, ambiguous procedures, and missing information during the exercise, then update the plan right away.
• Schedule quarterly review triggers to check for changes in laws, systems, vendors, or key personnel.

13. Post-Incident Review (Within 2 Weeks)

• Root cause analysis that explains what happened and why.
• Lessons learned meeting to identify what worked, what failed, and what to change.
• Action plan with owners and dates for improvements, such as patching, MFA, training, vendor changes, backups, and monitoring.
• Update this plan and train staff on the changes.

Appendix A. Templates to Prewrite and Store

• Internal staff holding statement: [Insert].
• Customer notice template: [Insert].
• Regulator notice checklist: [Insert].
• Customer support script and FAQ: [Insert].
• Media holding statement: [Insert].

Key Takeaways

With cyberattacks increasing in frequency and severity each year and having a disproportionate impact on SMBs, your business needs a data breach response plan that is up-to-date, clear, and actionable. Every day without a plan increases your risk of facing financial, regulatory, and reputational damage.

If you do not have a plan in place, here are three key takeaways to address immediately:

• This week: Review our free downloadable template, and identify roles, names, and contact information. Get confirmation from each person and use the guidance in the plan to explain their roles.
• Next week: Determine all your notification obligations by researching which data privacy laws apply to your business. Create a simple breakdown or chart to add to your response plan detailing who to contact in which scenarios.
• This month: Schedule your first tabletop exercise. Block time on everyone's calendars, choose a realistic scenario, and act on the lessons learned.

A few hours spent creating even a basic plan could yield massive savings very soon. And remember, your first plan is just a starting point. Treat it as a dynamic document that is regularly reviewed, updated, and refined so your team is trained and ready to minimize the impact of an attack when it comes.