NIS2 and suppliers: what regulated clients will ask you for (October 2026 deadline) - init.d - consulenza IT, DevOps e sviluppo software

# NIS2 and suppliers: what regulated clients will ask you for (October 2026 deadline)

Alessandro Corbelli~7 min
Table of Contents

If your company sells services to another company, sooner or later that client will send you a security questionnaire or a clause to sign. In 2026 it is more likely than ever: the European NIS2 directive, transposed in Italy by legislative decree 138/2024, is reaching its first big operational deadline.

NIS2 is not only about giants. By law it covers medium and large companies in eighteen sectors (not just energy and healthcare, also digital services, manufacturing and more) and, in some cases, smaller businesses too. Those in scope are placed on a list kept by ACN, Italy’s national cybersecurity agency, and must adopt security measures and report incidents. If you are not on that list you have no such obligations by law. But if you sell something to someone who is, those obligations reach you anyway, through the contract.

This article follows the Italian rules, because that is where most of our clients are: the directive is European, but dates and details are set by each country. We explain how the step from client to supplier works, which measures touch servers, backups and access, and where to start. An honest premise: this is not legal advice. These are the technical requirements ACN has published, translated into things you can check.

The deadlines: October 2026 is not for everyone

The calendar depends on when the entity was placed on the list. Every year, from 1 January to 28 February, the companies concerned register on the ACN portal, and the agency tells each of them whether it has been included. Two deadlines run from that notice:

  • 9 months for reporting significant incidents (for the first group, listed in 2025, it started in January 2026);
  • 18 months for the baseline security measures (for the same group, October 2026).

Entities listed for the first time in 2026 get more time: incident reporting from 1 January 2027 and baseline measures by 31 July 2027. So “October 2026” is not a universal date: it depends on the client in front of you. The measures are those of ACN Determination 379907 of 19 December 2025, in force since 15 January 2026: 37 measures for important entities and 43 for essential ones.

How it reaches a supplier: through contracts

The baseline measures include managing supply chain risk. In practice the client must assess the suppliers that can affect its security and put security requirements into contracts. ACN’s FAQ clarify the points that matter to you:

  • contracts already in place do not have to be amended; the requirements become mandatory for contracts signed, renewed or extended from the baseline-measures deadline onwards, unless there are documented legal or technical reasons not to;
  • the client assesses the risk of each supply: how much you access its systems and data, how much a prolonged outage of yours would weigh, how much recovery costs and how long it takes;
  • the requirements concern supplies with a potential security impact and must capture the substance of the measures, not copy their text.

So what you will find written down is decided by the client. The common thread is that whoever runs their servers, their management software or their online shop will have to show they have in order the same things the client must have in order in-house.

The measures that touch servers, backups and access

The baseline specifications are broad and also cover governance, training and documentation. The ones closest to infrastructure, and so to the answers an IT supplier will have to give, are these:

  • Inventory of systems and services (ID.AM, GV.OC): an up-to-date list of hardware, software, services and suppliers. The first step is knowing what runs, where and who manages it.
  • Only software that still gets security updates (PR.PS-02): only software, operating systems included, whose vendor guarantees security patches may be installed, and patches must be applied “without undue delay”, barring documented technical reasons. This is the case of anyone staying on an end-of-life PHP version. A recent example is the two critical flaws of PHP2Shell, fixed on 21 October 2026.
  • Backups, offline too (PR.DS-11): regular backups of data and configurations and, for relevant systems, offline copies as well. The 3-2-1 backup rule is a good starting point, as long as you test the restore.
  • Multi-factor authentication and separate accounts (PR.AA-03, PR.AA-05): multi-factor authentication for relevant systems, based on risk, and administrative accounts distinct from ordinary ones, with different credentials.
  • Remote access listed, protected and logged (PR.IR-01, PR.PS-04): a list of the systems reachable remotely and how, up-to-date firewalls, and logging of all remote access and of access with administrative privileges, with logs stored securely and preferably centrally. A bastion host for SSH access solves most of it.
  • Vulnerability management (ID.RA-08): a written plan saying how vulnerabilities are found, tracked and fixed, including monitoring the channels of CSIRT Italia, the national team that handles cyber incidents.
  • Suppliers and the supply chain (GV.SC, PR.PS-06): an inventory of suppliers with a contact and the type of supply and, for those who develop software, documented secure development practices. The supply chain theme concerns code too: see the story of the compromised npm packages.

One reassuring detail: many requirements apply “at least to the relevant information and network systems”, that is, those whose compromise would significantly affect the services. The client can limit where it applies them, and so where it will ask you for confirmation. Personal data remain a separate chapter, that of the GDPR, which we covered in GDPR on the infrastructure side.

Incidents: 24 hours, 72 hours, one month, and who warns whom

A NIS entity reports a significant incident to CSIRT Italia in three steps (article 25 of decree 138/2024):

  1. an early warning within 24 hours of becoming aware of the incident;
  2. a notification within 72 hours, with a first assessment of severity and impact;
  3. a final report within one month of the notification, with the cause and the measures taken.

The clock starts when the entity has evidence of the incident, which is often after the incident happened. That is why the time between “something happened on your server” and “the client knows” matters: ACN indicates that clients should contractually ask suppliers to report security events promptly. If a supplier’s incident hits the client’s services, it is the client that notifies CSIRT, and the supplier as well if the incident is significant for it; for cloud services both notify, except for infrastructure (IaaS and hosting), where only the client does.

In plain terms: you must be able to say within hours what happened, on which systems and with what consequences. Without logs, without a reachable contact and without a written procedure that is not possible.

Where to start, in one afternoon

You do not need a six-month project to begin. A sensible order:

  1. Take stock of servers, applications, external services and who manages them. A table is enough.
  2. Close the doors: multi-factor authentication wherever possible, separate administrative accounts, a list of remote access.
  3. Test a restore from backup, offline copy included. A backup never restored is a hope.
  4. Write two pages: the patching plan and the incident procedure, with the name and phone number of whoever answers.
  5. Prepare a client sheet summarising how you manage servers, backups, access and incidents: you will reuse it with every questionnaire.

Putting the technical side in order is our daily work of securing Linux servers. An honest note: we are a technical consultancy, we do not do compliance audits or legal advice. For that you need a lawyer or a specialised consultant.

In short

NIS2 reaches suppliers through contracts: after the baseline-measures deadline, which falls in October 2026 for the first group of entities and in July 2027 for the new 2026 entrants, regulated clients will have to ask for security requirements from those who serve them. The requests will revolve around concrete things: inventory, patches on supported software, backups offline too, protected and logged access, a vulnerability plan and an incident procedure. Whoever starts now can answer in an orderly way instead of improvising in front of a questionnaire.

Sources

Tux versione Gandalf, mascotte del blog init.d

init.d is the team led by Alessandro Corbelli, a Linux systems administrator and backend developer with over twenty years of experience. He designs and runs cloud infrastructure (Google Cloud, AWS, Azure), server farms and high-availability architectures, and builds custom software in Laravel/PHP and Vue - from the Take2Me food delivery platform to our clients’ management tools. On this blog we share technical notes on Linux, system administration, development, DevOps and e-commerce.


More Posts