Bringing OT into Scope After the Nordhavn Water Incident

The exclusion was not defensible as it was made, although a distinct OT scope can be legitimate.

Context establishment requires the organisation to determine its internal and external context, its dependencies and the boundaries of the assessment, with management approval. The premise that plant systems are engineering assets rather than information assets confuses asset category with risk relevance: the PLCs process and act on information, and information security events - malware on a contractor laptop, compromised remote support, spoofed telemetry - produce service and safety consequences. The six-hour manual operation is direct evidence of a cross-domain attack path, and the new regulation removes any ambiguity. What is illegitimate is not a separate OT assessment but a silent exclusion with no criteria, no stakeholder input and no approved scope statement.

How to structure it now:

• Re-establish context and scope with engineering, HSE, contractor management and the regulatory requirements as inputs; have the scope statement signed by the engineering director as well as the CISO.
• Keep one register with a clearly marked OT section, or two registers with explicit cross-references, so shared infrastructure (identity, remote access, backup, the two-year-old firewall) is assessed once. Treat that firewall as a control of unknown effectiveness until tested.
• Use scenario-based identification rather than asset enumeration. With 60 known PLCs, roughly 25 unrecorded devices and unknown firmware, a complete inventory would take months and would still be wrong. Anchor scenarios on hazardous outcomes: loss of pump control, dosing overfeed, telemetry spoofing, contractor remote access abuse, loss of operator visibility.
• Record the missing inventory as a risk entry in its own right, with a treatment action and owner. Poor asset data is a reason to assess carefully, not a reason to defer.

Impact criteria for an essential service must be multi-dimensional and written in the utility's own language, not borrowed from IT.

Define levels against: customers affected and duration of service loss (with the real manual-operation limit - six hours was managed, so what is the threshold?), public health, environmental discharge limits, regulatory notification obligations, financial cost and reputation. For example: 'catastrophic - loss of dosing control exceeding 30 minutes, any discharge above permit, or more than 50,000 customers without supply for four hours'. Likelihood definitions should distinguish opportunistic malware from a targeted actor against a water utility, because the OT threat landscape is not the office threat landscape.

Interaction with HSE. Safety and environmental harm are not information security impacts by definition, but information security events can be threat sources for them. Handle this with cross-references rather than conversion: each OT scenario links to the relevant HSE register entry, the two registers share likelihood evidence, and acceptance authority stays separate - the HSE manager accepts safety risk, the CISO and executive accept information risk, and overlapping cases go to a joint forum. Converting safety harm into an information security score would hide accountability and distort prioritisation.

Monitoring and review triggers, written into the process: the incident debrief as a mandatory review of the affected assessments; change triggers (new OT architecture, new contractor access route, firmware or patch change, new remote-support or cloud service); external triggers (vendor advisories for the SCADA product, regulatory change, sector threat intelligence); and periodic review with control-effectiveness evidence - segmentation testing, removable-media controls, contractor access logs. The malware incident's lessons should update the risk treatment plan and Statement of Applicability with owners and dates, and closure should be evidenced, not asserted.