Most industrial asset owners probably need an OT security program. Few can describe what that actually means or would entail though, in operational terms.
And that’s not a fault. It’s a reflection of where we are as a community: numerous standards and frameworks, incomplete regulatory drivers, converging environments and an ecosystem of vendors and experts defining “OT security” in their own ways.
Well, asset owners should take the charge. YOU define it. It does not have to have every bell and whistle, nuance, boundary pushing, disruptive, untenable objective laid out in a multiyear Gantt chart sitting in a slide.
But as a founder and practitioner in OT security, I see this confusion play regularly. Clients often ask:
“How would we take on such a huge effort? We have a detection tool, asset inventory and a firewall. ”
“I’m compliant. Why would I need a program?”
“Who would own the program?”
These aren’t just tactical questions. They expose deeper issues:
1) We lack a shared operational definition of what constitutes an OT Security Program.
2) Most programs are reactive, checklist-driven, or inherited from IT.
What Should an OT Security Program Actually Consist Of?
At its core, a program should be a structured, continuously managed and consensus based approach to securing industrial operations in context of the business, processes, and physical outcomes they support.
Here’s a pragmatic framework to start with:
1. Mission and Operating Context
- What does “secure operations” mean for your organization?
- What uptime/downtime impacts can you afford?
- What are the real-world consequences?
- Who are the key stakeholders?
No tool, standard, or control matters if it doesn’t align with your operational reality.
2. Program Governance and Ownership
- Would would be the defined owner of the OT security program?
- Can cross-functional roles across engineering, operations, safety, and IT be supported?
- Can we budget, review, and plan the program regularly?
Governance is often a missing foundation. It is not the first step or only step but, it does protect the program from becoming “just a project.”
3. Risk-Based Framework Alignment
- Choose a standard that fits your regulatory and business needs: ISA/IEC 62443, NIST CSF 2.0, API 1164, C2M2, etc.
- Use it as a supporting structure. Don’t just treat it as a control checklist. But don’t make it everything your program is built upon or around. Compliance is a facet of a program, not a program itself.
- Define a maturity roadmap and baseline where you are today.
Make the framework your own, don’t just chase certifications. While NIST is a US-based entity, SP 800-82r3 content can apply to any organization anywhere. While 62443 is the gold set of standards, you don’t need to fully adopt and certify to everything. Pull some from one, some from the other and make your own.
4. Capability Development and Integration
An OT security program creates investment points f or building and operationalizing the core capabilities (not tools yet):
| Capability | Purpose |
|---|---|
| Asset Visibility | Discover what you have, active or passively. |
| Segmentation | Design zones and conduits, enforce boundaries. |
| Detection & Response | Adapt security operational practices supporting triage and mitigation. |
| Patch & Vulnerability Management | Use SSVC and other intuitive methods for OT specific Vuln and Patch management. Build them together. |
| Access Control | Consider what will actually work operationally. Don’t IT whack this on OT’s head. |
| Change Management | Control and communicate changes to OT environments. |
| Backup & Recovery | Operationally verified, not just “configured.” |
These are capabilities, not tools. Tools come after, and they are not “the program.”
5. Sustainability and Change Readiness
- Does your program adapt to M&A, new lines, or digitalization projects?
- Are contractors, integrators, and vendors integrated into your security lifecycle?
- How much is your partner building for you, so that you can run on your own later?
Programs that cannot evolve will eventually degrade.
Closing Thought: You Don’t Buy a Program, You Build It
No vendor, software, or framework can give you an off-the-shelf OT security program. Sure, you can start with one as a foundation. But unless your business is the exact same as every other other business, make it your own.
You need a program that reflects the uniqueness of your processes, your risks, your people and your ambitions for operational resilience.
Let’s get past assuming that deploying an asset inventory tool or passing an audit means you’re good to go. OT Security Programs can be the organizational muscle that protects your future of industrial operations.
Have thoughts or want to share your experience building OT security programs in your organization? Reach out or comment below.
