Most guidance on cyber incident response is written for IT professionals. It assumes familiarity with forensic concepts, technical tooling, and organisational structures that most small business owners don't have. This guide is written for everyone else: the managing partner who finds an unusual message on a server, the practice manager whose emails are bouncing inexplicably, the finance director whose accounting software has locked them out.
The decisions made in the first two to four hours of a cyber incident often determine whether it becomes a contained disruption or an existential crisis. This is what you need to do.
Before an Incident: The Two Things to Prepare Now
Incident response is considerably more effective when it isn't being invented from scratch under pressure. Two things are worth preparing in advance.
The first is a contact list — written on paper and kept physically accessible, not only in digital systems that may be inaccessible during the incident. The list should include: your IT provider or managed security service, your cyber insurer's incident response line, your legal adviser, and your senior leadership team with out-of-hours contact numbers. If you have a managed SOC service, your named analyst's direct number belongs on this list. If a major incident occurs at midnight on a Friday, you should not be searching for contact numbers.
The second is an offline backup that you have verified works. An offline backup — stored separately from your live systems, not connected to the network that can be encrypted by ransomware — is the difference between "we had a serious incident and recovered in three days" and "we lost everything." Verify the backup quarterly by restoring a sample of data. A backup you haven't tested is not a backup — it's a hypothesis.
Step 1: Stay Calm and Assess Before You Act
The instinct when something appears wrong is to take immediate action — restart the server, reconnect the network, delete the suspicious file. Resist this instinct. Premature action often makes things worse: it destroys forensic evidence, spreads the problem to other systems, or alerts an active attacker that they've been detected, causing them to accelerate their timeline.
Take a breath. Look at what you can see. Write down — physically, on paper — what you're observing and when you observed it. This contemporaneous record will be important later: for your insurer, for a potential ICO notification, for the forensic team trying to reconstruct what happened.
Step 2: Do Not Turn Off Systems Immediately
This is counterintuitive and important. The instinct is to turn off the affected device or system to stop the spread. In some ransomware scenarios, shutting down immediately is the right call. In most other scenarios — an active intrusion, malware that hasn't yet executed its payload, a suspected compromise — shutting down destroys the volatile memory evidence (RAM) that forensic analysts use to understand what the attacker has done and where they are in the network. A powered-off system cannot be investigated without losing this evidence.
The exception: if you can see active encryption happening in real time — files being renamed with unusual extensions, a ransomware note appearing — disconnecting affected systems from the network (not necessarily powering them off) is the immediate priority, to prevent the encryption from spreading to other systems.
Step 3: Isolate, Don't Power Off
Isolation — removing a device from the network by disconnecting its network cable or disabling its Wi-Fi — stops an active attacker or active malware from communicating with the rest of your network or with external command-and-control infrastructure, while preserving the forensic evidence on the device. On a physical device, this means unplugging the network cable. On a Wi-Fi connected device, disabling Wi-Fi in the operating system or physically removing the device from Wi-Fi range.
Document which systems you have isolated and when. This information is critical for the incident response team.
Step 4: Call Your Incident Response Contact
This is the step that many small business owners delay while trying to handle the situation themselves or waiting to understand more before calling. Don't delay. Call your managed security service, IT provider, or cyber insurer's incident response line immediately. They need to know as early as possible — and the earlier they know, the more options they have.
If you have a SOC service with a named analyst, call them directly. They have context on your environment that a generic incident response team doesn't have, and they may already be aware of activity that preceded the visible symptoms you're seeing.
Step 5: Preserve Evidence
While waiting for the incident response team, preserve what you can without touching affected systems. Take photos of screens showing unusual behaviour. Print or photograph any ransom notes or unusual messages. Note the exact time you first observed symptoms and the exact sequence of events. Identify which users were logged in to affected systems and when they last used them.
Do not: delete files, run security scans on affected systems, attempt to restore from backup before the incident scope is understood, or tell staff to clear their email or files. All of these destroy evidence.
Step 6: Manage the 72-Hour ICO Clock
If personal data may have been compromised — and in most incidents affecting business systems, it has been — the UK GDPR 72-hour notification clock starts from the moment you become aware of the breach. You don't need to have full information within 72 hours. You need to have made a notification to the ICO, even if that notification is partial and will be updated as you learn more. Failing to notify within 72 hours is a separate regulatory failure from the breach itself.
Your legal adviser should be engaged early in any incident where personal data may be involved. They will advise on notification obligations and help you draft the initial ICO notification.
Step 7: Communicate Carefully
Internal communication during an incident should be limited to those who need to know. Using potentially compromised communication channels — company email, Slack, Teams — to discuss the incident may allow an attacker who retains access to monitor your response. Use personal mobile phones and messaging apps for coordination during the incident.
External communication — clients, suppliers, press — should be handled with legal advice and should wait until you have a clear understanding of what has happened. Premature or inaccurate communication creates its own problems. Saying nothing for a day while you investigate is better than saying the wrong thing immediately.
After the Incident: Learn, Don't Just Recover
Once the immediate incident is contained and recovery is under way, the most important question is not "how do we get back to normal" but "how did this happen, and what do we change so it doesn't happen again?" Recovery without remediation is just postponing the next incident. The forensic report from your incident response team should drive specific, documented changes to your security posture — not sit unread on a shelf.
Further Reading
Your Named Analyst Is Your First Call When Something Happens
With SOC in a Box, your first call during an incident isn't to a generic support line — it's to the analyst who already knows your network, has been watching it around the clock, and may already know more about what's happening than you do. Our Disrupt incident response team is available for escalation with no additional contract required.
Book your scoping call