NIS2 in Italy: What the October 31, 2026 Deadline Means for In-House Code

Italy implemented the NIS2 Directive with Legislative Decree 138/2024, that came into force on October 16, 2024. The National Cybersecurity Agency (ACN) is set as a supervisor of how it is applied. And by the end of October 2026 most organizations on the NIS list have to apply ACN's baseline security measures.

After this date, ACN will move from guidance to inspections. They will be looking for proof that each measure is actually working and someone monitors it.

 

Who has to meet the October 31 deadline?

Under ACN determination 379907/2025, organizations have 18 months to implement the baseline measures, counted from the moment ACN notifies them about their inclusion on the NIS list. For the entities that received this notice in 2025, the 18 months end in October 2026.

[NOTE] Organizations added to the NIS list later have their own 18-month countdown, which starts from their individual notice.

[IMPORTANT] Many gap analyses still refer to ACN's determination from April 2025 that’s no longer valid: determination 379907/2025 from December 24, 2025, replaced it and has been in force since January 15, 2026.

 

 

What do the baseline measures require?

The number of measures depends on the entity's category:

• Important entities have to implement 37 measures and 87 requirements;

• Essential entities have to implement 43 measures and 116 requirements.

For teams developing or maintaining software, there are 3 areas that matter the most.

Vulnerability management. Measure ID.RA-01 requires identifying and recording vulnerabilities in the organization's assets. And measure ID.RA-08 requires a process for receiving, analyzing and responding to vulnerability information:

• monitoring CSIRT Italia and sector ISACs for new vulnerabilities;

• fixing identified vulnerabilities promptly, through updates or mitigation measures;

• a formal vulnerability management plan approved by the management body.

[NOTE] Essential entities must also monitor software vendors' channels for vulnerabilities in critical software.

 

Supply chain security. Security policies must cover risks in the supply chain as ACN describes them in 4 phases: 

1. Assessing the risk of each supply. Both new and existing suppliers are assessed, and the depth of the assessment depends on the risk. The minimum criteria include the supplier's access to the organization's systems and data (like intellectual property, source code) and the impact of a service interruption.

2. Setting security requirements. The organization decides which security requirements apply to which supplier. The requirements apply only to suppliers where the risk is relevant.

3. Enforcing them through contracts. The requirements become contract clauses, such as incident notification deadlines, the right to request evidence and audit rights. This is mandatory for contracts signed, renewed or extended after the deadline. Existing contracts don't have to be rewritten, but their risk still has to be assessed and handled.

4. Verifying them over time. The organization checks that suppliers actually meet these requirements during the whole contract, using service reports, tests, audits, logs or certifications. A review is also needed after an incident, a change of subcontractor or a new relevant vulnerability.

 

Development and maintenance of information systems. Security policies must also cover how information systems are developed, configured, maintained and decommissioned.

For in-house applications, these areas overlap. An in-house application is an asset, so the vulnerabilities in its code fall under ID.RA-01. And the open-source libraries inside it come from third parties, so they are part of the supply chain as well.

 

What happens after October 31?

ACN supervises these 2 categories differently:

• Essential entities are supervised ex ante, so an inspection can happen without any incident;

• Important entities are supervised ex post, after an incident or a report.

An inspection usually starts with a document request, continues with a technical and organizational assessment, and moves to an on-site audit when needed.

[IMPORTANT] Fines may go up to €10 million or 2% of worldwide annual turnover for essential entities, and up to €7 million or 1.4% for important entities, whichever is higher. Also, the management body should be the one approving the security measures and answering for violations, so this responsibility can't be delegated to the IT team.

[NOTE] The European Commission proposed amendments to NIS2 on January 20, 2026. But the proposal is still under negotiation and keeps the core duties to manage cyber risks and report incidents, so the October deadline stays in place.

 

What evidence can the development team prepare?

Since ACN checks whether the measures actually work, each of the 3 areas above needs a record. Here's what the security team can prepare before the deadline on October 31.

1. A record of vulnerabilities found and fixed in in-house code. DerScanner SAST analyzes source code in 43+ languages and maps the findings to OWASP Top 10 and CWE/SANS Top 25. Scan history and Scans Comparison show when a vulnerability appeared and when it was fixed providing evidence for ID.RA-01 and ID.RA-08.

2. An inventory of open-source components. DerScanner SBOM generation produces a CycloneDX SBOM to support every release. And DerScanner SCA checks components for known vulnerabilities, supply chain risks and license policy violations.

3. Control over what enters the build. Artifactory Analysis connects to Nexus or JFrog and blocks downloads of components that violate custom security policies. We cover this approach step by step in How to Stop Malicious Packages at the Repository Manager, Before the Build.

 

If you're preparing evidence for ACN before October 31 and want to test DerScanner on your own codebase, book a demo or request a PoC. We're always up for a chat.