A small-business incident plan should help people make the first safe decisions under pressure. It does not need to predict every attack. It needs current contacts, clear authority, accessible procedures, and enough technical and business context to contain harm while preserving the ability to investigate and recover.
Connect incident response to business risk
Start with critical services, sensitive information, regulatory and contractual duties, cyber insurance conditions, and dependencies on suppliers. This context determines urgency and who must be involved.
NIST SP 800-61 Rev. 3 places incident response throughout cybersecurity risk management rather than treating it as an isolated technical phase. Preparation, detection, response, and recovery improve together.
Define reporting and severity
Give every employee a simple way to report suspicious messages, unusual sign-ins, lost devices, accidental disclosures, and operational disruptions. State what qualifies as urgent and provide an alternative route if email or normal chat is unavailable.
Use a small severity model based on business impact, data sensitivity, spread, and time pressure. Severity should trigger specific leadership, technical, legal, insurance, and communication contacts.
Assign authority before the incident
Name the incident lead and backups. Document who can isolate a device, disable an account, stop a service, engage outside specialists, approve spending, notify an insurer, contact law enforcement, and communicate with customers or employees.
Record mobile numbers and out-of-band contact methods. Vendor portals and account numbers should be available without relying on the compromised environment.
Prepare short scenario playbooks
Write first actions for the events most likely to create serious impact. A playbook should include evidence to preserve, containment options, approval requirements, validation steps, and escalation criteria—not a rigid sequence that prevents judgment.
- Compromised email or administrator account
- Ransomware or malicious activity on a device
- Fraudulent payment or supplier banking change
- Lost or stolen device
- Sensitive information sent to the wrong recipient
- Cloud, internet, or critical supplier outage
Plan evidence, communication, and obligations
Keep a time-stamped incident log of observations, actions, approvals, and communications. Preserve relevant logs and systems where practical and avoid making unnecessary changes that destroy evidence.
Legal counsel, privacy specialists, insurers, regulators, customers, and law enforcement may have different notification requirements. The plan should identify who evaluates those duties; it should not ask a technician to make legal conclusions during containment.
Recover safely and validate the business service
Recovery is more than turning systems back on. Confirm the threat is contained, credentials are protected, restored data is trustworthy, required integrations work, monitoring is active, and a business owner accepts the service.
Prioritize from documented recovery objectives. Keep temporary workarounds and heightened monitoring in place until the environment is stable.
Exercise and improve
Run a tabletop scenario with leadership, operations, communications, and technical participants. Test contact details, decision authority, access to backups and logs, supplier response, and communication drafts.
After an incident or exercise, assign improvements with owners and dates. Update the plan, architecture, controls, training, and supplier arrangements using what the team learned.
Authoritative resources
These primary sources provide additional technical and operational guidance for the topics discussed above.