Most OT security projects do not fail because of bad technology. They fail because of bad sequencing.
An IT security team arrives at a plant site with enterprise tooling, a change-control framework, and a 12-week rollout plan. Three months later, the project is dead. The engineers resisted. The network diagrams were wrong. The “supported” programmable logic controllers (PLCs) turned out to be 25-year-old controllers running unsupported firmware. The problem was not the tools selected, but the order in which the organization tried to use them.
The fix is a better order of operations. This framework was a central theme of our recent OT Resilience Blueprint webinar with Acronis and Guidepoint Security, and it’s worth unpacking in detail for teams that are earlier in that journey.
Crawl: Establish visibility before anything else
Before an organization can protect its industrial environment, it needs an accurate picture of what that environment contains. In most OT settings, that picture does not exist. There is no consistent record of what PLC firmware is running across sites, what code was last deployed to which device, or what changed during the lastest maintenance window. That lack of visibility is the underlying condition that makes OT environments difficult to defend, not the sophistication of the attackers targeting them.
The crawl phase addresses this directly. Deploy backup and version control on your highest-criticality assets. Get every PLC and controller into a system that timestamps changes, attributes them to a specific user, and produces a verified restore point. That is the scope of this phase: no sweeping policy rollouts, no hardware replacement programs.
Controls engineers and plant operations teams tend to embrace this step readily, because backup capability solves an operational problem they already have. When an engineer makes a configuration change that introduces an error, the ability to restore to a last-known good state is the difference between a 10-minute correction and a multi-hour production loss. Framing the crawl phase in those terms, rather than as a security mandate, can help drive adoption on the plant floor.
Walk: Apply governance where it matters most
Once baseline visibility is in place, the instinct is often to formalize change control across the entire environment at once. That approach consistently fails in distributed OT settings. Instead, identify the two or three processes where an unauthorized or erroneous change would carry the highest operational consequence: a temperature threshold in food and beverage production, a pressure control in an oil and gas facility, a chemical dosing sequence in water treatment.
Build change approval workflows around those specific processes first. Configure automated alerts so that when an unexpected modification is detected in a backup comparison, the appropriate personnel are notified before the change becomes an incident. When governance is proportionate to risk and scoped to what engineers recognize as genuinely critical, it’s followed. When it applies uniformly to everything, it gets routed around.
From this foundation, the deployment model established at pilot sites becomes repeatable. Organizations with mature programs reach the point where standing up a new site requires an afternoon, not a project plan.
Run: Build a resilience program on the foundation you’ve created
At the run stage, backup and version control become the operational backbone of a complete OT resilience program. An in-depth versioned audit trail provides the traceability needed for forensic investigation after an incident. Version history maps directly to compliance obligations under NIS2, TSA pipeline security directives, and IEC 62443. Recovery procedures can be validated in tabletop exercises designed around real OT failure scenarios, not adapted from IT playbooks.
At this stage, an organization can answer, in real time, exactly what code is running on every asset, what changed in the previous 24 hours, and how quickly any device can be restored to a verified state. That combination of visibility, traceability, and controlled recovery capacity is what operational resilience looks like in practice.
Where to begin
The organizations that make consistent progress in OT security share one characteristic: they do not attempt to address everything at once. They start with one site, demonstrate value to the engineering team, and use that foundation to expand methodically.
The crawl, walk, run model works because it’s structured around how OT environments actually operate, not around how IT security frameworks assume they do.
Watch the full OT Resilience Blueprint webinar to see how organizations are putting this framework into practice: Watch the webinar.
