Definitions and Classification

Three Lines, Not One

It is tempting to draw one blurry line between "nothing" and "incident." Your plan needs three. The investigation line means a human should look at this. The declaration line means the event meets your own criteria, so the plan activates. The reportability line means it meets a regulator's or a contract's definition, so an outside duty starts. Different people draw each line, for different purposes, and they do not always fall in that order. A regulator's line can sit below yours, counting events still under investigation, as the TSA pipeline security directive does, or well above it, counting only actual impact, as the proposed CIRCIA rule does.

Night shifts mix up three words, so define them first. An event is any observable occurrence, such as a logon, a configuration download or a mode change on a PLC; most events are harmless. An alert is a claim, from a tool or a person, that something matched a rule or looked wrong, and it must be checked before anyone believes it. A process alarm tells the operator about a process deviation. It is not a security alert, but it can turn out to have a cyber cause, and your page must say what happens then. ISA/IEC 62443-2-1, 2024 edition, makes the link explicit: its guidance says the evaluation of a facility event can find a security incident as the root cause. So your definitions page needs one referral rule. When a trip, upset or quality investigation finds no physical cause, or finds an unexplained change to logic, setpoints or configuration, it is referred across the investigation line. Write down who refers it, and to whom, on days and on nights; at Cedar Ridge that is the operations supervisor on days and the lead operator on nights.

The same standard separates two ideas that are easy to blur. A security compromise is a breach that could have led to disclosure, modification, unauthorized execution or denial of service, defined without regard to impact. A security incident is a compromise or a failed attempt that is "of some significance to the asset owner." Notice what that phrase does. The standard deliberately leaves the threshold to you, and if your plan does not set it, nobody has. Failed attempts are the first threshold to set. A note in the same clause says some environments treat failed attempts, such as failed logons, as incidents and others do not. Pick a rule and write it on the page. One workable rule, a design choice rather than a requirement, declares every failed attempt against Level 1 and 2 controllers or safety interlocks, while failed attempts elsewhere are recorded and trended. Some regulators have already answered this question for their own purposes, and they do not agree with each other.

Process safety already tracks near misses, and your definitions need the same bucket. Mustard's ISA book on industrial cybersecurity argues that counting only incidents gives false confidence. Its example is a vendor plugging their own USB stick into an engineering workstation: nothing was infected, but a procedure failed. On your page, that is recorded, not declared. It is logged, trended and reviewed, never just closed. The old accident pyramid, with many minor events beneath each serious one, is a useful picture; treat it as an analogy, not a fixed ratio.

One event can also be three things at once, owned by three plans. On the control network it is an incident, and the incident response plan owns it. At the plant, a threat to life, the environment or major assets right now is an emergency, owned by the emergency response plan. At headquarters, if the organization itself is threatened, it is a crisis, owned by crisis management. Your definitions page names each term and the plan that owns it, and the plans inventory from the previous chapter already holds the hand-off contacts.

Writing the Investigation and Declaration Lines

Write the investigation line as observable triggers, so a night operator never has to judge "cyber or not." Start with six: an unplanned logic, firmware or configuration change, checked against management of change first; an HMI value the field disagrees with; an unexplained mode change; a vendor remote session nobody booked; an alert the security team forwards about a plant-connected asset; and an IT incident on a system the plant depends on. Anyone may raise a trigger, and nobody is blamed for raising one. The declaration line needs criteria a tired person can apply at night. ICS4ICS, the ISA program that adapts incident command to industrial cyber incidents, publishes a declaration template, and adapted for a plant, four criteria make a solid start: a confirmed or credibly suspected compromise of an in-scope system; any activity on or near the safety system or safety interlocks; an incident at a dependency that threatens a critical function; or the declaring role's judgment that it should be declared. Add one rule: when in doubt, declare at the lowest activation level, defined later in this chapter.

NIST's incident response guidance says to designate an incident lead but names no role. ICS4ICS is stricter: only a designated incident commander declares, with primary, secondary and tertiary alternates appointed in advance. Your plan names one declaring role and its alternates, reachable around the clock. At Cedar Ridge the declaring role is the plant superintendent, with the on-shift lead operator covering nights and weekends and the city IT security manager as second alternate. If the declaring role is the chief information security officer, that person then needs incident command training and delegated authority. One thing never waits for a declaration: the control room can always put the process in a safe state on a safety threat.

A declaration is a switch, not a label, and the page lists what it switches on, as a checklist the declaring role runs every time: the response team and the plan; the incident record and timeline; the initial classification and activation level; the reportability check; the insurer notice condition; the option to activate the emergency, continuity or crisis plan; and delegated financial authority, if it is tied to declaration. Because declaration can start regulatory reporting deadlines, log the moment of determination with a time and a name. Under NERC CIP-008-6, for example, the reporting duty runs from the determination your own process makes. That moment has legal weight, and nobody should have to reconstruct it later from memory.

The Reportability Line

Regulators define "incident" differently, and the differences decide when your outside duties start. The table below sets out the definitions only, as of October 2026; deadlines and recipients belong in the notification matrix, covered in the response procedures chapter.

Regime	What counts
NERC CIP-008-6 (US electric)	A Cyber Security Incident includes attempts, judged against your own written criteria; a Reportable one actually compromised or disrupted an in-scope system.
TSA SD Pipeline-2021-01G (US pipelines)	Counts events still under investigation, before the cause is known.
CIRCIA (US, proposed rule)	A substantial incident means actual impact only; attempts excluded, as proposed. Final rule not published.
NIS2 Article 23(3) (EU)	Significant if it has caused or is capable of causing severe operational disruption or financial loss, or considerable damage to others. Thresholds and recipients are national.
SOCI Act Part 2B (Australia)	Critical incidents have a significant impact on availability; other incidents have a relevant impact, and likely or imminent impact counts.
CCSPA (Canada, Part 2 not in force)	Anything that may interfere with a vital service, a vital system or a critical cyber system counts.
CER pipeline regulations (Canada)	Physical outcomes only; a cyber cause counts through them.

Outside the US, the tests lean toward the possible, not just the actual. One event at a multi-sector operator can meet three definitions in three different ways. So write one rule on the page: your internal declaration line is at least as broad as the broadest definition that applies to you. Each regulator's test then becomes a separate checklist, run at declaration and at every reclassification. Put contracts on the list too, because an insurance policy's definition of a cyber event can trigger a notice duty no regulator imposes. The Cedar Ridge reportability check is honest about uncertainty: it marks the proposed federal rule as likely to apply, pending the final text, with a re-check; it lists the city's insurance policy beside the regulators, and it applies; and a row for the state drinking water program reminds the writer to confirm the state's own rule. Ending an incident takes a definition too. NIST's guidance says the end of incident recovery is declared based on criteria, so reserve one line on the page: closed when the end-of-recovery criteria in the recovery chapter are met, declared by a named role. Closing, like opening, is a logged decision by a named person, not a feeling that things are back to normal.

Severity in the Language of the Plant

Two people rate the same morning at a water plant. The security operations centre calls ransomware on forty office PCs critical, and an unexplained setpoint change on the chlorine dosing loop low: one device, no data lost. The plant manager rates them the other way round. Both are using a severity scale; only one is using the plant's. Severity measures how bad the consequence is, or could credibly become, and nothing else. NIST's 2025 guidance makes a useful split. Escalation means more resources or longer time frames; elevation means bringing in a higher level of management. Severity drives elevation: who must know, and who must decide. How hard an incident is to manage is a different question, complexity, rated separately. A scale that mixes the two answers neither question well.

Do not invent a severity scale. Many industrial sites rate risk with a consequence matrix that operations and safety staff already use, with rows such as health and safety, environment, output, asset damage, regulatory and reputation. Mustard's book notes that the plant risk matrix already rates severity by consequence type. Reuse it. A scale invented by security, in security words, is the fastest way to get operations to ignore your classification. Two public sources help but neither hands you a plant scale. NIST's 2025 guidance lists severity factors, namely asset criticality, functional impact, data impact, stage of observed activity, threat actor and recoverability, and leaves the scale to you; the fixed impact tables of the 2012 revision are gone. CISA's National Cyber Incident Scoring System scores national risk, not plant consequence, and its page still cites the 2012 revision. Borrow three of its ideas anyway: how far the activity reached, the attacker's observed stage, and recoverability.

Building the scale takes three moves. Keep the matrix's consequence rows exactly as they are. Collapse its bands into four severity levels, S1 to S4; if the matrix has five bands, the top two can share S4. Then rewrite every cell in plant language: "worker exposed to chlorine," not "safety major." One rule sets the level: the highest row the incident reaches. If your impact analysis used the same rows, its zero-to-three bands already line up with S1 to S4. Write the direction on every page and every card, because published schemes number their levels in opposite directions. In FEMA's incident complexity typing, Type 1 is the most complex and Type 5 the least; CISA's scoring system puts the safety system at location level 7; the Purdue model puts the process at Level 0; and at least one published security scale makes level zero the worst. S4 is the most severe. A night operator reading "level one" must never have to guess which end it is.

Rate every incident twice. Actual impact is what has already happened. Worst credible impact is what could happen next if nobody contains it. Picture an intruder on an engineering workstation that holds the safety system's project files: nothing has touched the process yet, so actual impact sits at the bottom of the scale, and worst credible sits at the top. Outside definitions split the same way: the proposed CIRCIA rule counts only actual impact, while CISA's scoring system also scores potential impact. Your plan records both. Worst credible does not mean worst imaginable, though, or everything becomes S4 and the scale stops working. So write the test down: the attacker has shown access to a system that can cause the consequence, and the mechanism exists, with no further barrier the attacker has not yet crossed. A phished business PC fails the test for S4, because no access to process systems has been shown; the engineering workstation passes. Set the level on the higher result that passes, reassess as evidence arrives, and record who agreed the test.

Floor rules set a minimum level, whatever the actual impact so far, and they are easier to apply at two in the morning than a weighted score. The four rules that follow are this book's starting proposal, not a standard; your safety or risk owner sets the final wording and levels. At least S3: unexplained activity on or near the safety system or safety PLCs; a confirmed unauthorized change at Level 1 or 2, such as logic, firmware or setpoints; and loss of trust in process values on a critical function. Investigate before rating: an unplanned configuration change with no management of change record is never closed as a routine event by default; it stays unexplained until someone proves otherwise. A floor sets a minimum, and nothing lowers a floor. Above the floors, four modifiers can each raise the level one step, up to S4. Proximity asks how far the activity reached toward the process, measured in your own zones. Attacker stage separates reconnaissance from established presence and from effect; in MITRE ATT&CK for ICS, Inhibit Response Function and Impair Process Control are late-stage tactics. Recoverability asks whether you can restore from known-good sources, and how long that takes. Scope asks how many sites or remote stations are involved.

Three habits from security scales do not belong here. Attribution is not severity: a quiet state actor still at reconnaissance can be S2, while commodity ransomware that stops the plant can be S4. Data volume is not severity: a plant can lose nothing confidential and still have its worst day. Machine count is not severity: forty office PCs can be S1 for the process. How many machines are involved does matter, but it measures how hard the incident is to manage, not how bad its consequence is. You draft the scale; you do not own it. The safety or risk owner confirms each cell matches the site matrix, operations confirms the floor rules, because operators will apply them, and the sponsor approves the finished scale. Put three signature lines under the table, because classification gets argued about during real incidents, and a scale the owners signed settles that argument quickly. Each level then answers two questions inside the organization: who must be told, and how quickly, and who must decide. At Cedar Ridge, S3 brings in the city utilities director within thirty minutes, and S4 adds the city manager and the communications officer. These are internal times the site sets. Outside notifications follow the reportability check, because a regulator's definition can trigger at a different point from your scale.

Before the owners sign, test the scale on paper. Run every scenario from the scenario list through it, rating actual and worst credible. If your high-consequence events come out S1 or S2, the cells are wrong; if every everyday scenario comes out S4, they are wrong the other way. At Cedar Ridge, compromised integrator remote access came out S4, above what the owners expected. The credibility test was met, because that access path reaches the chlorine dosing controller, and the owners kept S4 and recorded why. Go back to the two ratings from that morning. With the plant's scale, the chlorine dosing change goes straight to the floor rules: once confirmed as unauthorized, a change at Level 1 or 2 is at least S3, whatever the actual impact. The forty office PCs are rated on what they do to the process, which may be very little. Severity was never a security invention. It is the plant's own consequence language, applied to a cyber cause.

Complexity: The Second Axis

Two incidents hit one utility in one week. In the first, someone downloads unauthorized logic to one safety-related controller, caught in minutes. In the second, commodity ransomware spreads across forty HMIs and historian servers at six sites, and operators run on local panels with no safety impact. The first needs the plant manager now and three experts. The second needs a week, the vendor at every site and shift rotations. Give each one number and one of them gets the wrong response. Complexity measures how hard an incident is to manage. FEMA's Incident Complexity Guide, from June 2021, describes it as the difficulty or resistance an incident presents to its managers. Severity drives elevation; complexity drives escalation, meaning more people, more structure and more time. One incident can need a lot of one and very little of the other.

FEMA reads complexity from two indicator sets. Effect indicators describe the disruption; management indicators describe the structure needed, such as an emergency operations center or several operational periods, an operational period being the NIMS term for one planned block of response time. Its levels run from Type 5, least complex, to Type 1. Two cautions apply. The guide says nothing about cyber, and FEMA calls it a planning and training tool, not a live decision tool, so build your own table in advance. And in NIMS resource typing, Type 1 means the most capable resource, a trap for anyone mixing the two. FEMA's pattern needs translating before a plant can use it, and the indicators below are this book's translation, not a FEMA list. The incident lead can count or observe every one, so nobody argues about them: zones, sites and controllers affected; IT and OT both involved; outside parties engaged, such as the equipment maker, the integrator or an incident response retainer; law enforcement or a regulator engaged; more than one shift or operational period needed; manual operation that must be sustained; a rebuild needed, meaning images, firmware or logic restores; and an emergency operations center or emergency response team activated. Attacker identity is not on the list, because it measures neither axis, and safety consequence is not either, because it belongs to severity.

FEMA uses five types because it serves national emergency management. A single site needs fewer levels, ones a tired person can apply at night, and three work. C1 is contained: one zone or asset, one shift, on-site staff. C2 is extended: several zones, or IT and OT together, more than one shift, vendor support. C3 is major: several sites or a full rebuild, sustained manual operation, several outside parties, several days. Borrow FEMA's all-or-most test, adapted: move up a level when the incident shows all or most of the next level's indicators. Watch the lag, too. FEMA notes that in a fast-growing incident the management indicators often lag the effect indicators. If the effects already look like C2 but you are still staffed for C1, the response has not caught up. One more rule, this book's advice rather than FEMA's: operational periods follow the plant's shift pattern, so the handover and the incident briefing happen together. Cedar Ridge hands over at six, morning and evening.

One Activation Level From Two Axes

Now put the two axes together. Severity runs across, S1 to S4, with S4 the most severe. Complexity runs down, C1 to C3, with C3 the most complex. That gives twelve cells, and each cell holds an activation level. Use four levels, named in words: Monitor, Respond, Partial activation and Full activation. Words avoid a third numbering scheme on top of S and C. Several cells share a level, and the matrix is a lookup table your owners agree in advance, not a formula anyone calculates under pressure. A level name means nothing until the plan says what it switches on, and each level sets six things: who leads, by role title, never a person's name; which roles are staffed; whether the incident room or the emergency operations center opens; how often internal updates go out; who is elevated, taken from your severity table; and which other plans start, from the plans inventory, so the emergency plan when people or public health are at risk, business continuity when an outage passes the impact analysis tolerance, crisis management when the enterprise is threatened. External reporting is deliberately left out of the cell; it follows the reportability check.

One shortcut seen in published guidance maps each complexity type to one severity level, so that bigger automatically means worse. That collapses two axes into one, and the wrong things drift onto the complexity axis. Three symptoms give it away: a single phished operator account lands at a level meant for multi-shift responses; the words "nation-state" decide the top complexity level, although attribution measures neither axis; and a severe single-controller event gets a small response simply because it is small. If your draft does any of these, it is one axis wearing two labels.

Place the opening incidents on the matrix. The safety controller download is S4 by C1: elevate at once and keep the team small and expert, a Partial activation. The six-site ransomware is S2 by C3: escalate resources and run operational periods, with only moderate elevation, also a Partial activation but staffed very differently. Add a third case: loss of view across a site, with an attacker at the engineering level, is S4 by C3, a Full activation with the emergency operations center open. When two cells share a level name, the cell text says which staffing applies. At Cedar Ridge, an unexplained change to the chlorine dosing logic lands in S4 by C1: the plant elevates at once with a small expert team, a controls technician on the job and the integrator called, and any S4 cell with a public-health consequence also activates the plant's emergency response plan.

Someone on your planning team will propose a third axis for attacker behaviour. Resist it. Behaviour is an input to both existing axes. Later-stage tactics such as impairing process control raise severity through the modifier already on your scale; broad lateral movement across zones and sites raises complexity, because more of the plant is involved. A third axis would turn twelve cells into thirty-six, and nobody can use that at night. Classification also has to move as evidence arrives. FEMA leaves re-typing to the people managing the incident, so your plan names who that is; a workable rule is the incident lead, consulting operations, at every operational-period briefing, and at once when a severity floor rule triggers or a new site or outside party joins. Log every change with a time, a reason and a name, and run the reportability check again, because a reclassification can change your reporting position. Write the downgrade criteria beside the upgrade criteria, just as easy to use. If stepping down needs a committee, teams stay at Full activation for days and exhaust the night shift. At Cedar Ridge, a chemical supplier reports ransomware: on day one it is S2 by C2, Respond; by day three the supplier's portal is back and phone orders work, and the superintendent logs S1 by C1, Monitor, at the morning briefing. The plant's rule is to step down one level at a time, at a handover briefing, with the reason logged. An easy step down is what makes "declare low when in doubt" a safe habit.

Activation level and reportability are two separate answers, recorded side by side. A Monitor-level event can still be reportable: under the TSA pipeline directive, an event still under investigation already counts. A Full activation can fall outside a definition: under the proposed CIRCIA rule, a threat with no actual impact yet would generally not be substantial. So the classification record carries both columns, checked at the same moments, and neither decides the other. Finally, calibrate the matrix as you calibrated the scale. Run every scenario through it and compare each result with the level the owners expected. If two very different scenarios land in one cell, add a staffing note to that cell; if a cell is never reached, do not invent staffing for it, but give it its neighbour's level. At Cedar Ridge, seven of eight scenarios landed where the owners expected. After any change the owners re-sign, because a changed cell changes who gets called.

Case Study: Kojima Industries and Toyota, 2022

On Saturday night, 26 February 2022, at a Japanese parts maker most people outside Japan have never heard of, a file server at Kojima Industries failed around nine in the evening. Around eleven, after a restart, it showed a threatening message. Two days later, Japan's largest carmaker said it would stop all 28 lines at its 14 plants in Japan. No compromise of Toyota's own systems has been reported. Would your plan call that an incident? Start with what the record confirms. Kojima supplies plastic and electronic parts. Early on the Sunday it cut its links to business partners and stopped all its servers. Toyota stopped its lines in Japan on Tuesday 1 March, citing a system failure at a domestic supplier, and production restarted on the Wednesday. Kojima's own investigation report, at the end of March, confirmed ransomware and the way in: a subsidiary had its own remote-connection device, used for a dedicated link to one outside company. Hino, the truck maker in the Toyota group, also stopped plants. Just as important is what the record does not say. It gives no figure for lost vehicles, Kojima's report names neither the attacker nor the ransomware family, and Toyota's internal reasoning is not public. The sources are company notices and trade press, not independent review, so treat any claim about the attacker, or about exactly which data stopped the lines, as speculation. Your own incident records need the same discipline: label each fact confirmed, reported or unknown.

For Kojima, cutting the network to business partners and stopping its servers was containment. For every customer connected to it, the same move was the start of an outage. One decision triggered two plans: the supplier's plan was about its own systems, while the customer's question was about its own production, on systems that had not been touched. Under just-in-time supply, parts arrive close to when the line needs them, so a key supplier's outage can reach the customer's line quickly. Now take a definition that counts only a compromise of the site's own systems and test it against that week. By that wording Toyota had no incident, yet it stopped all 28 lines at its plants in Japan. A definition that misses the event that stops every plant has a hole in it.

Four lessons follow, and each lands on the definitions page. First, dependency incidents. Your declaration criteria should include an incident at a dependency that threatens a critical function. The dependency register names the suppliers and service providers whose loss matters and how long you can last without each; turn that into a trigger. Declare a cyber incident at a listed dependency when it is expected to hit a critical function inside its time-to-harm, whether or not anything on your own network has been touched. The trigger is the consequence, not the attacker's location. Second, who hears first. News of a supplier's incident often reaches a buyer, a logistics planner or an account manager first, as a delivery problem rather than a security alert. Kojima's report records that it contacted its affected customers on the Monday evening. Your plan must route supplier incident news from those desks to the declaring role or its alternate without delay, and your supplier contact list should say who on the supplier side will call you. Third, rate your own consequences. Severity comes from the effect on your critical functions, not from what happened inside the supplier's network. Rated as a customer would, as an exercise rather than Toyota's own unpublished rating, a day of lost production across 14 plants is a high consequence for a carmaker with no reported safety effect, while complexity comes from the parties involved: the supplier, the Hino plants, and the ministries Kojima reported to and the police it consulted. That places it in a high-severity, moderate-complexity cell. Fourth, decide one day at a time. Toyota announced a stop for one day, and on that day announced a restart for the next; as reported, the two companies found other ways to keep production going before Kojima's systems were fixed. In plan terms, that is an activation level with a fixed reassessment point and a stand-down criterion that does not wait for the supplier's full recovery.

Now turn the story around: your incident is someone else's trigger. On the Monday, Kojima's customers' production continued on data exchanged before the cut. That evening Kojima judged it could not get the next day's production data through another route, so it contacted the affected customers. That is the supplier's reverse duty, warning the customers your incident will hit. If you supply anyone, your plan must say who tells which customers, and by when, and the "by when" comes from what each customer needs from you. One more detail from Kojima's report is worth copying. It found no evidence that data had been taken, then brought systems back as each one was confirmed safe: email, a provisional company website, the network with business partners and internal business systems. The partner network is on that list. For a supplier, reconnecting customers is a recovery step of its own, decided by a named person against a written check. The same pattern fits a water plant. At Cedar Ridge, the chemical supplier's ordering system goes down and the supplier reports ransomware. No plant system is touched, and the incident is still declared, because the critical function is disinfection. Severity comes from the days of chlorine stock left against that function's time-to-harm; complexity is C2, with the supplier, an alternate supplier and the county involved. On day one it sits at S2 by C2, Respond. The superintendent reassesses it at every morning handover briefing and steps it down once orders flow again.

Four lines turn this story into plan wording for your definitions page. A cyber incident at a listed dependency that threatens a critical function within its time-to-harm is declared. Supplier incident news goes from the buyer, logistics or account desk to the declaring role at once. Severity and complexity are rated on our consequences and parties, not the supplier's. Reassessment cadence and stand-down criteria apply as for any other incident. If you supply others, add a fifth line naming who tells which customers, by their needed-by time. An incident is defined by the consequence to your critical functions, not by where the attacker happened to be.

Standards for This Chapter

The standards, laws and guidance this chapter relies on, with what each asks of the definitions and classification chapter, as checked in October 2026.

Standard or rule	Applies to	What it asks of this part of the plan	Status (Oct 2026) and where to check
ISA/IEC 62443-2-1:2024	Asset owners	Compromise versus incident ("of some significance to the asset owner"); the asset owner sets the threshold, including failed attempts; facility event evaluation can find a security root cause; configuration changes are security-relevant events.	2024 edition current.
NIST SP 800-61 Rev. 3 (2025)	Any organization (guidance)	Event definition; designate an incident lead; severity factors without a fixed scale; escalation versus elevation; end of recovery declared on criteria.	Current; the 2012 Rev. 2 tables are superseded. nist.gov
ICS4ICS Escalation-Notification-Declaration template	Industrial operators (guidance)	Declaration criteria; only a designated incident commander declares, with primary, secondary and tertiary alternates.	Free template. Link in Appendix B.
FEMA NIMS Incident Complexity Guide (June 2021)	Pattern for complexity (adapted)	Effect and management indicators; select a level when all or most indicators are shown; management indicators lag in fast-growing incidents.	Planning and training tool. Link in Appendix B.
CISA National Cyber Incident Scoring System	National risk scoring (borrowed ideas)	Location of activity, observed stage and recoverability as severity modifiers; potential impact scored.	Page still cites SP 800-61 Rev. 2. cisa.gov
MITRE ATT&CK for ICS	Reference for attacker stage	Late-stage tactics such as Inhibit Response Function and Impair Process Control raise severity.	Check the current version. attack.mitre.org
NERC CIP-008-6	North American bulk electric system entities	Incident includes attempts against your own written criteria; Reportable means compromised or disrupted; duty runs from your determination.	Enforceable; CIP-008-7.1 from 1 Jul 2028. nerc.com
TSA SD Pipeline-2021-01G	TSA-designated pipelines	Events still under investigation count.	In force to 15 Jan 2027. tsa.gov
CIRCIA (proposed rule, 2024)	US critical infrastructure	Substantial incident means actual impact; attempts excluded, as proposed.	Final rule not published Oct 2026. federalregister.gov
NIS2 Directive, Article 23(3)	Covered entities in the EU	Significant incident includes one capable of causing severe disruption or loss.	Check national law.
SOCI Act Part 2B (Australia)	Responsible entities	Critical and other incidents; likely or imminent impact counts.	In force. legislation.gov.au
CCSPA and CER pipeline regulations (Canada)	Designated operators; federally regulated pipelines	"May interfere" test (CCSPA, not in force); physical outcomes only (CER).	CCSPA Part 2 not in force Oct 2026. laws-lois.justice.gc.ca

What's Next

The plan now knows what an incident is, how bad it is, how big a response it needs and when it ends. It does not yet say who runs that response: who leads, who sits beside the lead, who decides to isolate or shut down, and how the plant reaches its vendors and outside partners at three in the morning. Chapter 4 writes the command structure, maps it onto real plant jobs and pins down the decision rights.

Reflect

• If your night shift saw a pump restart on its own tonight, which of the three lines would they think it crossed, and who would they call?
• Does your current plan say whether failed attempts against controllers are incidents, and who decided that?
• Would your severity scale rate forty infected office PCs above an unexplained setpoint change on a critical loop, and would operations agree with that rating?
• Which of your incidents would be severe but simple to manage, and which simple but sprawling, and does your plan staff them differently?
• If your most important supplier announced ransomware tomorrow, who at your site would hear first, and would your definitions call it an incident?