What Evidence Should You Require Before Approving an OT Security Change?

Before approving an OT security change, require evidence that the proposed action addresses the stated exposure, preserves the functions the process depends on, and can be executed under defined operating conditions with a credible recovery path. Identify what the tests did not represent. Assign the production decision to people with the relevant engineering, operations and safety authority, with explicit acceptance and stop conditions. A vendor recommendation, a successful installation or a lower vulnerability count cannot answer all those questions.

Urgency changes how quickly you must decide. It does not make an untested operational assumption true. Equally, uncertainty about a patch is not a standing justification for leaving a dangerous exposure untreated. The decision may involve applying the patch, restricting an exposure path, changing the operating condition, accelerating an outage or using a temporary measure with a review deadline.

I would make that choice through a change-specific argument supported by evidence. This paper develops a proposed approval method from OT guidance, configuration management, systems engineering and safety research. It is not a validated plant procedure or a report of equipment testing. The examples and timing calculations are fictional. Equipment-specific instructions, hazard analysis and authorized operating procedures remain essential to any production decision.

Define the decision as a change to an operating system of people and equipment

Start with the function you intend to protect and the change you actually propose. An operating-system patch on an engineering workstation, a firewall rule between zones and a controller firmware update are all security changes, but they disturb different dependencies. A single form asking whether the update installed successfully will miss the differences that matter.

NIST's OT guidance recommends testing patches in a sandbox where possible, scheduling updates within maintenance windows and having a recovery plan for the affected component or system. It also recognizes differences in availability requirements across levels and zones (Stouffer et al., 2023, Section 5.2.5.2). I would interpret those recommendations as the beginning of a decision specification, not permission to treat any test machine as representative of the plant.

The specification should name the asset and configuration, the protected function, the proposed transition and the operating conditions under which the transition is allowed. Include the relevant interfaces and the people who must respond if something unexpected happens. A change to a workstation may affect engineering access without directly changing controller logic; a change to a shared communication boundary may affect several functions even though only one rule is edited.

HSE's plant-modification guidance calls for traceable technical and safety review and recognizes that changes can affect parts of a plant remote from the immediate modification. It also includes procedures and people within the change-management scope (Health and Safety Executive [HSE], n.d.-b). I draw on that engineering principle here. The page is UK process-industry guidance with older references, not a declaration of the current legal obligations for every industrial organization.

A useful scope statement therefore describes both the intended effect and the protected constraints. “Remove an unauthorized maintenance path while preserving the approved operating and recovery functions” gives reviewers something to examine. “Implement best practice segmentation” leaves the consequence of success undefined. Without that definition, a team can deliver exactly the requested configuration and still leave the owner with the wrong result.

Separate the urgency of exposure from readiness to deploy

The first decision concerns the consequences of waiting. Establish whether the affected product and configuration are present, which relevant access paths exist, what exploitation evidence is available and what the exposed function means to this operation. Record the date of the evidence. A vulnerability finding is an input to that assessment, not a complete plant-level decision.

CISA's Stakeholder-Specific Vulnerability Categorization guide uses an explicit decision process for vulnerability response. Its exploitation assessment concerns information available at the time of analysis, rather than predicting future exploitation, and the guide emphasizes system scope and organizational impact (Cybersecurity and Infrastructure Security Agency [CISA], 2022, pp. 3–4). I would use that distinction to keep urgency evidence current without pretending it establishes the safety of a particular deployment.

The second decision concerns the proposed intervention. Does this artifact or configuration change address the relevant mechanism in this version? Which prerequisites does it require? What operational behavior could it disturb? A highly urgent vulnerability can coexist with poor evidence for one proposed fix. The conclusion should then be an urgent search for a defensible response, not a fabricated readiness score.

The third decision compares feasible courses of action. NIST's enterprise patch-planning guidance distinguishes routine patching, emergency patching, emergency mitigation and unpatchable assets. It recommends planning both temporary mitigation and its eventual replacement or removal (Souppaya & Scarfone, 2022, Section 3.5). That is general enterprise guidance; its timing examples are not OT maintenance instructions. The useful principle is that patch deployment is one response path among several.

I would present the owner with the best-supported feasible options and their remaining uncertainties. For each, state the exposure left in place, the operational constraints introduced and the evidence needed for the next decision. Deferral should have a reason, an accountable owner and a reassessment trigger. Otherwise, “wait for the next outage” becomes an indefinite exception disguised as a schedule.

Establish the baseline that makes the evidence interpretable

Before testing, identify what is installed and what is intended to be installed. The comparison needs more than a product name: relevant hardware revision, firmware, operating system, application version, enabled features, communication relationships and approved configuration. The required detail depends on what the change can affect. A file hash identifies particular bytes; it does not establish compatibility with every target bearing the same label.

Security-focused configuration management connects controlled change with analysis of its effect on existing controls. NIST SP 800-128 treats emergency changes within change control and calls for security impact analysis by people who understand the system (Johnson et al., 2011, Sections 2.3.8–2.3.9 and 3.3.3). I would use that structure to preserve the relationship between the approved proposal, the tested candidate and the resulting configuration.

Record the source of the candidate and the method used to establish its identity. Preserve the relevant vendor advisory and applicability conditions rather than retaining only a download link that may change. If a supplier has approved a particular combination, identify that combination and any stated exclusions. A support statement is evidence within its scope; it is not a substitute for checking the owner's integrations and operating conditions.

The baseline also includes work instructions and temporary conditions. If a test required disabling a function, changing a timeout or bypassing a control, those conditions belong in the result. Do not carry the test's success forward while quietly removing the assumptions that made it possible. Conversely, a difference that cannot affect the tested claim need not force a complete rebuild of the test environment; explain why it is immaterial.

Unexpected configuration drift requires a decision before the change proceeds. Updating the baseline to match whatever is discovered can erase evidence of an unauthorized or unexplained state. I would ask whether the discrepancy changes applicability, invalidates a test or reveals an additional exposure. The answer determines whether the original approval argument still applies.

Build acceptance around claims that can be disproved

An approval package should explain why its evidence supports its conclusion. NIST's trustworthy-systems engineering guidance describes assurance cases as structured claims, arguments and evidence with explicit assumptions and constraints, maintained as the system changes (Ross et al., 2022, Section 4.3). I would borrow that discipline without requiring every routine change to become a formal safety-case project.

For a consequential OT security change, I would organize the evidence into four claims. First, the candidate addresses the stated security problem in the applicable configuration. Second, required operating functions remain acceptable within the assessed conditions. Third, the deployment and recovery procedure can be performed with the available people, tools and time. Fourth, the remaining uncertainty is understood by the authority making the production decision.

Each claim needs a potential failure observation. A test that can only generate a pass is a demonstration of activity. For example, if the security objective is to restrict a maintenance path, the test should distinguish the prohibited path from the required approved path. If the operational objective includes a transition between modes, observing only steady-state communication leaves that transition unexamined.

Claim to support	Evidence to seek	Result that should prevent an unconditional approval
The security purpose is achieved	Applicable advisory, candidate identity and a bounded test or analysis of the affected mechanism	Wrong version, unexplained bypass or unsupported applicability
Required functions remain acceptable	Requirement-linked observations in representative operating and transition conditions	Unresolved loss of function, timing deviation or untested consequential interface
Deployment and recovery are feasible	Rehearsed steps, available resources, measured task durations and a credible fallback	Unavailable recovery artifact, incompatible rollback or insufficient decision time
Residual uncertainty is acceptable	Explicit exclusions, compensating conditions and authorized acceptance	A safety-relevant assumption has no engineering basis or responsible decision maker

This is an original review structure, not a scoring standard. The rows should not be averaged. Strong evidence that the patch removes an exposure cannot compensate numerically for an unresolved constraint on a critical protective function. The appropriate disposition may be a limited approval, an additional test, another intervention or a planned operating change.

Test the intended security effect and the operating function separately

The older DHS control-system patch guide recommends testing both whether a patch addresses the identified problem and whether it conflicts with coexisting applications. It also calls for functional tests, removal procedures and records of the patch and resulting configuration (Tom et al., 2008, Section 2.1.4). Those distinctions remain useful; its dated tools, vulnerability examples and scoring conventions should not be treated as current operational guidance.

I would separate the security test from the operational regression test because a failure can point in either direction. An application can continue working while the vulnerable path remains exposed. A restrictive policy can block the unwanted traffic while also blocking a legitimate dependency. A version string can change without proving either result. The evidence should identify the observation supporting each conclusion.

NASA's systems-engineering handbook distinguishes verification against specifications from validation against stakeholder expectations in the intended environment (National Aeronautics and Space Administration [NASA], 2016, Sections 5.3–5.4). That distinction is transferable even though the handbook concerns NASA engineering rather than plant certification. Correctly implementing the written rule is different from showing that the rule serves the operating need.

Test design should also establish that a negative result comes from the intended control. If a prohibited connection fails because the test target is unavailable, the result does not demonstrate the new policy. Include a legitimate comparison path and enough context to explain the outcome. Where testing the vulnerability itself would be unsafe or inappropriate, use supported vendor evidence, analysis and bounded checks, and state the narrower claim.

Avoid combining a security rollout with unrelated optimization merely because the outage is convenient. Multiple simultaneous changes make it harder to explain a deviation and to define the state to which recovery should return. Where dependencies require a combined change, treat the combination as the candidate and test its interactions. The approval should not fragment an inseparable transition into several individually reassuring tickets.

Represent the interactions that could defeat the change

A spare device with matching firmware can be valuable without representing the whole system. Identify which interfaces, loads, redundancy behavior, startup conditions and human actions could change the outcome. Then choose the test environment around those uncertainties. Physical similarity is not enough if the missing behavior is the very one the approval depends on.

Leveson's systems-theoretic accident model distinguishes failures of components from hazardous interactions among components, including cases where components satisfy their individual specifications (Leveson, 2004). I use that conceptual result to challenge a narrow acceptance assumption: evidence that each modified part works alone does not necessarily justify the integrated transition. It is a theoretical safety argument, not a measured estimate of failure probability for this proposed method.

Consider a fictional segmentation change between an engineering workstation and a controller network. A steady-state test may show the intended service continues. It may not exercise a maintenance transfer, a redundant-path transition or a recovery function. The test team should identify which of those functions are relevant and how each requirement will be examined. It should not infer their irrelevance from the absence of normal traffic during a short capture.

DHS's defense-in-depth guidance describes firewalls as controls between zones, warns about bypass paths and notes that rule changes and rule order can affect permitted data flows (U.S. Department of Homeland Security [DHS], 2016, Section 2.5.2). I would therefore review the path around the control as well as the rule itself. A permitted alternate route may defeat the security claim; an undocumented legitimate dependency may defeat the operational claim.

Where simulation or a test bench omits a consequential condition, record the omission as an unresolved production consideration. An authorized staged acceptance may address it, or the uncertainty may require a different design. The offline PLC backup-testing paper develops test-fidelity and restoration questions in detail. Here, the decision is whether the available representation is sufficient for this specific change, not whether the laboratory looks impressive.

Protect the safety argument from accidental common dependencies

Security and safety can depend on some of the same infrastructure without being interchangeable disciplines. A new restriction, software agent or administrative dependency should be reviewed for its effect on the functions relied upon to detect, prevent or mitigate hazardous conditions. That review needs the relevant engineering expertise; a security team's intention to reduce risk does not establish the effect on those functions.

HSE's control-system guidance includes the sensors, actuators, logic, utilities and other elements required to perform a safety function within the safety-related system. Its discussion of integrity addresses timely performance, availability and independence, including common dependencies (HSE, n.d.-a, “Safety related systems” and “System integrity”). I use these general principles, not the page's historic numerical examples or references as current design requirements.

For the proposed change, identify any assumption that a protective function remains independent or available. Does its administration now depend on the same service being changed? Could a new communications restriction affect its required information path? Does the maintenance arrangement temporarily alter the personnel or utilities available to respond? These are questions for analysis, not claims that every security change creates a hazard.

A checklist marked “no safety impact” should have a traceable basis. It may be entirely justified when the changed component cannot affect a relevant function within the defined system boundary. The record should explain that reasoning and its assumptions. If the boundary itself is disputed, the approval cannot resolve the dispute by assigning it to a low-risk category.

I would also make temporary operating instructions visible to the people taking over the next shift. HSE's modification guidance explicitly addresses authorization of operating procedures and temporary instructions during change (HSE, n.d.-b, “Operating procedures during change”). The security configuration may be correct while the human operating assumption has become outdated. Completion requires the relevant instructions and handoffs to match the accepted state.

A rollback file is not a complete recovery strategy

The recovery question is whether the team can reach an acceptable state after a failed or abandoned change. That state may be the previous configuration, an approved degraded condition or a controlled shutdown. It is not necessarily “restore the old file and resume.” The physical process and the software may have advanced while the change was being attempted.

I would distinguish configuration reversibility, data compatibility, operational recovery and return-to-service authorization. A documented uninstall procedure may establish how to reverse software changes without proving that changed data remains compatible. A successful controller restore may establish that a candidate loads without establishing the state of connected equipment. These are logical limits on the conclusion, not claims that every update changes data or prevents rollback.

Before deployment, identify the recovery artifact, its applicability, required tooling, authorized operator and the conditions under which recovery remains feasible. Rehearse the appropriate elements in a safe environment. If reversal is unsupported, define a forward-recovery or replacement path and assess it as part of the proposal. Labeling an irreversible change “standard” does not create a recovery option.

Time must be considered backward from the required operating condition. Suppose a fictional maintenance plan allows 90 minutes, reserves 30 minutes for recovery and 15 minutes for uncertainty. The latest decision point that preserves those allowances is minute 45: 90 minus 30 minus 15. This is planning arithmetic, not an industrial safety limit or a measured recovery capability.

If applying the change consumes 20 minutes and validation needs another 25, the plan reaches that decision point exactly. If validation instead needs 35 minutes, it finishes at minute 55; adding the assumed 30-minute recovery and 15-minute reserve gives 100 minutes, ten beyond the window. The response should be to redesign the plan, shorten its scope on a justified basis or provide a different authorized operating arrangement. Quietly deleting the reserve does not resolve the uncertainty it represented.

The governing safety constraints can be more restrictive than the maintenance window. The example does not establish how long any process may tolerate an interruption. Those conditions must come from the plant's engineering and operating requirements. The useful discipline is to identify the last responsible decision point before the available options disappear.

Make conditional approval precise enough to expire

An approval can be conditional without being evasive. State what may be changed, on which assets, under which operating condition and within which evidence boundary. Identify the conditions that require stopping, reverting or obtaining a new decision. Include who has that authority when the original approver is unavailable. “Proceed carefully” is not an acceptance criterion.

NIST's configuration-change control includes reviewing proposed changes, documenting decisions, implementing approved changes and retaining and monitoring change records. Its impact-analysis control includes analysis before implementation and an enhancement for separate test environments (Joint Task Force, 2020, CM-3–CM-4). These are controls to tailor, not proof that a completed form establishes functional safety. Their useful contribution is traceability from proposal to decision to observed state.

For the fictional segmentation change, a conditional approval might cover one defined service pattern after representative tests, with unresolved differences explicitly excluded. Another asset with different dependencies would require an applicability review. A successful first deployment supports later decisions only to the extent that the relevant conditions match. It does not authorize propagation across every device in the inventory.

Emergency authority should be established before the emergency. The expedited record can be shorter while still naming the reason for urgency, proposed action, accepted constraints, decision maker and follow-up. If evidence is unavailable, record the assumption and the consequence of being wrong. An emergency decision is accountable judgment under constraint; calling the missing evidence a pass undermines that judgment.

The OT vendor-access paper explains why permission to connect is separate from permission to change. Preserve that separation during implementation. A vendor's troubleshooting session should not silently expand into production modification, and an approved modification should not authorize unrelated access or enduring exceptions.

Close the change on evidence of the resulting state

The final record should identify what actually changed, which acceptance observations were obtained and what remains unresolved. Compare the result with the approved candidate and scope. Record deviations rather than retroactively rewriting the proposal so the outcome looks planned. Where the change creates a new baseline, explain why that baseline is accepted.

A production observation period should follow the functions and conditions that need observation. A quiet ten minutes may say little about a relevant daily task, an infrequent transition or the next maintenance operation. Equally, indefinite monitoring without a named acceptance question provides no clear closure. Identify what can be assessed now, what needs later observation and who owns that follow-up.

Temporary mitigations need their own retirement decision. Removing a restriction can reopen an exposure; leaving it indefinitely can preserve an operational constraint no one intended to make permanent. The closing record should explain whether each temporary measure is removed, retained under a revised basis or assigned a deadline. This is where the alternatives considered at the beginning connect to the actual state at the end.

I would measure the process through consequential failures and evidence gaps: changes applied outside approved scope, recoveries that could not be completed as planned, unexplained test-to-production differences and overdue conditions of approval. Count the relevant population and retain adverse outcomes. A falling number of open change tickets can reflect administrative closure without showing that the approval method improved.

Keep the burden proportionate without turning uncertainty into a pass

The strongest objection is cost. Most operators cannot build a complete replica of their plant or conduct a major assurance project for every patch. I would scale review to the consequence and novelty of the change. Reuse applicable evidence, standardize recurring change patterns and concentrate expensive tests on assumptions whose failure could invalidate the decision. The method should reduce uncertainty that matters, not maximize documentation.

A second objection is that excessive caution leaves exposed systems vulnerable. That is real. The decision record should make delay costly to justify by requiring explicit interim protection, reassessment and a path to resolution. It should also permit urgent action when a competent authority judges the available option preferable under the constraints. The framework offers no formula that can replace that judgment.

A third objection is that vendor approval should be enough. Vendor evidence can be central, especially for proprietary equipment. Its value depends on applicability: the tested version, combination, configuration and functions. Where the owner's integration differs, that difference needs analysis. Treating supplier evidence seriously means preserving its scope, not extending its conclusion beyond what was supplied.

The twelve references combine authoritative guidance and one original peer-reviewed safety paper accessed through an author-course copy. They do not constitute twelve empirical evaluations of this method. Older DHS and HSE material is used for identified engineering principles; current product behavior and applicable requirements need separate verification. No live controller, industrial network or physical process was accessed, and no production change is authorized by this article.

If your approval process can show that a patch installed but cannot explain why the changed operation is acceptable, request an OT security change-readiness briefing. Bring the proposed change, system boundary and existing evidence without credentials or sensitive plant details. I would use that discussion to scope the decision, identify the consequential gaps and define the next engineering acceptance step. The useful deliverable is an approval argument your operators can act on and your reviewers can challenge.