The first hour

The first hour of an incident determines its cost. Not the severity of the attack. Not the sophistication of the attacker. The decisions made — or not made — in those first sixty minutes.

Decisions made under pressure, without a plan, are almost always the wrong ones. Someone turns off the server and destroys the volatile evidence in memory — running processes, active network connections, encryption keys. Someone emails the entire company from the compromised email system, alerting the attacker that they have been discovered. Someone posts on social media before anyone understands the scope. Someone pays a ransom without consulting the insurer and discovers afterwards that the policy required pre-approval.

Every one of these mistakes happens regularly. Every one of them is preventable with a plan that exists, has been read, and has been practised once.

You do not need a security operations centre. You do not need a twenty-page document. You do not need a dedicated security team. You need a one-page plan, tested once, reviewed quarterly.

The one-page plan

One page. Not two. Not a binder. Not a wiki. One page.

If it is longer, nobody will read it under stress. Stress narrows attention. A three-page plan becomes a one-page plan involuntarily — the reader skips what they cannot absorb, and the parts they skip may be the parts they need. Design the plan to be one page from the start, so nothing critical is on a page that gets skipped.

Print it. Put a copy in a desk drawer at the office. Put a copy in the managing director's car — or their kitchen drawer, or anywhere they will be when the incident occurs at eleven o'clock on a Saturday night. Give a copy to the operations director. Give a copy to the finance director.

The digital version is useless if your systems are the ones that are compromised. You cannot open a SharePoint document when SharePoint is encrypted by ransomware. You cannot check your email for the incident response plan when your email is the thing that has been compromised. Print it.

The plan contains six things: what counts as an incident, who to call first, how to communicate out of band, what the critical assets are, external contact numbers, and containment principles.

What counts as an incident

Not every alert is an incident. Not every suspicious email is a crisis. Not every unusual log entry requires an emergency response. Define the threshold clearly so the person who discovers the problem does not have to make a judgement call about whether to raise the alarm. Judgement calls under uncertainty lead to delays. Delays cost money and data.

Incident — escalate immediately:

A phishing email that someone clicked and entered credentials. The credentials are compromised. Every account using that password is at risk. Every service where those credentials grant access must be treated as potentially compromised.

Ransomware on any machine. The scope is unknown — it may be one machine or the entire network. Isolate and escalate.

Unauthorised access to any account. A sign-in from an unfamiliar location. A new forwarding rule on a mailbox that nobody created. A new Global Administrator account that nobody authorised.

A data subject access request or complaint to the ICO. The regulatory clock is running.

Evidence of data exfiltration — large file downloads, unexpected outbound data transfers, files appearing in a personal cloud storage account.

Near-miss — log and review, no escalation required:

A phishing email that nobody clicked. Log it. Report it to Microsoft or Google using the built-in reporting tools. Review whether similar emails bypassed filters.

A brute-force attempt on an account that did not succeed, blocked by MFA or account lockout. Log it. Monitor for persistence.

Write these definitions on the plan. Make them binary — incident or not-incident. Remove the judgement call from the person who finds the problem. Their job is to match the situation to the list, not to assess severity.

Who to contact first

The first call is to an internal decision-maker — the managing director, the operations director, whoever can authorise spending and external communication. Not the IT person. Not the managed service provider. The decision-maker is first.

The IT person is second. The MSP is second. They will begin the technical response — isolating systems, preserving evidence, identifying scope. But they need authorisation before they engage external parties, communicate with customers, or incur costs.

The decision-maker needs to know before anyone starts fixing things because the response involves business decisions that carry legal and financial consequences. Do you tell customers? When? What do you say? Do you engage lawyers? Do you file a claim on your cyber insurance? Do you contact law enforcement? Do you take the website down as a precaution? These are not technical decisions. The managing director makes them. The IT person advises.

The call sequence on the one-page plan:

Each entry is a name and a personal mobile number. Not an office landline that rings out at six in the evening. Not a Teams username. Not an email address. A phone number that reaches a human who can act.

Out-of-band communication

What happens when your email is compromised and you need to talk to your team? You reach for Teams — but Teams runs on Microsoft 365, and M365 is the thing that is compromised. You reach for Slack — but Slack requires an email-based login, and your email is compromised. You reach for the shared drive where the incident response plan is stored — but the shared drive is encrypted by ransomware.

You need a communication channel that does not depend on the systems that may be compromised. This channel must be set up before the incident occurs. During the incident, it is too late to agree on one — you cannot coordinate the agreement to use a coordination tool using the coordination tools that are unavailable.

A pre-agreed WhatsApp group works. Signal works. A phone tree — a printed list of personal mobile numbers with a defined calling order — works. The medium does not matter much. What matters is that it does not depend on corporate infrastructure.

What does not work: Teams, Slack on a corporate account, a shared document on the compromised server, or any channel that the attacker may be monitoring. If the attacker is in your email, assume they can read Teams messages too — both run on M365.

Set this up now, while everything works. Create the group. Add the right people — everyone named in the call sequence, plus anyone who might need to communicate during an incident (finance, customer service, marketing). Name it something unmistakable — "Emergency — do not use for chat." Test it once. Send a test message. Confirm everyone receives it. Confirm everyone knows it exists.

Critical assets and their owners

Identify the five systems whose loss would stop the business from operating. Not the systems you are fond of. Not the systems that cost the most. The systems whose absence means the business cannot serve customers, cannot pay staff, and cannot function.

For most small businesses, the list is similar:

Email — Microsoft 365 or Google Workspace. Owner: the person who manages the admin console — typically the operations director or the IT lead. Hosted in the cloud, so a local fire does not destroy it — but a compromised admin account can. The business can survive without email for approximately one working day before customer relationships, supplier communications, and internal coordination begin to suffer.

Accounting software — Xero, Sage, QuickBooks, FreeAgent. Owner: the finance manager or director. Loss means you cannot invoice customers, reconcile payments, pay suppliers, or run payroll. Depending on your payroll schedule, a prolonged outage means staff do not get paid.

CRM — the system that holds your customer relationships, pipeline, and sales history. Owner: the sales director or commercial lead. Loss means lost deals, lost context, and a painful reconstruction from email archives and personal memory.

File storage — SharePoint, OneDrive, Google Drive, a network drive, or a NAS. Owner: IT lead. Contains contracts, project files, templates, and institutional knowledge. The data that cannot be recreated.

Website — your public-facing presence. Owner: marketing lead, operations director, or IT lead. Loss is reputational and commercial — prospective customers reach a blank page or a defacement.

For each system, write down four things: what it is, where it runs (cloud provider, on-premises server, hosted platform), who is responsible for it, and how long the business can survive without it. That last number is your Recovery Time Objective — the maximum tolerable downtime. It drives every decision about backup frequency, recovery investment, and insurance coverage. The backup strategy guide covers how to ensure your backups actually meet the RTO you set here.

External contacts

These numbers go on the one-page plan. They are useless buried in a contacts app on a phone that may be compromised or locked. Print them.

Your IT provider or managed service provider — their emergency or out-of-hours number. Not the general enquiries line. Not the sales number. The number that reaches an engineer who can start working. If your MSP does not offer an emergency number, that is a conversation to have now — before you need one.

Your cyber insurer's incident response line — this may be the most important number on the list. Call it before you call anyone else outside the organisation. Many cyber insurance policies include incident response services at no additional cost — digital forensics, legal advice, breach notification support, public relations assistance. But many policies require you to use their approved panel of responders and to notify them before engaging anyone else. If you engage an unapproved forensics firm and then file a claim, the insurer may decline it. Read the policy now. Identify the notification requirement. Put the number and the policy number on the plan.

Your solicitor — you may need legal advice on notification obligations under UK GDPR, on regulatory interaction with the ICO, on contractual notification obligations to customers, and on privilege considerations around forensic reports. A solicitor experienced in data protection and cyber incident response is preferable. If your regular solicitor does not cover this area, identify a specialist firm now and put their details on the plan.

Action Fraud — 0300 123 2040 — the UK's national reporting centre for fraud and cyber crime. Report the incident here for a crime reference number, which you will need for insurance claims and for any subsequent law enforcement investigation.

The NCSC — report.ncsc.gov.uk — the National Cyber Security Centre's incident reporting page. The NCSC provides advice and, for significant incidents, active assistance. Reporting also contributes to the national threat picture.

The ICO — the Information Commissioner's Office. If personal data is involved — and it usually is — you have 72 hours under UK GDPR to assess whether a notification to the ICO is required. Not 72 hours to decide whether you feel like it. Not 72 hours to hope the problem goes away. Seventy-two hours to make a documented assessment of whether the breach poses a risk to the rights and freedoms of the affected individuals. If it does, you must notify. The clock starts when you become aware of the breach — not when you finish investigating it.

Containment principles

Isolate first. Investigate second. The instinct to understand what happened is natural. Resist it until the bleeding has stopped.

Disconnect affected machines from the network — pull the Ethernet cable, disable Wi-Fi via the hardware switch or by turning off the wireless adapter. Do not turn the machines off. Powering down a machine destroys volatile evidence — running processes, active network connections, malware resident only in memory, encryption keys that a forensic investigator could use to recover data. If you turn the machine off, that evidence is gone permanently.

Do not attempt to "clean" the malware yourself unless you have specific expertise and know exactly what you are dealing with. Running antivirus scans during an active incident can modify, quarantine, or delete the artefacts a forensic investigator needs to determine how the attacker got in, how long they were there, and what they accessed.

Preserve evidence. Take a photograph of any ransom note displayed on screen — include the whole screen, not just the text. Note the exact time. Note which machines are affected. Note which user accounts were logged in. Note what was happening when the incident was discovered — who noticed, what they saw, what prompted them to look. Write it down on paper. Not in a document on the compromised system.

Disable compromised accounts immediately. Reset passwords from a clean device — not from a machine on the compromised network. Revoke active sessions. In M365: Azure Active Directory → Users → select the user → Revoke sessions. In Google Workspace: Admin console → Users → select the user → Security → Sign out user from all sessions.

If ransomware is involved: do not pay the ransom without consulting your insurer and solicitor. Payment does not guarantee recovery — the decryption tools provided by ransomware groups are often unreliable, slow, or incomplete. Payment funds the attacker's next operation. Payment may violate UK or international sanctions law if the attacker group is on a designated list.

Communication during an incident

Do not post about the incident on social media. Do not email all-staff from a potentially compromised email system — use the out-of-band channel. Do not speculate about the cause or scope until you know. Speculation becomes fact in a crisis — once someone says "we think they got the customer database," that becomes the narrative regardless of whether it is true.

If you have customers to notify, work with your solicitor on the wording. Notification should be factual: what happened (in general terms), what data may be affected, what you are doing about it, and what the customer should do (change passwords, monitor accounts, be alert to phishing). Nothing speculative. Nothing that pre-empts the investigation.

Internal communication should be frequent, honest, and brief. "We are investigating an incident. We do not yet know the scope. Do not log into any company system until further notice. Use the emergency WhatsApp group for updates." Short. Clear. Repeated as new information becomes available.

The tabletop exercise

A Saturday morning. Two hours. Everyone named in the plan — and ideally everyone who would be involved in a real incident, even if they are not on the call sequence.

Walk through a scenario. The classic is the most valuable because it is the most common: "It is Monday morning. The first person to arrive finds a ransom note on every screen. Email does not work. The phone system runs over the network and is down. The receptionist is standing in the doorway asking what to do. What happens next?"

Go around the room. Who calls whom? Where is the plan? Can anyone find their printed copy? Where are the backup codes for MFA? Where are the backups? Can you reach them — or are they on the same network that is now encrypted? Who talks to customers? Who talks to the press if a journalist calls? Who contacts the insurer? Does anyone know the policy number?

The point is not to get it right. The point is to find the gaps in the plan before a real incident finds them for you. Every tabletop exercise reveals something nobody thought of. A phone number that changed six months ago. A backup that has not been tested since it was configured. An assumption about who is responsible that nobody shares. A critical system that nobody listed because everyone assumed someone else owned it.

Document the gaps. Fix them. Update the plan.

The Synnovis case study elsewhere on this site is a reminder of what happens when the plan does not exist or does not work at the scale required.

Updating the plan

Review quarterly. Not annually. Quarterly. Things change: staff leave, phone numbers change, providers change, systems change, insurance policies renew with different terms.

Update when: a staff member named in the plan leaves or changes role; a phone number changes; you add, remove, or change a critical system; you change IT provider or MSP; your cyber insurance renews or the incident response provisions change; you discover a gap during a tabletop exercise.

Test annually with a tabletop exercise. Vary the scenario each year — ransomware one year, a compromised email account the next, a rogue insider the year after, a supply-chain attack the year after that. Each scenario tests different parts of the plan and different assumptions.

The operational picture

Write a one-page incident response plan covering six elements: incident definitions, the call sequence with personal mobile numbers, out-of-band communication arrangements, critical assets and their owners with recovery time objectives, external contacts including insurer and solicitor, and containment principles. Print it. Distribute it to everyone named in it. Run a two-hour tabletop exercise with a realistic scenario to find the gaps. Fix the gaps. Review the plan quarterly. Test it annually. The plan does not need to be perfect. It needs to exist, to be printed, to have been read, and to have been practised once — because the first hour determines the cost, and the plan is what makes that first hour count.