Change management platforms were built for IT: tickets, approvals, CABs, and closure. Operational technology lives by different physics — changes to systems that run grids, plants, and safety functions carry consequences that make "move fast and roll back" a non-answer, and regulators (NERC CIP, IEC 62443-aligned regimes, sector-specific rules) sample the evidence accordingly. Regulated engineering teams keep discovering the mismatch the hard way: an IT-only platform manages their OT change workflow right up until an auditor asks for verification evidence, baseline linkage, or the approval trail behind an emergency change — and the generic tool has a ticket where a record should be.
This decision guide maps where OT change management genuinely differs, where IT-only platforms break, and the criteria for choosing a platform that governs both estates without doubling the stack.
Four requirements separate OT change management from generic ITSM. Verification as evidence: OT changes require demonstrated pre-change baseline state and post-change verification that security and safety controls still hold — recorded, not asserted. Consequence-weighted authorization: approval authority scales with operational impact, and the record must show the right authority acted, before implementation. Scoped audit trails: regulators sample by system ("changes to this relay network, this year"), so every record needs its system reference as data. Emergency discipline: OT's expedited paths still demand the full chain on a compressed clock, because "we'll document it after the outage" is where findings are born. None of these are exotic — they're evidence requirements, which is exactly what IT-only ticket platforms don't structurally hold.
The failure pattern is consistent: workflow succeeds, evidence fails. The ticket routed and closed, but the approval doesn't bind to the deployed artifact; the verification "happened" in a technician's notes; the baseline update lives in a separate tool with no link; and the deploy-to-change reconciliation across the OT estate is nobody's query. Generic platforms also mishandle the boundary in both directions — imposing OT ceremony on routine IT change (breeding route-around) or letting IT-speed defaults leak into OT scope (breeding violations). The tell in any evaluation: ask the vendor to produce a sampled change's full chain — scoping, authorization with role, verification evidence, baseline linkage — and watch whether the answer is a record or a workflow diagram.
The teams that solve this well don't run two platforms — they run one governance model with risk-classified profiles. Every change rides a structured change request carrying its system reference and classification; approval policies enforce the authority matrix each class demands — lightweight for corporate IT, consequence-weighted with verification requirements for OT-scoped systems; test and verification executions and monitoring integrations bind evidence at execution; and retention runs to regulatory lookback. The Release Compliance Dossier assembles chains in the scoped, submission-ready form OT audits arrive asking for, while compliance objectives keep both estates' control coverage visible continuously.
Five questions sort the market. Can the platform enforce different rigor by system classification — one model, two profiles? Do approvals record identity, role, timestamp, and artifact binding structurally? Does verification evidence attach to the change automatically, including from OT-side monitoring? Does the population reconcile — every deploy or implementation mapped to an authorized change? And will engineers and technicians actually work in it, or around it? Run the sampled-change drill against each candidate with your own scoping, in the data-request format your regulator uses. The platform that answers in minutes, with records, is the one that survives both estates.
OT change management differs from IT ticketing in what must be provable: verification, authority, scoping, and continuity — per change, years later. IT-only platforms manage the workflow and lose the evidence. Choose a platform where rigor is a policy profile and evidence is a structural byproduct, and one governance model can hold the whole estate — grid to git.
Four requirements: pre/post verification recorded as evidence, consequence-weighted authorization with the right authority acting before implementation, audit trails scoped by system, and emergency paths that produce the full chain on a compressed clock.
At evidence, not workflow: tickets close, but approvals don't bind to deployed artifacts, verification lives in technician notes, baseline updates float unlinked, and deploy-to-change reconciliation across the OT estate is nobody's query.
No — the working pattern is rigor profiles: one governance model where risk classification drives requirements, applying OT-grade verification and authority rules to scoped systems while routine IT change stays lightweight.
A sampled-change drill in your regulator's data-request format: scoping, authorization with role, verification evidence, and baseline linkage produced in minutes — plus the population reconciliation story and realistic technician adoption.