Operating reality
Cyber risk has to be stated in process safety terms.
These sites already run a mature discipline for reasoning about low-probability, high-consequence events. Hazard studies, layers of protection and safeguard credits are established engineering language, understood by operations, by the regulator and by the insurer. A cyber risk register written in a separate vocabulary competes with that language instead of contributing to it, which is usually why it fails to attract funding.
The useful work is translation. A cyber scenario is expressed as an initiating event or as a challenge to a stated safeguard: what could cause the deviation, which independent protection layers are assumed to remain available, and whether a compromise of the basic process control system or of the systems around it could plausibly affect more than one of them at the same time. We do not perform HAZOP or LOPA studies, and we do not reopen process safety conclusions. We supply the cyber input those studies need and take their output as the ranking that drives remediation.
Two operational realities then shape delivery. The turnaround is the only honest change window, so scope must be defined and approved while the work list is still open. And contractor density is unlike any other sector: during a shutdown, large numbers of external people arrive with their own laptops, their own tools and their own connections, into an estate that already spans several control vintages and several vendors across upstream, midstream and downstream assets.
So the program is built around consequence, the turnaround calendar and access lifecycle — with the safety instrumented layer explicitly outside the boundary of anything active.
A cyber risk that cannot be written as an initiating event or a challenge to a named safeguard will never compete for money on a process site.
Operational priorities
Four things process programs have to get right.
These decide whether a process-sector program is funded and executed, well before any question of tooling arises.
01 · Speak the site's risk language
Cyber scenarios are written as initiating events and challenges to named safeguards, so they can be reviewed by the same people and in the same forum as every other process risk. That is also the form a regulator or an insurer can examine, rather than a maturity score with no consequence attached.
02 · Build the scope into the turnaround
Physical change happens in shutdown. Assessment therefore has to complete early enough for remediation to enter the work list as a costed job with a method statement, staged parts and an owner. Anything arriving after the work list closes waits for the next cycle.
03 · Control the contractor population
Third-party density is structural here and cannot be engineered away. It is managed as a lifecycle: who is granted access, to which zone, on whose equipment, brokered through what path, reviewed on what interval and revoked on what event. Turnaround peaks are planned for rather than absorbed.
04 · One standard across a mixed estate
Control vintages and vendors differ by unit and by site. The standard is written once, at the level of zones, conduits and required outcomes, then applied per platform, so a multi-site operator can evidence one position rather than defending a different answer at every asset.
In scope
Five environments we work in.
Safety instrumented systems are an absolute boundary. They are assessed by documentation and configuration review only, never interrogated live and never used as a cybersecurity testbed.
Process control and DCS
The basic process control system with its operator and engineering stations, controller networks, alarm management, and advanced process control or optimization layers where they are installed.
The question that matters here is not whether the basic process control system can be compromised, but what a compromise could initiate and which independent protection layers would still be available afterwards. We work from control system configuration, network drawings, firewall rule sets and passively collected traffic. No controller is polled, no alarm or interlock logic is altered, and nothing is done on a running unit outside your permit and management-of-change process.
Safety instrumented systems
Safety instrumented systems, fire and gas, and emergency shutdown, together with the separation between them and the basic process control system.
This is an absolute boundary. Review is by safety requirement specification, logic documentation, configuration exports and separation evidence only. Nothing is interrogated live, nothing is exercised, and no finding is ever demonstrated on a safety function. What that evidence does answer is whether independence is real or nominal — whether the same engineering workstation, the same credential, the same switch or the same remote path could reach both layers. Where it could, that is the finding, and it is a design conversation rather than a test.
Packaged units and skids
Compressor and dryer packages, analyzer houses, metering skids, burner management and vendor-supplied unit controls, each arriving with its own support agreement, connectivity assumption and patch position.
These are frequently the least examined systems on a site, because each was bought as a piece of equipment rather than as a control system. We review each package by configuration and by contract — what the supplier is permitted to connect to, what the skid can reach on the plant network, and whether its embedded switch bridges zones that were meant to stay separate. Zoning is then drawn around process dependency rather than around procurement history.
Plant network and historian
Plant networking and the industrial demilitarized zone, the historian, laboratory information and reporting systems, custody transfer and terminal metering data, and the interface to ERP and enterprise scheduling.
Integrity is as much at issue here as availability. Custody transfer figures, laboratory results and emissions records carry commercial and regulatory weight, so the questions are who can write to them, whether the flow is genuinely one-way where it is described as one-way, and what evidence exists that it is. We rebuild the boundary from firewall rule sets and routing, and give each permitted flow a direction, a purpose and a named owner.
Contractor and vendor access
Engineering workstations and project archives, jump hosts, turnaround contractor connections, and every standing remote path held by OEMs, integrators and specialist service providers.
Contractor density is structural in this sector and cannot be engineered away, so it is managed as a lifecycle: who is granted access, to which zone, on whose equipment, brokered through what path, reviewed on what interval, and revoked on what event. The design has to hold at turnaround peak rather than only in steady state, because that is when it is under most pressure and least supervised. Existing agreements are respected; changes are written so they can be raised at renewal or retender.
Related solutions
Where process engagements usually start.
Each stands alone. Most operators prove the method on one asset, time it to the next turnaround, and reuse the standard across the portfolio.
Questions from this sector
What process operators ask us before scope is agreed.
Our SIS is off limits. So what can you actually assess?
A great deal, and none of it requires touching the safety layer. From the safety requirement specification, logic documentation, configuration exports and separation evidence we can establish whether independence between the safety instrumented system and the basic process control system is real or only asserted — shared engineering workstations, shared credentials, shared network infrastructure, shared remote paths.
That is usually the finding worth having. A safety function that is sound in isolation but reachable through the same engineering path as the control system is not as independent as the safety case assumes, and establishing that costs nothing in availability.
We already run hazard studies. Why add a separate cyber assessment?
It should not be separate, and that is the point. We do not perform hazard or layer of protection studies, we do not reopen their conclusions, and we do not maintain a parallel cyber risk register in a vocabulary the site does not use.
What we supply is the cyber input those studies need — which scenarios are credible as initiating events, and whether a compromise could plausibly challenge more than one protection layer at once — and we take their output as the ranking that drives remediation. The work sits inside your existing process safety discipline rather than competing with it for attention.
The turnaround work list is already oversubscribed. Nothing new is getting on it.
Then the honest answer is to bid for very little of it. Most remediation is not shutdown work: access brokering, credential separation, firewall policy rebuilt from intent, backup and recovery, and monitoring can generally be delivered on a running unit under normal management of change.
What genuinely needs the turnaround is usually a small list — physical segmentation, cabinet and cabling changes, controller firmware where the vendor requires it. That list is written as costed, durationed jobs with method statements so it competes on the same terms as every other item, and it is presented while the work list is still open rather than after.
At shutdown we have hundreds of contractors on site. That cannot realistically be controlled.
Controlled individually, no. Controlled structurally, yes — and the sector already does this for physical access, permits and competence, which is the model worth extending rather than inventing something new.
The practical design is a small number of brokered routes rather than many bespoke ones, contractor equipment kept off the control network with access granted to a managed environment instead, entitlements tied to the permit and expiring with it, and revocation triggered by demobilization. The peak is planned for as a known event rather than absorbed each time.
Our DCS vendor tells us the system is secure because it sits on its own network.
That claim is worth testing on paper rather than accepting or dismissing. In our experience the control network is rarely as separate as the architecture drawing shows, because historian feeds, laboratory systems, metering exports, packaged skids and vendor support paths were each added afterwards, individually reasonable and never reviewed together.
Reachability is established from firewall rule sets, routing tables and configuration, not by probing the plant. If the separation holds, you have evidence for it. If it does not, you have a specific list of paths rather than a general worry.
Next step
Start with one unit, ahead of the next turnaround.
A single representative unit establishes effort, disruption and value, produces cyber input your hazard review can use, and gives the turnaround planner something costed rather than conceptual.
- No active scanning — passive collection and configuration review only
- SIS is an absolute boundary — documentation and configuration review only, never live
- Sequenced to the turnaround — scope closed while the work list is still open
- Contractor access managed as a lifecycle — granted, brokered, reviewed and revoked
- Vendor-independent — specifications written to be tendered competitively
Questions from this sector
What operators in this industry ask first.
What are the OT cybersecurity priorities in oil, gas, refining and chemicals?
Protecting safety instrumented systems and the integrity of the control layer around them, governing an unusually large contractor and vendor population, securing the paths between process control, the manufacturing execution layer and the enterprise, and preparing for recovery on assets whose maintenance windows are years apart.
How is safety instrumented system security handled?
Conservatively and with the process safety function in the room. A safety instrumented system is a protection layer, and any change to it is a safety change before it is a security change. InnovAKT's approach is to protect access to and around the safety system — engineering workstations, bypass management, network path, change authority — rather than to modify the system itself.
How do long turnaround cycles change the security program?
They make sequence decisive. Anything that requires a process interruption has to be identified years in advance and carried into the turnaround scope, or it waits for the next one. InnovAKT plans the program against the turnaround calendar and fills the intervening years with the substantial amount of work that does not need an outage.