Incident Response Plan: Key Steps, Roles and Testing

Share with

Contents

An incident response plan is the document your team opens when something has gone wrong. It sets out who takes charge, what actions happen in what order, who gets informed and how the incident is closed out.

A good incident response plan is written for a stressed reader. During a live breach nobody reads forty pages, so the plan needs to answer three questions in the first minute: am I allowed to act, who do I call, and what do I do first. Everything else can sit in annexes.

This page covers the sections an incident response plan should contain, how to define roles and escalation, how to test the plan, and how it fits into your information security management system.

What the Plan Is For

The plan turns intent into instructions. Your policy says incidents will be handled promptly; the plan says exactly how.

It sits alongside your wider information security incident management process. The process defines the lifecycle and record keeping. The plan is the operational document people use in the moment.

Three outcomes justify the effort:

Faster containment, because decisions are pre-approved
Consistent handling, so evidence and notification are not lost in the rush
Clear accountability, so nobody waits for someone else to act

Core Sections of an Incident Response Plan

Scope and Activation Criteria

State which systems, sites and data the plan covers, and who may invoke it. Activation criteria should be written so a duty engineer at 2am can apply them without a debate.

Name a single activation authority with at least two named deputies. Plans that require the CISO to authorise activation fail on the weekend they are needed most. Give the on-call responder standing authority to contain, and require approval only for actions with business impact such as shutting down a production service.

Roles and the Response Team

Define an incident response team by role, not by person, then list current names in an annex you can update without reissuing the plan.

Typical roles include an incident manager who coordinates and records decisions, a technical lead, a communications lead, a legal and privacy contact, an HR contact for insider cases, and an executive sponsor. In smaller organisations one person may hold several roles, which is fine as long as the plan says so.

One role is often missed: the scribe. Someone must log times, decisions and actions as they happen. Reconstructing a timeline afterwards from memory and chat messages is where most notification deadlines are missed. Day to day coordination usually sits with IT or security operations.

Communication and Escalation

The plan needs an internal escalation ladder with response times, and an external contact list covering regulators, key customers, insurers, law enforcement and any retained forensic support.

Two practical points. Hold contact details offline as well as online, since a ransomware event may take your directory and email with it. And pre-approve holding statements for staff, customers and media, so the communications lead is not drafting from scratch under pressure.

Notification duties belong here too. Map each obligation against your legal and regulatory compliance requirements, including the 72-hour GDPR window for notifiable personal data breaches and any shorter deadlines written into customer contracts.

Playbooks by Incident Type

Generic plans produce generic responses. Add short playbooks for your most likely scenarios: ransomware, business email compromise, credential theft, lost device, cloud misconfiguration and supplier breach.

Keep each playbook to one page with immediate actions, evidence to preserve, who to notify and recovery steps. Teams follow a one-page checklist. They do not read a manual while systems are encrypting.

Want playbooks, tasks and evidence linked to every incident record? Try Effivity for Free and build your response workflow in a few hours.

Free Trial →

The Six Phases the Plan Should Follow

Most recognised frameworks use the same sequence, and structuring the plan this way makes it easier to audit.

Preparation: tools, training, contacts, access and authority in place
Detection and analysis: confirm the incident and set severity
Containment: short-term isolation, then a stable longer-term hold
Eradication: remove the cause, close the entry point
Recovery: restore from clean sources and monitor closely
Post-incident review: what failed and what changes

Containment deserves the split into short and long term. Pulling a server off the network buys time but is not a fix, and plans that jump straight to eradication tend to destroy evidence.

Testing the Incident Response Plan

An untested plan is a draft. Testing is also the part auditors probe hardest, because it is easy to write a plan and hard to fake an exercise record.

Tabletop Exercises

Walk the team through a realistic scenario in a meeting room. Ninety minutes, one facilitator, no technical work. The value is in the gaps it exposes: nobody knows who calls the insurer, the out-of-hours number is wrong, or two people each believe the other can authorise isolation.

Run one at least annually, and include the executive sponsor. Record the date, participants, scenario and the actions raised.

Simulations and Drills

Go further where risk justifies it. Phishing simulations, restoring a critical system from backup within the stated recovery time, or a controlled test of your isolation procedure all give harder evidence than a discussion.

A restore test is the single most useful drill. Many organisations discover their recovery time objective is achievable on paper and not in practice, and it is far better to find that during a drill.

Every exercise should end with a written corrective action plan carrying owners and dates. Exercises that produce observations but no actions add nothing.

Keeping the Plan Current

Plans decay quietly. Staff leave, systems change, suppliers change, and the contact list ages faster than anything else.

Set review triggers rather than relying on an annual date alone. Review after any major incident, any exercise, any significant system or organisational change, and at least once a year. Treat the plan as a controlled document with version history and approval, the same discipline you apply through document control.

Keep an offline copy. A plan stored only on the network you have just isolated is not available when you need it.

What ISO 27001 Expects

Certification does not demand a specific template. It expects planning and preparation, defined roles, response according to documented procedures, evidence collection, and learning from incidents. These sit within the Annex A controls covering incident management.

Auditors usually ask for the plan, proof it has been communicated, records from the last exercise, and one real incident traced through the plan from report to closure with a documented root cause analysis.

Common Mistakes to Avoid

Writing the plan for auditors rather than responders
No named deputies, so activation stalls out of hours
Contact lists stored only in the systems that may fail
No scribe, leaving no reliable timeline
Recovery steps that assume backups are clean and tested
Exercises held but never documented
Closing incidents at service restoration instead of after verified fixes

The first mistake causes most of the others. A plan written to satisfy a checklist gets filed. A plan written to be used gets rehearsed.

How Effivity Supports Incident Response

Effivity's Information Security Incidents Management module holds the report form, severity, assigned tasks, evidence and timeline in one record. Workflows route each step to the right role automatically, so escalation follows the plan rather than memory, and every action is time stamped for the audit trail.

Document Control keeps the plan and playbooks under version control with approval history. Corrective actions from exercises and real incidents are tracked to verified closure, and dashboards show open incidents, ageing and overdue actions. Because information security management software links these records, your audit evidence is assembled as you work. A simple incident report form keeps first-stage reporting quick for staff.

Get a Free Personalized Demo to see the response workflow set up with your own roles and severity levels.

Free Demo →

Frequently Asked Questions

It is a documented set of instructions for detecting, containing and recovering from a security incident. It names roles, actions, escalation paths and communication steps.

Preparation, detection and analysis, containment, eradication, recovery, and post-incident review. Most frameworks follow this same sequence.

An incident manager, technical lead, communications lead, legal or privacy contact and an executive sponsor. Smaller teams can combine roles if documented.

At least once a year through a tabletop exercise, plus after major incidents or system changes. Record the date, participants and actions raised.

The policy states the commitment and rules for handling incidents. The plan gives the step-by-step instructions the team follows during one.

ISO 27001 requires planned incident response with defined roles, procedures and evidence handling. A documented plan is the usual way to show this.

Share with