P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Operational technology

OT and ICS security assessment

Plant and industrial control systems, assessed in terms of loss of view, control and safety, and mapped to IEC 62443 and NIS2 rather than to an IT checklist.

Plant networks get assessed with instruments built for corporate IT, and the mismatch causes real harm: active scanners have knocked controllers over, patching advice arrives that no vendor will validate, and findings come back rated on confidentiality when what matters is whether an operator can still see and control the process. This is an assessment that starts from the process and works outwards.

What it maps to

IEC 62443

The industrial security standard your assessor and your integrator are already using. Findings map to foundational requirements so they can be argued in the language of the standard rather than translated afterwards.

MITRE ATT&CK for ICS

Technique-level grounding for what was actually tested, so a finding cites something citable instead of asserting a risk rating.

NIS2

Energy, water, waste water, transport and several manufacturing categories sit in the NIS2 annexes, which is precisely where operational technology carries the risk.

The Purdue model

Declared obsolete regularly and still the vocabulary every plant, integrator and auditor uses. Used here to reason about consequence and distance from the process.

How the assessment runs

  1. 1

    Understand the process first

    Before any network work: what the plant makes, what the safety case assumes, and what a bad day looks like physically. A security finding that ignores the process cannot be prioritised sensibly.

  2. 2

    Map the zones you actually run

    Not the reference architecture and not the diagram on the wall. Where the two networks genuinely touch, which remote access routes exist, and which temporary exceptions became permanent.

  3. 3

    Observe passively

    Traffic capture and configuration review rather than active scanning. Scanning a live process is itself a risk, and fragile devices have been taken down by ordinary IT tooling.

  4. 4

    Test the paths that get used

    The corporate-to-plant route, the vendor remote access, the engineering workstation, the transient laptop and the USB path. Nearly every published industrial intrusion began on the corporate network and moved down.

  5. 5

    Express findings as consequence

    Loss of view, loss of control, loss of safety. One report the control room and the board can both read without a translation layer.

  6. 6

    Sequence remediation around reality

    Outage windows, vendor validation and spares availability decide what is possible. A plan ordered purely by severity is a plan that will not be executed.

What you walk away with

  • An assessment report written in consequence terms, with findings mapped to IEC 62443 foundational requirements
  • A zone and conduit picture of what is actually connected, including the paths nobody documented
  • Technique-level findings referenced to MITRE ATT&CK for ICS
  • A remediation plan sequenced around outage windows and vendor constraints
  • Where relevant, a view on NIS2 scope and what the obligations mean for the site
  • A short board summary that does not require the reader to understand a PLC

How this plays out

Example scenario

A manufacturer with a documented air gap between plant and corporate networks.

The work: Traffic observation at the boundary over a normal production week, and a review of how files actually reach engineering workstations.

The air gap was crossed daily by a sanctioned historian replication link and weekly by USB. Neither was a failing of policy; both were undocumented in the security model, so neither was monitored. The fix was a brokered transfer path and monitoring, not disconnection.

Example scenario

A utility preparing for NIS2 with an existing ISO 27001 certificate.

The work: Gap review of the certified management system against the plant estate, which had been scoped out of certification.

The certificate covered corporate IT and explicitly excluded operations. The scope statement that made certification achievable was the same statement that left the regulated part of the business uncovered.

Example scenario

A site where a vendor held standing remote access for support.

The work: Review of the access path, its authentication, and what it could reach once established.

The account was permanent, shared across the vendor's engineers, and reached the control network directly rather than through the DMZ. Moving it to brokered, time-bound, recorded sessions removed the exposure without changing the support arrangement.

Start the conversation

A question about this area, an invitation to speak, or a role you think fits: write, and you will get a straight answer.

Get in touch

Share this

Send it to whoever owns the budget or the risk.

← All areas

The problem

Operational technology gets assessed with tools and vocabulary built for corporate IT, and the mismatch does real damage. Active scanners knock fragile controllers over. Patching advice arrives that no vendor will validate and no operator will accept. Findings come back rated on confidentiality when the thing that matters is whether an operator can still see and control the process.

Meanwhile the path that actually gets used runs from a corporate mailbox, through a remote access route built for a vendor, into a network segment that was documented once in 2019.

What you get

  • An assessment that works passively, because active scanning of a live process is itself a risk
  • Findings expressed as loss of view, loss of control and loss of safety, so engineers and the board read the same report
  • Segmentation and conduit review against the zones you actually run, not a reference architecture
  • Mapping to IEC 62443 foundational requirements and, where you are in scope, to NIS2 obligations
  • A remediation plan sequenced around outage windows and vendor validation, not around severity ratings alone

Proof point

Assessment by someone who will tell you when the IT answer is the wrong answer. Grounded in ISO 27001 and ISO 42001 lead audit practice, and in the free OT threat map published on this site, which places ATT&CK for ICS techniques on the Purdue model and maps them to IEC 62443.