Da ottobre 2024 la direttiva NIS2 è legge anche in Italia, con il decreto legislativo 138/2024. Per molte aziende e amministrazioni il 2026 è l’anno in cui gli obblighi sono diventati concreti: da gennaio va notificato ogni incidente significativo e, per chi è stato inserito nell’elenco NIS nel 2025, entro ottobre andavano adottate le misure di sicurezza di base. Chi espone su Internet portali, servizi o e-commerce scritti in PHP si pone una domanda precisa: un’applicazione che gira su una versione di PHP fuori supporto è compatibile con questi obblighi?
In questo articolo leggiamo cosa dicono davvero la direttiva e il decreto italiano sulla gestione delle vulnerabilità, perché un PHP in End of Life è un punto delicato, quali sono le scadenze indicate dall’Agenzia per la cybersicurezza nazionale e cosa si può fare in pratica. È un’analisi tecnica: per stabilire se e come la tua organizzazione rientra nella norma, e con quali obblighi specifici, il riferimento resta il tuo consulente legale o il responsabile della conformità.
Chi deve applicare NIS2
Il decreto legislativo 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024, recepisce la direttiva (UE) 2022/2555. Si applica ai soggetti pubblici e privati dei settori elencati negli allegati, dall’energia ai trasporti, dalla sanità alle infrastrutture digitali, dalla manifattura di alcuni prodotti ai servizi postali, e per i settori degli allegati I e II alle imprese che superano i massimali della piccola impresa. I soggetti sono classificati come essenziali o importanti, con obblighi simili e regimi di vigilanza e sanzioni diversi.
Il primo adempimento è la registrazione sulla piattaforma dell’Agenzia per la cybersicurezza nazionale (ACN), che il decreto fissa ogni anno tra il 1° gennaio e il 28 febbraio. Sulla base delle registrazioni, l’Agenzia redige l’elenco dei soggetti e comunica l’inserimento a ciascuno.
Anche chi non rientra nell’ambito della norma ne sente gli effetti. I soggetti NIS devono occuparsi della sicurezza dei propri fornitori, e chi sviluppa, ospita o gestisce applicazioni per loro riceve sempre più spesso questionari, richieste di evidenze e clausole contrattuali sulla gestione delle vulnerabilità.
Cosa dice la norma sulle vulnerabilità
Il cuore tecnico è l’articolo 24 del decreto, che corrisponde all’articolo 21 della direttiva. Il comma 1 chiede misure tecniche, operative e organizzative “adeguate e proporzionate” ai rischi, che tengano conto “delle conoscenze più aggiornate e dello stato dell’arte”. Il comma 2 elenca gli elementi minimi che queste misure devono comprendere, dalla lettera a) alla lettera l).
Tre lettere riguardano direttamente un’applicazione che gira su un PHP fuori supporto:
- lettera a): politiche di analisi dei rischi e di sicurezza dei sistemi informativi e di rete. Un componente senza correzioni è un rischio da censire, valutare e trattare;
- lettera d): sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori diretti. Il comma 3 chiede di tenere conto delle vulnerabilità specifiche di ciascun fornitore e della qualità delle sue pratiche di sicurezza;
- lettera e): sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi, “ivi comprese la gestione e la divulgazione delle vulnerabilità”.
Il comma 4 aggiunge un punto spesso trascurato: se un soggetto rileva di non essere conforme a queste misure, adotta “senza indebito ritardo” le misure correttive necessarie. Le modalità di dettaglio sono definite dall’ACN con le proprie determinazioni; quella in vigore sulle specifiche di base è la n. 379907/2025, che organizza le misure secondo il Framework nazionale per la cybersecurity e la data protection.
Perché un PHP fuori supporto è un punto critico
Né la direttiva né il decreto citano versioni o prodotti, e non esiste una regola che vieti in sé il software fuori supporto. Il problema nasce dalla combinazione degli obblighi. Gestire le vulnerabilità significa conoscerle, valutarle e correggerle in tempi coerenti con il rischio. Su un ramo di PHP in End of Life le correzioni ufficiali non arrivano più: ogni nuova CVE che riguarda il codice di quel ramo resta aperta finché qualcuno non interviene. Come abbiamo spiegato nell’articolo su cosa significa PHP End of Life, a novembre 2026 sono in questa situazione tutti i rami fino all’8.1, e l’8.2 lo sarà dal 1° gennaio 2027.
Un componente senza correzioni richiede una risposta documentata, anche se non costituisce di per sé una violazione. Davanti a un’ispezione o a una richiesta di un cliente servono tre cose: sapere dove si trova, avere una valutazione del rischio che lo riguarda e poter mostrare cosa si sta facendo per ridurlo, con quali tempi. “Funziona da anni” non è una misura di sicurezza.
La situazione è diversa quando il pacchetto PHP, pur con un numero di versione vecchio, riceve ancora correzioni dalla distribuzione o da un fornitore di supporto esteso. In quel caso la vulnerabilità viene corretta e il punto da dimostrare diventa la copertura di quel supporto: chi lo fornisce, su quali CVE, con quali tempi e fino a quando.
Le scadenze in Italia
Il decreto rimanda all’ACN la definizione di modalità e termini. Secondo quanto pubblicato dall’Agenzia nella sezione dedicata alla NIS, per i soggetti inseriti nell’elenco nel 2025 l’obbligo di notifica degli incidenti significativi si applica da gennaio 2026, nove mesi dopo la comunicazione dell’inserimento, e le misure di sicurezza di base andavano adottate entro ottobre 2026, diciotto mesi dopo.
Per i soggetti inseriti per la prima volta nel 2026 l’Agenzia ha fissato termini specifici con determinazioni successive. Le date valgono quindi per la tua organizzazione solo se corrispondono alla comunicazione che hai ricevuto: verifica sulla piattaforma ACN e con chi segue la conformità.
Se una vulnerabilità diventa un incidente
Un PHP fuori supporto aumenta la probabilità che una vulnerabilità nota venga sfruttata. Se lo sfruttamento causa un incidente significativo, cioè una grave perturbazione dei servizi, perdite finanziarie o danni considerevoli ad altri, l’articolo 25 del decreto prevede una sequenza di comunicazioni al CSIRT Italia:
| Comunicazione | Termine | Contenuto essenziale |
|---|---|---|
| Pre-notifica | entro 24 ore da quando si viene a conoscenza dell’incidente | se può derivare da atti illegittimi o malevoli, se può avere impatto transfrontaliero |
| Notifica | entro 72 ore | valutazione iniziale di gravità e impatto, indicatori di compromissione se disponibili |
| Relazione intermedia | su richiesta del CSIRT Italia | aggiornamenti sulla situazione |
| Relazione finale | entro un mese dalla notifica | descrizione dettagliata, causa originale, misure di attenuazione |
La relazione finale chiede la “causa originale” dell’incidente. Se la causa è una CVE nota da mesi su un componente senza correzioni, la domanda successiva sarà inevitabile: perché era ancora aperta? Per questo la procedura di risposta deve essere pronta prima, con ruoli e passaggi chiari; ne descriviamo una nell’articolo sulle prime 24 ore dopo una CVE critica su PHP.
La responsabilità degli organi di amministrazione
NIS2 porta la sicurezza informatica al livello dei vertici. L’articolo 23 del decreto stabilisce che gli organi di amministrazione e direttivi approvano le modalità di attuazione delle misure di gestione dei rischi, ne sovrintendono l’implementazione, sono responsabili delle violazioni e sono tenuti a seguire una formazione in materia. Devono inoltre essere informati degli incidenti e delle notifiche.
Le sanzioni sono definite dall’articolo 38. Per le violazioni degli obblighi degli articoli 23, 24 e 25, i soggetti essenziali rischiano fino a 10 milioni di euro o al 2% del fatturato annuo mondiale, se superiore; i soggetti importanti fino a 7 milioni di euro o all’1,4%. Sono previsti regimi diversi per le pubbliche amministrazioni e, in caso di mancato adeguamento a una diffida, anche sanzioni accessorie per le persone fisiche con funzioni di vertice. Una decisione come “restiamo su PHP 7.4 ancora un anno” smette quindi di essere solo tecnica: va presa da chi ne ha la responsabilità, sulla base di una valutazione del rischio documentata.
Cosa fare in pratica
Per un’organizzazione che espone applicazioni PHP su Internet, una sequenza ragionevole è questa:
- inventario: per ogni server e applicazione, versione di PHP, origine dei pacchetti, esposizione su Internet, dati trattati;
- valutazione del rischio: per ogni componente fuori supporto, quali vulnerabilità note lo riguardano davvero nella configurazione in uso;
- piano di trattamento: migrazione a un ramo supportato con una data, approvata dagli organi responsabili;
- misure nel frattempo: backport delle patch di sicurezza sul ramo in uso, mitigazioni come la disattivazione delle estensioni inutili, la limitazione degli accessi amministrativi e un web application firewall;
- fornitori: chi gestisce server e applicazioni deve impegnarsi per contratto su tempi di correzione, comunicazione delle vulnerabilità e supporto in caso di incidente;
- evidenze: ogni decisione, intervento e verifica va registrato, perché è ciò che si mostra in un’ispezione.
Gli stessi materiali servono anche per gli audit ISO 27001 e PCI DSS, che chiedono evidenze molto simili: ne parliamo nell’articolo su come dimostrare la gestione delle vulnerabilità di PHP in un audit.
Tirando le somme
La NIS2, recepita in Italia con il D.Lgs. 138/2024, chiede misure adeguate allo stato dell’arte, una gestione delle vulnerabilità e un controllo dei fornitori che un componente senza correzioni rende difficili da dimostrare, anche se non vieta in sé il software fuori supporto. Per i soggetti inseriti nell’elenco nel 2025 la notifica degli incidenti è obbligatoria da gennaio 2026 e le misure di base andavano adottate entro ottobre 2026; per gli altri valgono i termini comunicati dall’ACN. Le decisioni sui sistemi obsoleti spettano agli organi di amministrazione, che ne rispondono. La strada più solida resta un inventario, una valutazione del rischio, un piano di migrazione con una data e, nel frattempo, patch e mitigazioni documentate. Per gli aspetti giuridici, a partire dall’inquadramento della tua organizzazione, fai sempre riferimento al tuo consulente.
