What is incident response in a small business?

Incident response is the agreed sequence of steps a business follows when something goes wrong with its IT — a phishing compromise, a ransomware event, a stolen laptop, a suspicious login. For a 20-person business it boils down to six stages: detection, triage, containment, recovery, communication, and post-mortem. The playbook should be written, practised, and short enough that someone reading it for the first time at 9pm on a Friday can still follow it.

How quickly should we respond to a security incident?

For a small business, the realistic targets are: detect within 15 minutes during business hours, triage within 30 minutes, contain within 2 hours, and begin recovery within 4 hours. Recovery time objective (RTO) for the most critical systems should be under 24 hours; recovery point objective (RPO) — the most data you can afford to lose — should be under 4 hours. These numbers are achievable with proper EDR, immutable backups, and a documented playbook.

Who should run incident response in a 20-person business?

One named incident lead inside the business (usually a director or senior operations person) plus the MSP. The internal lead owns business decisions — who to tell, when to disclose, when to bring in legal. The MSP owns technical execution — containment, forensics, recovery. The pairing matters: technical-only response misses business risk, business-only response misses technical risk.

When should a small business call the NCSC or report to the ICO?

Report to the NCSC via their Suspicious Email Reporting Service for phishing and via Action Fraud for cybercrime. Report to the ICO within 72 hours of becoming aware of a personal data breach that poses a risk to individuals — this is a legal obligation under UK GDPR. If you are unsure, report; the ICO would rather be told and stand down than not be told. We help clients make these calls in real time during an incident.

What is a post-mortem and why does it matter?

A post-mortem is the structured review you run after an incident is resolved — usually 5 to 10 days later when adrenaline has worn off. It documents what happened, what worked, what didn't, and what changes prevent a repeat. Done well it is blameless and produces concrete action items. Done badly it produces a Word document no-one reads. The point is not the document; the point is the changes to controls, people, and process that come out of it.

Do we need a written incident response plan?

Yes — but a short one. A 20-person business doesn't need a 40-page corporate IR plan. It needs a one-page playbook that fits on a fridge: the six stages, the named roles, the call list, the holding statement, and where the recovery procedures live. Long IR plans tend to live in SharePoint and never get read. Short ones get used.

← All insights

Blog 9 May 2026 8 min read

Good incident response in a 20-person business

Most incident response advice is written for organisations with a SOC, a CISO, and a legal team on speed-dial. None of which a 20-person Manchester business has at 4pm on a Friday. Here's what good actually looks like at our scale of client — and the one-page playbook we hand to every new client on day one.

By Ben Rosenthal, Senior Technician

Editorial illustration of a purple stopwatch with a warning triangle next to it — representing time-critical incident response in a small business.

I've sat in front of a screen at 9pm on a Tuesday watching a client's first ransomware event unfold. Two laptops popped, encryption spreading laterally over SMB, the on-call director ringing me asking what to do. We had a written playbook — about a side of A4 — and we worked through it in order. By midnight we'd contained, by morning we were restoring, and by Friday we were doing the post-mortem.

That's not because we're heroes. It's because the work had been done before the incident — the EDR was deployed, the backups were immutable, the playbook was written, the call list was current. None of which is glamorous. All of which is the difference between a controlled incident and an existential one.

Here's what good incident response looks like for a business of around twenty people. Not enterprise. Not a SOC. Not a 40-page plan. The actual thing that works at this scale.

The six stages

1. Detection — knowing it happened

The first failure mode is not knowing. The Verizon Data Breach Investigations Report consistently shows that most SMB breaches are discovered by external parties — a customer, a bank, a supplier — not the business itself. That is a tooling problem.

For a 20-person business, detection is three things: Microsoft Defender for Business (or equivalent EDR) reporting alerts to a managed inbox, conditional access flagging unusual sign-ins, and email security catching phish before it lands. We aim for 15 minutes from event to detection during business hours. Out of hours it can stretch to 60 — most of our clients aren't paying for 24/7 SOC and don't need to.

2. Triage — is this real, and how bad?

The next failure mode is treating every alert as DEFCON 1. Most aren't. Triage is the bit where someone with context decides: false positive, low-severity (one device, one user, contained), or live incident (lateral movement, data exfil, business systems impacted).

The decision rule we use: can we describe the blast radius in one sentence? If yes, it's probably contained — proceed cautiously. If no, treat as live incident and escalate. We aim to triage within 30 minutes of detection.

3. Containment — stop the bleed

This is the bit where speed matters most. The goal is not to fix it — it's to stop it spreading.

For an endpoint event: isolate the device via Defender (one click, takes about 30 seconds), disable the user account in Entra, kill any active sessions, force MFA re-enrolment. For email compromise: revoke OAuth grants, reset password, terminate sessions, audit forwarding rules. For ransomware: isolate the affected segment of the network, take backups offline immediately so they can't be encrypted, identify patient zero.

Target: contained within 2 hours. The clock starts at detection, not at "we've worked out what's going on" — partial containment beats full understanding every time.

4. Recovery — get the business back

Recovery is the boring bit. Restore from backup, rebuild affected machines from gold image, re-enrol identities, verify data integrity, bring users back online in stages. The non-negotiables here are:

Immutable backups — backups that ransomware cannot encrypt because they are write-once. Without these you do not have a recovery story; you have a hostage situation.
Tested restore — backups that have been actually restored within the last 90 days, not just verified by the backup software.
Clear RTO/RPO targets — for a 20-person business we set RTO under 24 hours for critical systems (email, finance, file storage) and RPO under 4 hours.

If you don't know your last successful restore date, that's the gap to close before any other security work.

5. Communication — tell the right people the right things

This is where most small businesses come unstuck. They focus on the technical fix and forget that incident response is also a comms exercise.

The internal lead owns this. There are usually four audiences:

Staff — what to do, what not to do, when systems are coming back. Short, calm, frequent updates beat one long email.
Customers — only if their data or service is affected. Holding statement first, full statement when facts are confirmed. Never speculate publicly.
Regulators — the ICO 72-hour clock starts at awareness, not confirmation. If a personal data breach is reasonably likely, report.
Authorities — phishing to the NCSC Suspicious Email Reporting Service, cybercrime to Action Fraud.

Pre-write the holding statements. Don't try to draft them at 9pm on a Friday during the incident.

6. Post-mortem — make sure it doesn't happen again

Five to ten days after resolution, when adrenaline has worn off, run a structured review. Three questions: what happened, what worked, what changes do we make? Blameless. Written down. Action items with owners and dates.

The output is not the document. The output is the changes — to controls, to process, to training, to tooling. We track those action items in the same way we'd track project tasks. Six months later we audit them. If they didn't get done, we ask why, and they often get re-prioritised.

The one-page playbook

For our clients, the actual playbook lives on one side of A4. Six stages as section headers. Roles named (incident lead, MSP technical lead, comms lead, deputy if leads are unavailable). Call list with mobiles. Pre-written holding statement. The single line: "If in doubt, isolate the device and ring Inology." The location of the recovery procedures.

That's it. Print it. Pin it next to the kettle. Practise it once a year as a tabletop exercise — sit in a room, pick a scenario ("ransomware on the finance laptop"), walk through it, find the gaps. The first practice is always uncomfortable. The fifth one is muscle memory.

What this costs

For a 20-person business, the tooling that makes good incident response possible is largely already in Microsoft 365 Business Premium: Defender for Business, Intune, Entra ID Plan 1. Add immutable backups (we use Datto with cloud immutability) and a managed alerts inbox at the MSP. The marginal cost per user, on top of M365, is small — single-digit pounds per user per month.

The cost of not doing it is the average UK SMB breach — a few weeks of disruption, customer trust damage, and a number that quietly five-figures its way onto the balance sheet.

How we onboard new clients

In the first 30 days we baseline detection (EDR deployed, alerts routed, conditional access enforced), test restore (actual restore from backup, not theoretical), write the one-page playbook with the client, and run a tabletop exercise. By day 90 the client has been through a practised scenario at least once. After that, we run an annual exercise as part of our regular service rhythm.

It's not glamorous. It's not the bit that wins awards. But it's the bit that means when something does happen, you spend the evening on the phone walking through a playbook — not staring at a screen wondering what to do.

#incident-response#security#smb#playbook

Want to pressure-test your incident response?

We'll run a tabletop exercise with your team — pick a scenario, walk through your current process, write up the gaps. No commitment, no jargon, no scoreboard.

Talk to a human