Regulatory

What NIS2 requires of a metro operator

The concrete obligations NIS2 and CER place on urban transport, and what to demand from any supplier putting software on your network.

Published on 4 August 2026 Metrosafe team

If you work in systems or security at a European urban transport operator, NIS2 has stopped being theoretical. This article summarises what it obliges, what CER adds on top, and — the practical part — what you should be asking of every supplier that puts a new system on your network.

An explanatory summary of the European framework and how it usually fits. National transposition and the classification of each entity are determined by the competent authority in each Member State.

The two directives, one sentence each

NIS2 — Directive (EU) 2022/2555 — replaces the original NIS directive and raises cybersecurity requirements for entities considered essential or important. Transport is expressly within scope.

CER — Directive (EU) 2022/2557 — is its twin for the physical resilience of critical entities. Where NIS2 talks about cyberattacks, CER talks about sabotage, natural disasters and service continuity in the face of non-digital incidents.

They were designed to work together. An entity designated as critical under CER falls, by that route, within NIS2 scope regardless of its size.

Member States were to transpose NIS2 into national law by 17 October 2024. The pace of transposition has been uneven, but the direction of travel is not in doubt.

What NIS2 obliges, concretely

The directive is not a list of technical controls in the style of an ISO standard. It is a framework of risk management with accountability. Its requirements group into four blocks.

1. Risk management measures

An all-hazards approach covering, at minimum: risk analysis and information system security policies, incident handling, business continuity and recovery, supply chain security, security in acquiring and maintaining systems, policies to assess the effectiveness of measures, cyber hygiene and training, cryptography, human resources security and access control, and multi-factor authentication.

2. Incident reporting

With staged deadlines that are the most visible change from the previous regime:

24 hours: early warning of a significant incident.
72 hours: notification with an initial assessment of severity, impact and indicators of compromise.
1 month: final report with a detailed description, threat type, root cause and measures applied.

Twenty-four hours is not much time if you have to start by reconstructing what happened through phone calls.

3. Management accountability

Management bodies must approve the measures, oversee their implementation and can be held personally liable for non-compliance. They are also required to undergo training. This is what has moved cybersecurity out of the technical meeting and into the board.

4. Supervision and enforcement

Essential entities are subject to proactive supervision: audits, on-site inspections and security scans, without needing an incident to have occurred. With a penalty regime attached.

The part that affects what you buy

Of the four blocks, the one that generates the most day-to-day work is supply chain security. Every supplier putting software on your network is new attack surface that you answer for, not them.

In practice: when someone presents a system to you, you should be able to obtain the following without friction. If a supplier takes weeks to produce this, you already know how long they will take when there is an incident at three in the morning.

Supplier checklist

Architecture and data flows: what is collected, where it is stored, who can access it, where it goes.
Identity and access controls: enforced multi-factor authentication, scoped role-based access, integration with your directory.
Encryption: in transit and at rest, with documented key management.
Audit trail: which operations are logged, at what granularity and for how long. Without this you cannot meet the 72-hour deadline.
External audit results: a recent penetration test by an independent third party, with declared scope and the status of finding closure.
Security analysis in the development lifecycle: SAST and DAST in the pipeline, dependency scanning.
Vulnerability management process: how issues are communicated, within what timeframes they are fixed, and how you find out.
Notification commitment: if the incident happens at the supplier, how long before they tell you. Your 24-hour clock starts running regardless.
Continuity: SLA, backups, a tested recovery procedure and known degradation behaviour.
Portability and exit: how you get your data back if the relationship ends.

A distinction worth making

You will see marketing material claiming a product “is NIS2 compliant”. It is worth being precise, because that phrase means nothing.

Entities comply — or fail to. Tools do not. NIS2 places obligations on organisations; it does not certify products. What a supplier can do is two things, and both are valuable: not make your compliance harder, and provide the evidence you need to demonstrate yours.

A supplier who hands you their architecture, their controls, their audit report and a notification commitment is giving you material for your file. One who hands you an invented badge is not.

Where a personnel location system fits

Worth flagging because it usually goes unnoticed: a system that records where each team was and what was done during an incident produces exactly the kind of evidence these frameworks demand.

For the 72-hour notification, having the response sequence reconstructible saves the slowest part of the report.
For CER’s operational continuity, being able to coordinate personnel dispersed across underground infrastructure during an evacuation or a physical incident is a resilience capability, not a luxury.
For continuous improvement, event replay turns the post-incident review into an analysis with data.

With one condition, and it matters: the system itself has to meet the bar the framework sets. A poorly secured traceability system is an added problem, not a solution.