A cyber incident is the worst possible time to invent a process. The morning it happens (ransomware note, hijacked mailbox, “why is our data on this website?”) is a fog of adrenaline, half-information and pressure to do *something*, and improvised somethings are how evidence gets destroyed, insurers get grounds to quibble, and 72-hour legal clocks get discovered on hour 70.
An incident response plan is the pre-made decisions that cut through that fog: who is in charge, what happens in which order, who must be told and by when. It is a short document, most of it is fill-in-the-blanks, and this page is the template. Write it on a calm Tuesday; it earns its keep on the other kind of day.
The template
Section 1 — Activation and roles
What counts as an incident (write these down; hesitation wastes the golden hour): suspected ransomware or file encryption, a compromised account or mailbox, data visible where it should not be, credible extortion contact, or an alert from your monitoring or IT provider escalated as genuine.
Who runs it: an incident lead plus deputy, named, with out-of-hours contacts. In an SME this is typically the owner or ops lead for decisions, with your IT provider as technical commander. Add the one-line authority note: what the lead may authorise (spend, disconnection of systems, sending staff home) without a board call.
Section 2 — The first hour: contain without destroying
The four standing instructions, in order:
- Isolate, don’t power off. Disconnect suspect machines from the network (cable out, WiFi off); leave them running. Powering off destroys the memory-resident evidence responders need and can, in some ransomware cases, eliminate recovery options.
- Preserve before you clean. No wiping, no “just reinstalling”, no deleting the phishing email everyone got. Evidence decides insurance claims and, sometimes, prosecutions.
- Cut attacker access. Force password resets and revoke active sessions for affected accounts, starting with anything privileged, via a channel you still trust.
- Start the log. Times, observations, actions, decisions, in a notebook or on a phone, from the first minute. Every later conversation (insurer, ICO, responders) is easier with a timeline, and the person keeping it should be named in Section 1.
And the standing prohibition: nobody communicates with the attacker except as directed by responders and your insurer.
Section 3 — First 24 hours: assess and notify
Assessment questions the technical team works through: what systems and accounts are affected, is the attacker still active, what data may have been accessed or taken, are backups intact and clean (check *before* restoring: restoring into a compromised environment re-infects), and what is the safe path back per the disaster recovery plan, which handles the rebuild while this plan handles the incident.
The notification list, with deadlines (this section is why the plan exists):
- Your cyber insurer: immediately. Policies commonly require prompt notification and often mandate using the insurer’s approved responders; acting first and telling them later is how cover gets complicated. Policy number and hotline go in the plan, not in a drawer.
- The ICO: within 72 hours of becoming aware, where personal data is involved and the breach risks people’s rights: a low bar that most incidents involving client, staff or customer data will clear. The clock runs from awareness, not from understanding, and a preliminary report is acceptable. Log the awareness time in Section 2’s log.
- Police Scotland / Action Fraud: report cybercrime; ransomware and fraud reports also generate the crime reference insurers ask for.
- Affected individuals: where the risk to them is high, directly and promptly: a decision to take with legal or insurer guidance, pre-drafted in outline.
- Banks and payment providers: immediately, where financial credentials or payment flows are touched.
- Clients and suppliers with contractual notice clauses: increasingly common in B2B contracts; list who and what the clauses say.
Section 4 — Communication
One named voice for staff, one for customers, one (usually the same) for anything public, with pre-drafted holding lines for each: honest, brief, no speculation. Staff messaging goes over a channel that does not depend on compromised systems. The rule that saves reputations: say what you know, say what you are doing, never guess in writing.
Section 5 — Recovery and stand-down
Recovery proceeds per the DR plan, in priority order, onto clean systems, with credentials rotated and the entry route closed *before* systems return. The incident formally ends with a stand-down decision by the lead, not a gradual drifting back to normal, because the drift is where re-infections and unfinished notifications live.
Section 6 — Post-incident review
Within two weeks: what happened, what the entry route was, what worked, what the plan got wrong, and the fix list with owners. The review is blameless by design; a culture where the person who clicked hides it for three days costs more than any click. Feed the lessons into the ransomware defences and the next plan revision.
Keep it usable
Same disciplines as every crisis document: printed copies with the lead and deputy, a copy reachable from a phone, an annual walkthrough against a scenario, and a revision date on the front. Ten pages maximum; this is a checklist with a chain of command, not a policy essay.
Frequently asked questions
What should a cyber incident response plan include?
Activation criteria and named roles, first-hour containment instructions (isolate without powering off, preserve evidence, cut access, start a log), the notification list with deadlines (insurer immediately, ICO within 72 hours where personal data is at risk, police, affected parties), communication arrangements, recovery hand-off to the DR plan, and a post-incident review process.
When do we have to report a breach to the ICO?
Within 72 hours of becoming aware of a personal-data breach likely to risk individuals’ rights and freedoms, including weekends; a preliminary notification is acceptable while facts develop. Not every incident qualifies, but assume the question needs answering formally, on the clock.
Should we call our insurer before fixing anything?
Yes, as close to immediately as containment allows: policies often specify approved responders and required steps, and self-directed clean-ups can prejudice cover. Insurer contact details belong inside the plan for exactly this reason.
Why shouldn’t we turn infected computers off?
Memory-resident evidence (what the attacker ran, from where) disappears at power-off, and some ransomware recovery routes depend on the machine state. Isolation from the network achieves the containment without the destruction.
Who should be the incident lead in a small business?
Someone with authority to make spending and operational decisions fast: typically the owner or operations lead, with the technical command delegated to your IT provider. The title matters less than the pre-agreed authority and the named deputy.
How is this different from a disaster recovery plan?
The incident response plan manages the *event*: containment, evidence, notification, communication. The DR plan rebuilds the *systems*. They reference each other and are tested together, but conflating them produces a document that does neither job at 3am.
From template to tested plan
Filling in the names takes an afternoon; knowing the plan works takes a walkthrough, and knowing your backups support Section 5 takes a test. All three are things we run with clients as part of business continuity planning, and the free IT health check will tell you today whether the technical assumptions underneath this plan (clean backups, MFA, monitoring that would even detect the incident) actually hold. Get in touch on a calm Tuesday.
