{"id":3403,"date":"2026-09-05T07:03:34","date_gmt":"2026-09-05T07:03:34","guid":{"rendered":"https:\/\/nordsterntech.com\/en\/incident-response-plan-template\/"},"modified":"2026-09-05T10:04:32","modified_gmt":"2026-09-05T10:04:32","slug":"incident-response-plan-template","status":"publish","type":"post","link":"https:\/\/nordsterntech.com\/en\/incident-response-plan-template\/","title":{"rendered":"Incident response plan template: what to write in each section"},"content":{"rendered":"<p class=\"ns-lead\">Most incident response plans are written for an auditor and read for the first time at 3 a.m., by someone who did not write them. That is the test this template is built to pass: not \u00abdoes it look complete\u00bb, but \u00abcan somebody who is frightened and half-awake do the right thing with it open on a second screen\u00bb.<\/p>\n<p>This incident response plan template gives you the complete section structure with guidance on what belongs in each part, a severity matrix you can adapt, a first-hour checklist, and an editable copy to download. It is aligned to the current NIST guidance and to what a PCI DSS assessor will test.<\/p>\n<div class=\"ns-tldr\">\n  <span class=\"ns-tldr-t\">In short<\/span><\/p>\n<ul>\n<li>Most templates online still teach the <strong>four-phase lifecycle NIST retired in April 2025<\/strong>. Check the date on anything you copy.<\/li>\n<li>If PCI DSS applies, Requirement <strong>12.10<\/strong> tells you exactly what the plan must contain \u2014 and the sub-requirements are where assessments actually fail.<\/li>\n<li>A plan without a <strong>severity matrix<\/strong> and <strong>named humans<\/strong> is a document, not a response capability.<\/li>\n<li>The parts auditors test hardest are the ones nobody rehearses: annual testing, training, and alert handling.<\/li>\n<\/ul>\n<\/div>\n<div class=\"ns-stats\">\n<div class=\"ns-stat\"><b>April 2025<\/b><span>NIST SP 800-61r3 replaced the four-phase lifecycle with the CSF 2.0 Functions<\/span><\/div>\n<div class=\"ns-stat\"><b>7<\/b><span>sub-requirements under PCI DSS 12.10, from plan content to finding PAN where it should not be<\/span><\/div>\n<div class=\"ns-stat\"><b>24\/7<\/b><span>availability PCI DSS demands of the people who respond, not just of the tooling<\/span><\/div>\n<\/div>\n<h2>Why most incident response plan templates are already out of date<\/h2>\n<p>If you search for an incident response plan template, most of what you will find teaches the four-phase lifecycle: preparation, detection and analysis, containment\/eradication\/recovery, and post-incident activity. That model came from NIST SP 800-61 Revision 2, and it was the industry&#8217;s shared vocabulary for over a decade.<\/p>\n<p>It was retired. In <strong>April 2025<\/strong>, NIST published <strong>SP 800-61 Revision 3<\/strong>, which reframes incident response as part of cybersecurity risk management and aligns it to the six Functions of the Cybersecurity Framework 2.0 \u2014 Govern, Identify, Protect, Detect, Respond and Recover \u2014 rather than to a sequence of phases.<\/p>\n<p>The practical difference is not cosmetic. The phase model implied that response starts when detection ends. The Function model says the things that decide whether your response works \u2014 governance, asset inventory, protective controls \u2014 belong to the plan even though they happen long before the incident. It also stops the pretence that containment, eradication and recovery happen in a tidy order; in a real ransomware event they overlap for days.<\/p>\n<figure class=\"ns-fig\">\n  <img decoding=\"async\" src=\"https:\/\/nordsterntech.com\/en\/wp-content\/uploads\/2026\/09\/fig-ir-modelo.jpg\" alt=\"Comparison between the retired four-phase NIST incident response lifecycle and the CSF 2.0 Functions used by SP 800-61r3\" loading=\"lazy\" \/><figcaption>What changed in April 2025. If your plan&#8217;s table of contents is the four phases, it is quoting a retired document.<\/figcaption><\/figure>\n<p>You do not have to rewrite a working plan tomorrow. But if you are building one now, build it on the current model \u2014 and if a template you found does not say which revision it follows, that tells you something about how carefully it was written.<\/p>\n<h2>What PCI DSS Requirement 12.10 demands<\/h2>\n<p>If cardholder data is in scope, your plan is not a matter of good practice. Requirement 12.10 is prescriptive, and each sub-requirement is tested separately:<\/p>\n<div class=\"tblwrap\">\n<table>\n<thead>\n<tr>\n<th>Requirement<\/th>\n<th>What it demands<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><b>12.10.1<\/b><\/td>\n<td>A documented plan covering roles, responsibilities, communication and contact strategies; containment and mitigation procedures for different incident types; business recovery and continuity; data backup processes; analysis of legal reporting requirements; coverage of all critical system components; and reference to the payment brands&#8217; own incident procedures.<\/td>\n<\/tr>\n<tr>\n<td><b>12.10.2<\/b><\/td>\n<td>The plan is reviewed, updated and <b>tested at least once every 12 months<\/b>.<\/td>\n<\/tr>\n<tr>\n<td><b>12.10.3<\/b><\/td>\n<td>Specific personnel are available <b>24\/7<\/b> to respond.<\/td>\n<\/tr>\n<tr>\n<td><b>12.10.4<\/b><\/td>\n<td>Responders are trained periodically, on their own responsibilities and on the monitoring tools they will use. The frequency is justified by a targeted risk analysis (12.10.4.1).<\/td>\n<\/tr>\n<tr>\n<td><b>12.10.5<\/b><\/td>\n<td>The plan covers monitoring and response to alerts from security systems: network controls, IDS\/IPS, file-integrity monitoring, anti-malware, change-detection on payment pages, wireless detection.<\/td>\n<\/tr>\n<tr>\n<td><b>12.10.6<\/b><\/td>\n<td>The plan is modified and evolved from lessons learned and from environment changes.<\/td>\n<\/tr>\n<tr>\n<td><b>12.10.7<\/b><\/td>\n<td>Procedures for when <b>PAN is found where it should not be<\/b>: retrieve and delete it securely, check for sensitive authentication data, determine how it got there and fix the leak.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<div class=\"ns-note\">\n<p><strong>The sub-requirement that catches people is 12.10.7.<\/strong> Most plans describe what to do when an attacker gets in, and say nothing about what to do when a developer finds a CSV of card numbers in a log bucket. That second scenario is far more common, and it is explicitly required.<\/p>\n<\/div>\n<h2>The template, section by section<\/h2>\n<p>Use this as the table of contents. Under each section is what actually belongs there \u2014 the parts people leave vague are the parts that fail on the night.<\/p>\n<div class=\"ns-doc\">\n<div class=\"ns-doc-head\">\n<div>\n      <span class=\"ns-doc-kicker\">Template<\/span><\/p>\n<h3>Incident response plan \u2014 structure<\/h3>\n<\/p><\/div>\n<p>    <button class=\"ns-doc-copy\" type=\"button\" data-copied=\"Copied\">Copy structure<\/button>\n  <\/div>\n<ol class=\"ns-doc-list\">\n<li><b>Document control<\/b><span>Owner, version, approval date and next review date. An unapproved plan is a draft, and a draft is what an assessor will call it.<\/span><\/li>\n<li><b>Purpose and scope<\/b><span>Which systems, which data, which locations and which subsidiaries. If PCI applies, name the cardholder data environment explicitly. Vague scope is how plans end up not covering the system that actually broke.<\/span><\/li>\n<li><b>Definitions<\/b><span>What is an event, what is an incident, what is a breach. Write the threshold that promotes one into the other, because that decision will be argued about at 3 a.m.<\/span><\/li>\n<li><b>Roles and responsibilities<\/b><span>Named people, not job titles alone: incident lead, technical lead, communications, legal, executive sponsor, and the deputy for each. Add the external ones \u2014 acquirer, payment brands, forensic investigator, insurer, outside counsel, your QSA.<\/span><\/li>\n<li><b>Severity classification<\/b><span>The matrix below. Each level needs a definition, an example, an acknowledgement time and who gets woken up.<\/span><\/li>\n<li><b>Detection and reporting<\/b><span>Every channel an incident can arrive through: monitoring alerts, the helpdesk, an employee, a customer, a supplier, a researcher, law enforcement. One phone number and one mailbox that work at 3 a.m., and what information to capture.<\/span><\/li>\n<li><b>Response procedures by incident type<\/b><span>Short playbooks, not prose: ransomware, cardholder data exposure, account compromise, supplier breach, insider misuse, denial of service, and PAN discovered where it should not be. Each with first actions, who decides, and what must not be done.<\/span><\/li>\n<li><b>Containment and evidence<\/b><span>Who authorises isolating or shutting down a production system, and the rule that evidence is preserved before anything is wiped. This single sentence saves the investigation.<\/span><\/li>\n<li><b>Communications<\/b><span>Internal, customers, regulators, acquirer and payment brands, law enforcement, insurer. Include holding statements written in advance: nobody drafts good copy during a crisis.<\/span><\/li>\n<li><b>Legal and regulatory obligations<\/b><span>Your applicable reporting duties with their deadlines, listed by jurisdiction. This is a legal question, not an IT one \u2014 get it answered before you need it.<\/span><\/li>\n<li><b>Recovery and closure<\/b><span>The criteria for declaring the incident closed, who signs it off, and how you verify the environment is clean before restoring.<\/span><\/li>\n<li><b>Post-incident review<\/b><span>Timeline, root cause, what worked, what did not, and actions with an owner and a date. Without owners and dates it is a feelings exercise.<\/span><\/li>\n<li><b>Testing and maintenance<\/b><span>The annual test at minimum, who takes part, how findings feed back into the plan, and the training programme with its justified frequency.<\/span><\/li>\n<li><b>Appendices<\/b><span>Contact list, critical systems inventory, decision log template, communication templates, and a printed copy \u2014 because your plan may live on the network you just isolated.<\/span><\/li>\n<\/ol>\n<\/div>\n<div class=\"ns-pull\">\n<p>Print it. Your plan may live on the network you just disconnected.<\/p>\n<\/div>\n<h2>Severity: the table that stops the argument<\/h2>\n<p>The most valuable page of any incident response plan is the one that tells a tired engineer whether to wake the CTO. These levels are an example to adapt, not a standard \u2014 but adapt something, and agree it before you need it.<\/p>\n<div class=\"tblwrap\">\n<table>\n<thead>\n<tr>\n<th>Level<\/th>\n<th>Example<\/th>\n<th>Acknowledge<\/th>\n<th>Who is told<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><b>SEV1<\/b> Critical<\/td>\n<td>Confirmed compromise of cardholder data, ransomware encrypting production, active exfiltration<\/td>\n<td>15 minutes, any hour<\/td>\n<td>Incident lead, executive sponsor, legal \u2014 immediately<\/td>\n<\/tr>\n<tr>\n<td><b>SEV2<\/b> High<\/td>\n<td>Confirmed intrusion with no data impact yet, malware on an in-scope server<\/td>\n<td>30 minutes<\/td>\n<td>Incident lead; executive sponsor within 4 hours<\/td>\n<\/tr>\n<tr>\n<td><b>SEV3<\/b> Medium<\/td>\n<td>Endpoint malware contained by EDR, phishing with credentials entered<\/td>\n<td>4 working hours<\/td>\n<td>Security team; escalate if scope grows<\/td>\n<\/tr>\n<tr>\n<td><b>SEV4<\/b> Low<\/td>\n<td>Policy violation, isolated failed login patterns, unverified report<\/td>\n<td>Next working day<\/td>\n<td>Security team, logged only<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2>The first hour<\/h2>\n<p>The plan&#8217;s opening page should be this list, in this order. Everything else is reference material.<\/p>\n<ol class=\"ns-steps\">\n<li><b class=\"ns-n\">1<\/b><strong>Write down the time.<\/strong> Start a decision log with a timestamp on every entry. It becomes your evidence, your timeline and your post-incident review.<\/li>\n<li><b class=\"ns-n\">2<\/b><strong>Assign the incident lead.<\/strong> One person, by name, who is not also doing the technical work.<\/li>\n<li><b class=\"ns-n\">3<\/b><strong>Classify the severity.<\/strong> Use the matrix, and re-classify later if it grows. Under-calling it is the more common error.<\/li>\n<li><b class=\"ns-n\">4<\/b><strong>Preserve evidence before touching anything.<\/strong> Memory captures and log copies first. Rebuilding the box destroys the answer to \u00abhow did they get in\u00bb.<\/li>\n<li><b class=\"ns-n\">5<\/b><strong>Contain what you can without destroying evidence.<\/strong> Isolate at the network, disable accounts, revoke sessions and tokens.<\/li>\n<li><b class=\"ns-n\">6<\/b><strong>Open the communication channel<\/strong> agreed in the plan \u2014 and assume the usual one may be compromised.<\/li>\n<li><b class=\"ns-n\">7<\/b><strong>Notify the people the plan says to notify<\/strong>, on the clock the plan gives you. If cardholder data may be involved, that includes your acquirer.<\/li>\n<li><b class=\"ns-n\">8<\/b><strong>Decide whether you need external help<\/strong> \u2014 forensics, legal, insurer \u2014 early. Making that call at hour twenty is what turns an incident into a bad one.<\/li>\n<\/ol>\n<h2>What an assessor actually tests<\/h2>\n<p>Writing the plan is the easy half. In an assessment, the questions land on the parts that require the plan to have been alive for a year:<\/p>\n<ul>\n<li><strong>Evidence of the annual test<\/strong> \u2014 attendance, scenario, findings, and what changed in the plan afterwards. A tabletop with no output does not count.<\/li>\n<li><strong>Evidence of training<\/strong>, per responder, matched to their role and to the tools they operate \u2014 plus the risk analysis that justifies the frequency.<\/li>\n<li><strong>Evidence that alerts get handled<\/strong>: tickets, timestamps, and what happened to the alerts that fired at 2 a.m. on a Sunday.<\/li>\n<li><strong>Evidence the plan evolved<\/strong>: a version history that shows lessons learned going back in.<\/li>\n<li><strong>The 24\/7 rota<\/strong>, with names and contact details that are current.<\/li>\n<\/ul>\n<h2>Five ways these plans fail<\/h2>\n<ul>\n<li><strong>Job titles instead of people.<\/strong> \u00abThe Security Manager will\u2026\u00bb is useless when the Security Manager left in March.<\/li>\n<li><strong>No severity matrix<\/strong>, so every incident is either ignored or escalated to the board.<\/li>\n<li><strong>Recovery steps that assume the network works.<\/strong> Store the plan, the contacts and the backups&#8217; restore procedure somewhere reachable when the domain is down.<\/li>\n<li><strong>Legal obligations left as \u00abconsult legal\u00bb.<\/strong> The deadlines exist whether or not you looked them up in advance.<\/li>\n<li><strong>Written once.<\/strong> A plan that has never produced a lesson learned has never been used, and it will show the first time it is.<\/li>\n<\/ul>\n<h2>Take the template<\/h2>\n<p>The editable version follows this exact structure, with the guidance notes in place so whoever fills it in knows what each section is for.<\/p>\n<p class=\"ns-cta-line\"><a class=\"ns-dl\" href=\"https:\/\/nordsterntech.com\/en\/wp-content\/uploads\/2026\/09\/incident-response-plan-template-nordstern.docx\" download><span>Download the template<\/span><span class=\"ns-dl-meta\">DOCX \u00b7 13 sections + first-hour annex \u00b7 editable \u00b7 no form to fill in<\/span><\/a><\/p>\n<p>Two honest caveats. A template gets you a structure, not a capability: the value appears when you name real people, agree the severity levels with the business, and test it. And if PCI DSS is in scope, the plan has to match the environment your assessor will look at \u2014 which is the part we usually end up doing alongside the <a href=\"https:\/\/nordsterntech.com\/en\/pci-dss\/\">PCI DSS work<\/a> rather than as a separate exercise.<\/p>\n<p>Filling this in is where most teams discover their real gap is detection: a response plan cannot start before somebody notices. If that is your situation, the conversation is about <a href=\"https:\/\/nordsterntech.com\/en\/soc\/\">monitoring<\/a> and <a href=\"https:\/\/nordsterntech.com\/en\/dfir\/\">incident response readiness<\/a> together, and it is one we have a lot. <a href=\"https:\/\/nordsterntech.com\/en\/contact\/\">Talk to our DFIR team<\/a>.<\/p>\n<hr \/>\n<h3>Sources<\/h3>\n<ul>\n<li>NIST SP 800-61 Revision 3 (April 2025), <em>Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile<\/em> \u2014 replaces the four-phase lifecycle of Revision 2.<\/li>\n<li>NIST Cybersecurity Framework 2.0 \u2014 the six Functions: Govern, Identify, Protect, Detect, Respond, Recover.<\/li>\n<li>PCI DSS v4.0.1, Requirement 12.10 and its sub-requirements 12.10.1 to 12.10.7.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Most incident response plans are written for an auditor and read for the&hellip;<\/p>\n","protected":false},"author":2,"featured_media":3400,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31],"tags":[],"class_list":["post-3403","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-soc-dfir"],"_links":{"self":[{"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/posts\/3403","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/comments?post=3403"}],"version-history":[{"count":3,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/posts\/3403\/revisions"}],"predecessor-version":[{"id":3406,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/posts\/3403\/revisions\/3406"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/media\/3400"}],"wp:attachment":[{"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/media?parent=3403"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/categories?post=3403"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nordsterntech.com\/en\/wp-json\/wp\/v2\/tags?post=3403"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}