Whoever works for a NIS entity sits inside its risk perimeter: Decree 138 writes it into Article 24

One firm wins the contract to bring fibre to a hospital. Another splices the runs of a regional data centre and keeps the OTDR traces of every splice made over the last three years. Almost none of these contracts ever mention the NIS decree. Yet if the client is an essential or important entity under Legislative Decree 138 of 4 September 2024 — Italy’s transposition of Directive (EU) 2022/2555 — that firm is not working next to the client’s risk perimeter: it is working inside it, by law. The useful question is not whether the decree applies to it. It does. It is where that duty becomes something you can write down and check.

Who falls in scope, in our sectors

Annex I places digital infrastructure among the highly critical sectors: the list names “data centre service providers”, “providers of public electronic communications networks” and “providers of publicly available electronic communications services”. For the latter two the decree leaves no threshold room: Article 3(5)(b) includes them “irrespective of their size”. If at least a medium-sized enterprise, Article 6(1)(c) classifies it essential; if smaller, it stays in scope as important. A data centre only falls in scope if it exceeds the small-enterprise ceilings (Article 3(2)) — and only becomes essential, not important, if it also exceeds the medium ones (Article 6(1)(a)).

This is not the same perimeter as Regulation (EU) 2024/2690 on data centres, which we have already covered: that regulation defines when a data-centre incident is significant. Nor is it the subject of the Cybersecurity Act on high-risk vendors, which concerns whoever manufactures the active equipment. Here the supplier under scrutiny is whoever works on the NIS entity’s physical infrastructure, not whoever makes its components.

The supply chain is in the text, not in our reading of it

Article 24(1) requires essential and important entities to adopt (our translation from the Italian text, verified against Normattiva) “technical, operational and organisational measures that are appropriate and proportionate […] to the management of the risks posed to the security of network and information systems which those entities use in their operations or in the provision of their services”. Paragraph 2 specifies that those measures “are based on an all-hazards approach, aimed at protecting network and information systems and their physical environment from incidents” — the perimeter is not only logical: it covers manholes, ducts, equipment rooms.

Among the minimum elements, letter (d) of paragraph 2 lists “the security of the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”. Not a general principle: a specific relationship. Whoever digs the ducts, splices the fibres and keeps the OTDR traces for a NIS entity is a “direct supplier”: the risk it carries enters the client’s perimeter, not a chapter of its own.

The governing bodies answer in person: Article 23

Article 23 places this on the client’s administrative and management bodies, not a technical office: they “approve the implementation arrangements for the cybersecurity risk-management measures […] under Article 24” and “are liable for the infringements referred to in this decree”. Whoever signs a specification for a NIS entity without the Article 24 clauses does not just leave the contracting firm exposed: it leaves itself exposed.

The clock: twenty-four hours, seventy-two hours, a month

Article 25(4) defines when an incident is significant: if it “has caused or is capable of causing severe operational disruption of the services or financial loss”, or if it “has affected or is capable of affecting other natural or legal persons by causing considerable material or immaterial damage”. From there runs the sequence in paragraph 5: “within 24 hours of becoming aware of the significant incident, an early warning” (letter a); “within 72 hours” a fuller notification (letter b); “a final report within one month of submission of the incident notification” including “the type of threat or root cause that has likely triggered the incident” (letter d); and, if still ongoing, “a monthly progress report and a final report within one month of the incident’s resolution” (letter e).

The sum the decree does not do, and the specification must

Here the law stops, and our own reasoning begins: not an obligation written into the decree, but a logical consequence of it. The 24-hour clock starts when the NIS entity becomes aware of the incident, not when it happens. If the specification does not require the contractor to report on a shorter deadline — twelve hours, six, whatever the route justifies — the client cannot meet the early-warning deadline: by the time the contractor reports it, part of the useful time is already gone. That deadline is not a contractual detail: it is the condition for the client to comply with Article 25 at all.

Eighteen months, nine months — but from when

Article 31 gives the Agency for National Cybersecurity, as the competent NIS Authority, the task of setting “terms, methods, specifications and gradual implementation timelines for the obligations”. The determination exists: signed by Bruno Frattasi on 18 December 2025, in force from 15 January 2026 in place of the earlier one, No. 164179/2025, it sets two deadlines: “the deadline for adopting the baseline security measures […] is set at eighteen months from the NIS entity’s receipt of the communication of inclusion in the list of NIS entities”, nine months for reporting baseline significant incidents.

Eighteen and nine months from when, though, is not a fixed date: both run from an individual communication, different for every entity. The ACN’s page renders this as an illustrative reference — “within 18 months (October 2026)” — absent from the signed text: it is the Agency’s estimate for the first registration round, not the statutory deadline. A specification that read by October 2026 would be wrong for most clients: the deadline has to be tied to the communication the client actually received, a document in its own file, not the contractor’s.

Where the record sits, today

The communication of inclusion sits with the client, on the Agency’s platform: the contractor has no access to it. The supply-chain clauses and the reporting deadline, where they exist, sit in the specification or the contract — not in the decree, which imposes neither, nor always in the requirements of whoever actually sent the crew on site. The OTDR traces and the fault log, which make a root cause checkable, sit with whoever did the work, when they exist at all. The physical perimeter Article 24 protects overlaps with what an up-to-date as-built record should describe, rarely in a format that survives a check. Four places: none of them, alone, shows a contractor is aligned with its NIS client’s risk perimeter.

See the service · Talk to an engineer

What we do not know

This is not legal advice. We have not read the ACN determination’s technical annexes in full: where we cite them, it is for structure, not verified content. We do not know, for any specific client, when it received its communication of inclusion, nor whether essential or important: that is a fact to ask for, not assume. The reasoning on a reporting deadline shorter than 24 hours is our own deduction, not a rule written into the decree. Anyone drafting a specification on this basis should have position and deadlines checked by a qualified consultant.

Two threads, on this subject

A NIS entity’s specification needs the clause Article 24 already points to and almost nobody writes down: supply-chain security as a requirement on the direct supplier, a reporting deadline shorter than the 24 hours binding the client, OTDR traces and the fault log as contractual records, not a technical courtesy. At acceptance, the check is that those clauses have a real match on the ground, not a generic statement of compliance with the NIS decree.

The communication of inclusion, specifications, contracts, OTDR traces and as-built records become, with CSIDIA, the group’s other company, a single map on which an AI checks, with an operator in command, whether the documents required for that client exist — a dated record, ready for an inspection, not reconstructed when one arrives. Within the client’s perimeter: on-premise, on standalone machines, or a dedicated cloud with a dedicated VPN and a data centre in Italy, always with shared management — the same approach behind the data centres we work with.

Do you need to check whether your client is a NIS entity, or turn Article 24 into a specification clause? Talk to an engineer: the first session is free of charge.