Now serving Canada and the USASupport line: 1-888-668-4474
Insights

Cybersecurity

Cyber incident response plan for a small business

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.