Before You Write: Planning the Plan

Templates Are Free; Working Plans Are Rare

Free incident response plan templates are easy to find. The US Environmental Protection Agency publishes one for water utilities, and the Australian Signals Directorate publishes guidance of its own. Yet in the SANS Institute's 2025 survey of industrial organizations, only 57 percent had a dedicated OT incident response plan. Templates were never the hard part. A template gives you the shape of the output: the headings, the blank tables, the order of the chapters. It never gives you the project that fills them in, and the steps every template on the market skips are exactly the ones that decide whether anyone uses the plan: getting a sponsor, forming a team, interviewing the people who run the process, and getting the plan approved by people whose signature means something in the control room. That is why this book treats an incident response plan as the output of a small project, with a sponsor, a team, a scope and a series of gates. A gate is a checkpoint with a named approver. The rest of this chapter builds that project, and the four documents it produces before anyone drafts a response procedure.

Nine Ways a Plan Fails Before Anyone Writes It

An OT plan can fail before anyone types the first heading, and the failures are predictable enough to name. The first starts with a download. Someone grabs the corporate IT plan, or a generic template, and starts filling in blanks. The headings may look fine; what hurts is who wrote the original and who was never asked. Operations, the people who actually run the process, never shaped it. The second is the one-author plan. Often the security lead takes it on because it landed on their desk, and the writing may be excellent, but decision rights get written down by someone who does not hold them. Operations, engineering and management never agreed to those rights, so they do not feel bound by them. The third is the plan with no sponsor. The author approves it, or the author's own manager does. On paper it is approved; in the control room it carries no weight, because nobody with authority over operations ever signed it.

The fourth failure is scope fog. The plan tries to be the business continuity plan, the emergency response plan and the security program all at once, or it never says what is out of scope, so readers cannot tell where this plan stops and another takes over. The fifth is shelfware: an 80-page document on a shared drive with nothing a tired operator can use at two in the morning. The sixth is detail at the wrong level, where device-level steps sit inside the policy-level plan and every network change forces a new approval. The seventh leaves the hardest questions to the incident itself: who can shut down, and whether the company can pay a ransom. The eighth is the consultant drop, where an outside firm writes the plan, leaves, and nobody owns its upkeep. The ninth is a plan written only to pass an audit clause. Notice that none of these nine comes down to writing skill. Each one is stopped by a step in the project, and the project has nine gates.

The Nine Gates

A plan project runs through nine gates: charter, discovery, outline, chapter drafts, walk-through, two review rounds, approval, and finally publish and hand-off. Each gate produces something you can hold, such as a signed charter, a findings log or a gap list, and each gate has a named approver. That approver is the point. Nobody moves to the next gate until the right person has said yes. Pin the nine failures onto the gates and the logic of the project becomes visible. The charter gate stops the missing sponsor, the lone author and the consultant drop, because it names a sponsor, a team and a custodian who keeps the plan current. Discovery stops the borrowed template, because operations is interviewed first, before a single chapter is drafted. The outline gate stops scope fog and deferred decisions: the core team agrees the table of contents and a scope statement before drafting begins, and it opens a decisions-needed log that lists each hard question with an owner and a deadline. Chapter drafts stop wrong-level detail by keeping procedures out of the core plan. The walk-through stops the compliance-only plan by testing the document against real scenarios. Approval collects the four signatures that give the plan authority, and publishing stops shelfware by putting controlled copies in people's hands and starting the training.

What the Project Costs, and Why It Is Worth It

A realistic planning example, offered as this book's own estimate for one mid-size site rather than as a benchmark, looks like this. Charter to publish takes about four to six months; rewriting an existing plan takes about two to three. The plan lead spends roughly a third to half of their time on it. Core team members give two to four hours a week, contributors four to sixteen hours in total, and the sponsor about four to six hours over the whole project. The biggest schedule risks are rarely technical: turnaround season, getting time with the night shift, legal review queues and slow vendor replies are what slip dates. That investment buys more than a better document. Many of the rulebooks covered later in this chapter ask who holds each role and who approved the plan, and a template cannot answer those questions. Only the project can, because named roles and signatures come out of its gates. Count the project as compliance work, not overhead: its gates produce the evidence those rules ask for.

Before you draft a single response procedure, the project builds four things. The first is a charter with a roadmap, signed by a sponsor. The second is a planning team roster with a drafting responsibility chart, so everyone knows who writes and who reviews each part. The third is a scope statement that says what is in and what is out. The fourth is a requirements register of the rules and contracts the plan must satisfy. Together these four become the first chapter of your plan, Governance and Scope. The rest of this chapter takes them one at a time.

Policy, Charter and Plan

Ask who at your site may tell the control room to shut down for a cyber reason, and where that is written. Most people can name a person; few can point to the page. In September 2024 the water treatment facility in Arkansas City, Kansas, switched to manual operations after a cyber incident, and the city manager called it a precaution. Someone had to hold the authority to make that call. Three documents get confused all the time, and keeping them apart is how you find where such authority should live. The policy is standing authority: it states management commitment, sets the scope and says who may disconnect or shut down. The charter is a time-boxed mandate for the project that writes the plan, and it lives only as long as that project. The plan is the deliverable itself. In shop terms, the policy is the licence, the charter is the work order, and the plan is the finished job.

Read your policy first. NIST Special Publication 800-61, revision 3, published in 2025, lists what an incident response policy covers. It opens with a statement of management commitment, then names roles, responsibilities and authorities, including which roles may disconnect or shut down technology assets. The Canadian Centre for Cyber Security's short guide ITSAP.40.003 makes the same two points: management commitment, and senior management approval of the policy. If your policy says nothing about shutdown authority, fixing that becomes the charter's first open decision. The asset-owner part of ISA/IEC 62443, part 2-1 in its 2024 edition, puts the principle in one line: "Organizational commitment from top to bottom is essential for IACS SP success," where IACS means industrial automation and control systems and SP means security program. The same clause allows the program to be phased, starting with the highest risks, and that supports a practical choice for your plan: get a minimum viable plan approved first, and add playbooks later.

The Sponsor and the Four Signatures

The sponsor owns the outcome of the plan project. They sign the charter, release people's time, settle disputes between departments and approve the finished plan. For a site plan that is usually the plant or site manager; for an enterprise plan it is an executive such as the chief operating officer, a vice president of operations or the chief information security officer. The test is whether this person can bind operations, not only IT. A chief information security officer passes only if their authority reaches the control room. If it does not, keep looking. Several regulators expect approval above the author, which is one more reason the choice matters. Under NIS2 Article 20 in the EU, management bodies approve the cybersecurity risk-management measures and can be held liable. Under NERC CIP-003 in the US electric sector, the CIP Senior Manager approves the cyber security policies, incident response included. Under Australia's SOCI Act, the board, if there is one, approves the annual risk management program report. Canada's Critical Cyber Systems Protection Act received Royal Assent in June 2026 but was not in force in October 2026; check Justice Laws and the Canada Gazette for its status. Your manager's approval is rarely enough.

Every plan project needs four signatures. The sponsor signs the charter and approves the plan. The plan owner is accountable for what the plan says. The operations authority agrees that the plan's decision rights bind the control room. The enterprise incident response owner agrees how the OT plan nests inside the company plan. Reviewers can be a wide group, including labour representatives and vendors, but approval stays with these four. At a small site one person may hold three of these roles; name all four anyway. Separate the plan owner from the plan custodian, too. The owner is accountable for the plan being right; the custodian keeps it current, handling edits, distribution and review dates. Naming the custodian in the charter cures the consultant drop, and ISA/IEC 62443-2-1 backs it up by requiring the asset owner to keep the response process current. Upkeep belongs in the charter from day one.

Sources disagree on who should own an OT plan. Some industry writing hands it to IT security; some makes the facility plan the parent and folds OT into it; NIST Special Publication 800-82, revision 3, gives the OT security program mandate to a senior security leader, with the chief information security officer as one example. You can end the argument by separating two things. Accountability for the plan sits with the sponsor and the plan owner. Authority within the plan stays with operations, which keeps the final say on process actions.

A Charter the Sponsor Will Read

A charter only works if the sponsor reads it, so keep it to one page, two at most. The fields are short on purpose. Every role carries a name and a backup. Every objective carries a measure and a date. Scope and team point to their own worksheets instead of repeating them, and page two holds the roadmap: the nine gates, each with a planned date and an approver. The sponsor signs both pages together, so they commit to dates, not just intentions. Objectives deserve particular care. A weak objective sounds like "improve incident readiness," and nobody can say when that is done. A strong objective carries a measure and a date: the plan is approved with all four signatures by a set date; every lead operator is briefed by the following month, proven by a sign-in sheet; the contact register is tested by phone, every number dialled and logged. Measurable objectives let the sponsor say whether the project is finished, and they tell you when to stop.

One box on the charter matters more than the rest. It lists the decisions only the sponsor can make, and four belong in it from the start: who may order a shutdown or isolation for a cyber reason; your stance on ransom or extortion; spend limits for the incident lead during an incident; and who speaks publicly. The charter does not answer these. It lists each one with its options and a decide-by date, and that date turns an open question into a commitment. Getting the sponsor's signature takes a short meeting, not a long presentation; plan on about twenty minutes. Bring three things: the decisions box, so the sponsor sees what only they can settle; the time you are asking from their people; and the one-line regulatory hook for your jurisdiction. Section 3.2.4 of NIST SP 800-82 revision 3 covers presenting the OT security case to leadership and is worth reading before you go. Then ask for a decision, not support. Support is easy to give. A signature commits them.

The Planning Team: Three Rings

The plan written by one person fails; so does the opposite. Picture a drafting committee of twenty that meets eight times in three months and produces one thing, a table of contents everyone has argued over. The plan operators actually use comes from somewhere in between. Start by separating two teams that published lists often blur. The planning team writes the plan, and it includes people who will never respond to anything, such as legal, HR and procurement. The response team carries the plan out, and you build it later, in the organization and command chapter. NIST 800-82, NIST 800-61 and the Canadian Centre for Cyber Security each list different people because they are answering different questions. The question here is narrower: who must help write this plan?

Think of the planning team as three rings. The inner ring is the core writing team, four to six people who meet weekly and draft the chapters. It has five seats: the plan owner and lead writer, often the OT security lead; an operations representative such as a shift supervisor or the operations superintendent; a control or automation engineer; the IT incident response lead from IT security or the security operations center; and a process safety or environmental, health and safety representative. Each seat owns the decisions in its own domain. Operations owns what happens to the process; safety owns what must never be traded away. The middle ring holds the contributors, consulted chapter by chapter for facts and for review of their own sections. Some work inside the fence. The plant manager shapes decision rights in the organization and command chapter; maintenance and instrument technicians supply facts for the inputs and recovery chapters; the site emergency response coordinator makes sure the plan hands off cleanly to the emergency plan; the business continuity coordinator checks the recovery chapter against existing continuity plans; physical security covers access to control rooms and cabinets. If you cannot name a chapter for someone, rethink their seat.

Other contributors sit outside the fence, in head office or another company. Legal counsel shapes the notification and legal sections of the response procedures chapter. Corporate communications shapes who speaks, and when. HR covers call-out rules, fatigue and insider cases. Procurement brings vendor contract clauses and emergency purchasing. The equipment maker, the system integrator and any managed security provider supply technical facts, and the insurer or broker tells you which notification conditions your policy sets. None of them writes chapters; all of them can sink one. Three groups go missing when IT builds the team. The first is the night shift: a plan written on day shift has never met the person reading it at two in the morning. The second is labour: a collective agreement can limit mandatory training hours and may set rules on call-out, so check yours. The third is the insurer, whose policy can set notice conditions the plan must respect. NIST SP 800-82 revision 3, section 6.2.4.5, names organized labor, vendors, legal and safety as stakeholders who give input. The outer ring holds reviewers, who read and challenge the draft, and approvers, who sign it. The rule behind the rings fits in one line: consult widely, write with a few, approve with the people who can bind the plant.

That NIST section adds a line that is easy to misread: these stakeholders should also "review and approve the plan." Read literally, your union and your integrator would sign your plan. In practice formal sign-off by a union or a vendor is unusual and may be inappropriate. A cleaner reading splits the two verbs. Review goes to everyone in the outer ring; approval stays with the accountable executives. Say so at your kickoff, so nobody expects a signature line they will not get. The vendor deserves the same clarity. Your integrator probably knows the control system better than anyone on site, which makes it tempting to hand them the pen. Do not hand them the decisions. ISA/IEC 62443-2-1 makes two points that settle this: a role is not the same as an organization, and the asset owner stays responsible even when service providers do the work. So the vendor reviews every chapter that gives it a task, and it may draft, but it never owns a chapter.

A Drafting Chart With One Owner per Chapter

A RACI chart assigns four letters. The rows are your plan chapters; the columns are the roles on your roster. R means responsible: this person drafts. A means accountable: this person owns the chapter's decisions and its final text. C means consulted: they supply facts or review. I means informed: they hear when it is approved. Several people can be R; only one can be A. This chart governs drafting only. Who decides what during an incident is a different chart, built in the organization and command chapter. Drafting charts fail in predictable ways. The letters are never defined, so everyone reads A differently. The chart is built by one person without the people named in it. Or it is approved, filed and ignored. OT adds a fourth failure: two people claim A on the chapter that covers shutting down the process. Do not treat that as a formatting glitch. It is a disagreement about authority, and only the sponsor can settle it, so log it as a sponsor decision with a date.

Plan chapter	Accountable (A)	Responsible (R) and consulted (C)	Night-shift read
Ch 2 Planning Inputs	Controls technician (plan owner)	Operations supervisor drafts; integrator consulted	Yes
Ch 5 Response Procedures	Operations supervisor	Controls technician drafts; city attorney drafts the notification and legal sections under the operations supervisor	Yes
Annex AC Regulatory Compliance Annex	City attorney	Controls technician drafts	No (accepted by the sponsor)
Ch 8 Plan Maintenance, Training and Compliance Annex	Controls technician	(drafted by the plan owner)	No (due at the first annual review)

The Cedar Ridge rows above, an illustrative extract, show the pattern. The response procedures chapter is owned by the operations supervisor, not the security lead, because operators must be able to follow those steps, so operations owns them. The city attorney drafts the notification and legal sections under that owner and owns the compliance annex. The integrator is consulted on planning inputs and never owns a row. Each row ends with a count of A letters and a night-shift check, a column that costs almost nothing and catches a plan written only for the day shift. For every chapter, answer one question: has a night-shift person reviewed it, yes or no? A no is allowed, but it needs a reason the sponsor accepts. A list of names and phone numbers may not need a night read; a response procedure always does. If the people on nights have never read the steps, the steps were written for someone else. Finally, a roster of names is a wish list until each line carries the hours that person commits and a backup. Contributors usually need four to sixteen hours in total, enough for one interview and a review of the chapters they feed, and the sponsor signs off that time in the charter. Without that signature, a contributor's manager can pull them back at any point. Small sites still need all three rings; some seats are simply filled by the same person, or from outside the fence. At Cedar Ridge the superintendent sits as sponsor, operations authority and the safety seat, because the plant has no separate safety role, and the single controls technician is plan owner and lead writer. Write every seat on the roster anyway, even when one name repeats.

What the Rulebooks Require the Plan to Say

In 2025 the US Coast Guard put a definition of an incident response plan into federal regulation: a set of predetermined and documented procedures to respond to a cyber incident that "pre-identifies key roles, responsibilities, and decision-makers." The last word matters. A plan can list roles and stop there. Before looking at individual regimes, two boundaries keep this part of the work manageable. It stays on two questions, what your plan must say and who must approve it; reporting deadlines are a separate job that belongs in the plan's notification matrix, covered in the response procedures chapter. And it is a map of the rules, not legal advice. Rules change and national laws differ, so check the current text that applies to your site before relying on any line here.

Lay the rulebooks side by side and a pattern appears. Eight elements show up in almost every one: a written plan, named roles, response procedures, communications and contacts, a link to recovery and continuity, testing, lessons learned, and a trigger that forces updates. These eight become the core chapters of your plan. Everything else is a regime-specific insert, and inserts are where sites get caught out. The three most prescriptive regimes for plan content are all American. In the electric sector, NERC CIP-008-6, the enforceable version today, spells out what the plan contains in its first requirement: processes to identify, classify and respond to cyber security incidents; criteria to evaluate and define attempts to compromise; the roles and responsibilities of response groups or individuals; and incident handling procedures. Attempts count, so your plan must say what an attempt looks like at your site. For pipelines, TSA Security Directive Pipeline-2021-02G lists measures rather than topics: prompt containment of an infected device, segregation of infected networks and devices, integrity of backed-up data, and an established capability and governance for isolating IT from OT when operations could be disrupted. Then comes the part that is easy to miss. For each measure, the plan must identify who is responsible, by position. Having the ability to isolate is not enough; the plan must say who decides.

Maritime facilities and vessels fall under the Coast Guard rule, 33 CFR part 101, subpart F, in force since July 2025. The response plan is one of the measures a wider Cybersecurity Plan must describe, and that plan follows a set list of sections, including communications and cyber incident reporting procedures. The owner must ensure the development, approval and execution of the response plan; the Cybersecurity Officer makes sure it is executed and exercised. Two named positions, two different duties, both written into the regulation. TSA also adds an insert no other regime here has: the plan must preserve volatile memory by collecting a forensic memory image before powering off or moving a device, and affected equipment must be isolated, secured and clearly labelled. That works on a server. On a PLC or an HMI a memory image is often not possible, so an OT plan cannot simply copy the line. It must say what is done instead, and who decides, and that question goes into your decisions-needed log. Water is different again. Under America's Water Infrastructure Act of 2018, community water systems serving more than 3,300 people keep an Emergency Response Plan that must include resilience strategies, cybersecurity included, and procedures for responding to a malevolent act. Cyber response lives inside another plan. The system self-certifies to EPA that the plan is done, and EPA does not review it. EPA offers water and wastewater systems a free cyber incident response plan template to add to that plan; the link is in Appendix B. Beyond water, your plan may need to trace back to a plan you did not write.

Status is where outdated sources trip people up. As of October 2026, NERC CIP-008-6 stays enforceable until CIP-008-7.1 takes over in July 2028 with virtualization changes, and a separate revision of the reporting threshold is still in the standards process. The TSA pipeline directive in force runs to May 2027, and its text is public. CFATS, the old chemical-security program, lapsed in 2023 with no reauthorization found; chemical sites can still fall under OSHA process safety and EPA risk management emergency planning. The CIRCIA final rule had not been published by mid-October 2026, so it holds a placeholder row in your register.

European law takes the opposite approach: it sets outcomes, not checklists. NIS2 Article 21 requires measures for incident handling, business continuity such as backup management and disaster recovery, crisis management, and secured emergency communication systems where appropriate, all resting on an all-hazards approach. Yet NIS2 lists no plan contents at all. National laws fill that gap, and transposition is not complete in every member state, so check the national law in each country where you operate. Two more EU instruments add specific pieces. The Critical Entities Resilience Directive, Article 13, requires a resilience plan or equivalent documents and a liaison officer as the point of contact with the authorities; that role belongs in your plan. For high-impact and critical-impact electricity entities, the Network Code on Cybersecurity requires cyber-attack management procedures that include roles and responsibilities, tasks, and reactions based on how the attack evolves, which asks for decisions tied to what responders observe. The most detailed EU list is not aimed at operators at all. Implementing Regulation 2024/2690 lists what an incident handling policy and a continuity plan must contain, including categorisation, escalation communications, contact lists, conditions to activate and deactivate the plan, order of recovery, and restoring from temporary measures. It binds digital providers such as cloud, data centre and managed security service providers, not energy or water operators. Use it two ways: as a benchmark for your own plan, and as a contract lever, because your security provider may be bound by it.

In Canada, the Critical Cyber Systems Protection Act was not in force in October 2026 and no operators were designated; once it applies, a designated operator's cyber security program must include steps to minimise the impact of incidents. Sector rules already apply. Interprovincial and international pipelines under the Canada Energy Regulator need a security management program that meets CSA Z246.1 and must submit an emergency procedures manual to the Regulator; linking that manual to your plan is good practice, not a legal requirement. Nuclear power plant licensees run a cyber security program under CSA N290.7 with an incident response process, and their quarterly report to the Canadian Nuclear Safety Commission covers updates to it. For electricity, NERC CIP standards are adopted province by province and the versions vary, so never write that CIP-008 applies in Canada as a blanket statement. Australia separates two documents people often merge. Under the SOCI Act, Part 2A, responsible entities keep a critical infrastructure risk management program, which is not an incident response plan; your plan is the evidence that you can mitigate the relevant impact. Part 2C goes further, but only for Systems of National Significance once the Secretary gives notice: those entities must have a written incident response plan, review it regularly, keep it up to date and copy it to the Secretary after adoption and after each variation. The Cyber and Infrastructure Security Centre's guidance for those systems sets eight criteria, IR.1 to IR.8, covering alignment with the risk program and likely scenarios, detection and first assessment, investigation and remediation, decision and escalation points, communications, roles, and post-incident review. Even where it does not bind you, it makes a strong self-check for any plan.

Under all four jurisdictions sit the standards. ISA/IEC 62443-2-1, 2024 edition, has a requirement that is easy to skip: after a detected compromise, the control system must go "to a predetermined state if normal operation cannot be maintained." Your plan needs those states written down. NIST SP 800-61 revision 3 and SP 800-82 revision 3 are guidance, not law. Retire outdated copies: SP 800-61 revision 2, the 2010 edition of 62443-2-1, and the first CISA performance goals, now replaced by CPG 2.0.

Regime	Who approves or receives what
NIS2	The management body approves the Article 21 measures.
NERC CIP-003	The CIP Senior Manager approves the policies.
USCG 33 CFR 101 subpart F	The owner ensures the response plan is approved; the Coast Guard approves the Cybersecurity Plan.
TSA SD Pipeline-2021-02G	TSA approves the Implementation Plan, not the response plan itself.
EPA / AWIA	The water system self-certifies to EPA.
SOCI Part 2A / Part 2C	The board approves the annual program report; a System of National Significance copies its plan to the Secretary.
CCSPA (not in force)	The cyber security program goes to the regulator once the operator's class is designated.

Approval is where the rulebooks differ most, and the table above lines them up; map each onto the four signatures in your charter. Regulators also expect overlap, and several say so. The CER Directive accepts documents drawn up under other law. The Coast Guard lets the Cybersecurity Plan sit inside, or be annexed to, the Facility Security Plan. AWIA puts cyber response inside the Emergency Response Plan. The EU electricity network code accepts NIS2 crisis measures that meet its terms. So write one plan, in plant language that operators can use, and keep the regulatory mapping in a separate compliance annex, so that a rule change touches the annex and not the procedures. Laws are not your only rulebooks, either. Customer contracts can carry notification clauses. Many cyber insurance policies require prompt notice, and some require the insurer's consent before you use responders outside their panel. Vendor service agreements set what your integrator will do and how fast, and your managed security provider's scope says what they watch and what they do not. Each of these shapes what your plan must say, and each goes into the requirements register beside the laws.

Drawing the Boundary

Responders need scope first, yet a plan can fail by never saying what is out. A scope statement says what the plan covers and what it does not, and then adds the part that is easy to skip: every exclusion names where that thing is covered instead. NIST SP 800-61 revision 3 describes the scope of a response policy as "to whom and what it applies and under what circumstances," and those questions work for a plan too: who it binds, which systems, and which events. A precise model comes from engineering rather than incident response. Idaho National Laboratory's consequence-driven, cyber-informed engineering method starts its first phase with an agreed objective, scope and boundary conditions, combined into one sentence that every party agrees before analysis begins. This book adapts that idea; it is an adaptation, not the method itself. Agree the boundary first, and later arguments get shorter.

Before any boundary, decide what kind of document this is. You have three options. An enterprise plan with a site OT annex is the usual starting point. A standalone site OT plan references the enterprise plan. A combined IT and OT site plan suits a small site with one team. Some regimes push you toward a distinct document: the Coast Guard puts the response plan inside the Cybersecurity Plan, and AWIA puts cyber response inside the water system's Emergency Response Plan. Treat the annex as the usual starting point; nothing requires it. Then draw five boundaries. The organizational boundary answers "to whom": the organization the plan binds and the outside functions it draws on, from plant staff on every shift to the head office or city functions, such as legal, communications, IT, finance and the emergency manager, that hold pieces of the response. The physical boundary lists sites, process units, substations, remote stations and pump stations. Multi-site companies hit a trap here: their most critical assets are often shared services, such as central OT monitoring, remote access, identity and enterprise backup, which sit outside any one site. The site plan must still say who owns the response when those services are lost, or every site assumes someone else does.

The system boundary names the Purdue levels and zones in scope, then decides the awkward systems one by one. The safety instrumented system is in scope for detection and notification, while engineering changes to it stay with the safety lifecycle under IEC 61511. Building management, fire and gas, physical access control, vendor-owned equipment and cloud-connected OT each need an explicit in or out, because silence is how a fire alarm controller becomes nobody's problem. The incident boundary sets which events start this plan. Three kinds belong inside: cyber incidents that affect OT; IT incidents that threaten OT, including a precautionary shutdown or isolation; and suspected cyber causes of process upsets. ISA/IEC 62443-2-1 supports the last one, noting that a facility event evaluation can find a security root cause. Defining and classifying incidents is a separate job, done in the definitions chapter; here you only set the edge. The party boundary covers outsiders with access to your systems or duties in a response: the equipment maker, the integrator, the managed security provider, the telecoms carrier, a cloud historian provider. The test is strict. In scope means named in the plan with a duty. A vendor that appears only in a contact list is not really in scope.

Exclusion	Where it is covered	Owner
Physical emergencies	Site emergency response plan	Emergency coordinator
Corporate data breach	Enterprise incident response plan	Chief information security officer
Safety instrumented system design	SIS lifecycle (IEC 61511)	Process safety lead
Continuity decisions	Site business continuity plan	Continuity coordinator

Exclusions are where a scope statement can fail. "Physical emergencies are out of scope" leaves a responder with nowhere to go. Each exclusion needs three things: a reason, the plan that covers it, and the person who owns that plan, as in the four common exclusions above. The rule is simple: no exclusion without an owner and a pointer. Finish the scope with one sentence the sponsor reads and the auditor quotes. A pattern: this plan covers cyber incidents and suspected cyber causes in the site's control systems, from field devices to the OT DMZ, including vendor remote access; it excludes physical emergencies, which go to the emergency plan, and data breaches, which go to the enterprise plan. Read yours aloud; if a night operator cannot follow it, shorten it. Cedar Ridge chose a standalone site plan, because AWIA already puts cyber inside its Emergency Response Plan and the city IT plan has no OT content, so the Emergency Response Plan's cyber element references the OT plan. Its physical boundary is the plant, four booster stations and two tanks, with one line for the shared city services: the plan owns the response to losing them, and city IT owns the repair. Its system boundary lists systems by tag and then states, explicitly, that the building fire alarm and its network controller are out, caught by an exclusion owned by the city emergency manager. Its party boundary names the managed security provider with one honest limit written down: that provider's monitoring covers city IT only.

The Requirements Register

Scope and requirements are not two separate tasks; they shape each other. Regulations often draw part of the boundary for you. In the electric sector, CIP-008 lists the systems each of its requirements applies to; TSA's directive applies to systems it defines as Critical Cyber Systems; Australia's SOCI Act starts from critical infrastructure assets. Your scope then decides which rules land on which systems, so fill both together and revisit the scope once the register is done. The requirements register lists every rule and contract the plan must satisfy. Each row records the version and the date you checked it, what the plan must contain, who signs, what evidence an auditor will want, and an owner, a status and a re-check trigger. The register lists obligations only. Mapping each one to a plan section comes later, in the compliance annex, and reporting deadlines go in the notification matrix.

Two habits make the register useful to an auditor rather than decorative. First, rows that do not apply are not deleted. At Cedar Ridge, a US water plant, the EU, Canadian and Australian rows are kept and marked not applicable, reviewed, with a reason, and each US row that does not apply carries its reason too: not a NERC registered entity, not a pipeline, not a maritime facility, not a listed company. An auditor will ask what you ruled out, and this is your answer. The one regime that clearly applies, AWIA, covers the whole plan, and its status line says the plan must be traceable to the Emergency Response Plan's cyber element. Second, contracts sit beside laws. The Cedar Ridge cyber insurance row, whose clause is illustrative, requires notice to the insurer's claims line, a panel response firm or the insurer's written consent, and consent before any extortion payment. No regulator mentions these, yet each one changes what the plan must say. A register goes stale quietly, so keep it honest: every row carries a version and a checked date; superseded versions are marked outdated with the current one named; pending rules such as CIRCIA keep a placeholder row with a trigger, such as publication of a final rule; and before the plan is approved, every row is re-checked against the current text. Treat the register as a map, not legal advice.

With the charter, the roster and drafting chart, the scope statement and the register in hand, the first chapter of your plan, Governance and Scope, is done: authority and ownership, the planning team and drafting RACI, the scope statement, and the requirements register. One distinction is worth repeating. The planning team roster is not the response roster. The response roster, with names and numbers for an incident, comes later and lives in the plan's Appendix A. The worksheets for all four documents, with the filled Cedar Ridge examples, are in Appendix A of this book.

Standards for This Chapter

This table lists the standards, laws and guidance this chapter relies on, what each asks of the governance and scope part of your plan, and its status as checked in October 2026. Rules change: confirm the current version before relying on any row.

Standard or rule	Applies to	What it asks of this part of the plan	Status (Oct 2026) and where to check
NIST SP 800-61 Rev. 3 (Apr 2025)	Any organization (guidance)	Policy states management commitment and names roles and authorities, including who may disconnect or shut down; policy scope covers to whom, what and under what circumstances.	Current; replaces Rev. 2. nist.gov
NIST SP 800-82 Rev. 3	OT operators (guidance)	Senior security leader holds the OT security mandate; stakeholders (labor, vendors, legal, safety) give input to the plan; presenting the case to leadership.	Current; a Rev. 4 draft was out for comment in late 2026. nist.gov
ISA/IEC 62443-2-1:2024	Asset owners	Top-to-bottom commitment; phased program; asset owner stays responsible when providers do the work; keep the response process current; predetermined safe state after a detected compromise.	2024 edition current; retire the 2010 edition.
NERC CIP-008-6 and CIP-003	North American bulk electric system entities	Plan identifies, classifies and responds to incidents, defines attempts, names roles and handling procedures; CIP Senior Manager approves policies.	CIP-008-6 enforceable; CIP-008-7.1 from 1 Jul 2028. nerc.com
TSA SD Pipeline-2021-02G	TSA-designated critical pipelines	Containment, segregation, backup integrity and IT/OT isolation measures, each with a responsible position; forensic memory image and labelling before power-off or moving.	In force 3 May 2026 to 2 May 2027; public. tsa.gov
USCG 33 CFR 101 subpart F	US maritime facilities and vessels	Response plan as part of the Cybersecurity Plan; owner ensures development, approval and execution; Cybersecurity Officer ensures execution and exercise.	In force 16 Jul 2025; Cybersecurity Plans due 16 Jul 2027. ecfr.gov
AWIA 2018 / SDWA section 1433	US community water systems serving over 3,300 people	Cyber response inside the Emergency Response Plan; self-certification to EPA.	In force; EPA template available (Appendix B). epa.gov
CIRCIA	US critical infrastructure	Nothing yet for plan content; hold a placeholder row.	Final rule not published as of Oct 2026. federalregister.gov
CFATS	US chemical facilities (former program)	None; OSHA process safety and EPA risk management planning may still apply.	Lapsed 28 Jul 2023; outdated.
NIS2 Directive, Articles 20-21	Covered entities in the EU	Management body approves measures; incident handling, continuity, crisis management, secured emergency communications; no plan content list.	Transposition not complete in every member state; check national law.
CER Directive, Article 13	EU critical entities	Resilience plan or equivalent documents; liaison officer for the authorities.	Check national implementation.
Network Code on Cybersecurity (EU) 2024/1366	High- and critical-impact electricity entities	Cyber-attack management procedures with roles, tasks and reactions as the attack evolves.	Check current status.
Implementing Regulation (EU) 2024/2690	Digital providers only	Detailed incident handling and continuity contents; a benchmark and a contract lever for operators.	In force for providers in NIS2 scope.
Critical Cyber Systems Protection Act (Canada)	Designated operators (none yet)	Cyber security program with steps to minimise incident impact.	Royal Assent Jun 2026; not in force Oct 2026. Justice Laws, Canada Gazette
Canada Energy Regulator (CSA Z246.1)	Interprovincial and international pipelines	Security management program; emergency procedures manual submitted to the Regulator.	In force. laws-lois.justice.gc.ca
CNSC / CSA N290.7	Canadian nuclear power plant licensees	Cyber security program with an incident response process; quarterly reporting of updates.	Check the current edition of N290.7.
SOCI Act Parts 2A and 2C; CISC IR.1 to IR.8 guidance (Australia)	Responsible entities; Systems of National Significance	Risk management program (2A); written, reviewed incident response plan copied to the Secretary (2C); eight content criteria as a self-check.	In force; check the current compilation. legislation.gov.au, cisc.gov.au
INL CCE Phase 1 (2020)	Method (adapted)	Agree objective, scope and boundary conditions as one sentence before analysis.	Reference method.
IEC 61511	Safety instrumented systems	SIS engineering changes stay with the safety lifecycle; the plan covers detection and notification.	Check the edition used at your site.

What's Next

A charter, a team, a scope and a register give the plan its authority and its edges. They do not yet tell you what the plant needs during an incident, which functions matter most, how long they can be lost, what states the process can be driven to safely, or which plans already exist that yours must hand off to. Chapter 2 gathers those inputs, starting with the interviews that turn people's knowledge into facts the plan can rely on.

Reflect

• If an alarm came in tonight, could your shift supervisor point to the page that says who may order a shutdown for a cyber reason, and who signed it?
• Which of the nine failures describes your current plan most closely, and which gate would have stopped it?
• Who at your site can genuinely bind operations, and would they sign a one-page charter with dated decisions in a twenty-minute meeting?
• Has anyone on the night shift ever read your response procedures, and what would change if you asked them to?
• Which exclusions in your current scope point nowhere, and who would own each one if you wrote it down?