Incident Playbook

Document version: 1.0
Date: February 12, 2026

First steps

Evidence and documentation

1. Preserve evidence before changing the system. Take a snapshot or image of the server and preserve relevant logs before powering off or making containment changes, so volatile evidence (memory, running processes) and logs are available for investigation.
2. Document from the start. Log who did what and when (with timestamps) from the moment the incident is recognised. Keep an incident timeline.

Containment

3. Lock down the server. Isolate from the network (or power off if appropriate), disable compromised accounts, block known attacker IPs. See Network isolation for provider-specific steps to wall off traffic at the network level. Prefer isolating from network first if you need to capture evidence; power off only when necessary (it destroys RAM/process evidence).
4. List any stolen credentials from .env files and other config.
5. Rotate all potentially exposed credentials — API keys, database passwords, service accounts — and invalidate active sessions. Do not only document them; assume they are compromised.
6. Find out how the attacker got access (root cause).
7. If they got access to databases, treat this as a data breach and follow the reporting section below.

Assessment and escalation

8. Classify severity (e.g. P1 / P2 or major vs minor) and escalate to leadership and legal when thresholds are met.
9. Involve legal counsel early for any suspected data breach or regulatory exposure.
10. Consider reporting to law enforcement for serious cases (e.g. ransomware, theft of data, criminal unauthorised access).

How to securely access data from a compromised server instance

1. Power off your server instance.
2. Take a snapshot of your powered off server instance. This should not activate the VM itself, but will allow a copy of the instance to exist.
3. Create a VFW with FTP and sFTP as the only port open, locked directly to your IP for access.
4. If you are concerned about Outbound from the VM, you can add a VPC to the instance, remove the public Outbound.
5. You can then use the snapshot on the new instance you created.
6. Connect from your IP with your own device and use Rescue CD to access your files. See here for documentation on Rescue CD.

Recovery

1. Verify backups before relying on them. Confirm backups were not also compromised or encrypted before using them for restore.
2. Confirm stabilised and secure before sending post-incident reports and closing the incident. Criteria include: no known persistence or backdoors, exposed credentials rotated, monitoring and hardening in place, and root cause addressed.

Reporting a breach

24 hours after we become aware of a breach, we must notify affected clients via email that an incident has taken place.

Communication: The Information Security Officer is responsible for incident response (see roles in the Information Security Policy). Assign them or a delegate as single point of contact for client and ICO communications so messaging is consistent. Notify internal stakeholders (leadership, legal, ops) as soon as the incident is recognised and keep them updated.

1. Create a folder called Incident [date] within Sharepoint inside Documents/Cybersecurity & Compliance/Incidents/
2. In this new folder, create an Incident Notification document to send to affected clients.
3. Once investigations are concluded and we are confident that we are stabilised and secure once more, create a Post-Incident Report document for each client detailing the following:
   • What happened
   • When we became aware of the incident
   • What information may have been involved
   • Data not involved
   • Assessment of risk to individuals
   • What we have done
   • What we are doing next
   • What we recommend you do
   • Role Under Data Protection Law
   • Your rights under UK GDPR
   • Ongoing updates

A GDPR data breach must be reported the ICO within 72 hours of becoming aware of the breach. Follow this link to report a breach.

Post-Incident Email Template

Dear <CUSTOMER>,

We regret to inform you that on <DATE> at <TIMESTAMP>, we became aware of a security incident that took place between <PERIOD>.

<BRIEF SUMMARY OF IMPACT>

**What happened?**
<BRIEF NON-TECHNICAL EXPLANATION OF CAUSE IF KNOWN>

**What did we do?**

<OUTLINE STEPS TAKEN TO REMEDIATE>

The incident was resolved at <TIMESTAMP> on <DATE>. <DESCRIBE CURRENT SYSTEM STATUS>.

**What are we doing to prevent this happening again?**
<OUTLINE PLAN FOR IMPROVING SECURITY MEASURES>

We will update you in the next few days about the extent of this incident and how it has affected you as we continue our investigations.

Thank you for your patience and understanding while we deal with this.

Kind regards,