ISA-95: the structural layer most Australian OT programmes skip

I’m kicking off a six-week OT re-architecture engagement this week. Before we touch a switch or firewall, the first sprint is functional hierarchy mapping. No exceptions, no shortcuts.

Most OT security programmes don’t do this. They reach straight for IEC 62443 zones and conduits, or for NIST CSF function-based controls, or for the CIRMP risk register, and they apply those controls to the asset list as it stands. The list is usually flat. A jump host sits next to a PLC sits next to a domain controller in the same Excel column.

The result is predictable. Audits surface gaps the team didn’t know existed. Incident responders find inter-level information flows that were never modelled. Re-architecture projects take twice as long because every decision is approximate.

The missing piece is structural. ISA-95 is what we use to put it back.

What ISA-95 actually is

ISA-95 is the international standard for enterprise-control system integration, formalised as IEC 62264. It’s not a security standard. It’s not a GRC framework. It’s a model for what each system in an industrial environment actually does and how information moves between them.

The functional hierarchy spans five levels.

• Level 0: physical processes. Valves, sensors, motors, the plant itself.
• Level 1: sensing and manipulation. PLCs, RTUs, intelligent field devices.
• Level 2: monitoring and supervisory control. HMIs, SCADA control, batch control.
• Level 3: manufacturing operations. Scheduling, dispatching, performance management, historians.
• Level 4: business planning and logistics. ERP, supply chain, financial systems.

That’s the whole model. Five levels. Each one defined by what it does, not what it runs on. A historian is Level 3 whether it lives on a SQL Server in a data centre or a PI server on a control network.

ISA-95 doesn’t tell you what to secure or how. It tells you what’s in your environment and how the pieces relate. That sounds basic. It’s the single most common gap I see in OT programmes that have already invested heavily in tooling.

How ISA-95 pairs with Purdue

The Purdue Enterprise Reference Architecture, adopted into ISA-99 and now woven into IEC 62443, gives you the network architecture: zones, conduits, the segmentation logic, the Industrial DMZ at Level 3.5, the data flows that should and shouldn’t cross level boundaries.

Purdue is the network view. ISA-95 is the functional view. They overlap at every level but they answer different questions.

When a project team treats them as the same thing, and most do, the gap shows up as soon as a control needs to be applied. “Where do we put MFA?” “On the jump host.” Right answer for the network architecture. Wrong answer for the functional hierarchy. The jump host’s Level 3.5 position is what makes it a Purdue concern. Its information-brokering role between Levels 4 and 3 is what makes it an ISA-95 concern. The right answer is both.

Mapping ISA-95 functional roles onto Purdue zones is the move most programmes skip. Once you’ve done it, control placement becomes mechanical. Skip it, and you’re guessing at every boundary.

Why GRC controls land badly without it

The frameworks Australian OT operators reach for all assume a functional hierarchy already exists.

IEC 62443 zones-and-conduits requires you to define the assets, the data flows, and the security level targets for each zone. Without ISA-95 you’re defining zones around physical proximity, which is rarely the right boundary.

NIST CSF paired with NIST SP 800-82 is built around function-based outcomes (Identify, Protect, Detect, Respond, Recover) applied to ICS-specific assets. Both halves of that pair lean on knowing what each asset does. Functional hierarchy first, then control mapping.

ASD’s Critical Infrastructure Risk Management Program assumes you can identify your asset register and the material risks across four hazard categories. That risk model is hard to operate against a flat list.

ISO 27019, the OT-specific extension to ISO 27002, assumes the operator has a documented process map. That’s an ISA-95 artefact.

In every case the GRC framework is the layer that sits on top. The structural layer underneath is non-negotiable. Skip it and the controls work in isolation but the programme doesn’t add up.

What it looks like in practice

We recently delivered a Proof of Concept for an Australian water and wastewater utility. The full case study is here: Water & Wastewater Utility – Secure SCADA Architecture. I’ll pull out the structural decisions because they show what ISA-95-led design produces.

Discovery surfaced a flat OT network. Enterprise identity ran into operational systems. Remote engineering access leaned on broad VPN trust. The asset list was a single column.

Before the team drew a single segmentation rule, every system was mapped to its ISA-95 functional level. The mapping made three things obvious.

The OT identity domain had to be separated from the enterprise identity domain. That decision wasn’t a security control choice. It was a functional necessity. Level 3 systems perform manufacturing operations functions. Authentication for those functions cannot share a trust boundary with Level 4 business systems that authenticate office users.

The Industrial DMZ at Level 3.5 stopped being a “where the jump host goes” question and became a defined functional role. Brokered, identity-aware, recorded. Every information flow between Levels 4 and 3 had to pass through it.

The architectural target became expressible. Purdue zones aligned to ISA-95 functional levels. Controls (MFA, application allowlisting, session recording, segmentation policy) mapped to the levels rather than the assets. The reference design now extends across the utility’s broader site portfolio with no further structural debate.

For the deeper architectural treatment, including Industrial DMZ design, control placement per Purdue level, and SOCI / CIRMP alignment, see our SCADA Security Design whitepaper.

Why S5 starts every OT engagement here

We don’t start with tooling. Vendor selection and the control catalogue come later. The first deliverable is always the functional hierarchy mapping.

That mapping is what makes everything else cheap. Once it exists, the GRC framework selection conversation gets short. IEC 62443 maps onto it. NIST CSF and NIST SP 800-82 map onto it. ASD CIRMP maps onto it. ISO 27019 maps onto it. The right framework for the customer is the one their regulators ask for, their executive sponsors understand, and their team can operate. That’s a business decision, not a structural one.

Without the mapping, the same conversation runs in circles. Teams compare IEC 62443 to NIST CSF as if they’re competitors. They aren’t. They’re different vocabularies for describing the same set of controls applied to the same functional hierarchy.

This is also why S5’s OT engagements deliver against multiple frameworks in parallel. We map once. The compliance evidence packs for SOCI, the security level claims for IEC 62443, and the function-and-category outcomes for NIST CSF all derive from the same architectural artefact.

What’s next

ISA-95 sets the structure. The next conversation is which GRC framework to lead with, and whether the answer is one framework or several mapped onto each other.

That’s the topic of the next post. We’ll work through how IEC 62443, NIST CSF with NIST SP 800-82, ASD CIRMP, and ISO 27019 actually compare for an Australian operator, where each one earns its place, and how to pick the lead framework without painting yourself into a corner.

Talk to our OT consulting team

If you’re sizing up your OT security programme, talk to our consulting team. We work across pre-CIRMP scoping, architecture reviews, and full re-designs. The starting point is always the functional hierarchy. Everything else is downstream.