Incident Response Plan Template and Tabletop Exercise Guide
Last updated:
Incident response plan template: the short answer
An incident response plan is a short, written document that says who does what when a security incident happens, how you decide it is serious, who you tell, and how you get back to work. This guide gives you a section-by-section incident response plan template you can copy, a 60-minute tabletop exercise script to test it, and a roles and decision table so nothing stalls while people wait for permission. Where we refer to formal guidance, we follow NIST’s SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025), which ties incident response to the NIST Cybersecurity Framework 2.0.
This guide updates our original 2021 incident response plan article and draws on our March 2025 article on incident response plans, which now redirects here. Updated November 2026.
Why most incident response plans fail
Executives often assume their IT team has an incident response plan. When we assess businesses, we find the same gaps again and again:
- The plan does not exist, or exists only in someone’s head.
- The plan was written once and never tested, so the first real test is the incident itself.
- Nobody knows who is in charge, so decisions wait.
- The plan reads like a software manual, not a playbook. If it cannot say who does what in the first ten minutes, it is a list of tool names.
- It was written for IT, not for the business. It does not say how long you can be down, what the downtime costs, what your insurer requires or what you must tell regulators and customers.
Two stories show the stakes. During an assessment for a large California community college district, we found that nothing was documented: network configurations, system dependencies and incident procedures all lived in the head of one IT director. We asked what happens if he is unavailable. There was no answer. A large global technology firm showed the opposite approach: it required a departing employee to document everything he did before his last day. Two months later, when his replacement died in an accident, the company got someone up to speed quickly because the record existed.
If your incident response plan only exists in someone’s head, it does not exist.
Incident response plan template
Use these twelve sections as your outline. Keep each short. A plan people can read in twenty minutes will be used. A forty-page plan will not.
| Section | What to write | Who owns it |
|---|---|---|
| 1. Purpose and mission | One paragraph: why the plan exists and what it protects (customers, revenue, safety, regulated data). | CEO or CISO |
| 2. Scope and severity levels | What counts as an incident. Define three or four severity levels, with an example of each, and who may declare each level. | CISO or security lead |
| 3. Roles and authority | Name the incident commander and a deputy. Name leads for IT, legal, communications, HR and finance. State who may shut systems down without asking. | CEO |
| 4. Contact and escalation list | Names, roles and phone numbers (not just email) for the team, insurer and broker, outside counsel, forensic firm, key vendors, law enforcement and your regulators. Keep a printed copy. | Incident commander |
| 5. Detection and triage | How incidents are reported internally, who triages, and the questions to answer first: what happened, what is affected, is it still happening? | IT or security lead |
| 6. Containment, eradication and recovery | Steps by incident type (ransomware, email compromise, lost device, vendor breach). Include backup locations and restore priority order. | IT or security lead |
| 7. Communications | Who speaks to employees, customers, media, board and investors. Pre-approved holding statements. How you communicate if email and chat are down. | Communications lead and counsel |
| 8. Legal, regulatory and insurance duties | Notification deadlines that apply to you, insurer notice requirements, contract duties to customers. Counsel decides what is required and when. | General counsel |
| 9. Evidence and logging | What to preserve (logs, images, memory), who handles it, and a decision log recording who decided what and when. | Security lead and counsel |
| 10. Business impact and priorities | Which services come back first, what an hour of downtime costs, and the manual workarounds for critical processes. | COO and CFO |
| 11. Post-incident review | A review within a few weeks of every significant incident: what worked, what failed, what we change, who owns each action. | Incident commander |
| 12. Testing and maintenance | The tabletop schedule, who reviews the plan, and when. Update after every incident, major change or staff turnover in a named role. | CISO |
The three kinds of incident response content
Once the outline exists, check that your plan covers three types of content, because plans usually over-invest in one and neglect the others.
- Operational: what employees do during an incident, who must be notified, and the specific measures that keep your network and infrastructure protected.
- Preparatory: what you do before an incident, including business continuity and disaster recovery planning, protected data backups, cybersecurity insurance and practice drills.
- Preventative: what reduces the chance of an incident, including patching, antivirus and endpoint protection, review of third-party tool settings, and awareness training for your team.
Training matters here. Everyone needs to know how to handle a small phishing attack as well as a ransomware campaign, which is why awareness training belongs in your plan. NCX Group’s free cyber security kickstarter program includes an online risk assessment, policy templates and awareness posters. For ransomware specifically, use our ransomware response checklist as a chapter of this plan.
What is an incident response drill (tabletop exercise)?
An incident response drill, usually run as a tabletop exercise, is a facilitated discussion in which your leadership team works through a realistic incident using your actual plan, without touching any systems. The point is to find gaps in decisions, authority and communication while the cost of finding them is an hour of time. CISA publishes free, customizable scenario packages, including ransomware, with objectives, discussion questions, an invitation template, a slide deck and an after-action report template: see the CISA Tabletop Exercise Packages.
Tabletop exercise script: a 60-minute incident response drill
Who attends: CEO, CFO, COO, general counsel, head of IT or security, communications lead, HR lead and anyone named in the plan. Add your outside counsel or broker if possible. Who facilitates: someone who does not own the plan, so the plan is tested rather than defended. What you need: your current plan, the contact list, a timer and one person taking notes.
The scenario: It is 6:40 on a Saturday morning. Your IT lead receives alerts that file servers are encrypting. A note on a screen demands payment and says data has been stolen. Your largest customer expects a delivery on Monday.
| Minutes | Segment | What the facilitator asks |
|---|---|---|
| 0 to 5 | Set the scene | Read the scenario. Confirm that people will answer from the plan, not from what they think they would do. |
| 5 to 15 | Detection and command | Who is told first, and by whom? Who is the incident commander? Who can authorize shutting systems down? Where is the contact list, and is it available if email is down? |
| 15 to 25 | Containment and scope | What do we isolate? What stays running? Who decides? How do we communicate with each other while systems are down? Do we know what data is where? |
| 25 to 35 | Insurance, counsel and law enforcement | Who calls the insurer and counsel? What does the policy require? Who contacts law enforcement? Who engages the forensic firm? |
| 35 to 45 | Inject: communications | A reporter emails to ask about the outage, and your largest customer asks if its data is affected. Who answers, what do they say, and who approved it? What do employees hear first? |
| 45 to 55 | Inject: the hard decisions | The attackers send proof they hold your data and set a deadline. Who decides about the ransom? What legal or regulatory notices might now be required, and who decides? |
| 55 to 60 | Debrief | Each person names one thing that would have slowed us down. Record the gaps. |
After the exercise
- Write the gaps down the same day, in plain words: “nobody knew who could shut down the file server.”
- Assign each gap an owner and a date, and put the list in front of the CEO.
- Update the plan, then run another exercise within a year, or sooner if the business changes.
- Rotate scenarios: ransomware, business email compromise, a vendor breach, a lost laptop with sensitive data, and an outage with no attacker at all.
For a prompt on how a quick exercise exposes gaps, see our post on testing your business’s first 72 hours.
Roles and decision points
Most incident delays are people waiting for permission. Decide these in advance and write the names into section 3 of your plan.
| Decision point | Decides | Why it needs deciding in advance |
|---|---|---|
| Declare an incident and its severity | Incident commander | Without it, everyone waits for someone else. |
| Take critical systems offline | IT or security lead, with delegated authority | Hesitation lets damage spread. |
| Notify insurer, counsel and law enforcement | CFO and general counsel | Insurance conditions and legal privilege can depend on timing. |
| Tell customers, employees and regulators | CEO with counsel | Messages must be consistent and accurate. |
| Engage outside forensics and recovery help | General counsel or CEO | Speed depends on a pre-agreed provider. |
| Pay or refuse a ransom | CEO and board with counsel | It is a financial, legal and ethical decision, not a technical one. |
| Declare the incident closed | Incident commander | Prevents half-finished recovery. |
Breach preparedness: how this connects to your wider program
An incident response plan is one part of being ready for a breach. The rest is a readiness assessment, named roles, notification duties and insurer contacts. Our breach preparedness and incident response services cover all of it, and our business continuity planning makes sure operations can resume while you recover. Our earlier piece on breach preparedness explains the basics.
Frequently asked questions
What should an incident response plan template include?
Purpose, scope and severity levels, roles and authority, a contact list, detection and triage, containment and recovery, communications, legal and insurance duties, evidence handling, business impact priorities, a post-incident review, and a testing schedule. The twelve-section table above covers each.
How long should an incident response plan be?
As short as will still be used. A plan that leaders can read in about twenty minutes, with checklists for the common incident types, beats a long document that nobody opens.
What is an incident response drill?
A drill, or tabletop exercise, is a facilitated discussion in which your leaders work through a realistic incident using your plan. It tests decisions, authority and communication without touching your systems.
How often should we test our incident response plan?
At least once a year, and again after any major change to your systems, vendors or leadership. Rotate scenarios so you do not rehearse only one type of incident.
Who should lead incident response?
One named incident commander with authority to make decisions, and a named deputy. Technical staff run the technical response. The commander makes sure legal, communications and business decisions are made quickly.
Related resources
- Ransomware response checklist for executives
- Podcast: why most incident response plans fail and what to do instead
- Has your business tested its first 72 hours?
- Cyber risk assessment (MyCSO Assurance)
- Incident response and breach preparedness services
If you want an outside team to build your plan, facilitate your first exercise or review the plan you have, schedule a conversation with NCX.
