Incident Response Plan for Small Business IT

Incident Response Plan for Small Business IT: Who Calls Whom

An incident response plan is the short written path a small IT team follows when something bad happens — ransomware, a leaked password, a vendor breach, or a critical system that will not come back. For roughly 20–100 person companies, that is not a 24/7 SOC runbook: it is who to call, how to triage severity, what to contain first, what to tell staff and customers, how to restore, and a one-page postmortem so the same failure does not repeat. This playbook sits beside your business continuity plan (keep the business running) and your helpdesk (day-to-day tickets) — it is the “security or critical IT incident” lane when minutes matter.

What is an incident response plan for small business IT?

An incident response plan (sometimes called a security incident response plan or incident response playbook) is a short, living document that answers five questions under pressure: who leads, how bad is it, what do we contain first, what do we say, and how do we restore without making it worse.

At SMB scale, IT incident response is not a dedicated security operations centre. It is a named incident lead plus one backup, three plain-language severity levels, a containment checklist you can follow at 11pm, and a one-page write-up after every real event. Cyber incident response and it security incident response use the same spine — the label changes with the trigger (malware, credential leak, vendor compromise, or a system that blocks payroll), not with team size.

Keep the plan next to identity and ticket hygiene you already own. Fuzzy MFA recovery? Fix your MFA rollout before inventing a thicker runbook. Incidents vanishing into DMs? Fix helpdesk intake first.

How is incident response different from business continuity or a helpdesk ticket?

Three lanes, one IT team. Mixing them up is how Sev1 events become “we’ll pick this up Monday.”

• Helpdesk / ticketing — day-to-day requests: password resets, new laptops, “printer is weird.” Track ownership and history (helpdesk ticketing for small business).
• Business continuity — keep the company working through outages, people gaps, and vendor downtime: what must stay up, who covers after hours, how you restore access (business continuity for a small IT team).
• Incident response — active security or critical-system event: contain → communicate → restore → learn. Ransomware, a leaked admin password, a compromised SaaS integration, or identity that will not come back cleanly.

Continuity asks “how do we keep serving customers?” Incident response asks “what do we stop, who do we lock out, and what evidence do we keep before we wipe?” Link both documents; do not merge them into one synonym post. A lockout ticket can escalate into an incident when severity says so — that handoff belongs in writing.

Who do you call, and how do you triage severity in the first hour?

Name people before the panic — who calls whom is the point of the plan.

1. Incident lead — owns severity, containment, and the single status channel (one named person).
2. Backup lead — same authority when the primary is unreachable; mobile numbers that work if Slack/email is part of the incident.
3. System owners — identity, email, file store, CRM, phones/softphones, VPN (reuse your continuity critical-systems list).
4. Leadership contact — who hears Sev1 within the first hour. One name, not a committee.

Severity in plain words (edit to fit your company):

• Level: Sev1 — Meaning: Customer data, payroll, or payment systems at risk; widespread identity compromise — Wake people?: Yes — escalate to incident lead within 15 minutes
• Level: Sev2 — Meaning: One critical system down or a contained account compromise; work partially blocked — Wake people?: Lead engages same day; backup if lead is out
• Level: Sev3 — Meaning: Annoying, reversible, work continues — Wake people?: Ticket and next business day unless it escalates

First-hour triage: open one ticket or incident channel (no DM scatter), assign severity out loud, contain before you “investigate forever,” and preserve a light evidence note before you wipe a machine. If calls or the WAN are the incident class, use your VoIP network requirements checklist.

How do you contain, communicate, and restore without a full SOC?

Most 20–100 person teams will never staff a SOC. You still need a boring contain → communicate → restore loop.

Contain first:

• Revoke or reset compromised accounts; kill active sessions where the IdP allows it.
• Isolate the affected device or user; pull it off Wi-Fi if malware is suspected.
• Disable the risky integration, API key, or shadow SaaS connector (shadow IT is where surprise incidents often start).
• Document what you changed — time, account, action — in the single incident channel.

Communicate next: a short internal status (what happened, what to do / not do, when the next update lands). Customer-facing wording only when their data or a service they use is affected — factual, approved by the named leadership contact. No fake timelines.

Restore carefully: prefer known-good backups or vendor rollback; verify MFA and access before declaring “fixed” (MFA rollout); confirm device join/leave if a laptop was the vector (device onboarding and offboarding checklist).

You need a lead who can say “contained,” “staff notified,” and “restore verified” — not invented dashboards.

What does a practical SMB incident response checklist look like?

Use this extractable incident response checklist. Copy it into a wiki page or ticket template; same steps every time.

Before anything breaks (half day, once)

1. Name an incident lead and one backup (not “whoever is online”). Write mobile numbers somewhere the team can reach when Slack/email is down.
2. Define three severity levels in plain words (e.g. Sev1 = customer data or payroll at risk; Sev2 = one critical system down; Sev3 = annoying but work continues).
3. List top systems and who owns each (identity, email, file store, CRM, phones/softphones, VPN) — reuse the same list as your continuity plan where it already exists.
4. Confirm break-glass admin access and MFA recovery paths work when the usual SSO path is the incident (MFA rollout).

First hour (triage + contain)

1. Open one ticket or incident channel; do not scatter updates across DMs (helpdesk intake hygiene).
2. Assign severity; if Sev1, say so out loud and escalate to the named lead within 15 minutes.
3. Contain first: revoke compromised accounts, isolate the affected device/user, disable the risky integration — document what you changed.
4. Preserve evidence lightly (screenshot, export of audit log if available); do not wipe a machine before a quick note of what you saw.

Comms and restore

1. Draft a short internal status (what happened, what to do / not do, when the next update is). Customer-facing wording only if data or service they use is affected — keep it factual, no fake timelines.
2. Restore from known-good backups or vendor rollback; verify MFA and access before declaring “fixed.”
3. For on-call ping when chat is noisy or down, prefer a company-managed softphone/number on sessiontalk.io over personal WhatsApp for the named lead (optional channel — not a phone-system buying guide).

After (postmortem lite, same week)

1. Write one page: what failed, what contained it, what you will change (MFA gap, shadow IT app, device offboarding, vendor access) — see shadow IT and device onboarding/offboarding where relevant.
2. Update the severity table and contact list; schedule a 30-minute tabletop with the backup lead within 30 days.

That list is your security incident response spine — stick to it and the plan stops being a shelf PDF.

How do MFA, shadow IT, devices, and on-call calling fit the same plan?

Incident response sits on the IT surface you already manage — not a separate silo.

MFA and break-glass — Many incidents are identity events. Offline MFA recovery and break-glass admins are response controls; keep them aligned with your MFA rollout.

Shadow IT — Unowned SaaS is how credentials and integrations surprise you (shadow IT for small business).

Devices — Lost, stolen, or malware-hit laptops need a known revoke path (device onboarding and offboarding checklist).

Remote / hybrid — Align after-hours escalation with your IT manager remote work checklist so the backup lead is not inventing side channels.

On-call calling (optional) — When chat is unreliable, ping the named lead on a company-managed softphone so the number follows the role. Softphones on sessiontalk.io (desktop, iOS & Android, pricing) are an optional bridge — not the hero of this post. Continuity owns “keep the business reachable”; IR owns “who gets woken for Sev1.”

FAQ

What is an incident response plan?

A short, written set of steps for who leads, how to triage severity, how to contain and communicate, and how to restore after a security or critical IT incident — sized for a small team, not an enterprise SOC.

How is incident response different from business continuity?

Continuity keeps the business running through outages and people gaps; incident response handles the active security or critical-system event (contain → communicate → restore → learn). Keep both; link them — see the business continuity plan for a small IT team.

Do small businesses need a full SOC?

Most 20–100 person teams do not. They need a named lead, severity levels, a containment checklist, and a vendor/MFA/device hygiene baseline — escalate to a specialist or insurer only when Sev1 data risk exceeds what you can handle.

What should we do in the first hour of a cyber incident?

Assign the lead, set severity, contain (accounts/devices/integrations), open one status channel, and avoid wiping evidence before a short note of what you observed.

Where does calling / softphone fit?

Only as an optional on-call channel when chat is unreliable — company-managed softphones on sessiontalk.io so the lead’s number follows the role, not a personal consumer app. This post is not a phone-system buying guide.