NIS2 for IT Operations and Infrastructure — What NIS2 asks of IT operations

In this lesson

Locate the work of IT operations in the ten measures of article 21(2), and quote the six points that fall on it word for word.
Decide whether the Annex to Implementing Regulation (EU) 2024/2690 binds your entity, or serves only as a reference.
Separate what the law requires from what is practice: patch deadlines, hardening baselines, segmentation designs and log retention periods.
Place operations correctly between the management body, the security function and the supervisor.

Your systems are the object of article 21

Article 21(1) requires member states to ensure that essential and important entities take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services”. The object of that obligation is the estate an operations team runs every day: servers, endpoints, network devices, cloud tenants, directories and backups.

The definitions show how wide that estate is. Under article 6(1), a network and information system is an electronic communications network; “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data”; and the digital data those elements store, process, retrieve or transmit “for the purposes of their operation, use, protection and maintenance”. Configuration files, credentials, logs and backup copies are therefore part of the system, not paperwork around it.

Article 6(2) defines their security as the ability to resist “any event that may compromise the availability, authenticity, integrity or confidentiality” of data or services.

Outsourcing does not move the obligation. Recital 83 says the measures apply “regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof.” If a provider runs your servers, the measures are still yours, and point (d) on supply chain security governs that relationship.

The six points that fall on operations

Art. 21(2)

Article 21(2) says the measures “shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following”. Ten points follow. Six of them are carried out in large part by IT operations. Read them as written, because the wording decides what you must be able to show.

(b) “incident handling”. Article 6(8) defines it as “any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident”. Operations owns the detection sources and much of containment and recovery.
(c) “business continuity, such as backup management and disaster recovery, and crisis management”.
(e) “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. Maintenance is where patching, configuration and change control live.
(h) “policies and procedures regarding the use of cryptography and, where appropriate, encryption”.
(i) “human resources security, access control policies and asset management”.
(j) “the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate”.

The other four points still reach your desk. Risk analysis under point (a) rests on your asset and vulnerability data; point (d) governs the providers who operate parts of your estate; the effectiveness assessment under point (f) uses data from your tools. Point (g), “basic cyber hygiene practices and cybersecurity training”, is partly technical: recital 89 lists practices such as “zero-trust principles, software updates, device configuration, network segmentation, identity and access management or user awareness”.

Two layers: the directive and the implementing regulation

Reg. 2024/2690, art. 1-2

Article 21(5) required the Commission to adopt implementing acts setting out the technical and methodological requirements of the measures for a named list of entity types. It did so in Commission Implementing Regulation (EU) 2024/2690. Article 1 of that regulation lists the entities it covers, which it calls the relevant entities: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers.

For those entities, article 2(1) states that the technical and methodological requirements of the measures in article 21(2), points (a) to (j), “are set out in the Annex to this Regulation”. The Annex is detailed: section 3.2 on monitoring and logging, 4.2 on backups, 6 on acquisition, development and maintenance, 9 on cryptography, 11 on access control, 12 on asset management. The regulation's closing formula states that it “shall be binding in its entirety and directly applicable in all Member States”, so a relevant entity is bound by the Annex without waiting for national law.

For every other essential or important entity, whether a hospital, a water utility or a manufacturer, the Annex binds nothing. It remains a structured reference written for the same ten measures, and recital 3 of the regulation says its requirements are based on European and international standards “such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401”. Using it as your yardstick is a sound decision, but record it as a decision. National law can add its own detail: check your country page at /transposition, and the frameworks hub for national frameworks, rather than assuming.

The qualifiers do work

Reg. 2024/2690, art. 2(2)

The Annex is full of “where appropriate”, “where applicable” and “to the extent feasible”. They are not escape hatches. Under article 2(2) of the regulation, where a relevant entity considers such a requirement “not appropriate, not applicable or not feasible”, it “shall in a comprehensible manner document its reasoning to that effect.” For operations, that is a decision log: the requirement, the systems concerned, why it does not apply, who decided, and when the decision will be reviewed.

Recital 5 adds that an entity which cannot implement some requirements because of its size “should be able to take other compensating measures that are suitable to achieve the purpose of those requirements”.

Law, and what is practice

Four things operations teams look for in the EU texts are not there, for any entity:

Patch deadlines in days. The Annex asks relevant entities to apply security patches “within a reasonable time after they become available” (point 6.6.1(a)) and to address vulnerabilities identified as critical to their operations “without undue delay” (point 6.10.2(c)). The number of days is yours to set.
Hardening baselines. Point 6.3.2(a) requires relevant entities to “lay down and ensure security in configurations for their hardware, software, services and networks”. Which benchmark you start from is practice.
Segmentation designs. Point 6.8.1 requires segmentation “in accordance with the results of the risk assessment”. It lists principles, not a topology.
Log retention periods. Point 3.2.5 requires logs to be kept and backed up “for a predefined period”. You predefine it.

When you set those numbers, write down their basis: the risk assessment, the asset classification, the threat information relied on. The directive gives a supervisor no figure to compare yours with; what can be tested is whether your numbers rest on a documented basis and whether you keep to them. A figure imposed by national law applies on top.

Who decides, who runs, who proves

Art. 20(1)

Article 20(1) requires the management bodies of essential and important entities to “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21” and to oversee their implementation. The management body approves; the security function designs the programme; operations implements and produces the records. For relevant entities, point 1.2.3 of the Annex adds: “At least one person shall report directly to the management bodies on matters of network and information system security.”

Two consequences follow. A standard you write, such as a patching or logging standard, implements an approved policy and should cite it. And article 21(4) requires an entity that finds it does not comply with the measures to take, “without undue delay, all necessary, appropriate and proportionate corrective measures”. A gap you discover goes into the risk treatment process with an owner and a date.

This course stays at the operational level. Designing the security programme, its policies and its reporting to the board is covered by the CISO certification in the academy; continuity planning, impact analysis and crisis management by the Business Continuity certification.

In practice

Two invented entities write a patching standard in the same month. The first is a cloud computing service provider with 180 staff and a turnover of EUR 30 million, so medium-sized: an important entity under Annex I, and a relevant entity under article 1 of the regulation. Its standard cites points 6.6 and 6.10 of the Annex as binding, sets its own deadlines by severity and exposure, explains why they meet “within a reasonable time”, and opens a register for patches not applied under point 6.6.2.

The second is a hospital group with 2,400 staff, a healthcare provider under Annex I above the medium-sized ceilings, so an essential entity under article 3(1)(a). The Annex does not bind it. Its standard cites article 21(2)(e) as the obligation, adopts points 6.6 and 6.10 as its reference by decision of the security committee, and records that decision. The two standards end up close in content; what differs is the legal basis each cites. The hospital group also checks its national law for additional requirements.

What a supervisor will ask

Which article 21(2) points does your team implement, and where? A mapping from each point to the procedures and system records that implement it.
Does Implementing Regulation (EU) 2024/2690 bind you? The entity type under its article 1, or the recorded decision to use its Annex as a reference.
On what basis did you set this deadline or this period? The risk assessment entry or decision record behind each number.
Where a requirement is marked not applicable, who decided and why? For relevant entities, the reasoning documented under article 2(2) of the regulation.

Key points

Article 21 concerns the network and information systems you run, whether maintained internally or outsourced (recital 83).
Points (b), (c), (e), (h), (i) and (j) fall in large part on operations; quote them as written.
The Annex to Regulation 2024/2690 binds only the entity types in its article 1; for others it is a reference adopted by recorded decision.
Patch deadlines, baselines, segmentation designs and retention periods are set by the entity and justified by its risk assessment.
The management body approves the measures (art. 20(1)); gaps found are corrected without undue delay (art. 21(4)).