The Missing Layer in OT Cyber Governance

Most organisations have completed an OT security checklist at some point. They have a list of controls, some in place and some not. The assessment report is filed. The remediation roadmap is produced. And then, in most organisations, the programme quietly loses momentum. The checklist was necessary. It was not sufficient. The missing layer is not the assessment. It is the continuous governance that should follow it.

What the assessment produces and what it does not

A well-executed OT cyber assessment produces a scored baseline, an identified list of gaps with severity and priority, a recommended remediation sequence, and evidence collected during the assessment process. What it does not produce is any mechanism for tracking what happens next.

The gap register lives in a PDF. The evidence collected is not maintained. The maturity score calculated on day one does not update when gaps are closed. By the time the next annual review arrives, the organisation often has to reconstruct what it did and collect fresh evidence, because nothing was maintained in the interim.

Why this matters

A board asked whether security posture is improving cannot be answered with "we did an assessment 11 months ago." A regulator asking for evidence of CIRMP compliance cannot be satisfied with a report from the previous financial year. A cyber insurer needs current evidence of controls in place.

The organisations that answer these questions credibly are those that have not just assessed their security posture but built a system for managing it continuously.

What the missing layer looks like when it is in place

Continuous OT cyber governance has three components.

A live gap register. Every gap identified in an assessment is tracked until closed. New gaps identified outside an assessment cycle are added. Status is current. When a gap is closed, evidence is attached and the record is updated.

Evidence management. Proof that controls are in place is stored in a structured, versioned repository. Evidence is dated. When configurations change, evidence is updated. The vault is accessible for audit at any time.

A maturity score that reflects the current state. Not the state on the day of the last assessment. The current state, updated as gaps are closed and evidence is submitted. Leadership can see whether the programme is improving between formal assessment cycles.

How IEC 62443 structures this

IEC 62443 does not only describe what controls should be in place. It describes how those controls should be managed over time, through its Maturity Level model. A control at ML-2 is documented and consistently applied. At ML-3, it is standardised across the organisation. At ML-4, it is measured and continuously improved.

Moving through maturity levels requires exactly the continuous governance infrastructure described above. It is not possible to sustain ML-3 governance using annual assessments and spreadsheets. It requires a managed programme with the systems to support it.

What Is OT Cyber Maturity?

OT cyber maturity describes how systematically and consistently an organisation manages the security of its operational technology environment. It is not a measure of how many security tools have been deployed. It describes the quality and consistency of the entire security management programme over time.

Maturity versus compliance status

A compliance status tells you whether a specific control was in place on the day it was checked. Maturity describes whether your organisation has the capability to maintain and improve that control over time. An organisation can achieve compliance status through a one-time effort. It cannot achieve maturity without sustained programme management.

The difference is significant to boards, regulators, and insurers because it distinguishes organisations that will maintain their security posture from those that will drift back to their previous state within 12 months.

What the maturity levels describe

IEC 62443 defines four Maturity Levels that describe how formally and consistently security practices are applied.

• ML-1 (Initial): Security practices exist but are ad hoc and informal. Controls are applied inconsistently across the organisation.
• ML-2 (Managed): Security practices are documented and followed consistently within individual teams or sites.
• ML-3 (Defined): Practices are standardised across the entire organisation and applied consistently at every site and asset.
• ML-4 (Improving): Practices are continuously measured, reviewed, and improved based on performance data.

Most industrial organisations in Australia fall somewhere between ML-1 and ML-2. Controls exist. Some are documented. Very few organisations have a programme at ML-3 or above.

What improving maturity looks like in practice

Moving from ML-1 to ML-2 involves documenting which controls exist, assigning ownership for each control, and establishing a repeatable process for verifying that controls are still functioning.

Moving from ML-2 to ML-3 involves standardising the security programme across all OT sites and assets, establishing governance oversight at the programme level, and creating consistent evidence collection and review processes.

Moving from ML-3 to ML-4 involves measuring security performance using defined metrics and using measurement data to prioritise improvement activities on a continuous basis.

Why Point-in-Time Assessments Are Not Enough

An annual OT security assessment produces a snapshot of security posture on one specific day. That snapshot is valuable. It provides a structured baseline, identifies gaps, and gives an organisation something concrete to act on. The problem is what happens next, or more precisely, what does not happen next.

The decay problem

Security posture decays. Controls that were in place during an assessment may not be functioning correctly six months later. A firewall rule correctly configured during the assessment period may have been modified for a maintenance job and never restored. An account correctly deactivated may have been recreated to support a vendor visit.

OT environments change more slowly on average but change without formal change management more often than IT environments. Plant modifications, equipment upgrades, and maintenance activities routinely alter the network environment without going through any formal change process. The assessment report describes what existed on a specific date. It does not describe what exists today.

What annual assessments cannot provide

Annual assessments cannot answer the questions that boards, SOCI Act regulators, and cyber insurers increasingly ask.

• Are the gaps identified last year being closed, and at what rate?
• Have new gaps opened since the assessment?
• Is evidence of compliance current and accessible?
• Is security posture improving or degrading?
• Who owns each gap and when is it expected to close?

An annual assessment report provides a partial answer to the first of these questions, once a year. It does not address the others.

The alternative is not more frequent assessments

The answer to the limitations of point-in-time assessment is not to run assessments quarterly. Structured assessments are resource-intensive and operationally disruptive. The answer is a persistent management system that tracks the state of each control continuously.

Annual assessments remain valuable as a structured baseline exercise. They should be the input to a continuous management system rather than the sole output of an OT security programme.

Understanding IEC 62443 in Practical Terms

IEC 62443 is the international standard for cyber security in industrial automation and control systems. For Australian operators of industrial infrastructure, it is the most comprehensive and widely recognised technical framework for OT cyber security. This article explains what it requires in plain language.

What the standard covers

IEC 62443 is organised into four series. Series 1 covers general concepts and terminology. Series 2 covers policies, procedures, and programme requirements including how to manage a security programme. Series 3 covers system-level security requirements including how to assess risk and what security capabilities a system must have. Series 4 covers component-level requirements for individual products.

Most organisations focus primarily on Series 2 and Series 3, which define what a security programme must do and what a system must be capable of.

Security Levels: what level of protection is required?

IEC 62443 uses Security Levels to describe the threat a system is designed to withstand. SL-1 protects against casual or accidental violations. SL-2 protects against intentional attacks using simple means, and is the minimum expectation for most connected industrial environments. SL-3 protects against sophisticated attacks with moderate resources, appropriate for critical infrastructure with a credible threat of targeted attack. SL-4 protects against state-sponsored attacks.

The target Security Level for a given system is determined through a risk assessment considering the consequences of a successful attack and the capability of likely attackers.

Foundational Requirements: what must a secure system do?

IEC 62443-3-3 defines seven Foundational Requirements. Every specific security control maps to one of these.

• FR-1: Identification and Authentication Control
• FR-2: Use Control (least privilege and authorisation)
• FR-3: System Integrity
• FR-4: Data Confidentiality
• FR-5: Restricted Data Flow (zone and conduit management)
• FR-6: Timely Response to Events
• FR-7: Resource Availability

Zones and conduits: how IEC 62443 structures the network

IEC 62443 requires assets to be grouped into security zones based on their security requirements and trust level. Communication between zones occurs through defined conduits with controlled and monitored traffic. Zone and conduit design maps directly onto the Purdue Enterprise Reference Architecture, which organises industrial networks into levels from field devices at Level 0 to enterprise IT at Level 4, with a critical Industrial DMZ at Level 3.5.

Zone definition forces an organisation to answer the fundamental question of OT security: which assets need to communicate with which others, and what controls should govern those communications?

What SOCI Means for OT Operators

Australia's Security of Critical Infrastructure Act 2018, amended significantly in 2022, places specific legal obligations on operators of critical infrastructure assets. Many organisations are aware the Act exists but uncertain about what it requires in practice. This article covers the key obligations for OT operators.

Who the Act applies to

The SOCI Act applies to operators of assets in 11 sectors: communications, data storage and processing, defence industry, energy, financial services and markets, food and grocery, health care and medical, higher education and research, space technology, transport, and water and sewerage.

Within each sector, the Act applies to assets meeting specific criteria set out in the Critical Infrastructure Rules. For energy, this includes electricity generation assets above certain capacity thresholds, electricity networks, and gas pipelines. For water, it covers systems serving populations above defined thresholds. Operators should confirm with the Department of Home Affairs whether their specific assets meet the criteria.

The CIRMP requirement

The most significant obligation for most operators is the development and maintenance of a Critical Infrastructure Risk Management Program. A CIRMP must identify hazards across four categories: cyber and information security, physical and natural hazards, supply chain risks, and personnel risks. It must assess the associated risks, implement mitigations, include a governance structure with clear ownership, be reviewed and updated at least annually, and be approved by the board or governing body.

Incident reporting obligations

Serious cyber incidents must be reported to the Australian Signals Directorate within 12 hours of the operator becoming aware. Other significant cyber incidents must be reported within 72 hours. These timelines apply regardless of whether the incident is confirmed or suspected. Source: Security of Critical Infrastructure Act 2018, Part 2B.

The link between SOCI and IEC 62443

The CIRMP must address cyber and information security risks. IEC 62443 provides the most comprehensive and internationally recognised framework for doing so in OT environments. Using IEC 62443 as the technical basis for the CIRMP cyber component allows organisations to demonstrate that their approach is grounded in established engineering standards rather than self-defined criteria.

The Difference Between OT Security and OT Cyber Maturity

These two terms are often used as though they mean the same thing. They describe different things. Understanding the difference is important for anyone responsible for OT security governance because the two states require very different programmes to achieve and maintain.

OT security: the controls in place

OT security describes the set of technical and procedural controls protecting an operational technology environment. Firewalls, network segmentation, access controls, patch management, monitoring systems. Having these controls is necessary. An organisation without security controls has no foundation to build on.

OT cyber maturity: how those controls are managed

OT cyber maturity describes how consistently those controls are applied, how well they are documented, how actively they are monitored, and whether the programme as a whole is improving. It is not enough for a firewall to be running. The processes for reviewing its rules, updating its firmware, logging and reviewing its alerts, and verifying it is correctly positioned in the network architecture are all governance activities that determine the maturity of the control, not just its presence.

An analogy that clarifies the distinction

An organisation can have a fire suppression system without having a fire management programme. The suppression system might work perfectly. But without regular testing, documented maintenance records, trained staff, and a review process, the organisation cannot demonstrate to regulators or insurers that the control will continue to function. The control exists. The governance of the control does not.

OT cyber security is directly analogous. A firewall is a control. The programme managing that firewall determines its maturity.

Why the distinction matters

Boards need to know that security posture is being actively managed, not just that controls were deployed at some point in the past. Regulators under the SOCI Act require a CIRMP demonstrating active risk management. Cyber insurers assess the maturity of a security programme, not just the presence of controls, when pricing coverage.

An organisation with a mature programme and modest controls is better governed than one with sophisticated controls and no programme management. The mature organisation can demonstrate its posture. The technically sophisticated but ungoverned organisation cannot.

How to Build an IEC 62443 Improvement Roadmap

An IEC 62443 assessment identifies gaps. A roadmap turns those gaps into an actionable, sequenced programme of work with defined milestones, ownership, and governance checkpoints. Without a roadmap, a gap register is a list of problems with no plan to solve them.

Step 1: Understand the full gap picture

Before sequencing remediation, understand what you are working with. An IEC 62443 assessment produces gaps rated by control domain, control weight (how much the control contributes to the overall Security Level score), and effort to remediate. You need all three dimensions to sequence intelligently. A high-weight, low-effort gap should be addressed before a low-weight, high-effort gap even if the latter appears more prominent in the report.

Step 2: Set a target Security Level

Remediation should be sequenced against a defined target Security Level. A Tier 1 utility with SOCI Act obligations targeting SL-2 needs to prioritise differently than a manufacturing site with no regulatory obligations targeting SL-1. The target Security Level determines which gaps are critical to close and which can be addressed over a longer timeframe.

Step 3: Prioritise by risk and operational impact

Not all gaps carry equal risk. Gaps in access control, zone segmentation, and authentication carry higher operational risk and should be addressed first regardless of effort. Controls that are technically straightforward to implement but carry high risk should be prioritised over controls that are complex but lower risk.

Step 4: Sequence by dependency

Some remediation activities are prerequisites for others. Zone segmentation must be designed before firewall rules can be written. Asset inventory must be complete before access control can be comprehensively applied. Map these dependencies and sequence accordingly so that earlier activities enable later ones.

Step 5: Assign ownership and target dates

Every item in the roadmap needs an owner and a target completion date. Without ownership, accountability is diffuse and nothing gets prioritised. Without dates, there is no mechanism to identify when the programme is falling behind.

Step 6: Treat the roadmap as a living document

Schedule regular reviews of roadmap progress. Track closure of each item with evidence. When a gap is closed, attach the evidence and update the maturity score. Report progress to leadership at defined intervals. The roadmap is a governed programme of work, not a static document produced at the end of an assessment and filed away.

Common Findings from OT Network Reviews

Across OT network assessments conducted in mining, utilities, and critical infrastructure environments in Australia, the same gaps appear consistently. Understanding the most common findings gives operators a realistic starting point for self-assessment before a formal review is commissioned.

Zone segmentation gaps (most common critical finding)

The most consistently identified critical gap is the absence of proper network segmentation. Many OT environments operate on flat Layer 2 topologies where all devices share a single network segment. PLCs, SCADA servers, engineering workstations, and historian servers all communicate without any access control boundary between them.

IEC 62443 requires assets to be grouped into security zones with controlled conduits between them. The Purdue Model defines the reference architecture. Most organisations assessed fall significantly short of this model, often because the network was designed for operational efficiency and segmentation was never added.

Remote access deficiencies

Remote access to OT systems is frequently found to be poorly controlled. Common findings include consumer-grade remote access tools installed directly on OT workstations without formal approval, VPN access without multi-factor authentication, persistent remote access sessions that are never terminated, and vendor access credentials that are shared across multiple individuals and never rotated.

Patch management gaps

OT environments frequently contain end-of-life equipment running operating systems and firmware that have not been patched in years. The challenge is that many of these systems cannot be patched without vendor involvement and cannot be taken offline without disrupting operations. The result is known, unpatched vulnerabilities that cannot be quickly remediated and must instead be managed through compensating controls such as network isolation.

Unknown controls

A significant proportion of IEC 62443 controls are answered as "Unknown" in most assessments. The organisation does not know whether the control is in place. Unknown controls represent areas where no visibility exists. An organisation cannot manage what it does not know, and unknown controls often represent the largest single category of risk in an assessment.

Incomplete asset inventories

Incomplete asset inventories are effectively universal. OT environments accumulate assets over years without formal change management. Shadow devices, legacy endpoints, and vendor-installed equipment are routinely found outside any register. Without a complete inventory, zone boundaries cannot be correctly defined, patch status cannot be verified, and access control cannot be comprehensively applied.

The Role of Evidence in OT Cyber Governance

Evidence is what turns a security claim into a security fact. An organisation can claim that multi-factor authentication is enforced on all remote access to OT systems. The evidence is the configuration records, the access policy document, the audit logs showing MFA-enforced sessions, and the periodic review records confirming the configuration is current. Without evidence, security claims are assertions. With evidence, they become defensible statements.

What evidence is

Evidence in OT cyber governance is any artefact that demonstrates a security control is in place, correctly configured, and functioning as intended. Evidence can include configuration screenshots or exported files, policy and procedure documents, audit logs, test results from security reviews, change management records, training completion records, and vendor certification documents.

Evidence must be dated so it can be shown to be current, specific to the control it supports, retained in a location accessible for audit, and versioned so that changes to configurations can be tracked over time.

What evidence is not

Evidence is not a verbal confirmation that a control exists. It is not a consultant's attestation that something was in place on the day of an assessment. It is not a slide from a board presentation stating that controls have been implemented. None of these can be independently verified against a specific date and configuration state.

How evidence decays

Evidence has a shelf life. A configuration screenshot from 18 months ago does not demonstrate that the configuration is still in place today. A policy document approved two years ago may not reflect current practices. Audit logs that were not retained are gone permanently. For evidence to remain valid, it must be refreshed on a defined cycle matched to the nature of the control it supports.

Why evidence management matters

When a regulator asks for evidence of CIRMP compliance, an organisation needs to produce it quickly and in an organised form. When a cyber insurer assesses coverage, it reviews evidence of control implementation. When a board wants assurance that security posture is being maintained, it needs access to current evidence.

Organisations that have been collecting and organising evidence consistently can respond to these requests efficiently. Organisations relying on assertions face a scramble to find documentation that may not exist.

What Does Good OT Cyber Governance Look Like?

Good OT cyber governance is not defined by the sophistication of the security controls deployed. It is defined by the quality of the programme managing those controls over time. This article describes what a credible governance programme looks like from the perspectives of a board, a regulator, and a cyber insurer.

From the board's perspective

A board fulfilling its governance obligations over OT cyber risk needs a regular, consistent view of the organisation's security posture, confidence that identified risks are being actively managed, evidence that the programme is improving over time, and clear ownership of the programme at the executive level.

Good governance means the board receives a regular report showing the current maturity score, the status of the remediation programme, and the trend over time. It does not receive a single annual assessment report and nothing else for 12 months.

From a regulator's perspective

A regulator assessing CIRMP compliance looks for a documented risk management programme with defined scope, evidence that hazards have been identified and assessed, evidence that mitigations have been implemented, a record of the annual review, and clear accountability for the programme. Good governance means the organisation can produce this evidence on request without a weeks-long preparation exercise.

From a cyber insurer's perspective

Cyber insurers assess governance quality when pricing coverage. They look for evidence of a structured security programme, documentation of controls in place, evidence that controls are tested and verified periodically, and a record of how incidents and near-misses have been handled. Organisations with mature governance programmes typically access better coverage at lower premiums than those that cannot demonstrate programme quality.

What mature governance looks like in practice

• A complete, current asset inventory with assigned owners for every device
• An active gap register tracking every identified deficiency through to closure
• An evidence management system with organised, dated, versioned artefacts
• A maturity score that updates as improvements are made
• Defined reporting to the board on a regular cycle with trend data
• A clear improvement roadmap with milestones and accountability
• An annual review process that updates the programme based on changes in the environment and threat landscape

Moving Beyond Spreadsheets for OT Security Management

Spreadsheets are the default tool for OT security management in most organisations. Gap registers, action trackers, evidence lists, and maturity scoring models are typically built in Excel. The spreadsheet approach works for a single assessment cycle. It breaks down as a governance tool at any level of sustained programme maturity.

Why spreadsheets fail as governance tools

Spreadsheets are static documents. Each version is a snapshot of the state at the time it was saved. Managing an OT security programme in a spreadsheet consistently produces multiple versions in circulation with no single authoritative source, evidence references pointing to files that have been moved or renamed, maturity scores nobody recalculates because the formula is complex or broken, action tracking that falls out of date because updates are manual and ownership is unclear, and no audit trail showing who changed what and when.

The fundamental problem is that a spreadsheet is a document, not a system. A governance programme needs a system where the current state of every gap, every action, and every piece of evidence is always visible, always current, and always attributable.

What a purpose-built system provides

A system designed for OT cyber maturity management provides a single source of truth for the gap register accessible to all relevant stakeholders, evidence management with upload, versioning, and audit trail, a maturity score that recalculates automatically as evidence is submitted and gaps are closed, action tracking with ownership and due dates that does not require manual spreadsheet updates, and reporting outputs that can be generated at any point in the year.

The governance benefit

The primary benefit of moving to a system is not efficiency, though efficiency improves significantly. It is credibility. When a board asks for the current maturity score, the answer should not require updating a spreadsheet. When a regulator asks for evidence of CIRMP compliance, the answer should not require two weeks to gather documents.

A system produces answers on demand. It maintains the evidence. It tracks the improvement. It provides the audit trail. A spreadsheet requires someone to perform all of those functions manually every time they are needed, and the result is only as reliable as the last time someone remembered to update it.