Incident Response Plan Template: A Practical, NIST-Aligned Framework You Can Fill In Today

Most Plans Fail for Lack of a Usable Document, Not a Lack of Knowledge

Someone has asked you to build an incident response plan. You have probably read about the 7 phases. What you likely do not have is an incident response plan template you can actually fill in.

If someone has told you to ‘get an incident response plan in place’ after a client security questionnaire, a cyber insurance renewal, or a near-miss, this post is for you. It builds on our conceptual guide to the 7 phases of incident response but does something the theory version cannot: it gives you a fillable structure you can use this week.

The template below aligns with current NIST guidance (SP 800-61 Rev. 3, published April 2025) while keeping the same 7-phase structure most existing incident response content still uses. That keeps you consistent with what auditors, insurers, and legal counsel already expect to see.

What Belongs in Every Incident Response Plan (The 5 Foundational Sections)

Regardless of which phase framework you use, every usable incident response plan needs five foundational sections. These are the scaffolding the phase-by-phase template fills into.

1. Incident classification and severity matrix. First, define what counts as an incident and how you rank severity. A three-tier system (Tier 1 critical, Tier 2 high, Tier 3 moderate) is enough for most small-to-mid practices. Assign each tier a maximum response time and an escalation trigger.

2. Named roles and 24/7 contact information. Also, every plan needs an incident commander, a technical lead, a communications lead, and a legal or compliance contact. List each by name, mobile number, and backup. If your team is small, one person may cover multiple roles; that is fine, but write it down.

3. A communication tree. Map who gets notified, in what order, and how. Include internal stakeholders, affected clients, outside counsel, your cyber insurance carrier, and regulators where applicable. Note the format (call, email, secure portal) and the maximum time from detection to notification.

4. Evidence preservation basics. During an incident, the impulse is to fix the problem fast. That impulse can destroy the forensic evidence you need for insurance claims and any downstream legal action. Include a short “do not do” list: do not wipe affected devices, do not delete suspicious files, do not restart systems until authorized.

5. Review cadence.A plan that gets a yearly review survives. A plan that gets shelved after one review becomes obsolete within months.

The 7-Phase Incident Response Plan Template (Fill-In Prompts)

Below is a fill-in template mapped to the same 7 phases used in our phases of incident response pillar post. Copy this into a document, fill in the prompts, and you have a starting plan. The prompts are deliberately short. This is a form to complete, not a lecture on what each phase means.

Preparation (Phase 1)

• Who is authorized to declare an incident?
• What tools and services are in the scope of this plan?
• Where is the current asset inventory maintained?
• Who is on the response team (name + role + contact)?
• What is the frequency of tabletop exercises?
• Where are the plan and its updates stored?

Identification (Phase 2)

• What monitoring or alerting sources feed into detection?
• Who triages initial alerts?
• What criteria promote an alert to a confirmed incident?
• What is the maximum time from detection to escalation?

Containment (Phase 3)

• What is the maximum acceptable containment time for a Tier 1 event?
• Who is authorized to isolate systems from the network?
• What short-term containment steps apply first?
• What long-term containment steps come next?
• How is chain-of-custody evidence preserved during containment?

Eradication (Phase 4)

• Who leads the root-cause investigation?
• What tools are used to identify the entry point and blast radius?
• Who signs off that the threat has been removed?
• What patches, credential rotations, or configuration changes are documented?

Recovery (Phase 5)

• What is the priority order for restoring systems?
• Who authorizes the return to production?
• How is post-recovery monitoring conducted, and for how long?
• What client-facing communications happen during recovery?

Lessons Learned (Phase 6)

• Who runs the post-incident review?
• Within what timeline is the review completed after the incident closes?
• What documentation is produced (timeline, root cause, corrective actions)?
• Where is the review stored, and who has access?

Ongoing Improvement (Phase 7)

• What corrective actions are tracked to completion?
• How often is the plan updated?
• What metrics are tracked over time (time to detect, time to contain, number of incidents by type)?
• When is the next tabletop scheduled?

Once these are filled in, print the document, share it with the team, and store a copy somewhere accessible without needing production systems (a locked cabinet or an offline backup).

A Worked Incident Response Plan Example

For example, consider a realistic scenario for a small law firm.

The event. On a Tuesday afternoon, a paralegal receives a phishing email that mimics a court filing notification. They click the link and enter their firm credentials. Two hours later, opposing counsel emails the managing partner asking why they received the firm’s discovery documents for an unrelated matter.

How the phases play out:

• Identification. The managing partner triages the message with the technical lead. Within 15 minutes, they confirm the paralegal’s account sent the wrong discovery file to an external recipient and that the account credentials may be compromised.
• Containment. The technical lead disables the paralegal’s credentials, rotates the account password, and forces a re-authentication across all firm accounts. The team temporarily locks access to the affected matter workspace.
• Eradication. A forensic review confirms the phishing entry point. The team removes the malicious email from all inboxes, patches the vulnerability, and enables multi-factor authentication on any accounts that did not already have it.
• Recovery. Normal workflow resumes and the team monitors affected accounts for 30 days. The team recalls the wrongly-sent discovery where possible, and the firm notifies the client per protocol.
• Lessons Learned. The team holds a 30-minute post-incident review. Root cause: paralegal accounts had no MFA enforcement. Corrective actions: enforce MFA firm-wide, refresh phishing training, and require secure file sharing for outbound client documents.
• Ongoing Improvement. A ‘sender confirmation’ step gets added to any external document share, and the next tabletop drill is scheduled within 60 days.

This is what a filled-in plan looks like in practice. Not dramatic. Not a nation-state attack. A phishing email, a wrong-recipient send, and a methodical response that keeps the client relationship intact.

What Is an Incident Response Drill (and How to Run One)?

An incident response drill (also called a tabletop exercise) walks your team through a hypothetical incident against your incident response plan. The team talks through what they would do, when, and why. Nothing actually breaks. The point is to find the gaps before an attacker does.

In practice, most small and mid-size firms can run a useful drill in under an hour.

A simple format:

• Prep (15 minutes). Write a short scenario (2 or 3 paragraphs). Name a facilitator who does not participate as a role. Send the invite with no scenario details attached.
• Run (30 to 40 minutes). Read the scenario aloud. Walk through each phase of the plan. At each phase, ask the team what they would actually do. Note gaps where the plan is unclear, contact info is stale, or a role is undefined.
• Debrief (10 minutes). Capture three specific corrective actions with owners and deadlines.

Recommended cadence:

• At least once a year.
• After any major system change (a new document management system, a merger, a new office).
• After any real incident, using the actual event as the scenario.

Sample scenarios to run:

• A phishing email leads to a partner’s credentials being used from an unfamiliar location overnight.
• A backup restore fails during a quarterly test, and the primary system goes down the same day.
• A departing associate emails client files to a personal address the day before their last day.

Finally, save the debrief notes with the plan. Every tabletop makes the plan tighter than the last one.

Where the Plan Intersects with Client Data

In fact, for firms handling client files, the containment and communication phases of your incident response plan have to account for two things standard IT templates often miss.

Client notification obligations. Depending on your profession, professional conduct rules govern your client notification duties (ABA Model Rule 1.4 for lawyers, AICPA rules for CPAs) and by statute (HIPAA for healthcare data, state breach notification laws for personal information). Your communication tree should include which clients get notified, by whom, and within what timeframe. Our client confidentiality rules by profession guide covers the specifics.

How files are actually stored and shared. During an incident, you need to know which systems client files live in, who has access, and how quickly access can be revoked. If your firm still moves files through personal email, personal cloud drives, or unmanaged USB drives, the incident response plan has a blind spot. A purpose-built secure file sharing platform gives you a documented audit trail of every access, a way to revoke access immediately, and a Business Associate Agreement where HIPAA applies.

For law firms specifically, our law firm data breach response playbook walks through the first 24 hours of a breach in more detail.

Get the Incident Response Plan Template

Download the fillable incident response plan template below. Print it, fill it in with your team, and store a printed copy somewhere accessible without production systems.

If a file sharing gap surfaces while filling it in a place where client documents move through personal email or an unmanaged cloud drive that is worth addressing before your next tabletop drill. Book a demo to see how TitanFile fits into an incident response workflow, or start a 15 day free trial to try it against a real client scenario.

This article and template are general guidance, not legal or professional-conduct advice. Have someone with real incident response experience review your finished plan, and consult ethics counsel or compliance professionals for jurisdiction-specific requirements.