Incident response plan template: the sections, and the one that gets left out

An incident response plan needs ten sections: purpose and scope, roles and contacts, severity levels, detection and escalation, containment and recovery, communications, legal and notification duties, evidence and record keeping, testing and maintenance, and a revision log. The whole template is on this page, below, in the order you would write it. It is easy to carry the first seven and stop. The three that get dropped are the only sections that show the plan is alive rather than merely written.

This template is built from two government sources, NIST’s incident response recommendations and the Canadian Centre for Cyber Security’s guidance on developing an incident response plan, plus Canadian privacy law for two rows. Both guidance documents are free to read and both are worth reading in full.

What sections does an incident response plan need?

The Cyber Centre puts it in one sentence. Your plan should identify the objectives, stakeholders, responsibilities, communication methods, and escalation processes used throughout the incident response lifecycle (Canadian Centre for Cyber Security, Developing your incident response plan, ITSAP.40.003, 2026).

NIST’s current guidance answers a slightly different question, because its list of elements is for the policy rather than the plan, and says that while a policy is individual to the organization, most incident response policies include the same key elements (NIST Special Publication 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025). Its list runs to seven: management commitment, purpose and objectives, scope, definitions, roles and authorities, prioritization guidelines, and performance measures.

Put the two together, add the privacy rules, and you get the ten sections this template uses. Here is what each one is for and where it comes from.

Section	What it settles	Basis
Purpose and scope	Which systems, sites and third parties the plan covers, and which it does not	NIST
Roles and contacts	Who decides, who executes, who is told, and how to reach each of them out of hours	Both
Severity levels	How an event becomes an incident, and what severity triggers what	NIST
Detection and escalation	How something reaches the response team, and the clock that starts when it does	Both
Containment and recovery	Who has authority to disconnect, isolate or shut down, and who approves restoring	NIST
Communications	What gets said internally, to customers, and publicly, and who signs it off	Cyber Centre
Legal and notification duties	Which regulator, which customers, which insurer, and in what order	Canadian privacy law
Evidence and record keeping	What is captured while it is happening, and how long it is kept	Canadian privacy law
Testing and maintenance	How the plan is exercised, how often, and what happens to the findings	Cyber Centre
Revision log	What changed, when, and who approved it	Both

The last three rows are the ones this page exists for.

What goes in each section?

Write it in this order. The wording is yours; the fields are not optional.

Section	Fields to fill	It is finished when
Purpose and scope	Systems in scope. Sites in scope. Third parties in scope. Explicit exclusions	Somebody outside the team can tell whether a given system is covered
Roles and contacts	Incident lead. Deputy. Technical lead. Legal. Communications. Executive sponsor. Insurer hotline. Outside counsel. Primary vendor	Every role has a named alternate and an after-hours number that has been dialled
Severity levels	Three or four levels. Definition of each. Who can set and change severity. What each level triggers	Two people reading the same event pick the same level
Detection and escalation	Intake channels. Who triages. Time to escalate at each severity. Who is woken up	The path from a help-desk ticket to the incident lead is one page and has no gaps
Containment and recovery	Authority to isolate, disconnect, shut down. Approval to restore. Backup restore owner. Criteria for declaring recovery	The person who would pull the cable knows they are allowed to
Communications	Internal holding statement. Customer notification owner. Public statement approver. Regulator contact	A draft holding statement already exists in the file
Legal and notification duties	Privacy regulator triggers. Customer contract clauses. Insurer notice clause. Law enforcement. Timelines for each	The order of calls is written down, insurer included
Evidence and record keeping	Decision log owner. What is captured. Where it is stored. Retention period	A retention period is stated and it meets the legal minimum
Testing and maintenance	Exercise type and cadence. Who attends. Who owns findings. Review trigger	The next exercise has a date on it
Revision log	Version. Date. Change. Approver	The current version is the one the team has actually read

A worked example: the severity table

Severity is the section easiest to leave as a placeholder, because it is the one that requires a decision rather than a description. Filled in, for a mid-market organization, it looks like this.

Level	Definition	Sets it	Triggers
SEV1	A core business service is down, or data confidentiality is confirmed lost	Incident lead, or anyone on the technical team pending confirmation	Executive sponsor woken. Legal engaged. Insurer notice clause checked within the hour
SEV2	A service is degraded, or unauthorized access is suspected but unconfirmed	Incident lead	Response team assembled in business hours. Hourly updates. Severity reviewed every four hours
SEV3	A single account or endpoint, contained on discovery	Triage	Logged and handled. Reviewed weekly for pattern

Three rows, not five. Every extra level is another argument at three in the morning about which one applies.

Which section gets left out?

Testing and maintenance, and it is not an accident.

A template is a document about documents. Adding a testing section commits whoever downloads it to doing something, and a template written to be finished rather than used has no reason to carry one. So the section can disappear, or shrink to a line saying the plan will be reviewed annually.

The Cyber Centre is blunter than that. Its guidance says to Test, revisit, and revise your incident response plan annually to keep it effective, and separately to Develop exercises to test your plan and response (Canadian Centre for Cyber Security, Developing your incident response plan, ITSAP.40.003, 2026). NIST’s recommendation is framed for programs, not calendars: Review and update all cybersecurity plans periodically or when a need for significant improvements is identified (NIST Special Publication 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025).

Worth knowing that Canadian guidance is not unanimous. The Cyber Centre’s own baseline controls for small and medium organizations ask for a written plan and an up-to-date hard copy and never ask for it to be tested at all (Canadian Centre for Cyber Security, Baseline Cyber Security Controls for Small and Medium Organizations V1.2, 2020). If your plan came out of that document, the testing section was never going to be there.

The gap showed up in the numbers. In one large survey of security and IT professionals, published in 2020, 52 percent of those with a response plan said they had never reviewed it or had no set period for reviewing or testing it (IBM Security, Cyber Resilient Organization Report, 2020).

The evidence and record keeping section can go missing for a duller reason: it looks like a technical logging question. It is not. It is about the decision record, and under PIPEDA, the federal private-sector privacy law, it has a floor. Every breach of security safeguards has to be recorded and the record kept for 24 months, whether or not anyone had to be notified (Breach of Security Safeguards Regulations, SOR/2018-64, section 6, 2018). A plan that does not name who keeps that record is asking for it to be reconstructed from memory two years later.

How do you size it for a 50 to 300 person organization?

By cutting depth, never by cutting sections.

All ten sections belong in a plan for an organization of this size. What changes is how much sits under each. One person will hold three roles, and that is fine as long as the plan says so and names who covers when that person is unreachable. Severity gets three levels, not five. Playbooks get written for the two or three scenarios you would actually face, not for a catalogue.

Two things do not scale down. The contact sheet has to be current. And the legal and notification section has to be right, because the obligations do not shrink with headcount.

One practical note. Keep the plan and the contact sheet somewhere reachable when your own systems are not. The Cyber Centre’s baseline asks for an up-to-date hard copy, which sounds quaint until the day the file share is encrypted.

How do you prove the plan was tested?

Not with the plan. The document is evidence that you wrote something.

Testing produces its own record or it produces nothing. NIST’s guidance says to Prepare an after-action report that documents the incident itself, the response and recovery actions taken, and lessons learned (NIST Special Publication 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025), and the same shape works for an exercise. The Cyber Centre asks for the same thing in two parts: All facts about the incident should be documented, then a lessons learned document setting out how the plan will be adjusted (Canadian Centre for Cyber Security, Developing your incident response plan, ITSAP.40.003, 2026).

So the artifact is a dated report naming the scenario, the people in the room by role, the decisions they took and the findings, with an owner against each finding. That is a record an auditor or an underwriter can check, rather than an assertion.

The remaining question is who writes it. An internally-produced report is a real document and a useful one. It is an account of your own response, written by your own response, and its weight depends entirely on how much the reader trusts you. A record confirmed by somebody with no stake in the outcome does not have that problem. That is the difference the testing section of your plan should be designed to produce.

Write the plan this week. Put a date against the first exercise before you close the file, because the section that gets skipped is the only one that turns the document into evidence.