The five steps are documented. The technology has been selected. The first controls are in place. Now what? For many organizations, OT security is treated as a project that is considered "finished" at some point, until the next incident, audit, or organizational change. A program that truly stands the test of time works differently.

OT security is never finished

A project has a beginning, an end, and a delivery date. A security program does not. Threats evolve. The environment changes. Systems are replaced, suppliers change, and regulations become more demanding. What is sufficient today may no longer be enough two years from now.

Yet many organizations still approach OT security as a project. They invest in an initial assessment, implement a series of controls, report completion to the board, and then move on. Until something forces them to take another look: an incident, a NIS2 audit, or a new supplier requesting access to systems that were never intended to be accessible.

The difference between a project and a program is not the size of the investment. It is whether security is viewed as a state or a process. A state can be achieved. A process must be maintained.

The foundation: what needs to be in place before you can build further

Building an OT security program on unstable foundations rarely ends well. Before discussing maturity levels and multi-year plans, three things must be in order.

Visibility is non-negotiable. Without a current and complete inventory of all systems in your OT environment, every next step is based on assumptions. Know what is running, how systems are connected, and how critical each asset is. This is not a one-time exercise. Systems change, are added, and are replaced. Your inventory must evolve with them.
Ownership must be assigned. OT security traditionally falls between departments. IT often does not feel responsible for the production environment, while operations does not want security measures that could disrupt continuity. As long as nobody is ultimately accountable, progress remains limited. A sustainable program needs an owner, ideally someone who understands both operational requirements and security considerations.
Risks must be prioritized. Not everything can be addressed at once, nor should it be. What matters is having a clear understanding of which systems, processes, and risks deserve attention first. Priorities should be based on business impact, the likelihood of an incident, and the current security posture.

Setting priorities when you cannot do everything at once

Step four of the roadmap discussed in the first blog, setting priorities, sounds straightforward. In practice, it is often the most difficult part. Every department has its own sense of urgency. Budgets are limited. And risks can be difficult to quantify in an environment that may not yet be fully understood. A practical approach is to combine three questions: what is the impact, how likely is it to occur, and how manageable is the risk?

Impact: what are the consequences if this system fails or is compromised? Consider production downtime, safety risks, reputational damage, and potential NIS2-related penalties.
Likelihood: how probable is it that this system will be targeted or exploited? Systems with external connectivity, known vulnerabilities, or outdated software typically score higher.
Manageability: what effort is required to reduce the risk, and how quickly can it be done? A control that can be implemented quickly and cost-effectively may deserve priority over a major infrastructure change that requires a year of preparation, even if the latter addresses a larger risk.

Combine these three perspectives and you create a priority list that can be defended to the board, explained to operations, and realistically executed by the security team.

Measuring progress: what do you report to the board?

One of the most common mistakes is reporting progress in purely technical terms: how many systems have been segmented, how many alerts have been investigated, or how many vulnerabilities have been remediated. These metrics are useful for the security team, but they often mean very little to senior leadership. What executives want to know is simple: are we better protected than last year? Are we meeting our NIS2 obligations? And which risks still require conscious business decisions?

Maturity. To what extent does the organization align with recognized frameworks such as ISA/IEC 62443 or the NIST Cybersecurity Framework? A maturity model provides a structured view of where you are today and what the next step should be. That is often easier to understand than a long list of technical findings.
Incidents and near misses. Not as something to hide, but as a learning opportunity. How many anomalies were detected? How many were investigated? How quickly were they addressed? Trends reveal far more than absolute numbers.
Consciously accepted risks. Which risks remain in place because the cost of mitigation outweighs the potential impact or likelihood? Those decisions should be openly discussed at board level, not buried in a technical report.

What if operations pushes back?

An OT security program never exists in isolation. Operations teams have production targets. Budgets are constantly reassessed. And security measures that affect established working practices often encounter resistance. That is normal. And it is manageable, provided you work with operations rather than around them.

The key is early involvement. Do not wait until the security architecture has been designed before engaging operations. Instead, involve operators and process owners from the start. They understand the systems, know which connections are critical, and can identify where controls may affect day-to-day operations. Their input improves both the architecture and the implementation process.

It also helps to position security as an enabler of continuity rather than a restriction. An operator who understands that segmentation can contain an attack within a single zone, reducing the likelihood of a plant-wide outage, is far more likely to support the initiative than someone who sees it as yet another IT policy requirement.

From one-time project to ongoing program: the four pillars

An OT security program that lasts is built on four pillars, each of which requires continuous attention:

Measurement and improvement. Establish recurring activities such as quarterly risk reviews, annual asset inventory updates, and periodic penetration testing. Use these moments not only for reporting but also for continuous improvement. A program that only reports what has been done will never evolve.
People and awareness. Technology cannot prevent an operator from inserting an infected USB drive or clicking a phishing email. OT security awareness training should not be a one-off event but an ongoing part of the program, tailored to the specific risks of the environment rather than a generic IT security course.
Preparing for when things go wrong. Incident response in OT differs from IT. The primary objective is not preserving data but restoring safe operations. Organizations should regularly test their response plans, including the people who will be responsible for executing them during a real incident.
Keeping suppliers under control. Third parties with access to OT systems require continuous oversight. Maintain visibility into which suppliers have access, what systems they can access, and on what basis. Review access rights regularly and establish clear security requirements for every supplier that forms part of the OT ecosystem.

How Nomios and Fortinet help build and sustain your program

Building an OT security program requires the right expertise and the right technology. Maintaining it, continuously improving it, and making progress measurable is where many organizations struggle.

Nomios works with organizations across the energy, transport, healthcare, and industrial sectors to address exactly that challenge. We always start with visibility: a comprehensive assessment based on ISA/IEC 62443 that identifies vulnerabilities while also producing a clear and actionable list of priorities. From there, we develop an approach that aligns with operational reality: practical, phased, and defensible at board level.

On the technology side, we build on the Fortinet portfolio, from FortiGate Rugged solutions for segmentation to FortiAnalyzer and FortiNDR for continuous monitoring. But we also help organizations address the human and organizational aspects of OT security, including ownership, governance, reporting structures, and stakeholder alignment.

Would you like to understand where your organization stands and what the next step should be? Contact Nomios. Together, we can assess your current situation, identify the most significant risks, and define an approach that fits your organization.

Building a program that lasts

OT security is not a project with a finish line. It is an ongoing program that evolves alongside changing environments, emerging threats, and increasingly stringent regulations. Organizations that understand this build something sustainable. They measure, report, adjust, and involve the people who make the biggest difference: operators, process owners, and executive leadership. They do not view security as a cost to be minimized, but as a prerequisite for operational continuity.

This concludes our three-part series, but not the conversation. A program that lasts requires a partner that learns, adapts, and grows with you. Nomios is ready to help.

The previous blogs in the series:

Blog 1: OT Security in 2026: from blind spot to strategic priority

Blog 2: From air-gapped to connected: staying in control when isolation is no longer an option