PHMSA Control Room Management Enforcement in 2025: Insights from the Case Notes

In our previous post, PHMSA Control Room Management Enforcement in 2025: An Overview, we examined the volume and distribution of Control Room Management (CRM) enforcement actions opened in 2025. That first article established the numerical baseline: 15 CRM-related enforcement cases and 94 element-level findings under §192.631 and §195.446.

This second article moves from numbers to implications. Rather than focusing solely on counts, it examines what PHMSA cited in the case notes themselves and what those findings reveal about program design, implementation discipline, and audit readiness. As educators and subject matter experts, our goal is to help operators learn from enforcement activity — not only from their own inspections, but from the broader industry experience. In a final article next month, we will translate these insights into practical steps operators can take to strengthen their programs.

The observations below are drawn directly from the 2025 enforcement documentation and reflect patterns observed across several cases.

Demonstrating Implementation vs. Stating Intent

One of the most consistent patterns in the 2025 enforcement notes was not the absence of written plans, but the inability to demonstrate implementation following system changes.

Several actions centered on API RP 1165 implementation related to SCADA systems.

• In one warning letter issued to a gas operator, PHMSA noted that although the CRM Plan referenced API RP 1165, the operator could not demonstrate that newly deployed SCADA screens had been audited against their HMI philosophy or the applicable 1165 requirements. Simply referencing the standard was insufficient; inspectors looked for evidence that a governance framework existed, that baseline screen reviews had been performed, and that additions or replacements triggered documented review using defined criteria (often via an API RP 1165 checklist).
• In a separate notice of probable violation involving a liquid operator, PHMSA found that API RP 1165 Section 5 requirements related to display response and refresh rates could not be demonstrated as implemented following control room consolidation. While historical data refresh confirmation existed, there was no documented validation following subsequent system modifications.
• Another enforcement action identified that the CRM Plan referenced API RP 1165 but did not clearly define what constituted “added, expanded, or replaced” for purposes of triggering compliance activities. Regulatory language in procedures and forms did not align precisely with the rule.

Across these examples, enforcement attention focused on whether implementation requirements were clearly triggered, evaluated, and documented when systems were rolled out or modified. The recurring issue was not simply the presence of references to API RP 1165, but whether operators had built departmental and cross-departmental systems to ensure those requirements were executed every time a change occurred.

Control rooms are rarely static. SCADA systems are expanded, hardware is replaced, consoles are relocated, and software versions change. Each modification can trigger requirements under §192.631 or §195.446. Gaps often emerge not because operators lack policies, but because change management procedures are overly generic, siloed between departments, or field-driven without accounting for control room impacts. The work of engineering, SCADA, and control room teams must trigger coordinated actions within a defined workflow — and in many cases, those integrated workflows do not formally exist.

Over time, modifications accumulate. Without defined validation checkpoints embedded in the change process, required reviews — such as P2P verification, alarm rationalization, training updates, setpoint review, or API RP 1165 validation — may not consistently occur before assets are placed in service.

These findings reinforce an important distinction: it is one thing to have policy, another to execute it once, and far more robust to build systems that ensure execution occurs consistently and is demonstrable through records.

Point-to-Point Verification and Documentation Depth

Another recurring theme involved point-to-point (P2P) verification under §195.446(c)(2), particularly during expansions or system modifications.

• In one enforcement action tied to a pipeline expansion, PHMSA cited the operator for failing to provide documentation demonstrating that required P2P verifications were performed after new segments were added. Records confirming display and alarm verification between SCADA and field equipment did not exist.
• In a separate case, inspectors found that P2P procedures did not clearly require matching values between SCADA displays and field devices. Records that did exist lacked sufficient detail to demonstrate which displays were verified, what values were compared, or how discrepancies were resolved. Related recordkeeping deficiencies were also cited.

These findings reflect two distinct but related system issues:

1. Required records were not generated.
2. Records were generated but were incomplete due to insufficient procedural design.

Both point back to workflow structure and documentation systems. In one case, change triggers did not consistently produce verification records. In the other, the form and process were not designed to capture the necessary detail.

P2P verification is technical by nature, yet enforcement evaluation extends beyond execution to documentation sufficiency. These requirements often intersect with capital projects and equipment upgrades managed outside the control room organization. When documentation ownership is unclear, required verification can be performed but not properly captured — or captured inadequately.

P2P is therefore not merely a technical task. It is a compliance trigger that must be clearly defined, consistently executed, and structurally documented when required.

Role Clarity and Authority During Emergencies

Several enforcement actions focused on clarity and internal consistency regarding controller authority and restart decision-making.

• In one inspection, PHMSA identified inconsistencies between the CRM Plan and O&M Plan concerning restart authority after shutdowns. Documentation did not clearly define who could approve restarts, how decisions would be recorded, or how they would be communicated.
• Another action cited deficiencies under §195.446(b), noting that the CRM Plan did not clearly define the qualifications of individuals authorized to direct or supersede controller actions.

These findings did not arise from specific operational incidents. Instead, they addressed structural integration between documents.

PHMSA’s expectations are that CRM Plans, O&M manuals, emergency procedures, and related documents are well integrated. That means cross-references are intentional, authority definitions are harmonized, and control room requirements are substantiated across silos.

Ambiguity in authority documentation is not merely a compliance issue. The CRM safety program is designed to ensure safe and effective operations. Industry incidents have demonstrated that unclear restart authority or superseding control pathways can lead to operational risk. Enforcement in 2025 reinforced that governance architecture must be explicit, integrated, and consistently maintained.

Procedure Integration and Internal Consistency

Several enforcement actions revealed issues related to internal document alignment and procedural integration.

• In one case, the CRM Plan referenced multiple leak detection systems but did not clearly describe how different alarm types should be addressed. The CRM Plan and Alarm Management Plan did not consistently define expected responses, creating ambiguity in operational guidance.
• In another case, inspectors cited discrepancies in regulatory terminology and inconsistent language across plans and forms, suggesting that updates had not been synchronized across documents.

The distinctive issue in this section is not authority structure alone, but document harmonization across operational domains. Control room programs do not exist in isolation. They intersect with leak detection programs, alarm management plans, integrity management, and emergency response procedures.

When revisions occur in one program but are not reconciled in others, inconsistencies surface. Enforcement in 2025 demonstrated that inspectors evaluate not only whether procedures exist, but whether they form a coherent, internally consistent framework.

Compliance Validation and Record Demonstration

Across multiple enforcement actions, the ability to demonstrate compliance through records emerged as a recurring theme.

• In one inspection, procedures referenced API RP 1165 implementation, but no documented audit or review confirmed compliance.
• In another, P2P documentation was insufficient to demonstrate what was verified or how consistency was maintained.

Validation activities typically occur after system changes, training events, alarm configuration updates, monthly reviews, or annual compliance tasks. Records must be generated from those activities — not reconstructed later.

When documentation processes are informal, decentralized, or inconsistently owned, record retention becomes unreliable. Enforcement frequently hinges not on whether work occurred, but whether operators can produce clear, retrievable documentation demonstrating that required work was completed and evaluated.

Compliance validation is therefore inseparable from operational execution. It is the structured proof that execution occurred.

Program Structure Under Change: What the 2025 Case Notes Suggest

Viewed collectively, the 2025 enforcement actions reveal a structural pattern.

Individually, the cases addressed API RP 1165 implementation gaps, P2P verification deficiencies, authority inconsistencies, document misalignment, and recordkeeping shortcomings. Together, they indicate that enforcement scrutiny focused on whether operators had developed systems that ensure policy outcomes are consistently achieved and not simply stated.

It is far more resilient to build systems that ensure the task is executed correctly every time, with documentation that demonstrates it.

Across multiple inspections, findings intersected with operational change — SCADA upgrades, pipeline expansions, consolidations, and procedural revisions. When operators rely primarily on individual awareness or manual coordination during change, gaps can occur. Systems must hold up to policy commitments and regulatory requirements when change introduces complexity.

The cases do not suggest that operators lacked a Control Room Management plan entirely. Rather, they show that systems sometimes failed to ensure synchronization across technical, procedural, and governance layers during change.

Control Rooms function as layered systems integrating technical infrastructure, procedural frameworks, governance architecture, and validation mechanisms. When one layer changes, the others must adjust in parallel.

Closing Perspective

Taken together, the 2025 enforcement record reinforces a practical reality: sustainable CRM compliance depends on structured workflows with clear ownership, defined triggers, and reliable status visibility.

Operators benefit from asking:

• Do our change management workflows explicitly trigger CRM validation tasks?
• Is ownership defined across engineering, SCADA, and control room functions?
• Do we have a reliable way to track completion and quality of required activities?
• Can we demonstrate compliance without reconstruction?

Ultimately, this is about building systems that integrate policy, workflow, documentation, and oversight into a cohesive compliance support program.

The 2025 case notes provide insight into where systems broke down. They also point toward where stronger integration, ownership clarity, and workflow visibility can strengthen both compliance and safe operations.

In our next and final article in this series, we will move from structural observations to practical application — outlining specific, actionable steps operators can take to institutionalize change-triggered compliance, strengthen cross-department workflows, and improve visibility into program status and performance. The goal is simple: translate enforcement insight into operational discipline that supports both audit readiness and safe, effective control room operations.