Writing an incident response plan your team will actually use

Most incident response plans are written for an auditor and then forgotten. During a real incident, nobody opens a 40-page document. What helps is a short plan that tells people who is in charge, how serious this is, who to call, and what to do first. This guide shows how to write one.

Keep the core plan short

Aim for a core plan of three to five pages, with separate one-page playbooks for common scenarios. Store a copy somewhere that will still be reachable if your email, identity provider or file share is down.

Define roles, not just names

• Incident lead: makes decisions, sets priorities and declares when the incident is over.
• Technical lead: directs investigation and containment.
• Scribe: keeps a timestamped log of facts, decisions and actions.
• Communications lead: handles customers, staff, regulators and media.
• Executive sponsor: approves major decisions such as taking systems offline or paying for outside help.

Name a primary and a deputy for each role, with after-hours contact details. In small teams, one person may hold several roles, but the incident lead and scribe should be different people.

Agree severity levels in advance

• Critical: confirmed compromise of sensitive data or a major outage affecting customers.
• High: likely compromise or significant disruption, still being confirmed.
• Medium: contained issue with limited impact.
• Low: suspicious activity with no confirmed impact.

Tie each level to clear actions: who is notified, how quickly, and whether executives, legal counsel or the insurer are involved.

Follow a simple lifecycle

NIST's incident response guidance, now aligned with the Cybersecurity Framework 2.0, describes preparation, detection and analysis, containment, eradication and recovery, and lessons learned. Your plan can use simpler wording, but each stage should have an owner and a definition of done.

Write playbooks for likely scenarios

• Compromised user account or mailbox.
• Ransomware on an endpoint or server.
• Exposed secret or cloud credential.
• Lost or stolen laptop.
• Suspected data breach involving personal information.
• Business email compromise and payment redirection.

Each playbook should fit on one page: how to recognise it, first containment steps, evidence to preserve, who to tell, and when to escalate.

Log everything as you go

A timestamped log of what was known, what was decided and why is invaluable for the post-incident review, insurers and regulators. Capture screenshots and evidence with a time and source. Don't rely on memory or chat history.

Signs your plan is working

People know where the plan is without searching. The first hour of an incident follows a predictable pattern. Decisions are recorded. Review actions are completed. If a tabletop exercise reveals confusion, that is a success: you found the gap before an attacker did.