Don't panic. We'll walk you through exactly what to do — step by step, right now.
You're staring at a login alert at 2 AM. The CFO's mailbox is suddenly full of password-reset requests you never sent. A vendor just emailed that your production database is being auctioned on a dark-web forum. You need an incident response plan — and you need it right now, not next quarter. This page is the SMB incident response playbook for the small business whose worst day has just arrived: the regional law firm, the 40-person manufacturer, the specialty clinic, the B2B SaaS startup that finally hit product-market fit. We walk through the six-phase framework that the NIST Computer Security Incident Handling Guide describes and translate it into the language, the roles, and the timeline of a team that does not have a dedicated CISO. Pair this guide with our free cyber risk assessment to baseline your stack before a breach happens, and with our policy and threat-stack builders to lock in the controls a regulator will look for after one does.
An incident response plan is the written, rehearsed playbook that an organization follows the moment a security event crosses the line from "anomaly" to "incident." It is not a binder on a shelf that no one opens; the IRS Commissioner, the FBI, and your cyber insurer will all ask whether you had one in the days before a breach. A working IRP names the people who pick up the phone, the thresholds that trigger each escalation, the systems that come offline first, and the regulators that get notified by what deadline.
For a small business, a good IRP fits on five to ten pages. It covers the six NIST phases below, lists the named roles (Incident Commander, Communications Lead, Technical Lead, Legal/Privacy Lead, External Counsel, Insurance Broker) by job title — not by name, because people leave — and is rehearsed twice a year with a tabletop exercise. Run a free cyber risk assessment against your current plan; the scorecard will flag exactly which sections are stale, which controls are missing, and which third-party processors you forgot to include in your notification list.
The NIST Incident Response framework breaks an incident into six phases. Each phase has a documented entry criterion, an exit criterion, and a named owner. SMBs that skip a phase consistently lose twice: once to the attacker, and once to the regulator who can show they did not follow their own plan.
The pre-incident work that pays off when things go wrong: an updated asset inventory, an offline backup of every critical system, MFA on every privileged account, an out-of-band contact list, and a signed retainer with a digital forensics firm. Preparation is where 80% of your real incident response time is either bought or wasted.
The minute a SOC alert, a helpdesk ticket, or a vendor call hints at an incident, the team confirms the scope. What systems are affected? Is data exfiltration in progress? Who declares the incident, and by what criteria? Triage ends with a written severity rating (Low / Medium / High / Critical) and a 15-minute briefing call.
Stop the bleeding without destroying evidence. Short-term containment is network isolation — pull the host off the VLAN, revoke the OAuth tokens, block the C2 IP. Long-term containment is the parallel decision to keep operating on a clean environment while forensics preserves the compromised one. Never reboot, wipe, or "fix" a compromised system before imaging it.
Remove the attacker's foothold: the planted webshell, the rogue cron job, the modified SSH key, the staging account in your CRM. Patch the underlying vulnerability that let them in. Rotate every credential that touched the affected host, including service accounts and API tokens.
Restore from the offline backup taken before the breach — never from a backup made after the attacker arrived. Validate that restored systems are clean, monitor them with elevated logging for at least 30 days, and only bring them back into production after the Technical Lead signs off in writing.
The "lessons learned" meeting held within 14 days. What worked? What didn't? Which playbook step was missing? Which control, added now, would have prevented this specific incident? The output is a written report, an updated IRP, and a prioritized ticket list assigned to named owners with dates.
Every US state, every EU member state, and most industry regulators have hard deadlines for notifying affected individuals and authorities after a data breach. Miss the deadline and the fine is on top of the breach cost, not in place of it. The table below summarizes the deadlines that matter most for a US SMB; check your state attorney general's site for the wording that applies in your jurisdiction.
| Framework | Deadline | Who Must Be Notified |
|---|---|---|
| GDPR (EU) | 72 hours to supervisory authority | Lead supervisory authority, affected data subjects |
| HIPAA | 60 days from discovery; immediate notice to HHS for 500+ records | HHS Secretary, affected individuals, prominent media for 500+ in a state |
| PCI DSS | Immediately upon discovery | Card brand, acquiring bank, payment processor |
| GLBA / FTC Safeguards | 30 days from discovery (as of 2024 Safeguards Rule amendment) | FTC, affected customers |
| State breach laws (CA, NY, TX, all 50 states) | 30–90 days depending on state and data type | State AG, affected residents, consumer reporting agencies for 1,000+ |
| SEC Item 1.05 (Form 8-K) | 4 business days | SEC and public investors (public companies only) |
Cyber insurance is the difference between a recoverable incident and a business-ending incident — but only when a claim is actually paid. Industry data shows that roughly 40% of small-business cyber claims are denied, almost always because the policyholder could not prove it had the controls listed on page one of the application. The three controls underwriters deny on most often are: multi-factor authentication on email and remote access, tested offline backups, and an endpoint detection and response (EDR) agent on every laptop and server. If your application says you have MFA and your incident started with a credential-stuffing attack that hit an MFA-less admin account, the carrier will deny the claim for material misrepresentation.
The fix is to align your incident response plan with what your policy actually requires. Read the "Minimum Required Security Controls" section of your cyber insurance application, and treat every control named there as a contractual obligation, not a suggestion. Our policy builder and threat-stack assessment tools map each control to the documentation an underwriter will request at claim time — so that the day a breach happens, you are answering "yes, here is the evidence" instead of "we thought we had that."
The same six mistakes show up in incident after incident after incident. Reading this list once before you need it will save you a six-figure lesson.
Print this. Stick it next to the on-call list. The order matters — steps 1–4 happen in the first hour, steps 5–7 happen that same calendar day, steps 8–10 happen in the first week.
Detection is the gap between the moment the attacker gets in and the moment you know. For SMBs the gap is measured in weeks, not hours — Verizon's 2025 DBIR found the median time-to-discovery for SMB breaches is 240 days. Closing that gap is the highest-leverage work you can do before an incident happens, because every decision downstream — what you preserve, who you notify, what you recover from — depends on knowing it actually happened. Run our free data breach scanner to check whether your domain or staff emails already appear in known public breach databases — it gives the responder a fast second opinion when the SOC alert is ambiguous.
Five signal categories drive detection for an SMB:
Triage the signal within 15 minutes. Confirm scope across hosts, accounts, and data stores; classify severity (Low / Medium / High / Critical) based on data class crossed with blast radius crossed with any exfil evidence; declare the incident and name the Incident Commander. The 15-minute briefing call should produce a written severity rating, an initial scope statement, and a decision to continue investigating on normal cadence or escalate. Run a free external scan with our Data Breach Scanner to confirm whether your perimeter already shows signs of an active incident — it is a useful starting point when the SOC alert is ambiguous and you need a second data source.
Containment is the most-overstepped phase of the SMB playbook. The instinct in the moment is to fix the problem — pull the plug, reimage the laptop, restore the file share. Every one of those actions destroys the in-memory state, the registry hives, the running process list, the timestamps, and the network connections your forensics firm needs to attribute the attack, scope the breach, and prove to regulators what actually happened. A recoverable technical incident becomes an unrecoverable regulatory one when the only system that knew the answer gets reformatted.
Short-term containment isolates without altering: pull the host off the production VLAN, revoke OAuth tokens and active sessions, block the C2 IP at the perimeter firewall, sinkhole suspicious DNS to a controlled host. Long-term containment is the parallel decision to keep operating in a clean environment (a freshly-built workstation for the now-isolated user, a backup tenant for the now-revoked application) while forensics preserves the compromised one as evidence. Make the long-term decision in the first hour — do not let "we'll keep working on it for a few more hours" become the reason the attacker reaches one more system.
Evidence-preservation mandate: never reboot, wipe, reimage, or run antivirus on a compromised host before a forensic image has been completed. Memory-resident malware, encrypted file handles, and the running process list are all lost on reboot. The disk can be forensically imaged bit-for-bit; the RAM cannot. Your forensic firm will image with a hardware write-blocker or a trusted bootable tool, then hash-verify the image before analysis. Anyone pushing back on this rule — including the affected user who wants their laptop back — is told it is for the regulator, not for them.
Eradication is where most SMB incidents lose ground. The attacker got in through one door; they left through many. Treating the door you can see and ignoring the rest is how the same intruder is back in 72 hours.
Run a forced artifact-hunt checklist with your forensic firm (or your IT lead if you do not yet have a retainer) before any system is returned to service:
Patch the underlying vulnerability (the unpatched Confluence server, the misconfigured S3 bucket, the phishing-resistant-but-not-phishing-proof MFA gap on email) and rotate every credential that touched the affected host — user accounts, service accounts, API tokens, database credentials, signing keys, and SSL private keys. Treat rotation as a mandatory step, not a follow-up that can wait. The credential the attacker exfiltrated is the credential they will try tomorrow on the box you have not yet thought to check.
Recovery is the phase where SMBs most often undo containment work. The instinct to "just restore from last night's backup" is the instinct that restores from a backup the attacker already had write access to. The result: the system is "back online" for twelve hours, then the attacker returns through the same encrypted-channel foothold they restored alongside the data.
Restore from the offline, immutable backup taken before the attacker arrived. Verify the backup by hashing it against your pre-incident known-good state before mounting — if the hashes differ, you are restoring an attacker-controlled copy. If you have no pre-incident backup, recovery is not yet possible; your incident is still in eradication.
Stage return to production in this order:
For SMBs that do not have a tested recovery process yet, start with our Incident Response Plan generator — it walks you through documenting the recovery procedure before you need it. Our Security Policy Generator covers the supporting controls (backup validation cadence, MFA exceptions, privileged access reviews) so the recovery step has a written standard to point at when the auditor asks. Run a free cyber risk assessment against your recovery process to flag the controls that underwriters will look for at claim time.
Most SMB incident reviews stop at "we fixed it." That is not a review — that is a status update. A real post-incident review meets within 14 days of incident closure, is attended by the people who made the decisions (not their deputies), and produces a written deliverable that changes something. Without this step, the next attacker walks through the same door.
RACI for the review:
Use a root-cause taxonomy that crosses initial-access vector with control gap — phishing plus no MFA on email is a phishing-MFA gap; RDP brute force plus exposed RDP is an exposure-detection gap; third-party breach plus no vendor inventory is a supply-visibility gap. The taxonomy tells you which remediation ticket category each finding belongs to. Output: a written report (5–10 pages is fine), an updated IRP with the change marked, and a prioritized ticket list with named owners and dates. Our Cybersecurity Audit Report baselines the controls you should add as remediation tickets — running it after an incident closes the loop between the breach you just had and the control gap that let it happen.
The best incident response plan is the one you wrote before the incident. Proactive preparation is the work that turns a worst-case day into a recoverable expense. The three artifacts that matter most:
Pair with our free cyber risk assessment to baseline your stack before a breach happens — the scorecard will flag exactly which sections of your preparation phase are stale, which controls are missing from your incident types, and which third-party processors you forgot to include in your contact list.
The questions below are the ones our SMB customers ask most often in the days before they decide to write or rewrite their incident response plan. Each answer pairs a practical action with the regulatory or insurance context that drives the timing. Browse the FAQ below; the full structured-data FAQPage schema is at the top of this page.
Q: What is the first thing I should do during a cybersecurity incident? Immediately contain the affected systems: disconnect impacted devices from the network, revoke compromised credentials, and preserve logs before they are overwritten. Do not reboot affected machines — forensic evidence is often lost on reboot. Once contained, activate your incident response plan and notify key stakeholders within the first hour.
Q: When do I need to notify regulators or customers after a breach? Notification timelines depend on your jurisdiction and the type of data involved. GDPR requires notification to supervisory authorities within 72 hours of discovering a personal data breach. HIPAA requires covered entities to notify HHS and affected individuals within 60 days. Most US states have breach notification laws requiring customer notification within 30–90 days. Consult legal counsel promptly — penalties for missing deadlines can exceed the cost of the breach itself.
Q: What should be in an incident response plan for an SMB? An effective SMB incident response plan covers six phases: Preparation, Identification, Containment, Eradication, Recovery, and Post-Incident Review. The plan should assign specific roles, include vendor contacts for cyber insurance, legal counsel, and a forensic firm, and be tested annually with a tabletop exercise.
Q: Does cyber insurance cover all incident response costs? Most cyber insurance policies cover forensic investigation, legal notification, credit monitoring for affected individuals, business interruption losses, and ransomware payments, subject to policy limits. However, 40% of claims are denied, most commonly for failure to maintain required security controls like MFA. Review your policy carefully before an incident.
Q: How do I detect a cybersecurity incident early enough to respond? Detection comes from five signal categories — EDR on endpoints, SIEM log correlation, email gateway flags, helpdesk ticket clustering, and third-party tips. Triage within 15 minutes and classify severity by data class crossed with blast radius. Our Data Breach Scanner gives a second data source when the SOC alert is ambiguous.
Q: How do I contain an incident without destroying the evidence? Short-term containment isolates (network segmentation, token revocation, DNS sinkhole) without altering the host. Never reboot, wipe, or run antivirus before a forensic image. Long-term containment is the parallel decision to keep operating in a clean environment while forensics preserves the compromised one.
Q: What artifacts must be hunted and removed during eradication? Webshells, cron jobs, unauthorized SSH keys, scheduled tasks, rogue IAM users, EDR policy exclusions, OAuth app grants, and SSO federation trusts. Rotate every credential that touched the affected host.
Q: How do I recover systems safely after a breach? Restore from the offline, immutable backup taken before the attacker arrived. Stage the return to production with elevated monitoring for at least 30 days. The Technical Lead must sign off before restored systems handle real customer data.
Q: What does an SMB post-incident review actually look like? Held within 14 days. Incident Commander runs the meeting. Outputs: a written report, an updated IRP, and a prioritized remediation ticket list with named owners. Our Cybersecurity Audit Report baselines the controls you should add as remediation tickets.
Q: How often should an SMB run a tabletop exercise? At least twice a year — quarterly is the standard. Rotate through ransomware, business email compromise, third-party breach, and insider threat scenarios. The plans that have never been rehearsed are the plans that fail at 2 AM.
Answer a few quick questions so we can build your personalized response playbook.
We'll classify your incident type, assign a severity level, and generate a step-by-step containment playbook with a notification checklist — all in about 15 seconds.
Classifying incident type and severity...
This playbook is AI-generated guidance. Contact qualified legal counsel, a cybersecurity incident response firm, and your insurance carrier before taking actions that may have legal or regulatory implications.
Required notifications based on your compliance obligations and incident type. Check off each one as you send it. Deadlines are countdown from incident declaration.