Operational technology (OT) is the hardware and software that physically runs your operations: the controllers on a production line, the sensors in a warehouse, the SCADA screens in a utility control room, the building-management system that keeps a hospital's air moving. It is not the laptops, email and finance software most people picture when they hear "technology." OT doesn't process invoices; it opens valves, moves conveyors and stops a machine before it tears itself apart.

For a COO, the payoff of getting OT right is concrete: fewer unplanned stoppages, machines that warn you before they fail, and a live picture of what your operation is actually doing. The risk of getting it wrong is just as concrete — a bad integration or a security gap can halt production for days.

This guide covers that specific layer: the systems that run the physical work. It is deliberately separate from the office and back-office software a COO also owns (closer to your core technology toolkit) and from the wider build-and-buy architecture decision in the tech stack blueprint. If your business moves atoms, not just data, a lot of your uptime and margin live here.

What operational technology actually is

OT is the layer that senses and controls the physical world. A programmable logic controller (PLC) reads a temperature sensor and decides whether to open a cooling valve. A SCADA system (supervisory control and data acquisition) gives operators the screens and alarms to watch a whole plant. Human-machine interfaces (HMIs) are the touchscreens on the floor. Industrial IoT sensors bolt onto older equipment to report vibration, pressure or energy use the original machine never measured.

Strong understanding here is a COO who can say, in plain terms, "these twelve lines run on PLCs from two vendors, our SCADA is version-locked to a 2014 release, and we have no sensors on the packaging equipment — which is exactly where our unplanned downtime is." Weak understanding sounds like "IT handles all our systems," which usually means nobody owns the shop-floor technology until it fails.

You do not need to program a PLC. You need to know what runs your critical processes, who supports it, and how exposed it is. The practical first move is a physical asset inventory: walk the floor with your maintenance lead and list every controller, HMI and networked device — its age, firmware, vendor, and what it connects to. Most operations discover devices nobody remembered installing.

Why a COO should care even outside heavy industry

OT is not only for factories. A cold-storage firm depends on refrigeration controllers. A hospital runs on building-management and medical-device networks. A retailer's distribution centre lives on conveyor and sortation controls. Even a modern office campus has HVAC, access control and elevators that are, technically, OT — and increasingly network-connected.

The COO-level question is the same everywhere: what physical process would stop the business if its controlling technology failed, and how well do we understand it? A firm that treats refrigeration monitoring as "facilities' problem" finds out during an outage that no one gets the 2am alert. A firm with strong OT ownership has named its critical systems, wired their alarms into an on-call rotation, and rehearsed what happens when they go dark — the same drawer as your business continuity planning, not a separate technical silo.

The IT/OT convergence problem

For decades OT and IT lived apart. OT ran on isolated networks, prized stability over updates, and measured uptime in decades. IT patched constantly and worried about data. Now the two collide, because everyone wants shop-floor data in their dashboards — and the moment you connect a PLC to a business network, IT's risks become OT's risks. Most integration mistakes come from applying IT habits to OT without translation.

Strong convergence is a joint IT/OT governance group with one clear owner, shared security policy, and a rule that no OT system gets patched or connected without operations signing off on the production risk. Weak convergence is IT quietly pushing an update to a controller during business hours and stopping a line — or operations plugging a sensor gateway into the network with no one in security aware it exists. Extend the same infrastructure governance that covers your data systems, carefully, to the shop floor.

Security: the part most COOs underestimate

OT security is dangerous in one specific way: many OT systems were designed when "the network" meant a cable inside a locked building. They often have hard-coded passwords, no encryption, and no ability to run modern security software. Connect them to a wider network and they become the softest target in the building.

Your job is not to run the security program but to insist it exists and fund it. Three moves do most of the work. First, network segmentation: OT on its own network, separated from IT and the internet by firewalls and a demilitarised zone, so a compromised laptop cannot reach a controller. Second, strict access control — who can connect a device, who can change a setpoint, and a log of both. Third, an OT-specific incident response plan, because "restore from backup and reboot" is not a strategy when the affected system is physically running a boiler.

A concrete example: a manufacturer lets a vendor connect a laptop for "remote support," the laptop carries commodity malware, and it spreads across a flat network to production controllers. The line stops for two days. Nothing exotic — a missing network segment and an unmanaged remote-access path. Treat OT with the same seriousness as the rest of your cybersecurity program, and know the standards auditors and insurers expect: IEC 62443 for industrial automation and the NIST Cybersecurity Framework.

Bringing legacy systems into the modern stack

Most OT work is not greenfield. You have a controller from 2009 that runs a critical process perfectly and speaks a protocol nothing else understands. The urge to "rip and replace" is usually wrong: the old system works, replacement is expensive, and every swap risks a new failure.

The strong pattern is to wrap, not replace. Use protocol gateways and middleware to translate a legacy device's output into a modern format your dashboards can read, without touching the control logic that keeps the process safe. Add non-intrusive sensors for data the machine never exposed. Document the legacy protocol and its quirks while the people who understand it are still around — undocumented tribal knowledge is a bigger risk than old hardware. The weak pattern is leaving everything undocumented, then discovering during a failure that the one engineer who understood the 2009 controller retired last year. When you do migrate, go one line at a time, with the old system kept ready to switch back to.

A phased approach that won't stop the line

OT projects rarely fail on technology; they fail on disruption. Your core constraint is that the operation must keep running while you change it. Phasing protects uptime, and each phase needs a clear owner and an exit test before the next begins.

The discipline that matters most is the pilot: prove the integration on something you can afford to lose before touching the line that ships your highest-margin product. Skip that to "save time" and you end up explaining a week of lost output. Staged rollout is also where good change management earns its keep — new screens and procedures land far better when operators helped shape them.

Choosing OT vendors and partners

OT vendor selection is a longer commitment than most software deals, because the equipment can outlive several management teams. The cheapest quote is rarely right; support, longevity and standards compliance matter more. Weigh candidates on real experience in your specific process (not a generic pitch), the protocols they support, their security track record, round-the-clock support, and an honest end-of-life roadmap. Ask pointed questions: how long will you support this product, what happens when a component goes obsolete, and can you show a reference site running it?

Fold OT suppliers into the same disciplined vendor management approach you use elsewhere — scored, reviewed, and never single-sourced for anything critical without a plan for the day that vendor disappears. Budget for total cost of ownership, not the sticker price: the purchase is often the smaller number next to training, integration, support and eventual upgrades. Hold a contingency reserve — a common rule of thumb is 15–20% — because OT work almost always uncovers something the site survey missed.

Measuring whether it's working

An OT investment that produces prettier dashboards but no better decisions has failed. Tie success to outcomes you already track: unplanned downtime, overall equipment effectiveness (OEE), mean time to repair, energy per unit, and safety incidents. If the sensors and controls are not moving those numbers, the project is not finished.

The high-value outcome is the shift from reactive to predictive. Strong integration means a vibration sensor flags a failing bearing days before it seizes, so you replace it during a planned window instead of an emergency stop. Weak integration means you collected the vibration data but no one built the alert, so the bearing still fails at 3am. Turning signals into decisions is the same muscle as the rest of your data-driven operations — the technology only pays off when someone acts on what it reveals.

Key takeaways

• OT is the technology that physically runs operations — controllers, sensors, SCADA, HMIs — and is distinct from office and back-office software.
• Start with an asset inventory. You cannot secure or improve equipment you have not listed and ranked by criticality.
• IT and OT are different disciplines; OT prizes safety and uptime over patching speed, and applying IT habits blindly causes most failures.
• Segment the OT network, control who can connect and change devices, and keep an OT-specific incident response plan.
• Wrap legacy systems with gateways and sensors rather than ripping them out, and document the old protocols before the experts retire.
• Phase every rollout, prove it on a non-critical pilot first, and keep a tested way to switch back.
• Measure OT against operational outcomes — downtime, OEE, safety — not against how good the dashboards look.

Frequently asked questions

What is the difference between OT and IT? IT manages data and information systems — email, ERP, laptops, servers — and optimises for confidentiality and frequent updates. OT monitors and controls physical equipment and processes, and optimises for safety and continuous availability. The practical difference: patching a laptop is routine, but patching a controller can stop production or damage equipment, so OT changes are rare, scheduled and tested. Does a COO in a non-industrial business need to care about OT? Yes, if any physical process would stop the business when its controlling technology fails. Refrigeration in cold storage, HVAC and medical devices in a hospital, conveyors in a distribution centre, and building systems in a large office are all OT. The test: list the physical systems whose failure would halt operations, and confirm someone owns each one, including its alarms and on-call response. Why is OT security treated separately from IT security? Many OT systems were built for isolated networks and lack encryption, modern authentication, or the ability to run security software. Connecting them exposes those weaknesses, and a breach can cause physical damage, not just data loss. That is why OT security leans on network segmentation, tight access control, and standards like IEC 62443, rather than simply extending office antivirus and patching policies to the shop floor. Should we replace legacy OT systems or keep them? Usually keep and wrap them. If a legacy controller runs a critical process reliably, replacing it is expensive and adds failure risk. The stronger approach is to use gateways and middleware to read its data into modern dashboards, add non-intrusive sensors, and document its quirks. Reserve full replacement for equipment that is genuinely obsolete, unsupported, or a security dead-end. How do we integrate OT without stopping production? Phase it. Inventory and rank your systems, design a tested rollback for every change, then pilot on one non-critical line before touching high-value production. Expand line by line during off-peak windows, proving stability at each step, and involve operators early so new procedures are adopted rather than resisted. The constraint that governs everything is that the operation must keep running while you change it. How do we know if an OT investment paid off? Tie it to metrics you already track: unplanned downtime, overall equipment effectiveness, mean time to repair, energy per unit, and safety incidents. The clearest sign of success is the move from reactive to predictive maintenance — being warned of a failing component in time to fix it on a planned window. If the data is collected but no one acts on it, the investment has not yet delivered.