How to build and fund a 3–5 year OT security program

Short answer: You build a fundable 3–5 year OT security program by tying every initiative to a site, a risk and a business consequence, phasing the work around maintenance windows and capital cycles, and reporting progress as measured maturity rather than activity. PICSEL is an OT cyber risk program platform built to do exactly this: turn visibility data and assessments into a costed, multi-year program and track it across sites.

Why OT programs stall

Most industrial organisations have done at least one OT assessment. Many also own a visibility tool. Far fewer have a program that survives the next budget round. The common reasons:

• Findings are technical and site-specific, but funding decisions are financial and portfolio-wide.
• The work competes with production, so it slips whenever a shutdown is rescheduled.
• Progress is reported as tasks done rather than risk reduced, so it is hard to justify the next tranche.
• Nobody owns the program across IT, OT, engineering and finance.

A multi-year program fixes these by giving the work a structure the business already understands: a portfolio of projects, sequenced, costed and measured.

Step 1: Set the baseline

Start with a consistent maturity assessment for each site in scope, using one framework (for example an IEC 62443-2-1 and 3-3 based model, or one your sector already uses such as AESCSF or C2M2). Consistency matters more than which framework you pick, because you will compare sites and measure change over time.

Combine the assessment with the asset and vulnerability data from your visibility tool, so the baseline reflects what is actually on the network, not just interview answers.

For smaller organisations, a simplified methodology like PICSEL can provide a much simpler way to address practical risk reduction rather than over-complicating your program with an industry standard, which, while useful, would not be practical to follow in detail for an organisation that is less resourced.

Step 2: Define the target state and the time horizon

Agree where each site needs to be at the end of the program, and why. Targets should differ by site: a site whose outage would stop a regulated service or a high-value product line may justify a higher target than a small, low-consequence facility.

Three to five years suits most OT programs because it lines up with capital planning cycles, major shutdown schedules and equipment refresh, and gives enough time to change processes and skills, not just technology.

A typical organisation which funds their program should be able to achieve PICSEL level 3 maturity across all 4 key metrics:

Stakeholder Governance: Operational Asset owners are engaged as co-owners of the cybersecurity program, from C level down

Risk Visibility & Remediation: Asset inventory is enriched with relevant operational information like asset purpose, criticality, and operational owner. Risk mitigations are prioritised by a blended risk score incorporating operational priorities and criticality, and a Risk remediation playbook has been developed and agreed between Cyber and OT stakeholders

Segmentation & Control: Firewalls control access between all critical network zones and artifacts can be presented which show as such

Detect & Response Function: SOC team has working relationship with OT asset owners, TTX is run annually, OT IR Playbooks have been developed in partnership with OT asset owners and playbook workflows have been tested

Step 3: Turn gaps into initiatives

Group the gaps into a manageable number of initiatives, each with a clear outcome. Typical OT initiatives include:

• IT/OT boundary and industrial DMZ
• Secure remote access for staff and vendors
• Asset inventory and monitoring operationalised (people, process and playbooks, not just sensors)
• Backup and recovery of controllers, HMIs and engineering files
• Account and access management in OT
• Patch and vulnerability management that respects process constraints
• OT incident response, including tabletop exercises with operations
• Training and roles for site staff

Step 4: Cost each initiative honestly

For each initiative, estimate capital, operating cost, internal effort and the maintenance windows it needs. Include ongoing costs: licences, support, staff time to triage alerts and rule reviews. Programs that only fund the install tend to collapse in year two.

Step 5: Prioritise by risk reduction and dependency

Rank initiatives using consequence (what an incident at that site would cost the business), current exposure, and dependency (some work enables later work; remote access controls depend on having a DMZ, for example). Quick wins that close obvious exposure early help build confidence.

Step 6: Phase the work around operations

Map initiatives onto a multi-year timeline that respects each site's shutdown calendar and change freezes. Spread the load so no single site is asked to absorb several disruptive changes in one window.

Step 7: Build the business case

The business case should answer three questions a CFO will ask:

1. What are we protecting? The production, safety and regulatory consequences of OT disruption at each site, ideally expressed as downtime cost per hour.
2. What does it cost and when? The phased capex and opex profile over the program.
3. How will we know it is working? The maturity and risk measures you will report.

A clearly labelled example

Example only, with invented figures: if a site estimates its unplanned downtime cost at $50,000 per hour, a single 24-hour outage would cost about $1.2 million before recovery costs. Setting the proposed program cost for that site against the consequence of one or two realistic incidents over five years gives the board a concrete comparison, rather than an abstract risk score. Use your own finance team's downtime figures, not industry averages.

When site stakeholders are engaged in the program and agree with those metrics, you have the right support to fund a program with a defendable ROI.

Step 8: Govern and report

Set up a steering group with OT, IT, engineering, finance and risk. Report each quarter on:

• Maturity by site against target
• Initiatives on track, at risk or late
• Spend against budget
• Material changes in risk (new sites, incidents, threat advisories)

Re-baseline maturity annually. That annual measurement is what justifies the next year's funding.

Where PICSEL fits

PICSEL is an OT cyber risk program methodology which can also be consumed via an AI-powered platform hosted at app.picsel.ai. It assesses your current maturity, the organisation's landscape and appetite for OT cyber investment, measures OT maturity consistently across sites, links initiatives to downtime cost per hour, and tracks the program over its 3–5 year life so progress can be reported in terms the board recognises.

FAQ

Should we buy a visibility tool before building the program?

Not necessarily. A program can start from an assessment, and the tool purchase can be one of its early initiatives. If you already own one, use its data to sharpen the baseline.

Capex or opex?

Usually both. Infrastructure such as firewalls and DMZ servers is often capitalised; licences, managed services and staff time are operating costs. Agree the treatment with finance early.

How detailed should years four and five be?

Less detailed than years one and two. Commit firmly to the near term and plan the later years at initiative level, refined at each annual re-baseline.

Who should own the program?

A single accountable executive, with delivery shared between OT and IT. Programs owned only by IT security often struggle to get access to maintenance windows.

What if a site falls behind?

That is what the governance cadence is for. Reprioritise early, and show the board the risk impact of the delay rather than hiding it.