Incident Response Plan: How to Build and Test One

A security incident is not a theoretical risk — it is a predictable event in any organisation that uses digital systems. The question is not whether an incident will occur but whether, when it does, the organisation has a prepared response that limits damage, speeds recovery, and preserves the evidence and documentation needed for insurance claims, regulatory compliance, and post-incident learning. We go deeper on the whole subject in our Complete Guide to Online Security and Privacy.

An incident response plan is the documented, tested framework that defines who does what, when, and how when a security incident occurs. Organisations without a plan figure out the response under the pressure of an active breach — and consistently produce slower, more expensive, and less thorough responses than those with a prepared plan.

This guide is written for small and mid-size organisations that need a practical, implementable framework — not the enterprise-scale NIST programme that assumes a dedicated security operations team. The plan described here is achievable for a 10–100 person organisation with a single IT administrator or small IT team, and it satisfies the documentation requirements that cyber insurance underwriters increasingly mandate.

The six phases — the framework every plan follows

The NIST incident response lifecycle provides the standard framework regardless of organisational size:

1. Preparation: what’s done before an incident occurs — documenting the plan, training people who will execute it, testing through tabletop exercises, and maintaining the tools and access needed to respond
2. Detection and Analysis: identifying and confirming the incident — determining whether an alert represents a genuine security event, what type it is, and what systems and data are potentially affected
3. Containment: stopping the incident from spreading while preserving evidence — isolating affected systems from the network (not powering them off, which may destroy volatile memory evidence), revoking compromised credentials, blocking attacker IP addresses
4. Eradication: removing the attacker’s presence — malicious software, backdoors, persistence mechanisms, compromised accounts
5. Recovery: restoring systems to normal operation from verified clean backups or rebuilt infrastructure
6. Post-Incident Review: analysing what happened, why the incident succeeded, what response worked and what could be improved, and updating the plan with lessons learned

Building the document — the five core elements

The plan doesn’t need to be long — it needs to be clear, specific, and actually used. A 5-page plan that lives on a printed card in the IT administrator’s desk and is reviewed quarterly is more useful than a 50-page compliance document sitting unread in a SharePoint folder.

1. Contact list and escalation path: name specific individuals with phone numbers, email addresses, and after-hours contact information — not just job titles. Include the cyber insurance incident hotline number. Include the IT administrator, the business owner or incident commander, and if pre-selected, the forensic firm and breach counsel. Include a quarterly reminder to verify all contacts are current — a contact list everyone knows is outdated is useless.

2. Incident classification (severity levels): define severity levels so the initial responder can quickly classify an incident and initiate the appropriate response without having to make a judgment call under pressure.

3. Communication protocol: who communicates with internal staff, customers, regulators, and press — and through what channel if email is potentially compromised. What must not be said publicly until legal counsel has reviewed it. The communication protocol prevents well-intentioned but legally problematic public statements made under pressure by people not aware of the legal implications. CISA’s incident response guidance identifies the communication protocol as the plan component most commonly improvised during actual incidents — and improvised communication is the component most frequently cited in subsequent legal proceedings as having worsened the organisation’s position.

4. Technical response procedures: step-by-step instructions for the containment and eradication actions most likely to be needed. These don’t need to cover every scenario — focus on the most probable incidents (ransomware, phishing-based account compromise, data breach) with enough specificity that anyone following the procedure can execute it under pressure.

5. Backup restoration procedure: documented process for restoring systems from backup, including who has access, where the backups are, how long restoration typically takes, and how to verify backup integrity. This procedure should be tested — not just documented.

The tabletop exercise — making the plan real

An untested plan is a document, not a plan. Tabletop exercises are structured discussions where the incident response team walks through a simulated security incident, applying the plan’s procedures in a low-stakes environment that reveals gaps before a real incident does.

To run a tabletop exercise:

1. Select a realistic scenario for the organisation’s threat profile — ransomware from a phishing email is appropriate for most organisations; a more targeted scenario for higher-risk ones
2. Present the scenario in stages, giving the team time to discuss and document what actions they would take at each stage
3. Key questions to answer: who makes the call to isolate affected systems? Who contacts the insurer? Who communicates with affected customers? What is the backup restoration procedure and how long will it take? Who has the access credentials needed to execute each response action?

Common gaps discovered in tabletops:

• The backup restoration process has never been tested — the estimated recovery time turns out to be three times longer than expected
• The forensic firm’s contact in the plan belongs to an account manager who left six months ago
• Network isolation requires access credentials that only one person holds, and they’re on holiday
• The communication template references a legal team contact that changed when the firm switched counsel
• Nobody knows who has administrative access to the email system to review audit logs for signs of compromise

Fixing these gaps before an incident is the highest-value use of incident response plan maintenance time. Schedule a tabletop exercise quarterly — use a different scenario each time to develop generalised response capability rather than preparation for one specific incident type.

Specific playbooks by incident type

The core plan provides the framework; incident-type playbooks provide the specific procedure for each likely scenario. Write a one-page playbook for each of the most probable incident types:

Ransomware playbook:

• Immediately power off the affected device (stops encryption in progress) and disconnect from the network
• Do not pay the ransom before checking nomoreransom.org for a free decryptor
• Notify the insurer before taking any further action — ransomware payment requires insurer approval to be covered
• Identify the scope (which systems are affected, which backups are clean)
• Preserve forensic evidence before restoration begins
• Restore from clean offline backup after forensics has confirmed eradication

Phishing-based account compromise playbook:

• Change the compromised account’s password immediately using a clean device
• Terminate all active sessions on the compromised account
• Review the account’s audit log for forwarding rules, connected apps, and delegated access added during compromise
• Check for emails sent from the compromised account during the compromise window — these may be phishing messages sent to contacts
• Enable 2FA if not already active; review 2FA method if active (attacker may have changed it)

Data breach notification playbook:

• Determine breach scope — what data was exposed, whose data, how many records
• Engage legal counsel to assess notification obligations by jurisdiction (GDPR: 72 hours to supervisory authority; HIPAA: 60 days; various state laws have different timeframes)
• Prepare notification letters — do not send until legal counsel has reviewed
• Document the timeline of discovery, scope determination, and notification for regulatory purposes

Compliance requirements that mandate a plan

For regulated organisations, an incident response plan is not optional:

• HIPAA Security Rule: requires covered entities to implement procedures for responding to security incidents
• PCI DSS Requirement 12.10: requires a documented incident response plan, tested annually
• SOC 2 (CC7.3 and CC7.4): requires incident detection and response procedures
• GDPR Article 33: requires a breach notification process within 72 hours to the supervisory authority

Compliance and security are, for once, pointing in the same direction — a documented, tested plan satisfies both. Our guide on cyber insurance covers the documentation requirements that underwriters mandate, which align closely with the plan structure in this guide. For CISA’s incident response guidance including templates and playbook examples for common incident types, CISA’s incident response playbooks provide adaptable templates appropriate for organisations of any size.

Maintaining the plan over time

Plans go stale quickly as personnel change, systems change, and the threat landscape evolves. A quarterly review checks that all contact information is current, the backup restoration procedure matches the current backup solution, and the playbooks reflect the current system inventory. An annual full review adds an updated tabletop exercise with a new scenario, a check that the insurer’s panel contacts are still current, and a revision of severity classification based on any new systems or data types added to the environment.

The plan is most effective when it’s familiar — when the people who will execute it have read it recently enough that they know where to find the contact list, what the severity levels mean, and which playbook applies to the incident they’re facing. Familiarity comes from regular review and regular exercise, not from filing the document away after creation. Schedule the first quarterly review immediately after the plan is first created rather than waiting for the next security awareness cycle. An incident response plan that’s exercised regularly is a security control that compounds in value with each exercise. You might also run into Software Supply Chain Security.

The one-page incident response quick reference card

The most useful artefact from the full plan is a one-page quick reference card that lives physically accessible — printed and kept at the IT desk, or stored as a PDF on a clean USB drive kept separate from the main infrastructure. During an active incident, accessing a SharePoint document that may itself be on a compromised system is a problem. The card addresses this:

Key contacts always on the card:

• Cyber insurer 24/7 breach hotline and policy number
• IT administrator (primary and backup contact)
• Business owner / incident commander
• Forensic firm contact (if pre-selected)
• Legal counsel
• Alternative communication channel if email is compromised (Signal group number, conference call bridge)

Fill in the blanks, print the card, laminate it, and put it somewhere accessible. Update it when any contact information changes. This card may be the most-used artefact from the entire incident response plan exercise — and the easiest to create. Related: Biometric Data Privacy.

An incident response plan is ultimately about reducing the panic-to-response time when something goes wrong. Every minute of disorganised response during an active breach is a minute the attacker can use. Every contact that can be reached immediately is minutes saved. Every procedure that’s been practiced is faster than one being followed for the first time under pressure. The plan doesn’t need to be perfect — it needs to be specific, accessible, and familiar enough that the first hours of a response are organised rather than chaotic. That difference in quality of response, in the first hours, is where the most significant reduction in incident damage typically occurs. If this sounds familiar, Small Business Cybersecurity is worth a look.