A suspected data breach creates two problems at once: the technical incident and the obligation to make sound decisions with incomplete information. This SMB breach response playbook gives your team a practical sequence for the first 24 hours, 72 hours, seven days, and 30 days, plus adaptable customer and regulator notification templates, a reporting timeline framework, and a recurring review routine. Use it alongside legal counsel, your incident-response plan, and the requirements that apply to your location, industry, and affected individuals.
Overview
A breach response should be organized around four goals: contain the incident, preserve evidence, understand the affected data, and communicate accurately. Speed matters, but rushed or speculative statements can create additional operational and legal problems. Assign one incident lead, establish a decision log, and keep technical investigation separate from public communications while ensuring both teams share verified facts.
Start by defining what is known, what is suspected, and what remains unknown. Record the time the issue was discovered, the systems involved, the indicators observed, and the people who have been notified. Preserve relevant logs, email headers, endpoint data, access records, backups, and cloud audit information before routine retention processes overwrite them. Do not alter compromised systems more than necessary to prevent ongoing harm or preserve evidence.
Your response team will usually need representatives from IT or security, business leadership, legal or privacy, communications, human resources if employee data is involved, and any relevant insurance or contractual contacts. A small business may combine several roles, but every responsibility should have a named owner and a backup.
For a broader first-day checklist, see Business Security Incident Response Checklist: What to Do in the First 24 Hours. If a supplier, hosted platform, or managed provider may be involved, use the third-party cyber incident response questions and escalation template.
What to track
First 24 hours: stabilize and preserve
- Activate the response team: Name the incident lead, technical lead, communications owner, and legal or privacy decision-maker.
- Contain carefully: Disable or isolate affected accounts, endpoints, tokens, integrations, or network segments. Avoid destroying evidence or disrupting essential services without recording the decision.
- Protect credentials: Reset credentials that may be exposed, revoke active sessions and tokens where appropriate, and review privileged access. Treat email compromise as a possible route to payment fraud and further intrusion.
- Preserve evidence: Export relevant logs and document collection times, systems, custodians, and storage locations.
- Establish a fact log: Track the suspected entry point, known affected systems, types of data, earliest evidence of access, and the latest confirmed activity.
- Check dependencies: Identify vendors, processors, insurers, banks, law enforcement contacts, and customers whose contracts may contain incident-notification requirements.
- Control communications: Direct media, customer, and employee questions to one approved channel. Tell staff not to speculate or forward unverified notices.
By 72 hours: scope and decision points
Move from immediate containment to a defensible assessment. Determine whether the event involved unauthorized access, acquisition, disclosure, loss, destruction, or availability disruption. Build a data inventory that identifies affected records, data subjects, locations, encryption or access controls, and whether credentials or financial information were exposed.
At this stage, document competing hypotheses rather than presenting an unconfirmed explanation as fact. Identify which systems are clean enough to restore, which require additional investigation, and whether the attacker may still have access. Review backups before restoration, verify that administrative accounts are secure, and monitor for persistence or credential reuse.
Begin a jurisdiction matrix. At minimum, list the location of the business, affected individuals, relevant employees or customers, data-processing locations, sector rules, contractual commitments, and the authority or customer group that may need notice. Notification duties can depend on the type of information, the affected population, the role of the organization, and whether a regulator or processor is involved. Do not rely on a generic deadline copied from another incident.
By seven days: prepare accurate notifications
Prepare a fact-checked incident summary and obtain legal review before sending external notices. A useful customer notice generally explains what happened, what information was involved, what the company has done, what the recipient can do, and how to obtain help. State uncertainty plainly when the investigation is ongoing; do not minimize the incident or claim that no misuse occurred unless that conclusion is supported.
Use the cyber incident communications matrix to separate messages for customers, employees, business partners, regulators, and insurers. A notification channel should be safe and verifiable. Avoid asking recipients to click an unfamiliar link, provide a password, or send sensitive information in response to the notice.
By 30 days: remediate and learn
Close the gap between the incident and normal operations with a written remediation plan. Prioritize root-cause fixes, identity and access improvements, logging coverage, backup validation, vulnerability management, vendor controls, and staff training. Record which actions are complete, which are accepted risks, who owns them, and their target dates.
Run a post-incident review that asks whether detection was timely, whether escalation worked, whether the contact list was accurate, and whether communications reached the right people. Convert findings into tabletop scenarios and test them through the quarterly incident readiness workbook.
Cadence and checkpoints
Use this reporting framework as a control, not as a substitute for jurisdiction-specific legal advice:
| Checkpoint | What to review | Output |
|---|---|---|
| Discovery and first 24 hours | Containment, evidence preservation, active access, internal escalation | Incident record, owner list, initial facts, containment log |
| Within 72 hours | Data categories, affected populations, processor involvement, insurance and contract terms | Preliminary scope and jurisdiction matrix |
| Before any notice | Verified facts, required recipients, approved channels, support arrangements | Legal-reviewed notification package and communications plan |
| Seven-day review | Investigation progress, notification status, monitoring, customer questions | Updated timeline, FAQ, and open-decision list |
| 30-day review | Root cause, remediation, control failures, lessons learned | Corrective-action register and management report |
For the jurisdiction matrix, create separate rows for each potentially applicable framework rather than one row labeled “privacy law.” Common categories include U.S. state breach-notification rules, federal or sector-specific requirements, contractual reporting clauses, European data-protection obligations where applicable, and rules in the places where affected individuals live. Record the official authority, triggering event, required content, method of submission, internal owner, counsel confirmation, and the date the requirement was checked.
Deadlines and thresholds change, and the same incident can trigger different obligations for a controller, processor, employer, healthcare organization, financial business, or public-sector entity. Verify current requirements through official government or regulator sources and qualified counsel at the time of the incident. The privacy law and breach notification tracker can serve as a starting point for organizing that review.
How to interpret changes
Not every new indicator changes the notification decision, but every material change should update the incident record. An expansion from one mailbox to a shared environment may increase scope. Discovery that exposed data was encrypted or tokenized may affect the risk assessment. Evidence of access to customer records, rather than attempted access, may change the analysis. A new affected jurisdiction may add a recipient, filing, or communications requirement.
Use a simple change log with five fields: timestamp, new fact, source of the fact, decisions affected, and owner. Mark facts as confirmed, probable, or unresolved. When a fact changes, identify which customer notice, regulator submission, FAQ, contract notification, or remediation task must be updated.
Be particularly cautious with external indicators. A threat actor claim, a suspicious file name, or a customer report can guide investigation but may not prove data access. Conversely, the absence of obvious evidence does not necessarily prove that data was not accessed. Explain the confidence level behind important conclusions and preserve the evidence supporting them.
For messages received by customers or employees, include a safe verification route. The data breach notification verification guide helps distinguish a legitimate notice from a follow-on phishing attempt. If the incident involves a text message, direct recipients to the smishing verification decision tree rather than embedding urgent links in the notification.
Customer notification template
Subject: Important information about a security incident at [Organization]
“We are writing to inform you about a security incident involving [system or service]. On [date], we identified [plain-language description]. We contained the issue and began an investigation with appropriate specialists. Our investigation determined that [confirmed information about affected data]. At this time, [state what is known and what remains under review]. We have [list concrete protective actions]. You can [specific recipient actions, such as changing a reused password through the normal sign-in page and monitoring relevant accounts]. For questions, contact [verified phone number or website] using the information in this notice. We regret the concern this may cause and will provide updates if the investigation identifies material new information.”
Regulator or authority notification template
Subject: Preliminary incident notification from [Organization]
“[Organization], acting as [relevant role if applicable], is notifying [authority] of a suspected or confirmed security incident identified on [date]. The affected environment is [description]. Current findings indicate [known facts], while [open questions] remain under investigation. Potentially affected data subjects and data categories are [description]. Containment and mitigation actions include [list]. Our incident lead is [role and contact method]. We will supplement this notification as material facts are confirmed and will coordinate any additional submission requirements.”
When to revisit
Revisit this playbook at least quarterly and immediately after a significant incident, major system change, acquisition, new vendor relationship, or relevant privacy-law update. The quarterly review should confirm the incident roster, escalation numbers, backup contacts, insurer and counsel details, regulator links, notification templates, approved communication channels, evidence-retention procedures, and vendor capabilities.
Run a short tabletop exercise each quarter using a different scenario, such as ransomware, business email compromise, lost device, cloud misconfiguration, or a supplier breach. Measure how long the team takes to identify the owner, preserve evidence, decide on containment, assemble the jurisdiction matrix, and draft a holding statement.
Before closing an incident, schedule follow-up checks at 30, 60, and 90 days for high-priority corrective actions. Keep the final timeline, decisions, notices, evidence inventory, and lessons learned in a controlled location. A breach response plan is useful only if the people, contacts, and assumptions in it still match the business.
Immediate action: assign an incident lead, open a dated decision log, preserve evidence, and start a jurisdiction matrix before debating public language. Those four steps give a small business the structure needed to respond calmly while facts are still developing.
