Building a Cyber Incident Response Playbook

Most organisations discover the state of their incident response during their first serious incident. That is an expensive way to find out that the on-call rota points at someone who left, that the backup has never been restored, or that nobody is sure who can authorise disconnecting the payment system.

This guide sets out how to build a playbook that works under pressure.

The lifecycle

The reference model most organisations work from is NIST SP 800-61, whose Revision 2 defines four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Revision 3 reframes the same activities around the NIST Cybersecurity Framework 2.0 functions, emphasising that incident response is part of continuous risk management rather than a separate discipline that activates on a bad day. Either framing works; what matters is that all four phases are covered, and that the first one carries most of the weight.

Phase 1 — Preparation

Name the roles, not the people

A playbook that names individuals fails the moment one of them is on a plane. Define roles, then list at least two people who can fill each:

• Incident Manager — runs the response, makes or brokers decisions, keeps the timeline. Not the most technical person in the room; the one who can hold structure while others work.
• Technical Lead — directs investigation and containment.
• Communications Lead — internal updates, customer messaging, and the press if it comes to that.
• Legal and Privacy — regulatory notification decisions, contractual obligations, privilege.
• Executive Sponsor — authorises business-affecting action, such as taking a revenue system offline.
• Scribe — records the timeline. An under-appreciated role that determines whether you can later prove anything.

Write down, in advance, exactly who can authorise disconnecting a production system. Debating that during an incident costs hours you do not have.

Establish an out-of-band communication channel

If an attacker is in your environment, they may be reading your email and your chat. Agree in advance where incident communications will happen — a separate messaging platform, phone numbers on a printed sheet — and how you will switch to it. This has to be arranged beforehand, because arranging it afterwards means arranging it over the compromised channel.

Make sure you are logging what an investigation needs

Forensic readiness is unglamorous and decisive. At minimum, ensure you collect and retain: authentication events including failures and MFA prompts, privileged action and administrative changes, cloud control-plane activity, endpoint process execution, network flow or DNS records, email gateway logs, and VPN or remote access records.

Two properties matter as much as coverage. Retention must be long enough — intrusions are frequently discovered months after initial access, and thirty days of logs will not reconstruct them. And logs must be stored where an attacker with domain administrator rights cannot delete them; the first thing a competent intruder does after gaining privilege is address the record of how they got it.

Prove your backups

Test restoration, not just backup completion. Confirm that backups are isolated from the network they protect — ransomware operators specifically target backup infrastructure — and that actual restore time matches what the business believes it to be. An untested backup is a hypothesis.

Write scenario playbooks

Write playbooks for the scenarios you are realistically exposed to, not for every scenario imaginable. For most organisations that is: ransomware, business email compromise, credential compromise and account takeover, data exfiltration, third-party or supply chain breach, and insider misuse. Each should be short enough to be read during an incident — a page or two of decision points, not a manual.

Rehearse

Run tabletop exercises with the actual decision-makers, at least annually. Exercises reliably surface the gaps that documents hide: the escalation path that dead-ends, the contact list nobody updated, the assumption that someone else is watching the alerts, the unresolved question of who talks to customers.

Phase 2 — Detection and analysis

Define severity in advance, in business terms, so that classification is a lookup rather than a debate.

Severity should be reassessed continuously. Incidents routinely start as medium and become critical once scope is understood — and much less often the other way round.

The first hour

The single highest-value page in any playbook. In order:

1. Appoint the Incident Manager. One person coordinating. Parallel uncoordinated action is how evidence gets destroyed.
2. Start the timeline. Every observation and every action, with timestamps and who did it. This becomes your evidence, your regulatory submission and your post-incident review.
3. Isolate, do not power off. Disconnect affected hosts from the network — pull the cable, block at the switch or security group — but leave them running. Powering off destroys volatile memory that may hold the only record of what executed.
4. Preserve logs immediately. Export and copy before rotation deletes them. Rotation does not pause for incidents.
5. Do not rebuild or wipe anything. Rebuilding a compromised host feels like progress and destroys the record of how far the attacker got — and usually leaves their access route open.
6. Move to the out-of-band channel. Assume email and chat may be read.
7. Assess the regulatory clock. If personal data may be involved, the GDPR 72-hour clock has probably started. Engage legal now, not once you understand the incident.

Scope the intrusion before you act broadly

The instinct is to fix what you can see. The risk is alerting the attacker while leaving their other access in place — resetting one compromised account teaches a competent intruder that they have been noticed and prompts them to use the persistence you have not found yet.

Where practical, understand the scope first: initial access route, accounts and systems touched, persistence mechanisms, data accessed. Then contain comprehensively in one coordinated action. This is a judgement call — with active ransomware encryption in progress, speed beats completeness — but it should be a deliberate decision, made explicitly, not a default.

Phase 3 — Containment, eradication and recovery

Containment

Containment is a business decision as much as a technical one, and it is where the executive sponsor earns their place in the playbook. Short-term containment stops the bleeding: isolating hosts, disabling accounts, blocking indicators, revoking sessions and tokens. Longer-term containment keeps the business running while eradication is planned — segmenting affected areas, standing up clean systems.

Record every containment action with its rationale and timestamp. You will be asked, later, why you did or did not disconnect a given system, and "we discussed it" is a weaker answer than a logged decision.

Eradication

Remove the attacker's access completely, which means addressing all of: the initial access route, every persistence mechanism found, and every credential that may have been exposed. Credential rotation after a domain-level compromise is broader than people expect — user and service accounts, API keys, certificates, and the directory service's own key material where relevant.

Rebuild compromised systems from known-good images rather than cleaning them. Once an attacker has had administrative access to a host, proving it is clean is harder and less reliable than rebuilding it.

Recovery

Restore service in a controlled order, with monitoring heightened on the restored systems. Recovery before eradication is complete is the classic route to being compromised twice by the same attacker in the same month — and the second time, having demonstrated that you cannot remove them, is materially worse.

Define in advance what "recovered" means: services restored, attacker access removed and verified, monitoring confirming no recurrence over a defined period, and root cause understood.

Phase 4 — Post-incident activity

Hold the review within two weeks, while memory is accurate and before the organisation moves on. The review should establish what happened and over what timeline, how the attacker got in, how long they were present, what was accessed, what worked in the response, what did not, and what specific changes follow with owners and dates.

Run it blamelessly, and mean it. The purpose is to make the next incident shorter. Reviews that assign blame produce responses that are careful rather than honest, and an incident review nobody tells the truth in is worse than none — it produces a false record that is then relied upon.

Feed the output back: update playbooks with what was actually learned, adjust detection to catch this pattern earlier, close the control gaps that allowed it, and — if the same root cause has now appeared twice — escalate it as a systemic issue rather than fixing the instance again.

Regulatory clocks

These start on awareness, not on understanding, and they are shorter than the time it takes to complete an investigation. Notification is therefore often made on incomplete information, with follow-up submissions as facts firm up — which is expected and permitted.

Determining whether an obligation is triggered is a legal question and belongs with your legal advisers. The response team's job is to establish the technical facts fast enough for that determination to be made inside the deadline. In the UK, the NCSC provides support for significant incidents, and cybercrime is reported to Action Fraud in England, Wales and Northern Ireland, or to Police Scotland in Scotland.

Ransomware: the specific decisions

Ransomware compresses every decision in this guide, so make these in advance:

• Assume data was stolen, not just encrypted. Most current operations exfiltrate before encrypting, which makes it a data breach with notification obligations regardless of whether you can restore.
• Check backup integrity before relying on it. Backup infrastructure is a primary target and is usually attacked before the encryption stage.
• Payment is a decision for the business, legal advisers, insurer and law enforcement — not for the technical team, and not made under pressure at 2am. It carries legal and sanctions implications that vary by jurisdiction and by who the attacker is. UK law enforcement guidance is consistently against payment, and payment does not reliably deliver working decryption or the deletion of stolen data.
• Engage your insurer early. Cyber policies frequently require notification within a set period and may require the use of panel providers; acting first and notifying later can affect cover.
• Do not negotiate without advice. If negotiation is contemplated, it should be handled by people who do it professionally.

A one-page structure for each playbook

Keep each scenario playbook short enough to be used. A workable structure:

1. Trigger — what indicates this scenario is occurring.
2. Severity — the default classification and what escalates it.
3. Immediate actions — the first five, in order.
4. Evidence to preserve — named log sources and systems, with how to export them.
5. Containment options — with the business impact of each stated.
6. Who to notify — internal roles, external parties, regulators, insurer, and the trigger for each.
7. Recovery criteria — what has to be true before service is restored.

Then print it. An incident that takes out your identity provider also takes out access to the wiki where the playbook lives.

Related reading

• SecIQ incident response services — live response support and readiness work.
• ISO 27001 readiness — where incident management sits in an ISMS.
• How to scope a penetration test — finding the entry routes before someone else does.