Vulnerabilità critiche in PHP e dichiarazione congiunta delle istituzioni europee: che cosa cambia, sul piano degli obblighi giuridici, per titolari del trattamento e soggetti NIS2

Abstract

Il 21 ottobre 2026 la Commissione europea (DG CNECT), l’ENISA, il CERT-EU, Europol EC3 e la rete dei CSIRT nazionali hanno diffuso una dichiarazione congiunta che invita le organizzazioni ad agire immediatamente su due vulnerabilità critiche di PHP, identificate come CVE-2026-109618 e CVE-2026-109619, idonee — secondo quanto riportato dalla fonte — a consentire l’esecuzione remota di codice non autenticata. L’atto non ha natura provvedimentale e non crea obblighi nuovi, ma intercetta un reticolo di doveri già vigenti: l’articolo 32 del Regolamento (UE) 2016/679 sulla sicurezza del trattamento, gli articoli 21 e 23 della Direttiva (UE) 2022/2555 recepiti dal decreto legislativo 138/2024, e l’obbligo di segnalazione delle vulnerabilità attivamente sfruttate introdotto dall’articolo 14 del Regolamento (UE) 2024/2847, applicabile dall’11 settembre 2026. La tesi che qui si sostiene è che un avviso tecnico di questo tenore operi, per i soggetti destinatari, come fatto costitutivo di “conoscenza” rilevante: da quel momento l’inerzia nella rimediazione diventa difficilmente giustificabile in sede di accountability e di eventuale contestazione sanzionatoria.

Premessa

In premessa va detto che la dichiarazione congiunta del 21 ottobre 2026 appartiene a una categoria di atti che il giurista tende, per abitudine, a collocare fuori dal proprio perimetro: un avviso tecnico su due vulnerabilità di un linguaggio di programmazione, corredato di indicazioni di rimediazione e di rinvii a repository e advisory. Trattasi, formalmente, di un atto privo di efficacia vincolante diretta, non riconducibile né al genere del provvedimento amministrativo né a quello della soft law interpretativa delle autorità di protezione dei dati.

Eppure, per quanto di stretto interesse in questa sede, l’atto produce effetti giuridici indiretti di notevole rilievo. Il primo discende dalla struttura stessa delle norme che presidiano la sicurezza informatica nell’ordinamento europeo: sia l’articolo 32 del Regolamento (UE) 2016/679, sia l’articolo 21 della Direttiva (UE) 2022/2555 e le corrispondenti disposizioni del decreto legislativo 138/2024, sia infine il Regolamento (UE) 2024/2847 adottano un paradigma di obbligazione di mezzi calibrata sul rischio e sullo “stato dell’arte”. Tale paradigma presuppone, per funzionare, che l’organizzazione acquisisca e processi le informazioni disponibili sulle minacce. Una dichiarazione congiunta diffusa dalla principale agenzia europea di cybersicurezza, dal CERT-EU e dalla rete dei CSIRT nazionali costituisce, con ogni probabilità, il tipo di informazione più agevolmente opponibile a chi, in un momento successivo, affermi di non aver potuto conoscere il rischio.

Il secondo effetto riguarda il piano temporale. L’avviso data al 21 ottobre 2026 la pubblicazione degli aggiornamenti da parte del PHP security team, con indicazione dell’orario (13:40 UTC) e il rinvio al security advisory ufficiale del progetto. La precisione del riferimento non è casuale: in materia di gestione delle vulnerabilità la finestra fra la disponibilità della correzione e la sua applicazione è esattamente lo spazio in cui si colloca l’eventuale rimprovero di colpa organizzativa.

Il presente contributo non si propone di analizzare il profilo tecnico delle due vulnerabilità — compito che compete ai CSIRT e ai team di sicurezza, e rispetto al quale la fonte rinvia agli advisory ufficiali — bensì di ricostruire il reticolo di obblighi giuridici che un evento di questo tipo attiva o riattiva in capo a tre categorie di soggetti: il titolare del trattamento che eroghi servizi o gestisca applicazioni basate su PHP; il soggetto essenziale o importante ai sensi del decreto legislativo 138/2024; il fabbricante di prodotti con elementi digitali destinatario, dall’11 settembre 2026, degli obblighi di segnalazione del Cyber Resilience Act. Il perimetro dell’analisi comprende altresì il rapporto contrattuale con i fornitori di hosting e di servizi gestiti, che nella vicenda in esame assume un rilievo pratico centrale.

Il fatto: struttura e valore istituzionale della dichiarazione congiunta

La dichiarazione si presenta come atto plurisoggettivo. Vi concorrono la Commissione europea per il tramite della Direzione generale CNECT, l’Agenzia dell’Unione europea per la cibersicurezza, il servizio di cibersicurezza per le istituzioni, gli organi e gli organismi dell’Unione (CERT-EU), il Centro europeo per la lotta alla criminalità informatica di Europol (EC3) e la rete dei CSIRT nazionali. Si tratta, in sostanza, dell’intera architettura di cooperazione operativa disegnata dalla Direttiva (UE) 2022/2555, che agli articoli 15 e 16 istituisce rispettivamente la rete dei CSIRT e la rete europea delle organizzazioni di collegamento per le crisi informatiche (EU-CyCLONe).

Il contenuto dispositivo è sintetico. Si raccomanda alle organizzazioni di identificare le proprie applicazioni basate su PHP, di coordinarsi con i fornitori di hosting e di servizi, e di applicare gli aggiornamenti rilasciati, dando priorità ai sistemi esposti su internet. Ove la rimediazione immediata non sia praticabile, si suggerisce di isolare le applicazioni esposte dalle reti pubbliche fino all’applicazione delle correzioni. Viene inoltre segnalato un profilo che merita particolare attenzione sul piano giuridico: molti prodotti commerciali e open source incorporano PHP “in background”, sicché possono risultare interessati dalle vulnerabilità anche organizzazioni che non ritengano di utilizzare direttamente quel linguaggio. A tal fine la dichiarazione rinvia a un repository curato dal CSIRT nazionale dei Paesi Bassi, dedicato alla mappatura del software di terze parti che include PHP, e alla raccolta di advisory mantenuta dall’ENISA.

Chiude il testo una sezione espressamente intitolata “EU Policy”, nella quale si ricorda che, a decorrere dall’11 settembre 2026, i fabbricanti di prodotti hardware e software sono tenuti a segnalare le vulnerabilità attivamente sfruttate attraverso la piattaforma unica di segnalazione prevista dal Regolamento (UE) 2024/2847, e che i requisiti sostanziali di cibersicurezza del medesimo regolamento troveranno applicazione dall’11 dicembre 2027, imponendo ai fabbricanti la sicurezza fin dalla progettazione e il supporto di sicurezza lungo il ciclo di vita, inclusa la rimediazione delle vulnerabilità senza ritardo.

Va detto che la presenza di una sezione di policy all’interno di un avviso operativo non è un dettaglio redazionale. Appare chiaro allo scrivente che le istituzioni europee stiano consapevolmente utilizzando gli eventi di sicurezza ad alto impatto come occasione di enforcement comunicativo: l’avviso tecnico veicola, insieme alla raccomandazione di patching, il promemoria dell’obbligo normativo. È una tecnica che si era già vista in occasione della dichiarazione congiunta sulle vulnerabilità SharePoint del luglio 2025, e che segnala una progressiva saldatura fra la dimensione della threat intelligence e quella della compliance regolamentare. [Nota redazionale: verificare l’esistenza e la data della dichiarazione congiunta sulle vulnerabilità SharePoint del luglio 2025 prima della pubblicazione.]

Il quadro normativo di riferimento

La disciplina europea della cibersicurezza: NIS2, gestione delle vulnerabilità e rete CSIRT

La Direttiva (UE) 2022/2555 — comunemente NIS2 — costituisce il perno dell’architettura. Per quanto rileva in questa sede, tre blocchi di disposizioni vengono direttamente in considerazione.

Il primo è l’articolo 21, che impone ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi posti alla sicurezza dei sistemi informatici e di rete. Il paragrafo 2 elenca un nucleo minimo di ambiti, fra i quali figurano espressamente la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete — con riferimento specifico alla gestione e alla divulgazione delle vulnerabilità — nonché la sicurezza della catena di approvvigionamento. In sostanza, la gestione delle vulnerabilità non è una buona pratica facoltativa: è un contenuto tipizzato dell’obbligo di sicurezza. In termini più pragmatici, l’organizzazione soggetta a NIS2 deve essere in grado di dimostrare di possedere un processo strutturato che comprenda l’inventario degli asset software, il monitoraggio delle fonti di advisory, la valutazione di applicabilità, la pianificazione e l’esecuzione del patching, la verifica dell’avvenuta rimediazione.

Il secondo blocco è l’articolo 23, che disciplina gli obblighi di segnalazione degli incidenti significativi secondo la nota scansione trifasica: preallarme entro ventiquattro ore dalla conoscenza dell’incidente, notifica dell’incidente entro settantadue ore, relazione finale entro un mese. Occorre qui una precisazione di non poco conto, sulla quale si tornerà: la vulnerabilità in quanto tale non è un incidente. L’obbligo di notifica sorge quando la vulnerabilità viene sfruttata e lo sfruttamento determina un evento che compromette la disponibilità, l’autenticità, l’integrità o la riservatezza dei dati conservati, trasmessi o elaborati, ovvero dei servizi offerti, con il grado di significatività richiesto dalla norma.

Il terzo blocco è l’articolo 12, che istituisce il quadro europeo per la divulgazione coordinata delle vulnerabilità e la banca dati europea delle vulnerabilità gestita dall’ENISA. Su questa base l’Agenzia ha reso operativa la European Vulnerability Database e ha successivamente assunto il ruolo di Root all’interno del programma CVE, assegnando identificativi tramite le CVE Numbering Authorities operanti sotto la propria radice. Il dato ha una valenza più che simbolica: la tracciabilità pubblica delle vulnerabilità, con identificativi stabili e informazioni sullo stato di sfruttamento, costituisce il presupposto fattuale su cui si innesta la valutazione di diligenza del singolo operatore. In altri termini, più il sistema informativo pubblico sulle vulnerabilità è completo e accessibile, meno sostenibile diventa l’eccezione di non conoscenza.

Il recepimento nazionale: il decreto legislativo 138/2024 e il ruolo dell’ACN

Il decreto legislativo 4 settembre 2024, n. 138, ha recepito la NIS2 nell’ordinamento italiano, individuando nell’Agenzia per la cybersicurezza nazionale l’autorità nazionale competente e il CSIRT Italia quale struttura deputata alla ricezione delle notifiche e al coordinamento operativo.

Le disposizioni che interessano maggiormente in questa sede sono quelle relative agli obblighi degli organi di amministrazione e direttivi, alle misure di gestione dei rischi e alla notifica degli incidenti. Il decreto, in continuità con la direttiva, costruisce un sistema in cui la responsabilità dell’adeguatezza delle misure è radicata al vertice: gli organi di amministrazione approvano le modalità di implementazione delle misure, sovraintendono alla loro attuazione e rispondono delle violazioni. Si tratta di una scelta che, letta accanto alla previsione di sanzioni amministrative pecuniarie di rilievo e alla possibilità di misure interdittive nei confronti delle persone fisiche con funzioni dirigenziali nei soggetti essenziali, muta sensibilmente la fisionomia del rischio di compliance rispetto al regime della prima direttiva NIS.

Va altresì ricordato che l’ACN ha adottato determinazioni attuative che specificano la tempistica di adeguamento e il contenuto delle misure di sicurezza di base, articolandole secondo un principio di gradualità e proporzionalità. Non si ha evidenza, alla data di redazione del presente contributo, di provvedimenti specificamente dedicati alla vicenda PHP: la dichiarazione congiunta rinvia, per gli advisory nazionali, ai canali ufficiali dei singoli membri della rete CSIRT, e dunque — per l’Italia — alle comunicazioni del CSIRT Italia.

Accanto a NIS2 restano operanti, nell’ordinamento nazionale, il perimetro di sicurezza nazionale cibernetica istituito dal decreto-legge 105/2019, convertito con modificazioni dalla legge 133/2019, con i relativi obblighi di notifica a termini assai più stringenti per i soggetti inclusi, e le disposizioni della legge 90/2024 in materia di rafforzamento della cibersicurezza nazionale, che per le pubbliche amministrazioni indicate ha introdotto, fra l’altro, obblighi di segnalazione e la figura del referente per la cybersicurezza. Il concorso di questi regimi genera, per taluni soggetti, una pluralità di canali di notifica con presupposti e termini differenti: profilo critico sul quale si tornerà.

Il Cyber Resilience Act: dalla vulnerabilità del prodotto all’obbligo del fabbricante

Il Regolamento (UE) 2024/2847 — Cyber Resilience Act — introduce un paradigma diverso e complementare. Mentre NIS2 e GDPR si rivolgono a chi utilizza sistemi e tratta dati, il CRA si rivolge a chi immette sul mercato prodotti con elementi digitali, imponendo requisiti essenziali di cibersicurezza e obblighi di gestione delle vulnerabilità lungo il periodo di supporto.

Il regolamento prevede un’applicazione scaglionata. I requisiti sostanziali, contenuti negli allegati e richiamati dagli obblighi dei fabbricanti, si applicheranno dall’11 dicembre 2027. Gli obblighi di segnalazione di cui all’articolo 14 si applicano invece già dall’11 settembre 2026, come la dichiarazione congiunta puntualmente ricorda. La norma impone al fabbricante di notificare, tramite la piattaforma unica di segnalazione, le vulnerabilità attivamente sfruttate contenute nel prodotto, secondo una scansione che prevede un preallarme entro ventiquattro ore dalla conoscenza, una notifica più circostanziata entro settantadue ore e una relazione finale nei termini previsti dal regolamento. Analogo obbligo è previsto per gli incidenti gravi aventi impatto sulla sicurezza del prodotto.

Il contenuto sostanziale degli obblighi del fabbricante, destinato a divenire pienamente esigibile dalla fine del 2027, comprende la progettazione e lo sviluppo del prodotto in modo da assicurare un livello adeguato di cibersicurezza in base ai rischi, la fornitura del prodotto privo di vulnerabilità sfruttabili note, la predisposizione di un processo documentato di gestione delle vulnerabilità, la redazione e l’aggiornamento di una distinta base del software — la cosiddetta SBOM — almeno per i componenti di primo livello, nonché la rimediazione tempestiva delle vulnerabilità mediante aggiornamenti di sicurezza resi disponibili, ove possibile, in modo gratuito e automatico.

Si ritiene che proprio la vicenda PHP illustri con particolare nitidezza la ragione sistematica di tali obblighi. La dichiarazione congiunta avverte che molti prodotti incorporano PHP senza che l’utilizzatore ne abbia contezza; e la circostanza che il CSIRT olandese abbia dovuto costituire un repository dedicato alla mappatura dei software di terze parti contenenti PHP è, sotto il profilo che qui interessa, la dimostrazione empirica di un deficit informativo strutturale. Quel deficit è esattamente ciò che la SBOM obbligatoria mira a colmare. In termini più pragmatici: oggi l’organizzazione deve ricostruire a posteriori, con strumenti collaborativi e repository pubblici, quali dei propri prodotti contengano la componente vulnerabile; dall’11 dicembre 2027 quella informazione dovrà, in linea di principio, essere già disponibile presso il fabbricante e tracciabile a monte.

Resta impregiudicata la questione — delicata e tutt’altro che risolta — del rapporto fra CRA e software libero e open source. Il regolamento esclude dal proprio ambito, a determinate condizioni, il software libero e open source fornito al di fuori di un’attività commerciale, e introduce la figura dello “steward” del software open source con obblighi attenuati. PHP, in quanto progetto open source mantenuto da una comunità, non è di per sé un prodotto immesso sul mercato da un fabbricante nel senso del regolamento; lo diventa, per così dire, nel momento in cui viene integrato in un prodotto commerciale. Di conseguenza, l’obbligo di segnalazione di cui all’articolo 14 grava non sul progetto a monte, bensì sui fabbricanti dei prodotti che quella componente incorporano e che la immettono sul mercato dell’Unione nell’ambito di un’attività commerciale.

Il GDPR: sicurezza del trattamento e violazione dei dati personali

Il Regolamento (UE) 2016/679 interviene su un piano ulteriore, che si sovrappone parzialmente ai precedenti senza confondersi con essi. L’articolo 32, paragrafo 1, impone al titolare e al responsabile del trattamento di mettere in atto misure tecniche e organizzative adeguate per garantire “un livello di sicurezza adeguato al rischio”, tenendo conto “dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche”. La lettera d) del medesimo paragrafo menziona espressamente “una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento”.

Va detto che la locuzione “stato dell’arte” è il punto di innesto normativo degli advisory di sicurezza. Lo stato dell’arte non è una categoria astratta: si alimenta delle pubblicazioni delle agenzie competenti, degli standard tecnici, delle raccomandazioni dei CSIRT. Nel momento in cui la Commissione, l’ENISA, il CERT-EU, Europol e la rete dei CSIRT dichiarano congiuntamente che due vulnerabilità sono critiche, che consentono esecuzione remota di codice senza autenticazione e che esistono correzioni disponibili, quella dichiarazione entra a far parte dello stato dell’arte conoscibile. Di conseguenza, la mancata applicazione della correzione, in assenza di una motivazione documentata e di misure compensative, difficilmente potrà essere ricondotta all’area del rischio accettato consapevolmente, e si avvicinerà piuttosto all’area dell’omissione.

L’articolo 33 disciplina la notifica della violazione all’autorità di controllo “senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza”, salvo che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche. L’articolo 34 impone la comunicazione agli interessati nei casi di rischio elevato. Le Linee guida 9/2022 dell’EDPB sulla notifica delle violazioni di dati personali, che hanno sostituito le precedenti linee guida del Gruppo di lavoro ex articolo 29, precisano i criteri di individuazione del momento della conoscenza e il rapporto fra accertamento e notifica, chiarendo che una fase di indagine interna ragionevolmente breve è compatibile con l’obbligo, ma che il termine decorre dal momento in cui il titolare acquisisce un ragionevole grado di certezza circa il verificarsi di un incidente di sicurezza che ha condotto alla compromissione di dati personali.

Qui si colloca una distinzione che, secondo il parere di chi scrive, merita di essere ribadita con nettezza, perché l’esperienza applicativa mostra che non sempre è chiara nelle organizzazioni: la mera esistenza di una vulnerabilità non sfruttata, su un sistema che tratta dati personali, non integra una violazione ai sensi dell’articolo 4, numero 12, del GDPR, e dunque non attiva l’obbligo di notifica. Si tratta di una condizione di rischio, non di un evento di compromissione. Diverso è il caso in cui l’analisi forense accerti che la vulnerabilità è stata sfruttata, oppure che non sia possibile escluderne lo sfruttamento: in tale seconda ipotesi, l’impossibilità di escludere la compromissione — in presenza di indicatori che la rendano plausibile — tende a essere trattata dalle autorità come elemento che orienta verso la notifica, secondo il criterio prudenziale che informa la disciplina.

L’avviso congiunto come fatto giuridicamente rilevante

Si è detto in premessa che la dichiarazione non crea obblighi. Occorre ora precisare in che senso, nondimeno, essa produca conseguenze.

La prima conseguenza attiene alla conoscibilità. Tutte le norme richiamate — l’articolo 32 del GDPR, l’articolo 21 della NIS2 e le corrispondenti disposizioni del decreto legislativo 138/2024, l’articolo 13 del CRA quando sarà pienamente applicabile — costruiscono obblighi il cui adempimento presuppone un flusso informativo. Un avviso diffuso congiuntamente dalle massime istituzioni europee competenti, pubblicato sul sito dell’ENISA e replicato dai CSIRT nazionali, rende oggettivamente conoscibile il rischio. In sede di eventuale accertamento ispettivo o sanzionatorio, l’organizzazione che non abbia applicato la correzione sarà chiamata a spiegare non tanto perché non sapesse, quanto perché, pur potendo sapere, non abbia agito.

La seconda conseguenza attiene alla qualificazione della colpa organizzativa. Nella prassi decisionale delle autorità di protezione dei dati, la mancata applicazione di aggiornamenti di sicurezza per vulnerabilità note e documentate è stata ripetutamente valorizzata come indice di inadeguatezza delle misure ai sensi dell’articolo 32. Si tratta di un orientamento che, pur nella varietà delle fattispecie, presenta una linea argomentativa costante: la vulnerabilità nota e corretta dal produttore sposta il baricentro della valutazione dalla sofisticazione dell’attacco alla tempestività della reazione difensiva. Non si ha evidenza, alla data odierna, di provvedimenti del Garante specificamente riferiti alle vulnerabilità PHP qui in esame; ma la struttura del ragionamento è prevedibile e già collaudata.

La terza conseguenza attiene al piano probatorio dell’accountability. L’articolo 5, paragrafo 2, del GDPR impone al titolare di essere in grado di comprovare il rispetto dei principi, fra cui quello di integrità e riservatezza di cui al paragrafo 1, lettera f). Un avviso pubblico e datato costituisce un punto di riferimento temporale esterno rispetto al quale misurare la reattività dell’organizzazione. In termini più pragmatici: se l’avviso è del 21 ottobre e la patch è stata applicata il 23 ottobre sui sistemi esposti, la documentazione di quel percorso — ticket, log di deployment, verbali del comitato di sicurezza — è un elemento di prova a discarico. Se la patch è stata applicata tre mesi dopo, la medesima documentazione diventa, specularmente, la prova dell’inerzia.

Il nodo della catena di fornitura: PHP come componente invisibile

Il passaggio della dichiarazione congiunta che segnala la presenza di PHP “in background” in molti prodotti commerciali e open source merita un’analisi autonoma, perché intercetta uno dei profili più problematici della compliance contemporanea.

L’organizzazione media non sviluppa software: lo acquista, lo noleggia come servizio, lo riceve preinstallato su apparati. La conoscenza della composizione interna dei prodotti è, nella generalità dei casi, indiretta e mediata dal fornitore. Di conseguenza, l’obbligo di “identificare le proprie applicazioni basate su PHP” — che la dichiarazione formula come se fosse un’operazione lineare — si traduce, sul piano pratico, in un’attività di interrogazione della catena di fornitura che richiede strumenti contrattuali e processuali adeguati.

L’articolo 21, paragrafo 2, lettera d), della NIS2 impone la sicurezza della catena di approvvigionamento, comprese le relazioni fra ciascun soggetto e i suoi fornitori o prestatori di servizi diretti. L’articolo 28 del GDPR, a sua volta, impone che il responsabile del trattamento offra garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate e che il contratto disciplini, fra l’altro, l’assistenza al titolare nel garantire il rispetto degli obblighi di cui agli articoli da 32 a 36 e l’obbligo di informare il titolare della violazione senza ingiustificato ritardo. Il Regolamento (UE) 2022/2554 — DORA — spinge il medesimo principio ancora più avanti per il settore finanziario, imponendo contenuti contrattuali minimi tipizzati nei rapporti con i fornitori terzi di servizi TIC e un registro delle informazioni sugli accordi contrattuali.

Appare chiaro allo scrivente che, in una vicenda come quella in esame, la differenza fra un’organizzazione preparata e una impreparata non si misuri sul piano tecnico, bensì su quello contrattuale e documentale. L’organizzazione preparata dispone di un inventario degli asset che correla ciascuna applicazione al fornitore responsabile e alla componente tecnologica sottostante; ha inserito nei contratti clausole che obbligano il fornitore a comunicare tempestivamente l’applicabilità delle vulnerabilità critiche ai servizi erogati e a dichiarare i tempi di rimediazione; ha concordato livelli di servizio differenziati per severità. L’organizzazione impreparata, al contrario, si trova a dover inviare richieste informali a decine di fornitori e ad attendere risposte che potrebbero non arrivare, in una condizione di incertezza che, dal punto di vista della responsabilizzazione, è essa stessa un’inadeguatezza.

Il riferimento al repository del CSIRT olandese, contenuto nella dichiarazione, è in questa prospettiva significativo e, insieme, sintomatico. Significativo perché documenta una prassi collaborativa di mappatura che supplisce alla carenza informativa; sintomatico perché quella supplenza è necessaria solo in quanto le informazioni sulla composizione del software non sono ancora sistematicamente disponibili presso i fabbricanti. Si ritiene che sia proprio questa constatazione a fornire la migliore giustificazione sistematica dell’obbligo di SBOM introdotto dal CRA.

Il concorso fra regimi di notifica e il rischio di duplicazione

Un profilo che merita attenzione, e che la dichiarazione congiunta — per la sua natura di avviso operativo — non affronta, riguarda il concorso fra i diversi obblighi di segnalazione che possono attivarsi in conseguenza dello sfruttamento di una vulnerabilità come quelle in esame.

Si consideri un’ipotesi esemplificativa, costruita in astratto. Una società italiana che eroga servizi digitali, qualificata come soggetto importante ai sensi del decreto legislativo 138/2024, gestisce un portale clienti basato su un’applicazione che incorpora PHP; la società è altresì titolare del trattamento dei dati personali degli utenti; produce inoltre un apparato con componente software che integra la medesima componente e lo immette sul mercato dell’Unione. Nell’ipotesi in cui una delle due vulnerabilità venga sfruttata con esfiltrazione di dati, la società si trova potenzialmente destinataria di tre distinti obblighi: la notifica dell’incidente significativo al CSIRT Italia secondo la scansione dell’articolo 23 NIS2 come recepito; la notifica della violazione dei dati personali al Garante per la protezione dei dati personali ai sensi dell’articolo 33 del GDPR, con eventuale comunicazione agli interessati ai sensi dell’articolo 34; la segnalazione della vulnerabilità attivamente sfruttata, nella qualità di fabbricante, attraverso la piattaforma unica di segnalazione ai sensi dell’articolo 14 del CRA. Se operasse nel settore finanziario, si aggiungerebbe la segnalazione degli incidenti gravi connessi alle TIC ai sensi del Regolamento (UE) 2022/2554; se rientrasse nel perimetro di sicurezza nazionale cibernetica, interverrebbero i termini assai più brevi previsti dal decreto-legge 105/2019.

I termini non coincidono perfettamente, i presupposti sono differenti — l’incidente significativo, la violazione di dati personali, la vulnerabilità attivamente sfruttata sono nozioni distinte — e i destinatari sono diversi. Si ritiene che questa stratificazione costituisca oggi uno dei principali fattori di complessità operativa per le organizzazioni multi-regolate, e che la risposta non possa che essere procedurale: una procedura unica di gestione dell’incidente che, a partire da un unico evento scatenante e da un’unica attività di qualificazione, attivi in parallelo i diversi canali di notifica secondo matrici di competenza predefinite. Costruire procedure separate per ciascun regime, affidate a funzioni aziendali diverse che non comunicano fra loro, è prassi che l’esperienza di audit mostra foriera di errori, omissioni e, soprattutto, di dichiarazioni fra loro disallineate — circostanza, quest’ultima, particolarmente insidiosa, perché le autorità comunicano fra loro e l’incoerenza delle rappresentazioni rese a soggetti istituzionali diversi è elemento che può aggravare la posizione dell’organizzazione.

Va aggiunto che il legislatore europeo è consapevole del problema: la NIS2 prevede meccanismi di cooperazione fra autorità e la possibilità di notifiche a sportello unico in alcuni contesti nazionali, e il CRA espressamente istituisce una piattaforma unica di segnalazione proprio per ridurre la frammentazione. Non si ha evidenza, tuttavia, che il risultato complessivo sia già oggi una effettiva semplificazione per l’operatore: il numero dei canali resta elevato e la loro integrazione è, allo stato, più un obiettivo di policy che un dato acquisito.

Profili critici

Un primo profilo critico riguarda la qualificazione giuridica della finestra temporale fra pubblicazione della correzione e sua applicazione. Nessuna delle norme richiamate fissa un termine per l’applicazione delle patch. L’articolo 32 del GDPR parla di adeguatezza al rischio; l’articolo 21 della NIS2 di proporzionalità; il CRA, per i fabbricanti, di rimediazione “senza ritardo”. Il risultato è che il termine di patching è, nella sostanza, autodeterminato dall’organizzazione in sede di policy interna e poi valutato ex post dall’autorità secondo un giudizio di ragionevolezza. Si ritiene che tale assetto, pur coerente con l’impostazione risk-based del diritto europeo della cibersicurezza, generi una significativa incertezza applicativa, che l’organizzazione prudente può attenuare soltanto in un modo: dotandosi di una policy che fissi termini differenziati per severità e per esposizione, applicandola con costanza e documentando puntualmente le eccezioni. In sostanza, l’autovincolo documentato diventa il parametro rispetto al quale l’organizzazione sarà giudicata — con l’avvertenza, non secondaria, che una policy scritta e sistematicamente disattesa è peggio dell’assenza di policy, perché prova la consapevolezza dello scarto.

Un secondo profilo critico attiene alla misura compensativa suggerita dalla dichiarazione congiunta, ossia l’isolamento delle applicazioni esposte dalle reti pubbliche in attesa della correzione. Dal punto di vista della sicurezza si tratta di una raccomandazione ineccepibile. Dal punto di vista giuridico, però, l’isolamento di un’applicazione esposta equivale, in molti casi, all’interruzione del servizio. Se quel servizio è oggetto di obbligazione contrattuale, l’organizzazione si trova a dover bilanciare l’esigenza di sicurezza con il rischio di inadempimento; se il soggetto è essenziale ai sensi del decreto legislativo 138/2024 e il servizio ha rilevanza per una funzione critica, l’indisponibilità prolungata potrebbe essa stessa integrare un incidente significativo soggetto a notifica. Si suggerisce pertanto di considerare, già in sede di redazione dei contratti e delle procedure di continuità operativa, che la sospensione precauzionale del servizio per ragioni di sicurezza sia espressamente contemplata e qualificata, così da non essere trattata ex post come mero inadempimento.

Un terzo profilo riguarda il perimetro soggettivo. La dichiarazione si rivolge genericamente alle “organisations”, e il suo contenuto raccomandatorio è, in sé, privo di selettività. Ma l’intensità dell’obbligo giuridico sottostante varia sensibilmente: il soggetto essenziale o importante ai sensi di NIS2 risponde di un obbligo tipizzato di gestione delle vulnerabilità; il titolare del trattamento risponde di un obbligo di adeguatezza modulato sul rischio per i diritti e le libertà; il fabbricante risponde, dall’11 settembre 2026, di uno specifico obbligo di segnalazione, e dall’11 dicembre 2027 di obblighi sostanziali di rimediazione. Si ritiene che la prima attività che il DPO e la funzione compliance debbano compiere, di fronte a un avviso di questo tenore, sia proprio la qualificazione del proprio ente rispetto ai diversi regimi — attività che, se non svolta a monte e tenuta aggiornata, difficilmente può essere improvvisata nell’arco delle ore in cui occorre decidere.

Un quarto profilo, di carattere più generale, riguarda il ruolo delle comunità open source. Il caso PHP mostra che componenti mantenute da comunità di sviluppatori volontari sostengono porzioni rilevanti dell’infrastruttura digitale europea. Il CRA tenta di governare il fenomeno attraverso la figura dello steward e l’esclusione del software non commerciale, ma il punto di equilibrio è delicato: un carico regolatorio eccessivo sulle comunità rischierebbe di disincentivare il mantenimento dei progetti, mentre un’esclusione troppo ampia lascerebbe scoperta la parte più fragile della catena. Secondo il parere di chi scrive, la vicenda in esame offre materiale utile alla riflessione: la correzione è stata rilasciata dal PHP security team con tempestività e corredata di dettagli tecnici completi, e la risposta istituzionale europea si è innestata su quel lavoro. Il modello di cooperazione sembra, dunque, funzionare sul piano operativo; resta da verificare se e come il quadro regolatorio riuscirà a sostenerlo anche sul piano delle risorse, profilo rispetto al quale non si ha evidenza di soluzioni consolidate.

Un quinto e ultimo profilo riguarda la dimensione probatoria dell’esclusione dello sfruttamento. Quando si accerta una vulnerabilità critica su un sistema esposto, la domanda decisiva ai fini del GDPR non è se la vulnerabilità esista, ma se sia stata sfruttata. La risposta dipende dalla disponibilità e dalla qualità dei log e dalla loro conservazione per un periodo adeguato. Un’organizzazione che non conservi log sufficienti si trova nell’impossibilità materiale di escludere la compromissione, e dunque — per prudenza — nella condizione di dover notificare. Ne consegue un corollario operativo che la prassi di audit conferma con regolarità: la politica di logging non è soltanto una misura di sicurezza, ma una misura che determina direttamente l’ampiezza degli obblighi di notifica. L’articolo 32 del GDPR e l’articolo 21 della NIS2 coprono entrambi la materia, ma è il collegamento con gli articoli 33 e 34 a renderne evidente la portata economica e reputazionale.

Adempimenti per il DPO e per l’impresa

Sul piano operativo, l’avviso congiunto impone anzitutto una verifica di applicabilità, che non coincide con la semplice ricerca del linguaggio PHP nei sistemi noti, ma richiede di interrogare l’inventario degli asset software e, ove questo non restituisca informazioni sufficienti sulle componenti di terze parti, di attivare le richieste ai fornitori. Si suggerisce di procedere per cerchi concentrici, partendo dai sistemi esposti su internet e dalle applicazioni che trattano dati personali su larga scala o categorie particolari di dati, secondo la stessa logica di priorità raccomandata dalla dichiarazione congiunta; la documentazione dell’ordine di priorità adottato e delle ragioni che lo sorreggono costituisce, essa stessa, elemento di accountability.

Segue, in stretta connessione, l’aggiornamento dell’inventario degli asset, che l’esperienza applicativa dei sistemi di gestione mostra essere il punto di rottura più frequente. Un inventario che si limiti a elencare server e applicazioni senza indicare le componenti software sottostanti, il fornitore responsabile della manutenzione e il riferimento contrattuale non consente di rispondere con tempestività a un avviso come quello in esame. Si suggerisce pertanto di cogliere l’occasione per arricchire l’inventario con il campo relativo alle componenti di terze parti, predisponendolo in una forma compatibile con le distinte base del software che i fabbricanti saranno tenuti a produrre in forza del Regolamento (UE) 2024/2847.

Il terzo adempimento consiste nell’attivazione della procedura di gestione delle vulnerabilità, con registrazione formale dell’avviso, assegnazione della severità, individuazione del responsabile della rimediazione e fissazione del termine. Qualora l’organizzazione sia soggetto essenziale o importante ai sensi del decreto legislativo 138/2024, tale procedura deve esistere già come attuazione dell’obbligo tipizzato di gestione e divulgazione delle vulnerabilità; qualora non vi rientri ma tratti dati personali, essa costituisce comunque attuazione dell’articolo 32 del Regolamento (UE) 2016/679. In entrambi i casi la registrazione documentata della decisione — compresa la decisione di non applicare immediatamente la correzione, se motivata — è ciò che distingue una scelta di rischio consapevole da un’omissione.

Laddove la correzione non sia immediatamente applicabile, occorre procedere all’adozione di misure compensative, quali la segregazione di rete, la limitazione dell’esposizione, l’inserimento di regole specifiche sui dispositivi di protezione perimetrale o, nei casi più gravi, la sospensione del servizio. Si ritiene opportuno che tale decisione, per le implicazioni contrattuali e di continuità operativa già evidenziate, sia assunta a un livello gerarchico adeguato e verbalizzata, coinvolgendo — ove il servizio sospeso abbia rilievo per funzioni critiche o per i diritti degli interessati — anche il responsabile della protezione dei dati nella valutazione degli impatti.

Parallelamente si impone una verifica retrospettiva di compromissione, consistente nell’analisi dei log disponibili per il periodo precedente l’applicazione della correzione, al fine di accertare se la vulnerabilità sia stata sfruttata. Tale verifica è giuridicamente decisiva, poiché da essa dipende l’attivazione o meno degli obblighi di notifica di cui all’articolo 33 del Regolamento (UE) 2016/679 e all’articolo 23 della Direttiva (UE) 2022/2555 come recepita. Si suggerisce di documentare anche l’esito negativo dell’analisi, con indicazione delle fonti di log consultate e del periodo coperto: la dichiarazione di non compromissione priva di supporto documentale ha, in sede di contraddittorio con l’autorità, un valore prossimo allo zero.

Qualora l’analisi accerti o non consenta di escludere la compromissione, occorre procedere alla qualificazione dell’evento rispetto a ciascuno dei regimi applicabili, attivando i canali di notifica pertinenti secondo le rispettive tempistiche. Si suggerisce in proposito di predisporre, in via preventiva, una matrice interna che associ le tipologie di evento ai regimi e ai destinatari, così da ridurre il tempo di decisione nella fase acuta; e di assicurare la coerenza sostanziale fra le diverse comunicazioni, affidandone la revisione finale a un’unica funzione di coordinamento.

Sul versante dei rapporti esterni, si impone la sollecitazione formale dei fornitori, da svolgersi con richiesta scritta e tracciata circa l’applicabilità delle vulnerabilità ai servizi erogati, i tempi di rimediazione previsti e le misure compensative adottate nel frattempo. Nei confronti dei responsabili del trattamento, tale richiesta trova fondamento diretto nell’articolo 28, paragrafo 3, lettera f), del Regolamento (UE) 2016/679, che impone l’assistenza al titolare nel garantire il rispetto degli obblighi di sicurezza; nei confronti dei fornitori TIC di entità finanziarie, negli obblighi contrattuali tipizzati dal Regolamento (UE) 2022/2554. Si ritiene che la mancata risposta del fornitore entro un termine ragionevole debba essere essa stessa registrata come evento di rischio e valutata ai fini della revisione del rapporto contrattuale.

Non secondario è l’adempimento di informazione e coinvolgimento del responsabile della protezione dei dati, che l’articolo 38, paragrafo 1, del Regolamento (UE) 2016/679 impone sia coinvolto tempestivamente e adeguatamente in tutte le questioni riguardanti la protezione dei dati personali. L’esperienza mostra che gli avvisi di sicurezza tendono a circolare esclusivamente all’interno delle funzioni tecniche, raggiungendo il DPO soltanto quando l’incidente si è già verificato. Si suggerisce di formalizzare il flusso informativo, prevedendo che gli advisory di severità critica relativi a sistemi che trattano dati personali siano notificati al DPO contestualmente alla loro acquisizione, così da consentirne la valutazione in fase preventiva e non soltanto rimediale.

Si impone inoltre un’attività di aggiornamento della valutazione d’impatto, ove sia stata condotta ai sensi dell’articolo 35 del Regolamento (UE) 2016/679 per i trattamenti interessati. La norma prevede al paragrafo 11 che il titolare proceda a un riesame quando insorgono variazioni del rischio: l’emersione di una vulnerabilità critica su una componente infrastrutturale di un trattamento ad alto rischio integra, secondo il parere di chi scrive, esattamente tale ipotesi, quantomeno quando la correzione non sia immediatamente applicabile e si debba ricorrere a misure compensative.

Per i soggetti che rivestono la qualità di fabbricanti di prodotti con elementi digitali, occorre infine la verifica degli obblighi di segnalazione ai sensi del Cyber Resilience Act, già applicabili dall’11 settembre 2026 per le vulnerabilità attivamente sfruttate. Si suggerisce di accertare preventivamente la registrazione sulla piattaforma unica di segnalazione, l’individuazione dei soggetti abilitati all’invio e la definizione delle soglie interne che attivano la procedura, poiché il termine di ventiquattro ore per il preallarme non consente attività preparatorie successive all’evento. Parallelamente, in vista dell’11 dicembre 2027, si suggerisce di avviare la predisposizione della distinta base del software e del processo documentato di gestione delle vulnerabilità, che costituiranno requisiti sostanziali e non meramente procedurali.

Chiude il quadro l’adempimento di rendicontazione agli organi di amministrazione, imposto per i soggetti NIS2 dalla responsabilizzazione del vertice prevista dal decreto legislativo 138/2024 e, più in generale, coerente con il principio di responsabilizzazione del titolare. Si ritiene opportuno che eventi come quello in esame siano portati all’attenzione dell’organo amministrativo con una sintesi che indichi l’esposizione accertata, le azioni intraprese, i tempi di rimediazione e i rischi residui, così da costituire traccia documentale della supervisione esercitata.

Conclusioni

La dichiarazione congiunta del 21 ottobre 2026 non introduce obblighi; ne attiva di esistenti e, soprattutto, ne rende difficilmente contestabile il presupposto conoscitivo. Il suo interesse per il giurista d’impresa e per il responsabile della protezione dei dati risiede meno nel contenuto tecnico che nella funzione sistematica che atti di questo genere stanno progressivamente assumendo: punti di riferimento temporali e sostanziali rispetto ai quali misurare la diligenza organizzativa.

Restano aperte alcune questioni di non lieve momento. La prima riguarda l’assenza, nell’intero impianto europeo, di un termine normativo per l’applicazione delle correzioni di sicurezza: scelta coerente con l’approccio basato sul rischio, ma che scarica sull’interprete e, in ultima analisi, sull’autorità di controllo la determinazione ex post del confine fra ritardo fisiologico e inerzia colpevole. Non si ha evidenza di orientamenti consolidati che individuino soglie temporali di riferimento, e si ritiene che un intervento chiarificatore — anche in forma di linee guida delle autorità competenti, ovvero di prassi condivise elaborate nell’ambito del gruppo di cooperazione NIS — sarebbe utile a ridurre l’incertezza.

La seconda questione riguarda l’effettiva convergenza dei regimi di segnalazione. La piattaforma unica prevista dal Regolamento (UE) 2024/2847 costituisce un passo nella direzione giusta, ma coesiste con i canali NIS2, con quelli del GDPR, con quelli settoriali di DORA e, per l’Italia, con il perimetro di sicurezza nazionale cibernetica e con gli obblighi introdotti dalla legge 90/2024. L’organizzazione multi-regolata continua a confrontarsi con una pluralità di adempimenti dai presupposti non coincidenti, e la semplificazione resta, allo stato, un obiettivo dichiarato più che un risultato conseguito.

La terza questione riguarda la sostenibilità del modello open source all’interno del nuovo quadro. Il caso PHP mostra una comunità in grado di rilasciare correzioni con rapidità e un’architettura istituzionale europea capace di amplificarne l’effetto; mostra anche, però, che la conoscenza della composizione del software è ancora affidata a iniziative collaborative volontarie. Gli obblighi di distinta base del software introdotti dal Cyber Resilience Act dovrebbero, dall’11 dicembre 2027, modificare questo assetto; sarà interessante verificare se la trasparenza sulla composizione dei prodotti si tradurrà effettivamente in una riduzione dei tempi di identificazione dell’esposizione, che è poi il fattore su cui si misura, in concreto, la resilienza.

La quarta e ultima questione riguarda il ruolo del responsabile della protezione dei dati rispetto a un fenomeno — la vulnerabilità software — che appartiene per tradizione al dominio tecnico. Si ritiene che la progressiva convergenza fra disciplina della cibersicurezza e disciplina della protezione dei dati renda non più sostenibile una separazione rigida dei perimetri: il DPO non è chiamato a valutare la gravità tecnica di un CVE, ma a presidiare il collegamento fra quella gravità e il rischio per i diritti e le libertà degli interessati, nonché a verificare che l’organizzazione disponga dei processi che consentono di assolvere, ove necessario, agli obblighi di notifica. In questa prospettiva, un avviso come quello del 21 ottobre 2026 è, a tutti gli effetti, documentazione rilevante per l’esercizio della funzione.

Riferimenti normativi

• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (UE) 2019/881 (Cybersecurity Act)
• Regolamento (UE) 2022/2554 (DORA)
• Regolamento (UE) 2024/2847 (Cyber Resilience Act)
• Direttiva (UE) 2022/2555 (NIS2)
• decreto legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali)
• decreto-legge 21 settembre 2019, n. 105, convertito con modificazioni dalla legge 18 novembre 2019, n. 133
• legge 28 giugno 2024, n. 90
• decreto legislativo 4 settembre 2024, n. 138
• Linee guida 9/2022 del Comitato europeo per la protezione dei dati sulla notifica delle violazioni di dati personali ai sensi del GDPR
• Dichiarazione congiunta della Commissione europea (DG CNECT), ENISA, CERT-EU, Europol EC3 e rete dei CSIRT dell’Unione europea sulle vulnerabilità critiche di PHP, 21 ottobre 2026