Building an OT Security Program: Governance, Roles and the C2M2 Maturity Path

01Key takeaways

1. 01

   An OT security program is governance, not a product: it assigns accountability, sets policy, measures risk and drives improvement across the OT estate.

2. 02

   Clear roles matter most. IT, OT operations and engineering have different priorities, so a written RACI prevents controls from falling between the teams.

3. 03

   IEC 62443-2-1 defines the requirements for an industrial automation and control system security program; the DOE C2M2 gives a practical maturity path to score and improve it.

4. 04

   A program needs a multi-year roadmap tied to risk, a defensible budget, and a small set of metrics leadership can actually read.

5. 05

   Exposure reduction, including segmentation and one-way data flow, is a program decision, not just an engineering choice. The program defines which boundaries should be conduits, which should be one-way, and who approves changes.

02What is an OT security program?

An OT security program is the set of governance structures, policies, roles and processes that manage cyber risk to operational technology over time. It is the management layer above the individual controls. Where a project ends, a program continues: it owns the controls, reviews them, funds them and improves them.

The distinction matters because OT environments rarely fail for lack of products. They fail because no one owns the OT firewall ruleset, because the engineering team patches on a different schedule than IT expects, or because a vendor connection was approved years ago and never reviewed. A program closes those gaps by naming an accountable owner for every control and every boundary.

Short version: a program decides who is accountable, what good looks like, and how the organization gets there across the OT estate.

03Why a program matters more than another tool

OT and ICS environments have a different risk profile from IT. Systems run for a decade or more, patch windows are scarce, and an outage can affect safety, the environment or physical production. In that context, ungoverned security spending tends to produce a pile of partially configured appliances and no clear picture of residual risk.

Threat activity has made this concrete. Public incident reporting and the techniques catalogued in MITRE ATT&CK for ICS show adversaries pivoting from IT into OT, abusing remote access, and targeting engineering workstations. A program matters because it forces the organization to decide, before an incident, who responds, what is protected, and what level of risk leadership has accepted.

A program also answers the question regulators and boards increasingly ask: not which products do you own, but how do you manage OT risk as a discipline. That question cannot be answered by a tool. It is answered by governance, documented roles and a maturity trajectory.

04Roles: IT, OT operations and engineering

The single most common failure in OT security programs is unclear ownership. IT security teams understand controls but not the process; engineering understands the process but not the threat model; OT operations owns uptime and is wary of anything that risks it. A program succeeds when it names accountability explicitly and writes it down.

A practical pattern is a steering function at the top (often a CISO or a joint IT/OT security committee with plant leadership), an OT security lead who bridges the two worlds, and named control owners at each site. The RACI below is a starting point to adapt, not a fixed template.

IT security

Accountable for shared services, identity, the IT/OT boundary and enterprise monitoring. Consulted on OT-specific controls; not the owner of plant uptime.

OT operations

Accountable for availability, safety and the running process. Owns change windows and must approve any control that touches production.

Engineering / automation

Responsible for system design, configuration, vendor integration and the control logic. Owns asset knowledge that the program depends on.

OT security lead

Accountable for the program itself: policy, risk register, roadmap and reporting. Bridges IT and OT and escalates to the steering committee.

Executive sponsor

Accountable for funding and risk acceptance. Signs off the residual risk the program cannot economically eliminate.

05Policy, risk register and governance cadence

Policy is what makes the program durable when people change roles. An OT security policy set should state scope (which sites, zones and asset classes), the control baseline, the exception and risk-acceptance process, and the review cadence. It should be explicitly OT-aware: a policy copied from IT that mandates monthly patching of a safety PLC will simply be ignored.

The risk register is the program's working memory. Each entry ties a specific risk to an owner, a control, a treatment decision and a review date. The governance cadence then keeps it alive: a regular steering meeting reviews the register, approves exceptions, tracks roadmap delivery and reads the metrics. Without cadence, even a good policy decays into a document no one opens.

• Scope and asset classification, aligned to IEC 62443 zones and conduits.
• An OT-specific control baseline with realistic patch and change expectations.
• A documented exception and risk-acceptance workflow with an accountable signer.
• A living risk register with owners, treatments and review dates.
• A fixed governance cadence: steering reviews, metric reporting and roadmap checkpoints.

06Standards: IEC 62443-2-1 and the DOE C2M2

Two references shape most OT security programs. IEC 62443-2-1 specifies the requirements for establishing an industrial automation and control system (IACS) security program. It is the closest thing to a normative checklist for what an OT program must contain, from organizational security to risk management and control deployment. It pairs with the rest of the 62443 series, which covers zones, conduits and component requirements.

The DOE Cybersecurity Capability Maturity Model (C2M2) gives the program a maturity path. It organizes practices into domains such as asset, risk, access, situational awareness and response, and scores each at maturity indicator levels (MIL1 to MIL3). A self-evaluation produces a profile that shows where the program is strong, where it is thin, and what the next defensible step is. NIST SP 800-82 Rev. 3 provides the OT-specific control guidance that complements both.

IEC 62443-2-1

Defines what an IACS security program must include. Use it as the requirements checklist for program scope and content.

DOE C2M2

A maturity model with domains and MIL1-MIL3 levels. Use it to score the program and prioritize the next improvement.

NIST SP 800-82 Rev. 3

OT-specific tailoring of NIST controls. Use it to translate program decisions into concrete technical controls.

07Walking the maturity path

Maturity is a direction, not a finish line. A useful pattern is to run a C2M2 self-evaluation as a baseline, map the gaps against IEC 62443-2-1 requirements, and then sequence improvements by risk rather than by domain. Most programs find their lowest scores in asset inventory, third-party and remote-access management, and situational awareness, simply because those are the hardest to sustain in a live plant.

Resist the urge to chase the highest maturity level everywhere. A safety-critical zone may justify MIL3 practices for access and configuration management, while a low-consequence reporting path is well served at MIL1. The program's job is to set target maturity by zone and consequence, then close the gap that buys the most risk reduction per dollar.

Score the program, set target maturity by zone, and improve in the order that reduces the most risk, not in the order the domains happen to be listed.

08Roadmap and budgeting

A roadmap turns the maturity gap into a sequenced, multi-year plan. A common shape is three horizons: foundation (asset inventory, network visibility, basic segmentation, governance and policy), control (remote-access hardening, monitoring, backup and recovery, exposure reduction at key boundaries), and optimization (detection engineering, exercises, continuous measurement). Each item should trace back to a risk register entry.

Budgeting is where programs win or lose credibility. Tie spend to risk and to roadmap horizons, separate one-time capital (segmentation hardware, diodes, sensors) from recurring operating cost (monitoring, staffing, vendor support), and present trade-offs in business terms: consequence avoided, downtime risk reduced, compliance obligation met. A program that can show what each dollar buys in risk reduction is far easier to fund again next year.

• Foundation: asset inventory, visibility, baseline segmentation, policy and governance.
• Control: remote-access hardening, monitoring, recovery, exposure reduction at high-consequence boundaries.
• Optimization: detection engineering, tabletop and live exercises, continuous metrics.
• Capital vs operating split, so leadership sees both the build and the run cost.
• Every line item traceable to a risk register entry and a target maturity level.

09Where exposure reduction and one-way transfer fit

Reducing bidirectional reachability is one of the highest-leverage decisions a program makes, and it is a governance decision, not just an engineering one. The program should classify each boundary: which must remain a controlled two-way conduit, which can be made one-way, and which can be disconnected by default. That classification then drives the architecture, not the other way around.

For publication-only boundaries, OT telemetry to enterprise reporting, logs to a SOC, historian replication, backup movement, a one-way path removes the inbound route entirely rather than relying on policy to hold. A controlled connectivity pattern can be evaluated alongside firewall segmentation and data diodes as part of the same boundary decision. The program's role is to own that decision, document the residual risk and assign who approves any future change.

This is also where the program differs from a SOC. A SOC watches the traffic that exists; the program decides which traffic should exist at all. Removing an unnecessary path is usually cheaper and more durable than monitoring it forever, and it is the program that has the authority to make that call.

10Common pitfalls

Most OT security programs stall for predictable, organizational reasons rather than technical ones. Naming the failure modes early makes them easier to avoid.

• Copying an IT program wholesale, so patch and change requirements clash with safety and uptime.
• Leaving ownership implicit, so controls fall between IT, OT and engineering.
• Treating a tool purchase or an OT SOC as if it were the whole program.
• Chasing a high maturity level everywhere instead of targeting it by consequence.
• A risk register and policy set that exist on paper but are never reviewed.
• Metrics that count activity (alerts, scans) but never show whether risk is going down.

The common thread is governance, not technology. A program that has clear owners, an OT-aware policy, a living risk register and a regular review cadence will outperform one with better tools and weaker accountability.

11Metrics and closing thought

Leadership reads a handful of numbers, not a dashboard. Useful program metrics combine coverage, posture and outcome: asset inventory completeness, the share of high-consequence zones meeting their target maturity, the number of unreviewed remote-access and vendor connections, mean time to detect and recover in OT, and the count of accepted versus open risks. Each should trend over time and tie back to a roadmap item.

An OT security program is ultimately a promise that risk is being managed deliberately rather than discovered after an incident. Start with roles and a written RACI, anchor the requirements in IEC 62443-2-1, score maturity with C2M2, and let the roadmap and budget follow the risk. The boundaries you can make one-way or disconnect entirely are the cheapest risk to retire, so decide those early and govern them like everything else.

FAQFrequently asked questions

SRCSources of record