NIS2 is the EU cybersecurity directive (2022/2555), transposed into Italian law by legislative decree 138/2024, in force since October 16, 2024. It covers 18 critical sectors and requires thousands of medium and large companies across the EU to manage cyber risk, report incidents, and vet their own suppliers.
If you run a software house that ships code to clients in those sectors, energy, healthcare, finance, public administration, the question that matters isn't whether NIS2 applies to you. In most cases it doesn't. The question is what your client, the one who does have to answer for it, is going to ask you, because the part of the law about supply chains reaches you too, even if you never register anywhere.
What NIS2 actually is, without the compliance jargon?
NIS2 is the second version of the EU directive on the security of network and information systems, in force in Italy since October 16, 2024 under legislative decree 138/2024. It widens the scope from 7 to 18 sectors, energy, transport, healthcare, finance, water, digital infrastructure, public administration, space, and others, and splits regulated organizations into "essential" and "important" entities, with different oversight and different penalties: up to 2% of global turnover for essential entities, up to 1.4% for important ones. Entities in scope have to manage risk to their networks and systems, report significant incidents to CSIRT Italia within tight deadlines, and, the part that matters here, assess the security of their own direct suppliers, including how those suppliers build software. The authority that enforces this in Italy is the National Cybersecurity Agency (ACN), which also runs the registration portal and receives incident reports.
Who does it actually apply to, and why it's probably not you?
The standard threshold follows the EU's medium-enterprise definition: more than 50 employees, or more than €10 million in annual turnover or balance sheet total, with sector-specific exceptions that pull in small and micro enterprises for a few categories (energy, telecoms, public administration among them). But for a software vendor, the sector matters more than the size. The European Commission lists 18 sectors: energy, transport, healthcare, financial services, water and wastewater, digital infrastructure, managed ICT service management, space, public administration, postal services, waste management, and manufacturing of critical products, among others. Custom software development for third-party clients isn't one of them. A company providing digital infrastructure or managed ICT services (cloud, data centers, hosting) can fall directly in scope; a software house writing code for a client, almost never. The perimeter isn't yours. The problem is somewhere else.
Why the supply chain reaches you anyway?
Legislative decree 138/2024, in article 24, requires essential and important entities to adopt "adequate and proportionate" measures to manage cyber risk, and those minimum measures explicitly include supply chain security, the security of the relationship with direct suppliers and service providers. When assessing that chain, a regulated entity has to consider each supplier's specific vulnerabilities and the overall quality of its security practices, including its secure development procedures. If you write software for a regulated entity, you're one of the suppliers that assessment has to cover, even though you never register with ACN or sign anything with them directly. The compliance obligation stays with your client. The questionnaire, the contract clause, or the audit request that lands on your desk is still yours to handle. The same shift in who has to produce the evidence shows up, with a different object, around what's inside a build an AI agent generated: the formal responsibility sits with the client, but the vendor has to supply the actual proof.
What ends up in the contract: vulnerabilities, patching, change traceability
The requests that come from a NIS2-regulated client tend to repeat themselves, regardless of sector.
| Area | What the client tends to ask | What you need to answer it |
|---|---|---|
| Vulnerability management | A documented process for finding, assessing, and fixing vulnerabilities | A vulnerability log with dates and time-to-fix |
| Patching and updates | A declared maximum turnaround for critical patches | A verifiable history of releases and patches, dated |
| Incident notification | Cascading disclosure: if an incident touches your code, the client needs to know within hours | An agreed notification channel and a log of who knew what, and when |
| Secure development practices | Evidence that code doesn't ship by accident: review, tests, authorization | Real traceability of who, or which agent, wrote and approved each change |
| Change traceability | Who did what, when, under what authorization | A linked, signable record, not just a commit message |
The last two rows are the ones most software houses show up unprepared for, because they're not about how secure the code itself is, they're about being able to show, after the fact, who authorized and who reviewed every change. That gap widens further once part of the code comes from an agent instead of a person: an AI code review tool checks the quality of the diff, it doesn't produce, on its own, proof that someone authorized and accepted it.
What's worth tracking now, before your client asks?
Italy's own deadlines for regulated entities are already set by ACN: registration or an update on the ACN portal between January 1 and February 28, significant-incident notification to CSIRT Italia live since January 1, 2026, an annual information update due by May 31, and baseline security measures fully operational by October 31, 2026, the date from which ACN can start inspections. None of those deadlines are formally yours. But your client's calendar becomes yours in practice: the sooner they're asked to assess their suppliers, the sooner it lands on your desk.
You don't need to build NIS2 compliance that was never asked of you. You need to be able to answer, with something more solid than a commit message, who authorized a change, what was checked before it shipped, and who stands behind it. Detent, the end-to-end delivery system (detent-ai.com), keeps intent, authorized context, execution, and a human signature tied together across every delivery, from request to release: the kind of record that turns an awkward client question into a five-minute answer instead of a reconstruction from memory.