Small Business Incident Response Plan: Breach Response Guide

Small Business Incident Response Plan: A Practical Playbook

A cyber incident can begin with a suspicious email, an unfamiliar login, a lost laptop, a compromised vendor account or files suddenly becoming inaccessible. The first few hours are often confusing, but a written incident response plan gives your business a repeatable way to contain damage, preserve evidence, communicate accurately and restore essential operations.

This guide is designed for small businesses that may not have a dedicated security operations center or full-time incident response team. It focuses on the actions business owners, IT providers, managed service providers, operations leaders and communications staff can prepare before an incident occurs.

An incident response plan is not a substitute for legal advice, digital forensics or specialized recovery support. If personal information, protected health information, payment data, regulated records or material business information may be involved, contact qualified legal counsel and relevant insurers promptly. Notification duties vary by jurisdiction, industry and the type of information affected.

What an incident response plan should accomplish

A useful plan should help your organization answer five questions:

What happened? Define the suspected incident, affected accounts, systems, locations and data.
How do we stop it spreading? Isolate affected devices, accounts, networks or cloud resources while avoiding unnecessary destruction of evidence.
Who needs to know? Identify internal decision-makers, technical responders, legal counsel, cyber insurance contacts, vendors, law enforcement and potentially affected individuals.
What should we restore first? Prioritize systems according to safety, revenue, customer service, legal obligations and operational dependency.
How do we improve afterward? Document decisions, determine root causes, close exploited gaps and test the revised plan.

This structure aligns with established incident-handling practice. The NIST Computer Security Incident Handling Guide describes incident response as a lifecycle that includes preparation, detection and analysis, containment, eradication, recovery and lessons learned. CISA also recommends that organizations maintain and exercise a cyber incident response plan and communications plan.

Prepare before an incident

Preparation reduces the number of decisions your team must make under pressure. Keep the plan short enough to use during an emergency, but link to detailed procedures where necessary.

1. Assign roles and decision authority

Small businesses often combine several responsibilities in one person. That is acceptable if the plan clearly states who is responsible and who acts as a backup.

Incident lead: Coordinates the response, maintains the timeline and assigns actions.
Technical lead: Handles containment, account protection, logging, system analysis and recovery coordination.
Business lead: Determines which operations and services are most important to restore.
Legal or privacy adviser: Evaluates contractual, regulatory and notification obligations.
Communications lead: Drafts employee, customer, partner and public messages.
Insurance contact: Confirms whether the policy requires prior approval before engaging vendors or paying response expenses.
Human resources or facilities contact: Coordinates employee matters, physical access and insider-threat concerns when relevant.

Document the authority to disconnect systems, disable accounts, pause transactions, contact law enforcement and approve public statements. Do not assume that the most technical person should make every business or legal decision.

2. Build a current contact matrix

Store a printed copy or an offline copy of the contact list. If email or the company directory is unavailable, responders still need access to essential phone numbers and alternate communication methods.

Contact	Primary contact	Backup	When to contact
Incident lead	[Name and phone]	[Name and phone]	Every suspected security incident
IT or managed service provider	[24/7 number]	[Escalation number]	Technical investigation and containment
Cyber insurer or broker	[Claims hotline]	[Account manager]	As soon as a covered incident is suspected
Legal counsel	[Name and phone]	[Privacy counsel]	Potential personal-data, contractual or regulatory impact
Forensics or incident response firm	[Emergency number]	[Alternate provider]	Evidence collection and compromise assessment
Cloud and SaaS providers	[Support contacts]	[Account representative]	Account compromise, outages or data exposure
Law enforcement	[Local contacts]	[FBI field office or IC3]	Extortion, fraud, theft or serious disruption
Communications lead	[Name and phone]	[Backup]	Internal or external notifications

3. Identify critical systems and data

Create a simple inventory of systems that support revenue, safety, customer service and legal obligations. Include email, identity services, file storage, accounting, payroll, point-of-sale systems, websites, production systems, backups and third-party platforms.

For each system, record the owner, administrator, provider, authentication method, backup location, recovery priority and dependencies. A list that is slightly incomplete but maintained is more useful than a detailed inventory that is six years old.

4. Prepare backups and recovery access

Backups should be protected from the same compromise that affects production systems. CISA recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. Review whether backup credentials are separate, whether backup systems are reachable from ordinary user accounts and whether restoration can be performed if the primary identity provider is unavailable.

At least once a year, perform a practical recovery test. Restore a representative file, rebuild a workstation, recover a key application or simulate a cloud-account lockout. Record how long each step takes and what access or documentation was missing.

What to do during the first hour

The first priority is safety and containment, not perfect diagnosis. Use an out-of-band channel such as phone calls or a known-clean messaging method if the attacker may have access to company email or collaboration tools.

1. Confirm and declare the incident

Capture the initial report without altering the suspected device unnecessarily. Record who noticed the problem, when it was noticed, what was observed and which systems or accounts appear involved. Assign an incident number and start a timeline.

Examples of events that should trigger escalation include ransomware notes, mass file encryption, suspicious administrator logins, unauthorized payment changes, confirmed malware, exposed customer records, stolen credentials, unexplained data transfers and a lost device containing business information.

2. Contain affected systems and accounts

Disconnect affected computers from wired and wireless networks where practical.
Disable or suspend suspected compromised accounts, sessions, API keys and tokens.
Block known malicious domains, addresses or indicators supplied by your responder.
Preserve relevant cloud snapshots, logs and alerts before retention periods remove them.
Separate confirmed affected systems from clean systems during investigation and recovery.
Do not reconnect a system merely because the visible symptoms have stopped.

CISA’s #StopRansomware Guide recommends immediately isolating impacted systems and using coordinated, out-of-band communications when responding to ransomware. If network disconnection is impossible, powering down may be considered, but doing so can remove volatile evidence. For a suspected breach, coordinate with your forensic provider before shutting down or reimaging devices whenever circumstances allow.

3. Protect privileged access

Change credentials only through a coordinated process. Prioritize administrator, email, identity-provider, remote-access, backup, financial and cloud-management accounts. Revoke active sessions and rotate exposed secrets, including API keys, signing keys and service-account credentials.

Do not make password changes from a computer that may be compromised. Use a known-clean device and verify that recovery email addresses, multifactor authentication methods and administrator roles have not been altered.

4. Preserve evidence

Keep original emails, headers, ransom notes, screenshots, log exports and alerts. Do not delete suspicious files, wipe devices or rebuild every affected system before responders have documented what happened. Maintain a timeline that separates confirmed facts from assumptions.

The Federal Trade Commission advises businesses to document their investigation, avoid destroying evidence and consider independent forensic investigators who can capture images, analyze evidence and recommend remediation. Its Data Breach Response: A Guide for Business is a useful reference for organizations dealing with exposed personal information.

Ransomware incident response

Ransomware may involve both encryption and data theft. Treat a ransom note as evidence of a potentially broader compromise, not proof that only the displayed computer was affected.

Isolate affected devices, servers, virtual machines and cloud resources.
Protect backup infrastructure and verify whether backups were accessed, deleted or encrypted.
Check identity systems, remote-access tools, endpoint alerts and logs for earlier attacker activity.
Preserve the ransom note, wallet address, attacker email, file extensions and sample encrypted files.
Prioritize restoration using a clean environment and a documented critical-asset list.
Consult legal counsel, your insurer, law enforcement and qualified technical responders before making payment decisions.

Payment does not guarantee recovery, deletion of stolen data or prevention of another attack. Decisions about ransom demands can also involve sanctions, reporting, insurance and legal considerations. Do not treat payment as a technical recovery plan.

Communications and breach notifications

A communications plan should be accurate, coordinated and useful to the people who must take protective action. Avoid speculation, blame and overly broad assurances such as “no data was accessed” unless your investigation supports that conclusion.

Internal holding statement

“We are investigating a technology security incident affecting some business systems. We have activated our response process, isolated systems where appropriate and engaged specialist support. Please do not speculate publicly or forward incident-related messages. Direct questions to [contact]. We will provide the next update by [time].”

Customer or partner statement structure

State that an incident was identified and that an investigation is underway.
Describe the affected service or information only when reasonably confirmed.
Explain what the recipient should do, if any action is required.
Provide a verified contact method and a page for updates.
State when the next update is expected.
Do not disclose technical details that could increase risk or assist an attacker.

The FTC recommends reaching affected audiences, including employees, customers, investors and business partners, while avoiding misleading statements and providing information that helps people protect themselves. In the United States, all states, the District of Columbia, Puerto Rico and the U.S. Virgin Islands have breach-notification laws, but requirements differ. Additional federal or sector-specific requirements may apply. Have counsel determine who must be notified, what must be said and when.

Recovery: restore operations in the right order

Recovery should begin only after the organization has reasonable confidence that the active threat is contained. Rebuilding systems without addressing stolen credentials, persistence mechanisms or exploited vulnerabilities can lead to reinfection.

Establish a clean administration path. Use trusted devices, protected administrator accounts and verified authentication methods.
Address the initial access method. This may include resetting credentials, removing unauthorized remote tools, fixing a vulnerable service, closing a misconfiguration or replacing compromised hardware.
Restore identity and core communications carefully. Validate administrator roles, forwarding rules, mailbox access, multifactor authentication and recovery methods.
Recover critical services from known-good sources. Use clean backups or rebuilds, then scan and validate before reconnecting systems.
Restore in business priority order. Start with services required for safety, revenue, customer commitments and dependent systems.
Monitor after restoration. Increase logging and alert review, watch for repeated access attempts and keep affected systems under observation.

Define recovery targets before an incident. A recovery time objective describes how quickly a service should be restored; a recovery point objective describes how much data loss is acceptable. These are planning targets, not promises, and should be based on business impact rather than technical convenience.

Post-incident review

Hold a review after immediate operations stabilize. Focus on improving the system rather than assigning blame. Ask:

How was the incident detected, and how long did validation take?
Which accounts, systems, vendors and data were affected?
Did the contact matrix work when email or normal systems were unavailable?
Were logs and backups available, trustworthy and usable?
Which containment decisions helped, and which caused delays?
Were communications accurate, timely and consistent?
What technical, procedural or training changes are required?
When will each corrective action be completed, and who owns it?

Update the incident response plan, contact list, asset inventory and recovery procedures based on documented findings. Keep a concise incident record for insurance, legal, audit and future training purposes.

Incident response tabletop exercise template

Run a tabletop exercise at least annually and after major changes to systems, vendors or staffing. The goal is to rehearse decisions, not to test whether employees can guess the “right” answer.

Scenario

“At 8:15 a.m., an employee reports that shared files have unfamiliar extensions. Several customers also report receiving suspicious messages that appear to come from the company. The accounting administrator cannot sign in, and the backup console shows an unexpected configuration change.”

Exercise prompts

Who declares the incident, and how are responders contacted if email is unavailable?
Which systems and accounts are isolated first?
Who can authorize network disconnection or service shutdown?
What evidence must be preserved before devices are rebuilt?
When are the insurer, counsel, IT provider, law enforcement and customers contacted?
Which business functions are restored first?
What facts can be stated publicly at 10:00 a.m.?
What would change if stolen data were confirmed?

Exercise record

Finding	Risk or impact	Owner	Due date	Status
[Example: insurer contact stored only in email]	[Cannot confirm coverage quickly]	[Name]	[Date]	[Open]
[Finding]	[Impact]	[Owner]	[Date]	[Status]

Downloadable quick checklist

Declare the incident and start a timestamped log.
Move communications to a trusted out-of-band channel.
Isolate affected devices, accounts, networks or cloud resources.
Protect administrator, email, remote-access, backup and financial accounts.
Preserve emails, logs, alerts, ransom notes and other evidence.
Contact your IT provider, insurer, legal counsel and response specialists.
Identify affected systems, data, users, vendors and business processes.
Determine notification and contractual requirements with qualified counsel.
Restore from verified clean sources in business priority order.
Monitor restored systems and complete a documented lessons-learned review.

A small business does not need a large manual to begin. It needs clear authority, reliable contacts, protected backups, practical containment steps and a communication process that people can follow under pressure. Review the plan whenever systems or vendors change, and exercise it before a real incident exposes the gaps.

Small Business Incident Response Plan: Breach Containment, Communications and Recovery Steps