NIS2 Checklist for Control Rooms: What Operators Have to Put in Place

NIS2 does not regulate the control room as such. It regulates the organisation behind it — and only if that organisation qualifies as an essential or important entity under the national law that transposes the directive. Where it does, the risk-management obligations extend to the network and information systems used for its operations or for the provision of its services. Depending on function and architecture, that includes the SCADA system, telecontrol equipment, KVM infrastructure, video wall controllers and operator workspaces. This article translates the legal requirements into a technical quick check for your control room.

Directive (EU) 2022/2555 — the NIS2 Directive — was published in the Official Journal on 27 December 2022 and entered into force on 16 January 2023. It repealed and replaced the original NIS Directive (EU) 2016/1148. What binds an operator, however, is not the directive itself but the national law transposing it, and that is where the timing differs from country to country.

The timeline: what applies and when

Under Article 41, Member States had to adopt and publish the transposing measures by 17 October 2024 and apply them from 18 October 2024. Several Member States missed that deadline, so the date on which the obligations actually bite varies across the Union. Austria, for example, transposed the directive with the NISG 2026, which enters into force on 1 October 2026. The first thing to establish for any site is therefore simple: which national law applies to this entity, and what does it set as the deadline for registration, self-declaration and supervision?

The practical consequence for operators is that the retrofit window is already running. Where a Member State transposed late, the later start date does not create a supervision-free grace period: once the national law applies, competent authorities can use their supervisory powers, and for essential entities those powers include inspections, security scans and requests for information.

Reporting deadlines when an incident happens

Article 23(4) sets a staged reporting regime for significant incidents. An early warning is due without undue delay and in any event within 24 hours of becoming aware of the incident. An incident notification with an initial assessment — including severity, impact and, where available, indicators of compromise — follows within 72 hours. The CSIRT or competent authority may request an intermediate report on status updates. A final report is due no later than one month after the 72-hour notification. If the incident is still ongoing at that point, a progress report is submitted instead, and the final report follows within one month of the incident handling being completed.

These clocks run irrespective of shift schedules. Meeting them requires defined escalation criteria, named responsible people with designated deputies, and logging from which the moment of becoming aware and the course of an incident can be reconstructed reliably.

Are you in scope? Entity type and company size

Operating a control room does not by itself bring an organisation into scope. What is needed is an assessment of the specific entity type under Annex I or Annex II of the directive, of company size, of the territorial link and of any special rules or exemptions in the national transposing law.

Operators in energy, transport, drinking water, waste water, health and digital infrastructure are frequently among the relevant target groups — typically the organisations that run a control room for energy and water utilities, a traffic management control centre or an emergency and dispatch control room. Even in these sectors, though, the classification has to be made case by case.

On size, Article 2(1) applies the size-cap rule: the directive covers entities of a type referred to in Annex I or II that qualify as medium-sized enterprises under Article 2 of the Annex to Recommendation 2003/361/EC, or that exceed the ceilings for medium-sized enterprises in paragraph 1 of that Article. Under that Recommendation, an enterprise is medium-sized if it employs fewer than 250 people and has an annual turnover not exceeding EUR 50 million and/or an annual balance sheet total not exceeding EUR 43 million; the small-enterprise ceiling is fewer than 50 people and turnover or balance sheet total not exceeding EUR 10 million. Article 3(4) of that Annex — the rule on when a change of status takes effect — does not apply for the purposes of NIS2.

Article 3(1) then classifies entities of a type referred to in Annex I that exceed the medium-sized ceilings as essential entities. Entities of a type referred to in Annex I or II that do not qualify as essential are important entities under Article 3(2). Size is not always decisive: under Article 2(2), the directive applies regardless of size to providers of public electronic communications networks or publicly available electronic communications services, trust service providers, TLD name registries and DNS service providers, and to entities that are the sole provider in a Member State of a service essential for critical societal or economic activities, or whose disruption could significantly affect public safety, public security or public health, or induce systemic risk. Entities identified as critical entities under Directive (EU) 2022/2557 are essential entities as well.

The financial frame is sharp. Under Article 34(4), Member States must ensure that essential entities infringing Article 21 or 23 face administrative fines of a maximum of at least EUR 10 000 000 or at least 2 % of the total worldwide annual turnover in the preceding financial year of the undertaking to which the entity belongs, whichever is higher. For important entities, Article 34(5) sets EUR 7 000 000 or 1,4 % of that turnover, again whichever is higher. Because these are minimum ceilings that Member States must provide for, national law can go further, and typically adds separate penalties for late registration or incorrect information.

Article 20 makes this a board-level matter. Management bodies of essential and important entities have to approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements. Their members are required to follow training so that they can identify risks and assess risk-management practices. Cybersecurity is explicitly a management and supervisory task, not a delegated IT topic.

Article 21: what the risk-management obligations require

Article 21(1) requires appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of the network and information systems that entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents. Proportionality is assessed against the entity’s exposure to risk, its size, and the likelihood and severity of incidents including their societal and economic impact.

Article 21(2) requires an all-hazards approach that also protects the physical environment of those systems, and lists as a minimum: policies on risk analysis and information system security; incident handling; business continuity, such as backup management and disaster recovery, and crisis management; supply chain security, including the relationships between the entity and its direct suppliers or service providers; security in acquisition, development and maintenance, including vulnerability handling and disclosure; policies and procedures to assess the effectiveness of the measures; basic cyber hygiene practices and cybersecurity training; policies on cryptography and, where appropriate, encryption; human resources security, access control policies and asset management; and the use of multi-factor or continuous authentication, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

Network segmentation is not named as a separate measure in that list. For the entity types covered by Commission Implementing Regulation (EU) 2024/2690 — DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed service and managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers — it is spelled out in the technical and methodological requirements. For everyone else it follows from risk analysis, proportionality and the state of the art, and in control room environments it regularly does.

That is where a conflict familiar to every operator appears. An operator has to work on systems in several security zones at the same time — the SCADA system, office communication, video management, occasionally a remote maintenance session. A single operator PC connected to several zones at once can bypass separation mechanisms and create additional lateral movement paths. Such an architecture has to be assessed particularly critically and justified in a traceable way. How usability and separation can be reconciled is something we cover in cybersecurity trends in control rooms and critical infrastructure.

Technical quick check for your control room

The following twelve points are a technical quick check for the control room architecture. They do not replace a full compliance assessment, which additionally has to cover governance, risk analysis, incident management, business continuity, supply chain security, secure acquisition and maintenance, vulnerability handling, effectiveness testing, cyber hygiene, cryptography, human resources security and asset management. Every point that stays open is a candidate for the action plan.

Architecture and zone separation

• Zone model documented: is there a current plan showing which systems sit in which security zone and through which transitions they communicate?
• Separation technically enforced: is the separation between process control technology and office IT enforced by technical means — not merely agreed organisationally?
• Workspace without zone breach: can the operator work on all necessary systems without a single machine being connected to several zones at once?
• Remote maintenance controlled: are external connections time-limited, logged and individually enabled instead of permanently open?

Access and traceability

• Role concept instead of shared accounts: does every operator work under a personal identity, or do shared shift accounts exist?
• Multi-factor or continuous authentication: is it defined and documented on a risk basis for which users, systems and types of access it is used — in particular for privileged and external access?
• Logging sufficient: can it be established after the fact who had which access to which system and when, and are those logs stored centrally and protected against tampering?
• Permissions maintained: are accounts demonstrably withdrawn when staff leave and when roles change?

Availability and operations

• Redundancy without single point of failure: is there a component whose failure blinds the entire control room — a single video wall controller or a central KVM node, for instance?
• Restart tested: are restart and emergency procedures documented, and are they tested in practice at risk-based intervals, with results, defects and follow-up measures documented?
• Reporting chain across shifts: can every shift recognise a potentially significant incident, escalate it internally and document the moment of becoming aware in a traceable way? Are responsible people, deputies and the competent CSIRT defined?
• Supply chain assessed: are direct manufacturers and service providers assessed with regard to vulnerability handling, security updates, support periods, response times and secure development processes — and are those requirements contractually and operationally verifiable?

Point twelve is regularly underestimated, even though supply chain security is named explicitly in Article 21(2). A video wall controller for which security updates are no longer available can, depending on its function, connectivity and criticality, become a significant technical and regulatory risk. Operators should document support status, known vulnerabilities, compensating measures and, where necessary, a replacement path. How support and response times can be secured contractually is something we address in our overview of complete solutions for an entire control room project.

KVM and zone separation: what technology can and cannot do

A properly designed KVM system can help to keep source systems in secured technical rooms and separate security zones while video, keyboard and mouse signals are routed to the operator workspace in a controlled way. Whether the separation actually holds depends on the specific architecture — in particular on shared components, management and control networks, the permission concept, interfaces, logging and hardening. A KVM system is therefore a possible technical building block, never an automatic proof of compliance.

Whether a proprietary or a standard-IT-based KVM architecture is better suited is not decided by the technology label, and no regulatory preference can be derived from NIS2. What matters is traceable access control, secure administration, logging, vulnerability and patch management, the ability to segment, availability, restart capability, manufacturer support and supply chain security. Standardised interfaces can make integration into existing security tooling easier; at the same time, the additional complexity and attack surface of the IT infrastructure have to be taken into account. We discuss the architectural differences in why KVM-over-IT is the paradigm shift your control room needs.

Implementation during live operation

Most control rooms that now have to retrofit cannot afford a shutdown. A traffic management centre or a grid control room keeps running while it is being rebuilt. That is feasible, but it requires a staged migration with a fallback option in every phase — as described in modernizing a control room during live operation.

Operators should plan several months for inventory, risk analysis, concept, procurement, testing and implementation. The target date for the required risk-management measures is the date on which the national transposing law applies to the entity — not the later end of a registration period. Registration should be prepared in parallel, in particular the entity and sector classification, contact details, EU establishments and, where required, IP address ranges.

Control room solutions from a single source

controlrooms GmbH plans and builds control rooms and command centres as a single-source provider: as-is analysis, planning to ISO 11064, KVM architecture and zone separation, large-format visualization, operator workspaces, integration and ongoing service. For critical infrastructure operators that means one point of contact for the whole chain — instead of separate responsibilities whose interfaces produce exactly the gaps NIS2 addresses.

If you want to know where your installation stands technically, we look at the existing architecture with you and map the points of this quick check to your specific situation.

Request a no-obligation as-is analysis for your control room

Erich Strasser
controlrooms GmbH
Phone: +43 664 8866 7817
Email: erich.strasser@controlrooms.at

Legal basis and further information: the relevant texts are the national law transposing NIS2 in the Member State concerned, Directive (EU) 2022/2555 and any applicable Union or national implementing acts. Note: this article describes technical and organisational aspects of control rooms. It is not legal advice and does not replace a full compliance assessment. Whether an organisation qualifies as an essential or important entity, and which systems and measures are covered, has to be assessed case by case. Legal status: 8 August 2026.

Visit our showroom in Vienna Prater or Wieselburg

Technology for control rooms, command centers and KVM workspaces is best evaluated live. In the controlrooms showroom we demonstrate video walls, KVM, operator desks and typical 24/7 scenarios working together in real conditions — including zone separation and access concepts.

Appointments by arrangement. controlrooms GmbH supports you with analysis, planning, integration and ongoing service.

Request a showroom appointment

FAQ

Frequently asked questions about NIS2 in the control room

From when does our control room have to meet the NIS2 requirements?

The obligations apply through the national law transposing the directive. Member States had to adopt the transposing measures by 17 October 2024 and apply them from 18 October 2024, but several transposed later, so the binding date depends on the country. In Austria, for example, the NISG 2026 enters into force on 1 October 2026. The target date for the technical measures is the date on which the national law applies — not a later registration deadline.

Does NIS2 cover the control room itself or only classic IT?

What is covered first is the organisation, provided it is classified as an essential or important entity. Only then is it assessed which network and information systems it uses for its operations or for the provision of its services. Depending on function and architecture, those can include the SCADA system, telecontrol equipment, KVM infrastructure, video wall controllers and operator workspaces. A split into “IT only” therefore falls short.

Can a KVM system contribute to secure zone separation?

A properly designed KVM system can help to keep systems of different security zones apart while still making them accessible from a shared operator workspace. Whether the separation is robust has to be assessed and documented on the basis of the specific architecture, the shared components and the access paths. The KVM system replaces neither the risk analysis nor a firewall, a segmentation concept or an information security management system.

What penalties apply for infringements?

For infringements of Article 21 or 23, Member States must provide for administrative fines of a maximum of at least EUR 10 000 000 or at least 2 % of the total worldwide annual turnover in the preceding financial year of the undertaking to which an essential entity belongs, whichever is higher. For important entities the figures are EUR 7 000 000 or 1,4 % of that turnover, again whichever is higher. These are minimum ceilings, so national law may go further and usually adds separate penalties for late registration or incorrect information.

Which reporting deadlines apply after an incident?

For significant incidents the deadlines are staged. An early warning is due within 24 hours of becoming aware of the incident, and an incident notification with an initial assessment within 72 hours. A final report follows no later than one month after that 72-hour notification. If the incident is still being handled at that point, a progress report is submitted first and the final report within one month of the handling being completed.

Do we have to replace our existing control room completely?

Usually not. Access control, zone separation, logging and redundancy can often be retrofitted within the existing architecture. What makes sense is an as-is analysis that compares the technical state with the risk analysis. Replacement is then targeted at the points where a requirement cannot be met proportionately in any other way.