Incident plan essentials
- Before an incident: Name who can declare an incident, disable accounts, isolate devices and contact outside help.
- First hour: Protect people and critical services, preserve useful evidence, contain the known path and keep a decision log.
- Recovery: Restore from verified sources, monitor for recurrence and document what changed.
- Framework: NIST SP 800-61 Rev. 3 is the current NIST incident-response guidance; it was finalized in 2025.
Last updated: September 24, 2026
An SMB incident plan should work when the primary IT person is unavailable. It needs contact details, decision authority and a short set of actions that can be followed under pressure. NIST SP 800-61 Revision 3 frames incident response across the NIST CSF 2.0 functions; it supersedes Revision 2. The plan below turns that guidance into an operating checklist, not a claim of NIST certification.
Put these names in the plan now
| Role | Authority and backup |
|---|---|
| Incident lead | Declares the incident, coordinates decisions and maintains the log; name a deputy |
| Technical lead or IT provider | Investigates and contains accounts, devices and services within pre-approved limits |
| Business owner | Chooses continuity priorities and authorizes disruptive steps |
| Communications/legal contact | Reviews customer, regulator, insurer and public notifications as applicable |
| Finance contact | Calls the bank promptly when a payment or vendor record may be affected |
Store the contact list offline as well as in a restricted online location. Include after-hours numbers, provider contracts, cyber-insurance contact, key customer dependencies and the location of backup credentials. Do not put passwords into the incident document.
A first-hour decision sequence
- Confirm the report. Record who noticed what, when, the affected systems and immediate business impact. Avoid guessing the root cause.
- Protect critical operations. If a payment is at risk, call the bank. If a device may be spreading malware, isolate it using the pre-approved method. If an account is compromised, revoke active sessions and reset access through a clean administrator path.
- Preserve what you can. Save relevant messages, alerts, timestamps, account events and device identifiers. Capture evidence before wiping or rebuilding when safe and feasible; ask a specialist if legal or forensic requirements are likely.
- Set a communication rhythm. Tell leadership what is known, unknown, next and owned. Avoid premature public claims or promises of a recovery time you have not tested.
- Escalate appropriately. Contact the IT provider, insurer, bank, law enforcement or counsel according to the incident and contractual obligations. Reporting duties vary by sector, data, location and contract; obtain legal advice for actual notice requirements.
There is no universal “first 15 minutes determine the outcome” rule. The right containment action depends on whether the event is a lost device, suspicious login, ransomware, data exposure or fraudulent transfer. Preserve the ability to learn what happened while stopping active harm.
Scenario branches
| Signal | Initial containment | Check before restoring |
|---|---|---|
| Suspicious Microsoft/Google login | Revoke sessions, reset credentials, review MFA and forwarding rules | Accounts, delegated access and mail rules are clean |
| Ransomware on one device | Isolate affected device and stop shared-drive spread | Backups are separate, clean and restorable |
| Lost work laptop | Revoke access, locate/lock/wipe if managed, assess stored data | Replacement device and account access are verified |
| Payment diversion | Call bank immediately, pause related transfers, preserve correspondence | Vendor record and mailbox compromise path resolved |
| Exposed customer file | Restrict sharing and preserve access logs | Scope, affected data and notification decisions reviewed |
For ransomware-specific steps, use the first-30-minutes guide. For payment diversion, use the BEC verification guide. The backup strategy guide covers restore testing before a crisis.
Recovery and learning
Restore the most important service first, using a known-good backup and clean credentials. Test a small restored workload before reopening broad access. Monitor for repeated malicious activity, then record the root cause where known, workarounds, customer impact and unresolved uncertainty. Assign corrective actions with owners and dates. A short post-incident review is useful even when the event turns out to be benign.
Build and practice in 90 days
| Window | Deliverable | Proof |
|---|---|---|
| Days 1–30 | Roles, contacts, critical services and pre-approved containment actions | Deputy can locate and use the plan |
| Days 31–60 | One account-compromise and one payment-fraud walkthrough | Decision log and missing access identified |
| Days 61–90 | Restore test, customer-communication draft and corrective-action review | Restore record and updated plan |
Use the editable runbook
Download the incident-response runbook and fill in real owners, contacts and decision rights. Keep a copy accessible if your normal cloud account is unavailable.
Sources checked September 24, 2026: NIST SP 800-61r3, NIST's revision announcement, CISA SMB resources, and FBI IC3 BEC response. This is a planning guide, not legal advice or a tested incident-response service.