01
Before the incident: fill this in now.
A playbook with blank contact fields is a document, not a tool. The fifteen minutes you spend populating the roles and contacts below is the highest-return investment in this template. When an incident starts, your team should be able to pick this up and act without searching for phone numbers or debating who has authority to make decisions.
Non-negotiables: apply to every incident, every time
- Preserve evidence before mass changes. Logs, mailbox audit trails, sign-in records, and disk images where available. Once overwritten they cannot be recovered. Evidence quality directly affects your insurer claim, your ICO position, and any legal proceedings that follow.
- Switch to out-of-band communications immediately if email is suspected compromised. Phone calls, Signal, or a secondary tenant. Assume the attacker can read your incident response activity if you coordinate through the affected system.
- Start and maintain a decision log from the first minute. Every material decision: who made it, when, and why. The log is your post-incident narrative and your regulatory defence. It cannot be reconstructed after the fact.
- Do not fix silently. Undocumented remediation destroys the evidence trail your insurer and regulator will ask for first. Do the action. Record it before and after.
Roles: name these before an incident
Incident LeadName / role
Technical LeadName / role
Comms LeadName / role
Legal / DPOName / role
Insurer contactPolicy / broker
Critical contacts: keep an offline copy
MSP / IT providerOut-of-hours no.
Cloud admin portalURL / tenant ID
Backup providerPortal / contact
Key systemsERP / TMS / CRM
DefendVista IR line+44 (0)33 0122 4448
Keep a printed copy somewhere accessible without a login
If ransomware has encrypted your environment, this playbook is useless if it only exists in your corporate email or SharePoint. Print it, save it to a personal device, or post it physically in the server room. A laminated card with five decisions pre-agreed is not overcaution. It is the minimum viable backup for this document.
02
Response playbooks.
Two playbooks covering the most common SME incident types. Select the one that matches your situation. In a ransomware event that began as account compromise, run both: start with Account Compromise to understand identity exposure, then continue with Ransomware for the encryption and recovery phases.
Covers ransomware encryption events, suspected pre-encryption deployment, and double-extortion scenarios where data exfiltration is also suspected alongside encryption.
Ransom note found
Files encrypted or renamed
Abnormal CPU / disk activity
Multiple endpoints unresponsive
EDR / AV alerts firing
Backup jobs failing unexpectedly
Unusual outbound network traffic
1
First 15 minutes: freeze the situation
Declare → Assign → Log
- Declare the incident out loud. Assign the Incident Lead and Technical Lead from your roles card immediately, before any other action is taken.
- Switch to out-of-band communications now if corporate email or messaging is uncertain or affected.
- Start the decision log. First entry: time of discovery, who reported it, and exactly what was observed. Do not skip this step under pressure.
- Confirm scope indicators: which sites, servers, endpoints, and accounts are showing symptoms. Do not assume; verify.
- Do not wipe or reimage affected systems yet. Evidence is destroyed and recovery options may be foreclosed permanently. Do not power everything off unless a specialist has instructed you to for safety or evidence reasons.
- Notify the insurer at this stage if your policy requires early notification. Check the conditions section before the incident, not during it.
2
Containment: stop the spread, protect backups
Isolate → Lock → Protect
- Isolate affected endpoints from the network using EDR network isolation if available, or physical disconnection from the switch. Document each system isolated and when.
- Disable or lock suspicious accounts, especially privileged accounts and service accounts. Revoke active sessions where your identity platform supports it.
- Block confirmed malicious IP addresses or domains at the firewall or DNS level if indicators of compromise have been identified.
- Protect backups immediately: lock backup administrator accounts, verify backup admin credentials are separate from domain credentials, and pause replication if contamination of the backup set is suspected. A compromised backup copy is one of the most damaging outcomes of a ransomware event.
- Segment critical servers if lateral movement is suspected: identity and domain controllers, finance systems, and backup infrastructure specifically.
3
Triage: what happened and what is at risk?
Vector → Exfil? → Scope
- Identify the initial access vector: phishing link or attachment, exposed RDP, VPN credential compromise, unpatched internet-facing service, or vendor compromise. This directly affects the ICO notification assessment and the recovery approach.
- Assess whether data exfiltration is likely. Indicators: staging tools installed on affected systems, unusually large outbound transfers in recent logs, cloud storage or file-sharing activity from unexpected accounts, or exfiltration claims in the ransom note.
- Check domain controllers and your identity platform for compromise indicators: new administrator accounts created, unexpected group policy changes, unusual service account activity or logons.
- Confirm encryption scope and business impact: which systems are affected, which are confirmed clean, which operations are halted, which clients are affected, and which personal data categories are involved.
4
Recovery strategy: choose a path
Validate → Restore or Rebuild → Harden
- Do not begin recovery until containment is confirmed. Restoring into a still-active attacker environment results in reinfection, often within hours.
- Determine which backup sets are clean. Backups taken after the attacker gained access may themselves be compromised. Work backwards from the earliest confirmed infection date to find a clean restore point.
Option 1: restore from known-good backups
- Validate backup integrity before restoration: checksums where available, test restore to isolated environment first.
- Restore to a clean environment rather than the compromised one where feasible.
- Reset all credentials and rotate secrets before any restored system is reconnected.
- Document each restore: system name, backup date used, who verified it.
Option 2: rebuild critical systems
- Prioritise sequence: identity platform first, then email, then line-of-business, then endpoints.
- Build from clean images. Enforce MFA and logging during rebuild, not after.
- Only reconnect after validation. Do not rush reconnection under business pressure.
- Document each rebuilt system, who performed it, and what was validated.
Most SME recoveries involve both: restore data from backups onto rebuilt infrastructure. Build the decision around which combination is faster given your specific backup state and the scope of compromise.
5
Comms and reporting
Insurer → ICO → Board → Clients
- Insurer: notify early and follow their panel process. Many policies require notification within a specific window after discovery. Do not make major recovery decisions before checking whether the policy requires insurer approval.
- ICO: assess the GDPR breach threshold now. Ransomware affecting systems holding personal data is typically notifiable. The 72-hour clock runs from awareness, not from the end of investigation. An incomplete notification on time is better than a complete one that is late.
- Board: factual update within two hours if possible. What happened, what is affected, what is being done, what decisions are needed from leadership. No speculation about scope or cause while investigation is ongoing.
- Client and supplier comms: use a holding statement while investigation continues. Draft this before sending; do not write it in real time. Factual, calm, no speculation.
- Sector regulators: FCA, SRA, CQC, and NHS all have notification obligations that run in parallel to the ICO. Assess your sector-specific requirements simultaneously.
6
Evidence pack: minimum viable
Log → Preserve → Document
- Timeline: first indicators observed, discovery time, declaration time, each containment and recovery action with timestamps and the person who performed them.
- Key logs: identity and directory audit logs, EDR and endpoint alerts, firewall and proxy logs covering the suspected intrusion period, and server event logs from affected systems.
- Scope documentation: list of affected systems, compromised accounts, and categories of personal data involved for the ICO notification assessment.
- Attacker artefacts: copies or screenshots of the ransom note, any attacker communications, and indicators of compromise identified during triage. Do not delete these.
- Decision log: every material decision, by whom, on what basis, and what the next action was. This is your narrative and your defence.
Covers email account compromise, business email compromise (BEC), identity platform breach, and OAuth application abuse. Also applies when a supplier account has been compromised and used to target your organisation.
Unusual sign-in location or time
Unexpected inbox rules created
Payment diversion attempt
MFA fatigue prompts reported
Unknown OAuth app authorised
Supplier reports suspicious email
Impossible travel alert
1
First 15 minutes: secure the identity
Disable → Revoke → Scope
- Disable or reset the compromised account immediately, or revoke all active sessions if your identity platform supports selective session termination.
- Revoke refresh tokens before resetting the password. In Microsoft 365, use Revoke sign-in sessions in the admin centre. A password reset alone does not terminate an existing authenticated session.
- Reset the password and require fresh MFA enrolment. If attacker-controlled MFA methods were added, remove them before the legitimate user re-enrols.
- Check adjacent accounts immediately: the same team, the finance function, and executive accounts. Lateral movement to higher-privilege accounts often occurs within the first hour of initial access.
2
Containment: remove attacker footholds
Rules → OAuth → Forwarding → Harden
- Audit inbox rules on the compromised account and all adjacent accounts. Remove any that forward, delete, or move messages to unusual destinations. Attackers create persistence rules to maintain visibility after a password reset.
- Remove malicious delegates, shared mailbox access grants, and suspicious OAuth application authorisations. Check application permissions in your identity platform directly, not just the mailbox settings.
- Block external auto-forwarding at the organisational level if it is not a business requirement. This is a transport rule, not a per-user setting, and prevents data leaving the organisation silently.
- Review mailbox access logs and sign-in patterns for the affected and adjacent accounts: look for unusual geographies, device IDs, and access times. Export and preserve before logs roll over. M365 Unified Audit Log default retention is 90 days on standard licences.
- Enforce MFA and conditional access, and disable legacy authentication protocols (IMAP, POP3, basic auth). Legacy auth bypasses MFA entirely and is a common attack vector.
3
Financial controls: if payment diversion is possible
Alert finance → Verify → Recall
- Alert finance immediately. Any bank detail change, new payment instruction, or change to supplier account details received in the affected period must be treated as potentially fraudulent until verified by voice callback to a known number. Do not reply to or call a number provided in the suspect email.
- Contact key suppliers and customers if fraudulent emails were sent from the compromised account. Provide factual guidance: any payment instruction received from this address in the window [date to date] should be verified before processing.
- If a fraudulent payment has been made, contact the sending bank immediately. SWIFT recall is highly time-sensitive: hours matter. The sooner this is escalated, the higher the probability of recovery. Do not wait for the investigation to conclude before making this call.
- Preserve all evidence: full email headers, timestamps, and the original message content of any fraudulent communications. Do not delete or edit.
4
Investigation: what did they access?
Time window → Data → Lateral movement
- Establish the time window of attacker access from sign-in and audit logs. In M365, the Unified Audit Log is the primary source. The default retention is 90 days on standard licences; check your configuration before assuming full coverage.
- Identify what was read, sent, or downloaded during the access window. Focus on: contracts and commercial data, HR and payroll information, client personal data, and any credentials or system access information stored in email.
- Confirm whether lateral movement occurred: other accounts accessed, SharePoint or OneDrive files downloaded or shared, Teams message history reviewed, or admin portal activity from the compromised account.
- Validate the endpoint posture for devices the compromised account was used on. If the attacker had access to a corporate device, assess for credential harvesting tools or persistent malware.
5
Recovery, notification, and assurance
Harden → Notify → Brief
- Implement the controls that failed. At minimum: MFA enforcement (not just availability), conditional access requiring compliant devices, and legacy authentication disabled if still active.
- Improve detection coverage: alerting on new inbox rule creation, unexpected OAuth application authorisation, impossible travel sign-ins, and bulk email or file access. These are the early indicators that were present before the compromise became visible.
- ICO assessment: if the compromised account held or had access to personal data, apply the breach threshold test. A confidentiality breach (attacker read personal data) is typically notifiable. Apply the test: is there a risk to the rights and freedoms of the individuals whose data was accessed?
- Brief leadership: root cause (what the attacker used to gain access), impact (what was accessed and what was affected), actions taken, and the prevention measures now in place. Factual, not speculative.
- Review supplier access: if the compromise involved a supplier account or could have exposed supplier credentials, notify affected suppliers and review third-party access permissions.
03
Decision log: fill in during the incident.
Copy this structure into a shared document, a print-out, or a messaging thread at the start of the incident. Every material decision is logged here: any decision that affects containment, recovery, evidence, notification, or communications. When the incident is over, this log is your post-incident narrative. It is also the first document your insurer, the ICO, and any legal counsel will ask to see.
One entry per decision. Start from minute one.
Time
HH:MM and date
Decision taken
What was decided
Owner
Name and role
Reason
Why this decision
Evidence basis
What information informed it
Next action
Who does what next
This is what stops “we panicked” becoming your post-incident narrative. An ICO investigation or insurer review that encounters a structured decision log, even one documenting a chaotic incident, is treated substantially differently from one where no contemporaneous record exists.
When to call DefendVista
If you are working through this playbook and the scope is growing, the attacker appears still active, the backups are compromised, or the first notification deadline is approaching: call before making the next major decision. The activation line is +44 (0)33 0122 4448, available out-of-hours for active incidents. Early engagement preserves options that late engagement cannot recover.