Incident Response Plan Template + Walkthrough

In late May 2024, Evolve Bank & Trust noticed systems behaving strangely and first assumed a hardware fault. It was the LockBit ransomware group, which got in after a single employee clicked a malicious link. The breach exposed data on 7.64 million people and ended in an $11.85 million class-action settlement. An incident response plan template is what turns that moment from improvisation into a procedure. It gives a US business the structure to detect, contain, and recover from a breach in a Word document the team can open and follow under pressure. The six phases below align to NIST SP 800-61.

The Fast Guide to the Incident Response Plan Template
In May 2024, the LockBit group breached Evolve Bank & Trust after one employee clicked a malicious link, exposing data on 7.64 million people and leading to an $11.85 million settlement. An incident response plan template turns that kind of moment from chaos into a procedure.
The template follows the NIST SP 800-61 lifecycle in six working phases: preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Each phase has a clear owner and output.
IBM puts the average breach at $4.88 million in 2024. Organizations with an incident response team that tested their plan saved $2.66 million per breach, a 58% reduction, and detected breaches 54 days faster.
The template classifies every event by severity, from Sev 4 handled by one analyst to Sev 1 that pulls in the Incident Commander, executives, legal, and outside responders.
An incident response plan is not a business continuity plan. The IR plan stops and removes the threat; the continuity plan keeps the business running while it does.
Test the plan with tabletops and simulations. An untested incident response plan template is the most common and most expensive failure on this list.
Phishing and stolen credentials start most breaches, so the template’s detection phase and its escalation matrix matter more than any single tool.

The financial case is settled. IBM puts the average breach at $4.88 million in 2024, and organizations with an incident response team that tested their plan saved $2.66 million per breach. A tested plan is the single best return in cybersecurity spending. This template is built around NIST SP 800-61, the US standard for computer-security incident handling. You do not need a security team of twenty to use it, but you do need the plan written, assigned, and tested before the first alert fires. Our cybersecurity risk management guide sets the wider program around it.

Every figure here comes from the issuing body or a primary report, including NIST, IBM’s Cost of a Data Breach study, and the breach’s own regulatory filings. The template is the practitioner version of those standards, sized for a business without an enterprise security budget.

Why Every Business Needs an Incident Response Plan Template

Breaches are no longer rare events reserved for large enterprises. Small and mid-size US businesses are targeted precisely because their defenses are thinner, and a single click can hand an attacker the keys.

The Evolve case began with one employee and ended with millions of records gone. An incident response plan template compresses an enterprise security program into a document one team can run.

It answers the questions a breach forces in the worst possible moment: what is happening, who decides, and what we do first. Deciding those on a calm day is the entire value. The threat is measurable, not hypothetical. The FBI’s Internet Crime Complaint Center logs billions in reported cyber losses each year, and international standards like ISO 27035 exist precisely because incident handling is now a core business function. A template brings that discipline within reach of a small team.

What an Incident Response Plan Template Includes

A complete incident response plan template covers the six lifecycle phases plus the scaffolding that makes them work: a severity classification, a roles and escalation matrix, contact lists, communication scripts, and a testing schedule. Each phase answers one question the incident raises.

Together they replace panic with a sequence. The document stays short on purpose. A 15 to 25 page plan that the team has read and rehearsed beats a 100-page manual nobody opens, the same lesson our information security risk management guidance applies across the program. Readable under stress is the design goal.

How the IR Plan Template Differs From a Continuity Plan

An incident response plan and a business continuity plan solve different problems. The IR plan detects, stops, and removes a security threat; the business continuity plan template keeps critical functions running while that happens. A breach usually activates both, and our IR versus continuity comparison maps where they hand off. In practice the two plans share a crisis team but split the work. The incident response plan owns the security decisions, the isolation, eradication, and evidence, while the continuity plan owns keeping orders, payments, and service running on workarounds. A serious breach needs both firing at once. Figure 1. A tested incident response plan cuts breach cost. Cohort difference per IBM Cost of a Data Breach 2024; bars illustrative around the measured $2.66 million gap. The chart is the business case in one image. The cohort that built and tested an incident response plan paid $2.66 million less per breach than the cohort with neither. For a small business, that gap is the difference between a bad quarter and bankruptcy.

The Six Phases in the Incident Response Plan Template

NIST SP 800-61 groups incident response into four stages, which most templates expand into six working phases for clarity. Each phase has an owner, an output, and a trigger that moves the incident to the next. The table lists all six before the walkthrough puts them in motion.

Phase	What Happens	Key Output
1. Preparation	Plan written, team trained, backups tested, tools ready	A ready, rehearsed team
2. Detection and analysis	Alerts triaged, the event confirmed and classified by severity	A declared, scoped incident
3. Containment	Affected systems isolated, accounts disabled, evidence preserved	The spread stopped
4. Eradication	Malware removed, the entry vector closed, credentials reset	A clean environment
5. Recovery	Systems restored from clean backups and monitored	Operations resumed safely
6. Lessons learned	After-action review, notifications sent, the plan updated	A stronger next response

  The six-phase model traces to two sources. NIST SP 800-61 defines the four-stage lifecycle, and the SANS Institute PICERL model splits it into the six phases most templates use: preparation, identification, containment, eradication, recovery, and lessons learned. Both describe the same response at different granularity.

Preparation and Detection in the Incident Response Plan

Preparation is the phase that decides the other five. It keeps contact lists current, backups tested, logging on, and the team rehearsed, so detection is not the first time anyone reads the plan. The NIST Cybersecurity Framework calls this the difference between a program and a binder. Detection and analysis is where speed pays. The template defines what counts as an incident, how alerts are triaged, and how the responder confirms and scopes the event before declaring it. IBM found that testing the plan cuts the time to detect and contain a breach by 54 days. Figure 2. Testing the incident response plan shortens the breach lifecycle by 54 days (IBM 2024). Faster detection is lower cost.

Containment, Eradication, and Recovery in the IR Plan

Containment stops the bleeding. The template directs the team to isolate affected hosts, disable compromised accounts, and preserve evidence before anything is wiped, so the investigation and any legal disclosure survive. Acting fast without preserving evidence is a mistake the plan prevents. Eradication and recovery close the loop. Eradication removes the malware and shuts the door it came through; recovery restores systems from clean backups and watches for reinfection before declaring the incident over. Rushing recovery before eradication is how a business gets breached twice in a week. Evidence is the quiet priority in the early phases. Memory images, logs, and disk snapshots taken before cleanup are what a forensic firm, an insurer, and a regulator all need later, so the template makes evidence capture a containment step rather than an afterthought. Wiping first destroys the case.

Lessons Learned in the Incident Response Plan Template

The final phase is the one most teams skip and most regret. A structured after-action review captures what worked, what failed, and which controls to fix, then feeds the findings back into the plan. The incident response plan template treats this as mandatory, not optional, because the next attacker is already studying the same vector. Lessons learned is also where the cost is recovered. The review names the control that failed, the phishing filter or the unpatched server, and the key risk indicators that should have flagged it earlier, then funds the fix while the breach is fresh. A finding logged and closed is the difference between one breach and two.

Filling Out the Incident Response Plan Template

A blank template is not a plan. Filling it out means three decisions the rest of the document depends on: how you classify severity, who runs the response at each level, and how you communicate. Get those right and the phases run themselves.

Severity Levels in the Incident Response Plan Template

Severity drives everything downstream. The template classifies each event from Sev 4, a logged nuisance one analyst handles, up to Sev 1, a confirmed breach that pulls in the Incident Commander, executives, legal, and outside responders. Misclassifying a Sev 1 as a Sev 3 is how an hour of delay becomes a headline.

Severity	Example	Response Target	Who Is Involved
Sev 1 (critical)	Confirmed ransomware or mass data theft	Immediate, 24/7	Commander, execs, legal, IR firm
Sev 2 (high)	Malware on a key system, account takeover	Within 1 hour	Commander and team leads
Sev 3 (medium)	Isolated malware, suspicious access	Within 4 hours	On-call responder, duty manager
Sev 4 (low)	Spam, blocked phishing, policy breach	Next business day	Security analyst

  Severity also drives your obligations. A Sev 1 breach of regulated data triggers notification clocks and, for ISO 27001 certified firms, a documented incident record the auditor will read. The template ties each severity level to the legal and contractual duties it sets off, so nobody improvises a disclosure under pressure.

Roles and Escalation in the Incident Response Plan

A plan with no names is a wish. The template assigns an Incident Commander, a deputy, and leads for technical, communications, and legal work, with primary and backup contacts for each. In a small business one person wears several hats, so the matrix records who covers whom when the commander is unreachable, a discipline our CRISC, CISA, and CISM guide maps to the credentials behind those roles. Escalation is the other half of roles. The template states who can declare an incident, when a Sev 2 becomes a Sev 1, and which external parties get called and in what order. Ambiguity here costs the first hour, the most expensive one, when nobody is sure who owns the decision.

Walkthrough: The Incident Response Plan Template in Action

A template proves itself in a scenario. The walkthrough below runs a ransomware breach modeled on the 2024 Evolve case through all six phases, showing what the team does and when. Reading it once makes the blank template feel like a script rather than a form. Keep one copy of the plan offline. A breach often takes down email, file shares, and the systems the plan itself lives on, so the template is printed and stored where the team can reach it without the network. A plan trapped inside the encrypted drive is no plan at all.

A Ransomware Walkthrough of the IR Plan Template

The scenario starts the way most breaches do. An employee clicks a phishing link, an attacker quietly accesses file shares, and days later endpoint detection flags mass file encryption. The plan moves the team from that alert to a contained incident in hours, not days. Notice how fast the clock runs. From the first confirmed alert, the team has hours, not days, to isolate systems before the attacker finishes stealing data or detonates ransomware across the network. The template’s pre-assigned roles are what make that speed possible, because nobody is deciding who does what while the encryption spreads.

Phase	What the Team Does in the Scenario	Timing
Preparation	Plan, contacts, and tested backups already in place	Before the incident
Detection and analysis	Confirm encryption, trace the phishing entry, classify Sev 1	Hour 0 to 1
Containment	Isolate hosts, disable accounts, block the attacker, preserve logs	Hour 1 to 4
Eradication	Remove the malware, reset all credentials, close the vector	Hour 4 to 24
Recovery	Restore from clean backups, validate, monitor for reinfection	Day 1 to 3
Lessons learned	After-action review, notify regulators and customers, update the plan	Week 1 onward

  The walkthrough also shows where third parties enter. Evolve’s breach reached fintech partners like Affirm, Mercury, and Wise through its Open Banking connections, so the template’s communication phase scripts vendor and customer notice. Our third-party risk guide anchors the supplier side of the response a breach forces on a small business. By the lessons-learned phase, the plan has done its job. A breach that could have run for months was found, contained, and closed in days, and the after-action review turns the experience into a stronger next response. That compression is the entire return on writing the incident response plan template before it was needed. Figure 3. How breaches start. Stolen credentials and phishing lead the vectors an incident response plan template must detect, the same path the Evolve breach took.

Testing the Incident Response Plan Template

An untested plan is a guess. The template schedules exercises because a plan decays the moment a contact, a system, or a vendor changes, and the test is where you find the broken phone number before the attacker does. Testing is also where IBM’s $2.66 million saving is earned. Regulators expect the plan, not just the intent. The FTC’s data breach response guide and sector rules treat a tested incident response plan as a baseline control, and examiners increasingly ask to see the exercise records. A plan you can produce and prove beats one you can only describe.

How to Test the Incident Response Plan

Test on a cadence the business can keep. A tabletop quarterly, a walkthrough twice a year, and a full simulation annually is a realistic schedule, and the CISA incident response services guidance recommends the same layered approach. Each test type exposes a different gap.

Test Type	What It Validates	Frequency
Tabletop	Decisions, roles, and escalation in a discussion	Quarterly
Walkthrough	Each step of the plan read end to end	Twice a year
Simulation	A live, hands-on response to a staged incident	Annual
Red team	Whether detection and containment work under a real attack	Annual or biennial

  Run the first exercises internally, then escalate. A tabletop the team runs over lunch builds familiarity cheaply, while an external red team or simulation, once a year, tests whether detection and containment actually hold under a real attack. Start small, then prove it under pressure. Document every finding. The template includes an after-action log, because the value of a test is the gap it exposes, not the box it ticks. A finding that is recorded and fixed turns the next real breach into a rehearsal the team has already run.

Frequently Asked Questions on the IR Plan Template

Common Incident Response Plan Template Mistakes

Seven mistakes turn an incident response plan template into shelfware. The table pairs each with its root cause and the fix, so the plan works when the alert fires rather than gathering dust. Most trace back to writing the document once and never testing it.

Pitfall	Root Cause	Remedy
Writing the plan once	Treating it as a compliance checkbox	Schedule tabletops and an annual simulation
No severity classification	Treating every alert the same	Define Sev 1 to Sev 4 with response targets
No named Incident Commander	A response run by committee	Assign a commander and a deputy with authority
Wiping systems before evidence	Rushing to clean up	Preserve logs and images before eradication
Recovery before eradication	Restoring too fast	Confirm the threat is gone, then restore
Plan only stored online	A single network-dependent copy	Keep an offline, offsite copy the team can reach
No customer or regulator script	Focusing only on the technical fix	Pre-write notice templates and disclosure timing

The Incident Response Plan Template Beyond 2026

Three forces are reshaping the incident response plan template through 2027. The first is regulation. The SEC’s four-day disclosure rule, the FFIEC handbook, and state laws now put hard clocks on breach notice, so the template’s communication phase carries deadlines, not just contacts. The second force is sector-specific rules pushing the plan down the supply chain. The FFIEC assessment for banks and NYDFS Part 500 for insurers now expect a tested incident response plan, and larger clients ask small vendors to show theirs. For regulated US businesses the bar is explicit. Banking examiners under the FFIEC and insurers under New York’s DFS cybersecurity regulation must maintain and test an incident response capability, and the template is how a small firm meets that expectation without a dedicated security team. The third force is AI, on both sides. Attackers use it to write better phishing, and defenders use it to triage alerts faster, so the template’s detection phase increasingly assumes machine-assisted analysis. The NIST SP 800-61 Revision 3 update folds this into the CSF 2.0 functions the program already tracks. The durable advice outlasts every trend. Write the template, classify severity, name the commander, and test on a cadence you can keep. An incident response plan template is only as good as the last time a team actually ran it, on a calm day, before the real alert.

Infographic: The Incident Response Plan Severity Hierarchy

Figure 4. The incident response plan severity and escalation hierarchy, from a Sev 4 logged by one analyst to a Sev 1 that pulls in the whole crisis team.

Build Your Incident Response Plan Template

Risk Publishing helps US businesses build and test the incident response plan template that turns a breach from a crisis into a procedure, aligned to NIST SP 800-61 and the rules their sector enforces. Review the advisory services page to see how the engagement runs, and contact the practice when incident readiness is the next priority