How to Build an Incident Response Plan: Phases, Roles and Playbooks

Every organisation will face a security incident. The difference between a bad day and a disaster is usually whether a tested incident response (IR) plan existed before it started. I have written incident response and device isolation policies for a regulated environment, and this is the structure I recommend.

The six phases of incident response

The widely used SANS model has six phases. NIST SP 800-61 groups the same activities into fewer stages, but the work is the same.

1. Preparation: the plan, the team, the tools, logging and training, all in place before anything happens.
2. Identification: detecting the incident, confirming it is real and assessing its scope and severity.
3. Containment: stopping the spread, for example by isolating devices, blocking IPs and disabling compromised accounts.
4. Eradication: removing malware, backdoors and attacker access, and fixing the root cause.
5. Recovery: restoring systems from clean backups and monitoring closely for signs of the attacker returning.
6. Lessons learned: a blameless review of what happened and what to change.

Roles in the incident response team

• Incident lead: coordinates the response and makes decisions.
• Technical responders: SOC analysts, system and network administrators.
• Communications: internal updates, customers and media.
• Legal and compliance: regulatory notification, contracts and evidence handling.
• Executive sponsor: approves high-impact decisions such as shutting down a business system.

Put names, deputies and out-of-hours phone numbers in the plan. During a ransomware attack, email may not work.

Define severity levels

Use three or four levels, from low (a single contained malware detection) to critical (ransomware spreading or confirmed data breach). Each level should define who is notified, how fast, and who can declare it.

The first playbooks to write

A playbook is a step-by-step guide for a specific incident type. Start with the incidents you are most likely to face:

• Ransomware
• Compromised user account
• Business email compromise and phishing
• Malware on an endpoint
• Data breach or data leakage
• Lost or stolen device

Device isolation and evidence

Isolating a compromised device quickly is one of the most effective containment steps. Modern EDR tools can cut a machine off from the network while keeping it connected to the security console for investigation. Avoid simply powering devices off: memory contains valuable evidence. Record every action with a timestamp, because investigators, insurers and regulators may need it.

Communication and legal obligations

Know your notification duties before an incident. For example, organisations handling US health data under HIPAA must notify affected individuals without unreasonable delay and no later than 60 days after discovering a breach. Contracts with clients often impose even shorter deadlines. Your plan should list each obligation and who owns it.

Test the plan with tabletop exercises

Run a tabletop exercise at least twice a year: walk the team through a realistic scenario and see where the plan breaks. Every exercise uncovers missing contacts, unclear decisions or broken assumptions, which is exactly the point.

A good IR plan depends on good detection, which is why it pairs with a SOC. If you need an incident response plan, playbooks or help during an active incident, contact me.

References and further reading

1. NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
2. CISA: Incident response resources
3. US HHS: HIPAA Breach Notification Rule
4. MITRE ATT&CK