The standards landscape

A single municipal facility is touched by dozens of standards at once. Building automation, lighting, connected devices, control systems, networks, information security and data protection — each with its own versions and revisions. Keeping up manually is beyond what a person can do, and that fact decides how the work should be organised.

The aim is to know which standards apply where, and what it costs when they are not met.

The problem

Standards are looked at one at a time. From an operational point of view they apply simultaneously, at the same facility, to the same equipment.

The consequence

No one knows which standard applies, compliance cannot be shown, and the organisation risks having no answer when a customer or an authority asks.

The remedy

Place the standards on the map, at the nodes they govern, and let the watching be done by something that does not tire.

The three families a municipality meets

1 · Information security management systems

ISO/IEC 27001 describes how an organisation systematically manages information security: scope, risk assessment, choice of controls, follow-up and continual improvement. It is organisational — it addresses how you work rather than how a switch is configured.

For a municipal IT organisation it is useful for two reasons: it provides a structure that supervisors recognise, and it forces a statement of scope. The second is often the more valuable, because the question — what is included — rarely has a clear answer before someone asks it.

2 · Industrial control systems and operational technology

IEC 62443 is the standards series for security in industrial automation and control systems. It is relevant well beyond industry: building automation, water treatment, energy plants and access control follow the same logic.

Two concepts from the series are useful even to someone who never reads the standard:

• Zones and conduits. The facility is divided into zones with a shared protection need, and the connections between them are described explicitly. It is risk-based segmentation, and it becomes natural once reality is already drawn.

• Security levels. Four levels, from lowest to highest, stating what protection a zone should have. That makes it possible to say a zone should be at level two rather than to say it should be secure.

3 · Product requirements through legislation

The Cyber Resilience Act differs from the standards by being binding. It states what must be achieved — secure design, vulnerability handling and support for a stated period — while the standards describe how it is done. The development requirements in IEC 62443 are often pointed to as a route for component manufacturers to demonstrate secure design in the regulation's sense.

For a purchasing organisation that means the question can be asked in two steps: which standard do you follow, and how do you meet the binding requirements?