The call comes at 6:40 on a Tuesday: a finance user cannot open a single file on the shared drive, and every filename now ends in .locked. Your team is four people, two of them on vacation, and the first question anyone asks is the one nobody can answer fast — who does what now?

A workable incident response plan answers that in under a minute. Not a binder, not an audit exercise. Two to six pages that name the scenarios you are likely to face, the people who own each decision, and the steps to contain damage and get the business working again. Here is how to build one your team will actually open.

Pick Five Scenarios, Not Fifty

Plans fail when they try to be exhaustive. You do not need a chapter on every attack technique; you need a starting point for the handful of incidents that realistically hit a small IT shop.

• Ransomware or wiper activity on a file server, endpoint, or hypervisor.
• Business email compromise — a spoofed invoice, a mailbox rule quietly forwarding mail, a payment request that looks nearly right.
• Lost or stolen device holding company data, with or without disk encryption.
• Admin account takeover in your identity provider, cloud console, or backup platform.
• Departing or malicious insider — bulk downloads, deleted repositories, lingering access nobody revoked.

For each scenario, write five to ten lines: the first action, who decides, what to preserve, who to call. If a scenario needs more than a page, it is probably two scenarios. Keep the language boring and imperative — "Disable the account, then pull the sign-in logs for the last 30 days" beats "appropriate remediation should be undertaken."

Assign Roles for People Who Already Have Other Jobs

Small teams cannot staff a formal incident command structure, but they still need clear ownership. Four roles cover almost everything:

• Incident commander. Runs the response, makes the call on severity, and is the only person who talks to senior leadership. This role coordinates; it does not usually touch a keyboard.
• Technical lead. Directs the hands-on work: isolation, log collection, restoration.
• Communications lead. Handles staff, customer, and vendor messages so the technical people are not interrupted every ten minutes.
• Scribe. Timestamps every decision and action. This log becomes your evidence, your insurance narrative, and the raw material for your post-incident review.

With four people, one person may hold two roles — but never let the incident commander also be the scribe. The person making decisions should not be buried in notes. Name a deputy for each role, and settle in advance who takes over if the commander is the one who is unreachable.

Set Severity Levels and a Channel That Does Not Depend on Email

Define three or four severity levels by business impact, not by how scary the alert looks. A quick working scale:

• Sev 1: business-stopping, data loss or exposure likely. Wake people up, any hour.
• Sev 2: significant degradation or a confirmed compromise contained to one system. Same-day response.
• Sev 3: a single suspicious account or device. Handle during business hours.
• Sev 4: policy violation or near-miss with no confirmed impact. Log and review.

Then decide how you will talk when your normal tools may be compromised. If attackers control a mailbox or a chat workspace, announcing the incident there hands them your playbook. Agree on one out-of-band channel in advance — a phone bridge, a separate messaging app, or conference line — and put it on a card people keep offline.

Contact card fields: internal escalation numbers (office and mobile) · out-of-band bridge details · managed service provider support line and contract number · cloud and backup vendor support · cyber insurance claim line and policy number · outside counsel · forensic retainer, if you have one · after-hours facilities and building access.

Print two copies per person and store one somewhere that does not require a login. Check whether your insurance policy requires notification within a set window, and loop in counsel early on anything involving personal data — those obligations vary by jurisdiction, so get advice rather than guessing.

Decide Containment Authority Before the Pressure Hits

Containment is where hesitation costs the most. Someone needs pre-approved authority to disable an account, block outbound traffic, isolate a host through your endpoint tool, or take a service offline without waiting for a meeting. Get that authority in writing from leadership now, while nothing is on fire.

Write down the trade-offs too. Isolating a machine can destroy volatile memory that a forensic investigator might want. Reimaging a compromised server often erases the log trail. As a rule: capture what you can, document what you did, and choose rebuild over cleanup whenever evidence is not the priority. Preserve logs somewhere the attacker cannot reach — a separate account, a write-once store, or an external drive you disconnect after copying.

Recover in Order: Rebuild, Restore, Rotate, Watch

1. Confirm the foothold is gone. Check for persistence: scheduled tasks, startup items, new admin accounts, mailbox rules, API tokens, SSH keys.
2. Rebuild rather than clean any system the attacker touched. Install from known-good media or images.
3. Restore from a backup that predates the incident. Verify the backup's integrity before restoring, and test that the restore process works when you are not under pressure.
4. Rotate every credential in the affected trust path — service accounts, domain admin passwords, API keys, session tokens, and the credentials to your backup platform itself.
5. Reconnect in stages and watch closely. A week of heightened monitoring after recovery is normal, not paranoia.

Run a Lessons-Learned Meeting People Do Not Dread

Hold the review within a week, keep it to 45 minutes, and make it blameless. The goal is a better plan, not a culprit. Ask three questions: what happened, what slowed us down, and what would we change? Separate the root cause from the friction — the phishing email is the cause, but the missing backup catalog is what turned it into a two-day outage.

End with owners and dates. Then update the plan itself: adjust severity thresholds, add the vendor you wished you had called, fix the runbook step that did not work. A plan that never changes after an incident is a plan nobody read.

Keep It Short and Rehearse It

Put a one-page quick reference at the front: severity levels, roles with names and numbers, the out-of-band channel, and the first three actions for each scenario. Everything else is supporting detail.

Store an offline copy — a printed version, an encrypted drive in a locked drawer, or a password manager with emergency access configured for two people. Test the phone tree quarterly. Run one tabletop exercise a year; a 60-minute conversation through your ransomware scenario will surface gaps no document review ever will. Review the plan after every staff change, and give new hires the quick reference on day one.

The plan does not need to be impressive. It needs to be accurate, current, and short enough that a tired person at 6:40 in the morning can follow it without thinking.

Photo: Pexels / Pixabay