Aging RTUs and a corporate baseline that does not fit
A municipal water utility runs 3,200 pressure and flow sensors and 140 remote terminal units (RTUs) across a distribution network serving 400,000 people. Some RTUs are 14 years old, run unpatched firmware and sit in unlocked roadside cabinets. The IT security team proposes applying its ISO/IEC 27001 baseline to the whole OT estate: full-disk encryption, endpoint agents, monthly patching and 12-character passwords rotated every 60 days. The OT engineer objects that two RTU models cannot host agents or encryption, and that a firmware update last year bricked three units and caused a nine-hour pressure anomaly affecting 2,000 households. The board has approved a risk treatment plan but requires every deviation from the corporate baseline to be justified and owned. The water regulator requires incident notification within 72 hours, and an independent cyber assessment is scheduled in five months.
1. How do you decide which baseline controls apply to the RTU estate, and how do you justify the deviations?
Read the worked answer
Start from risk scenarios, not from the control list. ISO/IEC 27400 expects tailoring to device capability, physical exposure and criticality; it is not a clause-by-clause conformity checklist. Build a short scenario set: unauthorised setpoint change causing pressure loss or contamination risk; stolen credentials enabling mass manipulation; ransomware crossing from IT to OT. Each control then gets judged on whether it reduces one of those scenarios.
Test the control's objective, not its form. Disk encryption protects confidentiality of data at rest. An RTU in a locked cabinet holds little confidential data; the real need is command integrity and authenticity. So substitute controls that meet the objective: cabinet locks, tamper switches and scheduled inspection instead of encryption; network segmentation, allow-listing and one-way data flows instead of endpoint agents; a jump host with MFA and session recording instead of 60-day password rotation on devices that cannot enforce complexity.
Where the objective cannot be met, record residual risk. Do not pretend the control exists.
Produce a tailoring matrix as the audit artefact: baseline control, applicability, rationale, compensating control, residual risk, named owner, review date. Include where you deliberately accepted a gap because the control's failure mode - a bricked RTU and a pressure anomaly - is worse than the risk it addresses. That documented reasoning is what the board and the assessor need; a blanket 'OT exemption' is not.
2. Who owns the residual risk, and what does a defensible acceptance look like?
Read the worked answer
Ownership sits where the consequence is borne and the action can be taken. The OT/operations manager owns the operational risk on the distribution network; the CISO owns the security programme and its assurance; the executive and board accept anything above the agreed appetite. A security team cannot accept water-supply risk on behalf of operations.
A defensible acceptance has six elements:
- A specific scenario with likelihood and impact expressed in operational terms - households affected, hours of disruption, regulatory exposure - not a colour on a heat map.
- The compensating controls actually in place and verified, not planned.
- A named owner and a signature.
- A time limit and a trigger for review - capital plan cycle, vendor end-of-support, a change in exposure.
- The funding decision or replacement commitment that will eventually retire the risk.
- An explicit note that acceptance does not remove regulatory duties.
Differentiate by model and location. Accepting residual risk for 20 old RTUs on secondary mains is not the same as for units on critical trunk mains. Segment the register accordingly so remediation money follows consequence.
Link to detection. Because notification is due within 72 hours, acceptance depends on being able to detect an incident. If monitoring cannot see the RTUs in question, the acceptance is not informed and should not be signed. Revisit the whole position at the five-month assessment and present the tailoring matrix as evidence of deliberate decisions.
3. With 140 RTUs and a five-month assessment deadline, what do you do first and why?
Read the worked answer
Prioritise by consequence times exposure, and buy evidence cheaply. First, rank the 140 RTUs by what they control (trunk mains versus secondary distribution) and by exposure (unlocked cabinet, cellular or internet-reachable path, shared credentials, unsupported firmware). That ranking, not the asset list order, sets the queue.
Quick, low-regret actions in the first 60 days: physical security and inspection regime for cabinets on critical assets; removal of any direct internet exposure; credential changes where the device supports them; logging of remote access; network segmentation between the control centre and corporate IT. These reduce the most likely paths and are defensible even if later replaced.
Then verification, not more tooling. Sample-test configurations to confirm that what you believe is true actually is. Record results as the basis of the tailoring matrix.
Finally, evidence packaging for the assessor. A clear scope statement, the scenario-based risk assessment, the tailoring matrix with owners, the residual risk register with signatures, and a dated remediation roadmap aligned to the capital plan. Assessors rarely penalise a documented, risk-based deviation; they penalise unknown devices and undocumented acceptance. Note that the five-month deadline also implies the board must decide on replacement funding before then, otherwise the same gaps reappear next year.