Federal OT Safety PLC Code Review: Securing Logic Changes, Simulation Evidence, and Approval Workflows Before Deployment

PLC logic changes in federal operational technology environments carry a level of risk that most software change processes are not designed to handle. A misconfigured rung in a ladder logic program can silence an alarm, disable an interlock, or command a physical actuator in a way that causes equipment damage, process failure, or a safety event. Unlike a misconfigured server, the consequences are not always recoverable with a rollback command. They may already be in motion by the time anyone notices.

Federal OT environments add layers of accountability that commercial industrial facilities often do not face. RMF authorization boundaries, safety system documentation requirements, and engineering governance expectations mean that a PLC logic change needs more than a technician’s approval and a backup of the previous file. It needs a defensible record: who reviewed it, what they checked, how it was tested, what the simulation showed, and who authorized the release. That record has to survive an audit, a safety investigation, and a program transition.

Most OT teams understand this in principle. The gap is in execution. Review processes are informal, simulation evidence is not retained, version control is inconsistent, and approval authority is unclear. When an assessor asks for evidence that a logic change was validated before deployment, the answer is often a verbal explanation rather than a documented artifact. That is a program risk, a compliance gap, and an operational liability.

This article addresses the build-stage controls that close that gap: structured peer review of PLC logic, simulation and offline test evidence, separation of duties between engineers and approvers, version control practices, release packaging, and handling emergency changes without abandoning governance. The goal is a process that is defensible under scrutiny and practical enough that engineers will actually follow it.

What PLC Code Review Actually Covers

PLC code review is not a general quality check. It is a structured examination of specific logic constructs against known safety, operational, and security criteria. The reviewer is not just asking whether the logic compiles or whether the engineer intended the change. They are asking whether the logic behaves correctly under all expected conditions, including edge cases, fault states, and input combinations that may not occur during normal operation.

Ladder logic review focuses on rung-by-rung examination of contact and coil relationships, timer and counter configurations, and the sequencing of outputs relative to interlocks and permissives. A reviewer should be able to trace every output coil back to its enabling conditions and confirm that no coil can be energized in a state that violates a safety or operational constraint. This includes checking for coil duplication, where the same output is driven by multiple rungs in ways that could produce unexpected behavior depending on scan order.

Function block diagrams require a different review posture. The reviewer examines data flow between blocks, confirms that input and output data types are compatible, and checks that block execution order is deterministic. Feedback loops, uninitialized variables, and blocks that execute conditionally require particular attention because their behavior may not be obvious from a visual inspection of the diagram.

Structured text review is closest to traditional software code review. The reviewer checks for correct variable scoping, loop termination conditions, division-by-zero risks, and any logic that depends on timing assumptions that may not hold under all scan cycle conditions. Structured text is also where security-relevant logic is most likely to appear: authentication checks, mode transitions, and command validation routines that could be bypassed if written incorrectly.

Across all programming languages, the review should include a diff against the approved baseline. The reviewer should be examining only the changes, not the entire program, unless the change scope is broad enough to require a full-program review. A structured diff reduces review time, focuses attention on what actually changed, and produces a record of exactly what was modified. That record becomes part of the release artifact.

Review criteria should be documented in advance, not left to individual reviewer judgment. A review checklist that covers safety interlock preservation, alarm configuration integrity, mode transition logic, output coil conflicts, variable initialization, and security-relevant logic gives reviewers a consistent standard and gives approvers confidence that the review was thorough.

Simulation and Offline Test Evidence

Simulation is not a substitute for peer review, and peer review is not a substitute for simulation. They address different failure modes. Review catches logic errors that a reviewer can reason about statically. Simulation catches behavior that only emerges when the logic executes against inputs over time. Both are required for a defensible pre-deployment process.

Offline simulation should be conducted in an environment that is isolated from the production network and that uses a representative model of the process being controlled. The simulation environment does not need to be a full digital twin, though digital twin validation is increasingly practical for complex systems. At minimum, it should be capable of injecting the input signals that the changed logic will respond to and capturing the output behavior for review.

Defining Test Cases Before Simulation Begins

Test cases should be defined before simulation begins, not derived from what the simulation happens to show. Each test case should specify the initial state of the system, the input sequence being applied, the expected output behavior, and the pass or fail criteria. This prevents the common failure mode where a simulation is run, the engineer observes that nothing obviously bad happened, and that observation is recorded as evidence of successful testing.

Test cases should cover normal operating conditions, boundary conditions at the edges of expected input ranges, fault injection scenarios where sensors report out-of-range values or fail to respond, and any mode transitions that the changed logic participates in. For safety-critical logic, test cases should explicitly verify that safety interlocks cannot be defeated by the changed logic under any tested input combination.

Retaining Simulation Output as Evidence

Simulation output must be retained as a release artifact. This means capturing logs, trend data, or screenshots that show the system state at each test step, the inputs applied, and the outputs observed. A statement in a review form that says “simulation completed successfully” is not evidence. The actual output data is evidence. An assessor or safety investigator should be able to look at the simulation record and independently verify that the test cases were executed and that the results matched expectations.

Deviations from expected behavior during simulation must be documented and resolved before the logic advances to the approval stage. A deviation that is explained away verbally without a documented resolution creates a gap in the evidence chain. If the deviation was determined to be acceptable, that determination should be recorded with the reasoning and the name of the engineer who made it.

Separation of Duties and Approval Authority

The engineer who writes a logic change should not be the same person who approves it for production deployment. This is not a bureaucratic preference. It reflects the reality that an engineer who has been working on a change for hours or days has a cognitive investment in it that makes it harder to catch their own errors. A second reviewer with no authorship stake is more likely to notice a logic gap, a missing interlock check, or an assumption that does not hold.

In federal environments, separation of duties also carries accountability weight. When an incident occurs and the question is asked about who authorized a logic change, the answer needs to be traceable to a specific individual with documented authority, not to a team consensus or an informal agreement. That traceability requires that the roles of author, reviewer, and approver be distinct and that each role be documented in the release record.

Approval authority should be defined in advance and tied to the scope and risk level of the change. A minor modification to a non-safety-critical output timer may require a single peer review and a lead engineer sign-off. A change to a safety interlock or a mode transition sequence may require review by a second engineer, sign-off from a safety engineer, and authorization from the system owner or program office. The approval matrix should be documented and should not be negotiated on a per-change basis.

Operators and cybersecurity personnel have roles in this process that are distinct from engineering review. Operators should confirm that the changed logic is consistent with how the process is actually run, not just how it is documented. Cybersecurity personnel, particularly ISSOs and ISSMs, should confirm that the change does not introduce new attack surface, modify security-relevant logic, or affect the authorization boundary in a way that requires RMF documentation updates. These reviews should be parallel where possible, not sequential, to avoid compressing timelines unnecessarily.

Emergency changes require a defined expedited path. When a production system is down or a safety condition requires an immediate logic correction, the normal review timeline is not practical. The emergency path should still require a minimum review, even if it is a single qualified reviewer rather than the full review board. The change should be deployed with a documented exception, and the full review process should be completed within a defined window after deployment. Post-deployment review is not equivalent to pre-deployment review, but it is far better than no review at all, and it preserves the evidence chain.

Version Control and Baseline Management

PLC logic files need version control with the same discipline applied to any other configuration item in a federal system. The production baseline is the approved, deployed version of the logic. Any change to that baseline requires a new version, a review record, and an updated baseline upon successful deployment. The version history should be complete enough that any previous version can be retrieved and compared to the current production version.

Naming conventions matter more than they appear to. A file named “PLC_Program_v3_FINAL_revised_USE_THIS_ONE.L5X” is not a version-controlled artifact. A structured naming convention that includes the system identifier, the version number, the date, and the change reference number produces a file that can be located, compared, and traced without verbal explanation. The naming convention should be defined in the program’s configuration management plan and applied consistently.

Baseline tagging should occur at two points: when a version is approved for deployment and when a version is confirmed as successfully deployed to production. These are not the same event. A version may be approved but not yet deployed, or deployed to some controllers but not others in a multi-PLC system. The version control system should be able to represent this distinction.

Diff documentation is the record of what changed between the previous approved baseline and the version under review. This documentation should be generated systematically, not written from memory. Most PLC programming environments support export formats that can be compared programmatically or through dedicated comparison tools. The diff output should be attached to the review record so that a reviewer who was not involved in authoring the change can understand exactly what was modified without having to perform their own comparison.

Version control for PLC logic in federal environments also intersects with Operational Technology (OT) Security requirements around configuration integrity. An unauthorized modification to a PLC program is a security event, not just an engineering error. The version control system should be access-controlled, and access logs should be retained. If a version of the logic exists in the field that does not match the approved baseline, that discrepancy needs to be investigated and resolved, not explained away.

Release Packaging and Deployment Gates

A release package is the complete set of artifacts that authorizes and enables a logic change to be deployed to production. It should be self-contained. The team deploying the change should not need to contact the authoring engineer, locate additional files, or make judgment calls about what version to deploy. Everything required should be in the package.

A complete release package includes the approved logic file with its version identifier, the peer review record with reviewer names and sign-off dates, the simulation test cases and results, the approval signatures from all required authorities, deployment instructions specific to the target controller, rollback instructions if the deployment fails, and a record of any deviations or exceptions that were granted during the review process.

Deployment gates are the checkpoints that must be cleared before the logic file is transferred to the production controller. A gate is not a rubber stamp. It is a verification step with a specific question and a documented answer. Common deployment gates include confirmation that the release package is complete, confirmation that the target controller’s current version matches the expected baseline, confirmation that the maintenance window is active and the appropriate personnel are present, and confirmation that the rollback procedure has been reviewed by the deployment team.

The following table compares key characteristics of informal versus structured PLC logic release processes to illustrate where governance gaps typically emerge.

Characteristic	Informal Release Process	Structured Release Process
Review authority	Authoring engineer self-approves or verbally confirms with a colleague	Defined reviewer and approver roles, documented sign-off
Simulation evidence	Not retained or described as a general statement	Test cases defined in advance, output logs retained as artifacts
Version control	File copies with informal naming, no baseline tagging	Structured naming, baseline tags at approval and deployment
Diff documentation	Not produced or described verbally	Systematically generated and attached to review record
Release package	Logic file only, context communicated verbally	Complete artifact set including review records, test evidence, and deployment instructions
Emergency change handling	No defined path, governance bypassed entirely	Expedited path with minimum review and mandatory post-deployment documentation
Audit readiness	Relies on engineer recollection and informal records	Self-contained release packages retrievable by version and date

Post-deployment verification is the final gate. After the logic is loaded to the production controller, the deployment team should confirm that the controller is running the correct version, that the program checksum or hash matches the approved release file, and that the system is behaving as expected in its initial operating state. This confirmation should be documented and added to the release record. The release is not complete until post-deployment verification is recorded.

Common Mistakes

The most common failure in OT PLC code review is treating it as a formality rather than a technical control. Teams go through the motions of a review, but the review is not structured against defined criteria, the reviewer does not have the time or access to examine the logic in depth, and the record produced is a signature on a form rather than evidence of a substantive check. When an incident occurs or an assessor asks for review evidence, the record does not support the claim that a meaningful review took place.

Simulation environments that are not maintained are a persistent problem. A simulation environment that was accurate when it was built but has not been updated to reflect production configuration changes will produce results that do not represent real system behavior. Engineers may know this and still use the environment because it is the only option available. The result is simulation evidence that provides false assurance. Maintaining simulation environment currency requires assigned ownership and a defined update process, neither of which happens automatically.

Approval authority that is not defined in advance creates negotiation at the worst possible time. When a change is ready for deployment and the maintenance window is approaching, the question of who needs to sign off should not be answered by whoever is available. Undefined approval authority leads to either over-approval, where changes are held up waiting for unavailable personnel, or under-approval, where changes are deployed without the required sign-off because the process was not clear.

Version control that exists in name only is another common gap. Teams may have a shared drive with logic file copies, but without structured naming, baseline tagging, and access controls, that drive is not a version control system. It is a file archive with no traceability. When a question arises about what version is running in production and how it differs from what was reviewed, the answer requires manual investigation rather than a query against a version control record.

Emergency changes that bypass governance entirely are the highest-risk failure mode. The pressure to restore a system quickly is real, and the instinct to skip review steps under that pressure is understandable. But an emergency change that is deployed without any review and without post-deployment documentation creates a production system that may be running logic that no one has verified. If that logic has an error, the next incident may be worse than the one the emergency change was meant to fix. An expedited emergency path that preserves minimum review and requires post-deployment documentation is not slower than no process. It is a process that can be executed quickly because it is defined in advance.

Treating RMF compliance as equivalent to operational assurance is a mistake that affects both cybersecurity and engineering teams. A system can be authorized under RMF and still have a PLC logic review process that would not survive operational scrutiny. RMF authorization addresses the security posture of the system at a point in time. It does not continuously validate that logic changes are reviewed, tested, and approved before deployment. Those controls require a separate, sustained process that operates at the engineering level.

Recommended Federal Approach

Start with a current-state assessment of how PLC logic changes are actually handled, not how they are documented in policy. Interview the engineers who make changes, the operators who work with the systems, and the cybersecurity personnel who are responsible for the authorization boundary. Identify where review steps are skipped, where evidence is not retained, where version control is inconsistent, and where approval authority is unclear. The gap between documented process and actual practice is where the risk lives.

Define the review criteria before building the review process. The criteria should be specific to the programming languages in use, the safety classification of the systems being modified, and the operational context of the facility. A review checklist for a safety instrumented system will look different from a checklist for a non-safety process control system. Both need checklists, but they should not be identical.

Establish the approval matrix as a program document with named roles, not named individuals. Roles persist when personnel change. An approval matrix that names specific people becomes invalid every time someone transfers or separates. Define the role, define the qualifications required to fill it, and document who currently fills it with a process for updating that record when personnel change.

Build or refresh the simulation environment before it is needed for a specific change. Simulation environments that are built under time pressure to support a specific change review are rarely representative of production configuration. Assign ownership of the simulation environment to a specific role, define the update cadence, and include simulation environment currency as a standing agenda item in engineering program reviews.

Implement version control with access controls and audit logging. The version control system should record who accessed or modified a logic file and when. Access should be restricted to personnel with a defined role in the review or deployment process. The production baseline should be write-protected after deployment, with any modification requiring a new review cycle.

Define the emergency change path in writing before an emergency occurs. The path should specify the minimum review required, the maximum time window for post-deployment documentation, and the authority who can invoke the emergency path. Test the emergency path in a tabletop exercise so that the team knows how to execute it under pressure. An emergency path that has never been practiced is unlikely to be followed correctly when the pressure is real.

Integrate the PLC logic review process with the program’s broader configuration management and RMF documentation. Logic changes that affect the authorization boundary, modify security-relevant functions, or change the system’s behavior in ways that affect the system security plan should trigger a notification to the ISSO. This does not mean every logic change requires a full RMF review. It means the cybersecurity team is not surprised by changes that affect their documentation.

Measure the process over time. Track how many changes go through the full review path versus the emergency path, how often simulation deviations are identified and resolved before deployment, and how often post-deployment verification identifies discrepancies. These metrics tell you whether the process is working and where it is breaking down. A process that is never measured is a process that drifts toward the path of least resistance, which in OT environments is the path of least governance.