Incident Response Without a SOC: The 5-Step Playbook a 50-Person Company Can Actually Run

It is 2 a.m. Your operations manager calls: she cannot log in, and the files on the shared drive have all sprouted the same unfamiliar extension. You do not have a security operations centre. You do not have a 24/7 analyst watching a console. You have a small IT team — or one person and an outsourced provider — and a business that needs to open in six hours. The thing that decides how this ends is not a tool you should have bought; it is a plan you can run right now. Most companies under 250 people do not have one. Their entire incident response strategy is “call the IT person and hope.” This is the five-step version you can actually run without a SOC.

Why a SOC isn’t the prerequisite

The reflex when a breach hits is to assume you were beaten because you lacked enterprise tooling. You weren’t. In April 2025, NIST rewrote its incident-response guidance (SP 800-61 Revision 3) and, tellingly, moved away from a rigid lifecycle toward a model built around preparation, coordinated response, and continuous improvement — the functions of the Cybersecurity Framework, not the purchase order for a 24/7 console. The point is blunt: response quality is decided by preparation and decision-making, not by how many screens you own.

A 50-person company does not need a SOC to respond well. It needs a named owner, a written sequence, tested backups, and someone to call. Building exactly that capability — without the headcount of a full security team — is the core of our Virtual CISO service. The playbook below is what that capability looks like in practice.

The five-step playbook

Five steps, in order. Each one has a single job. Print them, put the contact details next to step one, and you have something a tired person can follow at 2 a.m.

1. Prepare — before anything happens

Preparation is the only step you can do calmly, so it carries the most weight. Name one incident lead and one deputy (so you are never blocked on a single phone). Write a one-page plan: who decides, who communicates, who to call. Set up an out-of-band communication channel — a group chat on personal phones or a separate messaging app — because if your email or network is compromised, you cannot coordinate the response inside it. Keep offline, tested backups (a backup you have never restored is a hope, not a backup). And put a number on the plan: an MDR provider, an incident-response retainer, or an external specialist you can reach out of hours.

2. Detect and triage

Without a SOC, detection comes from two places: an alert from your endpoint protection or managed detection service, or a human (“my files look wrong”). The skill is triage: in fifteen minutes, answer two questions — is this real, and how bad. Check whether it is spreading, what is affected, and whether data has left the building. If it clears the bar, declare an incident out loud. Naming it is what switches the team from “is this a glitch” to “we are running the plan.”

3. Contain — and preserve the evidence

Containment is the first hour, and it is where instinct betrays you. Isolate affected machines from the network — pull the network cable or disable Wi-Fi — but do not power them off and do not wipe them. A powered-off or reimaged machine destroys the forensic evidence you will need to know how far the attacker got, whether they are still inside, and what to put in your regulatory report. Disconnect, don’t delete. Change the credentials that matter (admin accounts, remote access, email) from a clean device.

4. Eradicate and recover

Only once you understand the scope do you remove the foothold: close the entry point, remove persistence, and rebuild or restore affected systems from a known-clean backup taken before the compromise. Reset passwords broadly and force re-authentication. Validate each system before you reconnect it — restoring the malware along with the data is a common and demoralising way to start the incident over. Recover deliberately, not at the speed panic wants.

5. Report — and improve

This is the step small companies forget, and it is now a legal deadline, not a courtesy.

If you are in scope of NIS2, Article 23 sets a clock: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month. Whether that clock runs on you today depends entirely on where you are. Belgium has been live since October 2024 and auditing since April 2026; Germany’s law applies from December 2025, Luxembourg’s from May 2026, the Netherlands’ from 15 August 2026, and Austria’s from 1 October 2026. France has not transposed at all: the loi résilience cleared the Sénat in March 2025 and the Assemblée nationale’s commission spéciale in September 2025, has never reached a plenary vote, and on 8 July 2026 the Commission referred France to the Court of Justice. No examination date is on the legislative file, and nobody can honestly give you one — so a French company’s NIS2 duties are coming rather than current. That is a reason to rehearse the reporting step now, not a reason to skip it.

Two other clocks can run at the same time, and this is the part that surprises people. If personal data was exposed, GDPR Article 33 gives you 72 hours to notify your data protection authority. If you sell a product with digital elements, the Cyber Resilience Act has been running its own clock since 11 September 2026. Article 14 sets two independent triggers — an actively exploited vulnerability in your product, and a severe incident affecting its security — and each one gives you 24 hours to send an early warning to ENISA and your coordinating CSIRT, then 72 hours for the notification. The final reports differ: 14 days after a fix or mitigation is available for the vulnerability, one month after the notification for the incident. The CRA clock is the awkward one, because it can start with a customer telling you that something you sold them is being abused — not only with something happening on your own network. We wrote the whole map up in One Incident, Three Regulators, and our NIS2 compliance services and Cyber Resilience Act support exist largely to make these deadlines survivable rather than terrifying.

Then do the part NIST now stresses most — improve. A short, honest review of what worked and what didn’t, fed back into step one, is what turns one bad night into a stronger plan.

Five steps any small team can run — mapped to NIST’s incident-response functions and the NIS2 reporting clock.

The mistake that turns an incident into a crisis

The incidents that become company-defining disasters usually share one of three errors, and none of them require a sophisticated attacker. The first is destroying evidence — wiping or rebuilding the first compromised machine before anyone understood the breach, leaving you unable to answer the regulator or to know if the intruder still has a key. The second is coordinating the response inside the compromised system itself, so the attacker reads your plan in your own email. The third is paying a ransom on instinct without containment, often funding a second extortion because the access was never closed. Each of these is a decision, not a technical failure — which is the same point we made in 5 Signs Your Business Has Already Been Compromised and traced hour by hour in Anatomy of a Ransomware Attack: by the time you are reacting, the cost is set by preparation you did or didn’t do months earlier.

The eight things to have in place before an incident — the difference between a bad morning and a bad quarter.

What to put in place this week

You do not need a budget cycle to start. This week, name your incident lead and deputy and write their numbers on a one-page plan. Open an out-of-band group chat and test it. Confirm you have a backup you have actually restored in the last 90 days. Save your national CSIRT and data-protection authority contacts into that one-pager now, while it’s calm, so nobody is searching for them at 2 a.m. If you sell software or a connected product, add the CRA reporting route beside them — that one has been live since September and most product teams have never used it. That is most of a working incident response capability, and it costs almost nothing but an afternoon.