Municipal water supplier: scoping and sequencing an 18-month programme with EUR 400,000

A defensible scope statement has five elements.

1. Service definition. The supply of drinking water to 480,000 people: abstraction, treatment, storage, distribution, metering and customer billing. Everything else is judged by whether it supports that service.
2. Organisational and physical boundary. The GmbH as the legal person, all 42 waterworks, both control rooms, and the administrative sites.
3. Supporting assets, explicitly including OT. SCADA servers, PLCs, RTUs, telemetry links, the historian, the remote-maintenance path into the vendor, the billing SaaS, and the ISO 9001 documentation set.
4. Dependencies. The pump and valve vendor, the laboratory, chemical suppliers, telecoms and the billing provider - recorded as dependencies even where they are out of scope as entities.
5. Exclusions with reasons. Legitimate exclusions are things like a separate legal entity outside the Annex I activity. Excluding OT because it is old, because it is patched twice a year, or because a vendor manages it, is not a legitimate exclusion.

Why IT-only fails. Art. 21(1) applies to the networks and information systems the entity uses for its operations or for the provision of its services, under an all-hazards approach. The pumps, the chemical dosing and the pressure management are the service. An IT-only scope would also make the risk analysis wrong by construction: the highest-consequence scenario here is a manipulated treatment process, not a compromised mailbox.

What a supervisor will notice. The scope statement is the first document requested in an audit. A scope that excludes the very systems that determine whether water flows signals that the programme is documentation rather than risk management.

Ordering principle: externally observable legal deadlines and single points of failure first; capability that can be bought later is deferred. Sequence by exposure, not by framework chapter order.

• Weeks 1–6 (about EUR 15k): registration filed, management body approves the programme and the risk method (Art. 20), incident contact point named, risk-analysis method chosen. Mostly internal effort.
• Weeks 7–12 (about EUR 60k): incident-handling capability and a notification playbook with pre-drafted 24-hour, 72-hour and one-month templates (Art. 21(2)(b)–(c), Art. 23); unique named vendor accounts plus MFA and a jump host for remote maintenance (Art. 21(2)(j)); a real OT asset inventory (Art. 21(2)(i)). Removing the shared account is the single highest-value technical change in the whole plan.
• Months 4–9 (about EUR 150k): tested backup and restore for the historian and SCADA configurations; documented manual-operation procedures so the utility can run without SCADA; supplier security requirements written into new contracts (Art. 21(2)(d)); access-control review across all three segments; OT patching process with compensating controls between Windows.
• Months 10–18 (about EUR 175k, including contingency): cryptography for inter-site links (Art. 21(2)(h)), secure acquisition requirements (Art. 21(2)(e)), effectiveness measurement (Art. 21(2)(f)), internal audit and a tabletop exercise with the national CSIRT.

Cut first under a 25% reduction: the crypto refresh (compensated by network segmentation) and the internal-audit tooling (delivered with internal resources). Never cut: MFA on remote maintenance, restore testing, or the notification playbook - those are the three things that decide whether an incident becomes an infringement.

Start from the legal test, not the product. Art. 21(1) requires measures that are appropriate and proportionate to the exposure, the size of the entity, the likelihood of incidents and their severity, taken together with cost and state of the art. The obligation is to reduce risk, not to own a particular category of tool.

What the risk actually is. The exposure is that four vendor engineers share one administrative identity with no second factor, so activity cannot be attributed and credential theft is uncontainable. The proportionate fix is identity and access control: unique named accounts per engineer, MFA, a jump host with session recording, time-bound access windows tied to the maintenance calendar, and alerting on out-of-window sessions. Estimated at EUR 30,000–40,000 including integration effort.

Why the full suite is the wrong first move. EUR 180,000 is 45% of an 18-month budget for a marginal improvement over the interim control, and it would push incident handling and restore testing past the point where they can be delivered - two obligations with external deadlines attached. A better control bought later is worse than an adequate control bought now.

Evidence to retain, because the supervisor audits decisions and not intentions (Art. 29 for essential entities):

• risk-register entry with likelihood, impact and affected service;
• options appraisal with the quoted costs of both routes;
• the management-body decision approving the interim control (Art. 20);
• residual risk accepted, by whom, and the review date;
• the date the interim control was verified as operating, not merely deployed.