Direttiva NIS2: dinamiche di notifica degli incidenti e sicurezza della catena di approvvigionamento

L’evoluzione del quadro normativo europeo e il recepimento nazionale

L’infrastruttura digitale dell’Unione Europea ha subito, nel corso dell’ultimo decennio, una trasformazione radicale che ha ridefinito i confini della sicurezza nazionale ed economica. In questo contesto di iper-connettività, la minaccia cibernetica si è evoluta da fenomeno isolato a rischio sistemico, capace di paralizzare settori nevralgici della società civile e dell’industria. Per fronteggiare tale asimmetria tra l’evoluzione delle minacce e la maturità difensiva degli Stati membri, il legislatore europeo ha varato la Direttiva (UE) 2022/2555 (NIS2).

Questo impianto normativo abroga e sostituisce la precedente Direttiva (UE) 2016/1148 (NIS1), la quale, pur avendo il merito di aver introdotto i primi standard, aveva generato un’applicazione disomogenea tra le diverse giurisdizioni nazionali, creando oneri amministrativi complessi per le entità transfrontaliere e lasciando ampie porzioni dell’economia digitale prive di un’adeguata copertura regolatoria.

Il fulcro della Direttiva NIS2 risiede nell’istituzione di un livello comune elevato di cibersicurezza nell’Unione Europea, imponendo agli Stati membri di rafforzare le proprie capacità di resilienza attraverso un approccio “multirischio”. L’innovazione principale della normativa è l’estensione massiccia del proprio perimetro di applicazione. Abbandonando il sistema di identificazione discrezionale della NIS1, la NIS2 adotta un criterio dimensionale e settoriale oggettivo: qualsiasi entità pubblica o privata di medie o grandi dimensioni che operi nei settori definiti ad alta criticità (Allegato I) o in altri settori critici (Allegato II) ricade automaticamente sotto l’egida della direttiva.

Tra i settori ad alta criticità figurano: l’energia, i trasporti, il settore bancario, le infrastrutture dei mercati finanziari, la sanità, l’acqua potabile, le acque reflue, le infrastrutture digitali, la gestione dei servizi TIC (Tecnologie dell’Informazione e della Comunicazione), la pubblica amministrazione e lo spazio. I settori critici includono, invece: i servizi postali e di corriere, la gestione dei rifiuti, la fabbricazione di prodotti chimici, la produzione alimentare, la fabbricazione di dispositivi medici e apparecchiature, nonché i fornitori di servizi digitali come motori di ricerca e piattaforme di social network. L’impatto di questo allargamento è imponente: le stime indicano che il numero di organizzazioni coinvolte aumenterà di un fattore dieci, coinvolgendo centinaia di migliaia di imprese in tutta Europa.

In Italia, il percorso di armonizzazione ha trovato il suo culmine con l’adozione del Decreto Legislativo 4 settembre 2024, n. 138 (D.Lgs. 138/2024), che ha recepito formalmente la Direttiva NIS2, entrando in vigore il 16 ottobre 2024. Il legislatore nazionale ha confermato l’Agenzia per la Cybersicurezza Nazionale (ACN) quale Autorità nazionale competente e Punto di contatto unico NIS, affidandole altresì le funzioni operative del Computer Security Incident Response Team (CSIRT) Italia.

La struttura del D.Lgs. 138/2024 impone obblighi cogenti organizzati in tre macro-aree:

• la governance della sicurezza (Articolo 23),
• l’adozione di misure di gestione dei rischi proporzionate e adeguate (Articolo 24)
• e la rigorosa disciplina della notifica degli incidenti (Articolo 25).

Inoltre, le entità devono iscriversi e aggiornare annualmente le proprie informazioni sulla piattaforma telematica dell’ACN, creando un censimento istituzionale dell’infrastruttura critica nazionale.

Un elemento di rottura rispetto al passato è il regime sanzionatorio e il principio di responsabilità diretta degli organi apicali. La Direttiva NIS2 esige che gli organi di amministrazione e direttivi delle entità essenziali e importanti approvino le misure di gestione dei rischi, ne supervisionino l’attuazione e siano formati in materia di cibersicurezza. In caso di inadempienza, le sanzioni amministrative pecuniarie previste assumono una magnitudo deterrente analoga a quella del Regolamento Generale sulla Protezione dei Dati (GDPR): per le entità essenziali, le sanzioni possono raggiungere i 10 milioni di euro o il 2% del fatturato annuo globale, mentre per le entità importanti il tetto è fissato a 7 milioni di euro o all’1,4% del fatturato.

A tali sanzioni pecuniarie si affiancano provvedimenti inibitori, tra cui la possibilità per l’ACN di disporre la sospensione temporanea dall’esercizio delle funzioni dirigenziali per i soggetti apicali responsabili delle violazioni. Questa architettura punitiva sancisce la definitiva trasformazione della cibersicurezza da questione squisitamente tecnica, relegata ai dipartimenti IT, a priorità strategica di governance aziendale, esponendo i Consigli di Amministrazione a responsabilità legali e finanziarie dirette.

La tassonomia degli incidenti e l’architettura di notifica multi-fase

La tempestività nella condivisione delle informazioni sulle minacce cibernetiche costituisce il prerequisito fondamentale per la difesa collettiva. Un attacco informatico non mitigato in una specifica entità può propagarsi rapidamente attraverso le reti di interconnessione, causando disservizi a cascata su scala nazionale o continentale. L’Articolo 23 della Direttiva NIS2 e il corrispondente Articolo 25 del D.Lgs. 138/2024 affrontano questa dinamica istituendo un obbligo di notifica degli incidenti significativi basato su un rigido approccio multi-fase (multi-stage reporting approach).

Il fondamento di questo meccanismo risiede nel concetto di “incidente significativo”. Secondo la definizione normativa, un incidente acquisisce tale qualifica se soddisfa almeno una di due condizioni:

1. ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per l'entità interessata;
2. oppure si è ripercosso o è in grado di ripercuotersi su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.

Per supportare le organizzazioni nella corretta identificazione di tali eventi, il legislatore italiano, attraverso la Legge 90/2024 e le successive Determinazioni dell’ACN (inclusa la Determinazione n. 379907/2025 sulle specifiche di base), ha elaborato una complessa tassonomia di riferimento. Tale tassonomia cataloga le fattispecie di incidenti e stabilisce le soglie di rilevanza che, una volta superate, fanno scattare l’obbligo di segnalazione e notifica, eliminando le ambiguità interpretative e promuovendo una risposta armonizzata a livello nazionale.

L’architettura di notifica imposta dalla NIS2 si articola in scadenze temporali perentorie, ciascuna progettata per soddisfare una specifica esigenza operativa delle autorità di vigilanza e dei team di risposta alle emergenze.

Questa accelerazione procedurale rappresenta uno dei cambiamenti più dirompenti per la cultura aziendale. Storicamente, le organizzazioni tendevano a procrastinare le comunicazioni verso l’esterno fino all’ottenimento di un quadro investigativo completo, nel timore di incorrere in danni reputazionali o responsabilità legali derivanti da informazioni parziali. La Direttiva NIS2 capovolge questo paradigma: il legislatore europeo stabilisce esplicitamente che il mero atto di notifica non espone l’entità notificante a una maggiore responsabilità (increased liability). Al contrario, l’omissione, il ritardo o la reticenza nella fase di Allerta Preliminare costituiscono violazioni gravi, sanzionabili autonomamente, poiché precludono all’ecosistema di difesa nazionale ed europeo la possibilità di attuare misure preventive.

L’acquisizione dell’evidenza: l’interpretazione giuridica del “dies a quo”

Il cardine su cui ruota l’intero regime sanzionatorio e operativo della notifica è la determinazione esatta del momento in cui si avvia il cronometro normativo. L’Articolo 23 della Direttiva utilizza la formula “dal momento in cui viene a conoscenza dell’incidente significativo” (becoming aware), una locuzione che necessita di una rigorosa interpretazione giuridica e procedurale. Nel panorama del diritto italiano, le Linee Guida dell’ACN sulla gestione degli incidenti informatici traducono questo concetto nella fase di “Rilevamento e Acquisizione dell’Evidenza”.

Dal punto di vista dell’analisi giuridica, la fase di rilevamento è il momento critico in cui un’anomalia tecnica si trasforma in un fatto giuridicamente rilevante. L’ACN chiarisce che l’evidenza non deve essere confusa con la certezza assoluta, con la risoluzione dell’incidente o con la piena comprensione delle dinamiche di attacco (cause, vettori, perimetri di compromissione). L’acquisizione dell’evidenza si perfeziona nel momento esatto in cui l’organizzazione matura la consapevolezza oggettiva e documentabile che un evento avverso con impatto “significativo” (in base alle soglie tassonomiche) è ragionevolmente in corso o si è già verificato.

Questo approccio mira a scoraggiare pratiche dilatorie. Un’entità non può legittimamente invocare l’incompletezza dell’indagine forense per giustificare il superamento delle 24 ore. L’Allerta Preliminare ammette intrinsecamente un grado di incertezza: essa richiede di dichiarare se l’atto è “presumibilmente” malevolo. Il legislatore tollera la provvisorietà delle prime informazioni, proprio perché la successiva scadenza delle 72 ore è preposta alla rettifica e all’approfondimento dei dati iniziali sulla base delle indagini in corso.

La determinazione del dies a quo impone alle organizzazioni di strutturare processi interni di escalation rapidissimi. Il dipartimento tecnico che per primo rileva l’anomalia (ad esempio, il Security Operations Center) non può trattenere l’informazione per prolungati cicli di validazione interna. Le Linee Guida ENISA raccomandano l’istituzione di un team multidisciplinare che includa, oltre al Chief Information Security Officer (CISO) e ai tecnici di incident response, una figura denominata Cyber Legal, Policy and Compliance Officer. Tale figura ha il compito di operare un rapido triage legale: analizzare i dati tecnici grezzi e stabilire immediatamente se le soglie di rilevanza normativa sono state varcate, attivando senza indugio la comunicazione istituzionale tramite il Referente CSIRT, la figura chiave designata per interloquire ufficialmente con l’ACN.

Un ulteriore elemento di complessità nel triage legale è la convergenza delle tempistiche NIS2 con quelle previste dall’Articolo 33 del GDPR. Se l’incidente cibernetico significativo comporta anche la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso a dati personali, l’organizzazione si trova a dover gestire due flussi di notifica paralleli ma distinti: uno verso il CSIRT per la conformità alla NIS2 (con scadenze a 24 e 72 ore) e uno verso l’Autorità Garante per la Protezione dei Dati Personali (entro 72 ore).

Sebbene a livello normativo si discuta della futura istituzione di uno sportello unico (single-entry point) per snellire questi adempimenti, allo stato attuale le organizzazioni devono coordinare gli sforzi tra il CISO e il Data Protection Officer (DPO) per garantire che le comunicazioni inviate alle diverse autorità siano tempestive e, soprattutto, coerenti e non contraddittorie nei contenuti, poiché discrepanze documentali in questa fase esporrebbero l’entità a doppie istruttorie sanzionatorie.

Il rischio sistemico e gli obblighi di sicurezza della catena di approvvigionamento

La disciplina della notifica acquisisce un livello di criticità esponenziale quando l’analisi si sposta dall’infrastruttura interna dell’entità alla sua catena di approvvigionamento (supply chain). La Direttiva NIS2 riconosce formalmente che i perimetri aziendali tradizionali sono ormai disciolti in ecosistemi di servizi interdipendenti. L’Articolo 21, recepito dall’Articolo 24 del D.Lgs. 138/2024, impone l’inclusione della “sicurezza della catena di approvvigionamento, compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o prestatori di servizi” tra le misure tecniche, operative e organizzative obbligatorie per la gestione del rischio.

Questa previsione normativa è corroborata da un’analisi del panorama delle minacce (threat landscape). I rapporti periodici dell’ENISA documentano un incremento vertiginoso degli attacchi mirati alla supply chain. Statistiche recenti indicano che circa il 62% degli attacchi informatici rivolti a organizzazioni clienti ha sfruttato, come vettore di compromissione iniziale, la fiducia riposta nei confronti dei loro fornitori diretti. Nel 66% degli incidenti analizzati, gli attori della minaccia hanno mirato al codice sorgente o all’infrastruttura di sviluppo dei fornitori per inoculare malware o backdoor (come avvenuto nei celebri casi SolarWinds o Kaseya), compromettendo silenziosamente e simultaneamente centinaia di clienti a valle.

La logica criminale è lineare: le entità essenziali (come istituti di credito, grandi reti ospedaliere o reti di distribuzione elettrica) investono ingenti capitali per erigere difese perimetrali formidabili. I loro fornitori di software gestionale, i provider di servizi cloud, o persino i manutentori di sistemi HVAC (Riscaldamento, Ventilazione e Condizionamento dell’Aria) operano spesso con standard di sicurezza nettamente inferiori. L’infiltrazione nell’infrastruttura del fornitore diviene così il percorso di minor resistenza per violare l’obiettivo finale.

Per arginare questo fenomeno, la Direttiva obbliga le entità in ambito a eseguire rigorose attività di Vendor Risk Assessment e due diligence prima di procedere all’affidamento di servizi TIC critici. Il rispetto della norma implica che i soggetti essenziali e importanti valutino sistematicamente le pratiche di cibersicurezza dei fornitori, il loro ciclo di sviluppo sicuro del software e la loro capacità di gestire le vulnerabilità. Le linee guida tecniche dell’ENISA sulla gestione dei rischi forniscono indicazioni pragmatiche in tal senso, richiedendo alle organizzazioni di redigere una politica formale sulla sicurezza della supply chain e di tradurla in clausole contrattuali vincolanti. Tali clausole devono includere, tra l’altro, il diritto di eseguire audit (right to audit), obblighi formativi per i dipendenti del fornitore, requisiti sulle pratiche di subappalto e, soprattutto, l’impegno stringente a notificare senza indugio gli incidenti di sicurezza che presentano un rischio per le reti del cliente.

Una delle conseguenze più profonde e complesse di questo impianto normativo è il cosiddetto “effetto domino” (cascading effect) della conformità. Sebbene la Direttiva NIS2 definisca chiaramente quali settori e quali dimensioni aziendali determinano l’ingresso nel perimetro di applicazione (escludendo di fatto molte micro e piccole imprese), l’Articolo 21 obbliga i soggetti normati a imporre i medesimi standard di sicurezza ai propri fornitori. Questo meccanismo di “flusso verso il basso” (flow-down) dei requisiti di cibersicurezza significa che migliaia di piccole imprese fornitrici di servizi IT o infrastrutturali si troveranno contrattualmente obbligate a conformarsi a standard di stampo NIS2, pur non essendovi tenute direttamente per legge.

La gestione di questa pressione negoziale e operativa rappresenta una delle sfide di mercato più imponenti nell’era post-NIS2, specialmente quando si tratta di definire e rispettare i tempi di notifica di un incidente che si propaga dal fornitore al cliente.

Il paradosso della notifica a cascata: la problematica delle “23 ore”

Il punto di frizione più severo tra le esigenze giuridiche della NIS2 e le dinamiche operative della supply chain emerge nell’ipotesi in cui un grave incidente di sicurezza abbia origine nell’infrastruttura di un fornitore di servizi TIC e impatti i sistemi o l’operatività del soggetto essenziale (il cliente). L’applicazione pedissequa dell’obbligo di notifica innesca un potenziale disallineamento temporale che rischia di paralizzare la compliance dell’entità a valle.

Consideriamo il seguente scenario operativo: un fornitore di servizi cloud o un Managed Security Service Provider (MSSP), definito “Azienda A”, subisce un incidente informatico significativo. L’Azienda A, consapevole dei propri obblighi di segnalazione verso le autorità e i propri clienti, avvia le procedure di analisi e risposta, ma, a causa di inefficienze organizzative, complessità tecnica o semplice interpretazione dilatoria degli SLA contrattuali, attende prima di comunicare l’evento alla propria clientela. Al compimento della 23ª ora dall’inizio dell’incidente (pertanto ancora formalmente entro il limite delle 24 ore previsto per la propria Allerta Preliminare), l’Azienda A notifica la violazione all’Azienda B, un soggetto essenziale in ambito NIS2 che fa affidamento sui servizi compromessi.

Il nodo cruciale risiede nell’impatto di questa notifica ritardata sui doveri dell’Azienda B. Qualora i tempi previsti per l’Azienda B venissero calcolati a partire dall’insorgenza assoluta dell’incidente sui sistemi di A, l’Azienda B si troverebbe con una sola ora a disposizione per analizzare l’evento, valutare l’impatto sui propri servizi e inviare l’Allerta Preliminare al CSIRT nazionale, configurando una situazione di assoluta irrealizzabilità pratica.

La risoluzione del paradosso giuridico: il riavvio del cronometro

Sotto il profilo strettamente esegetico e legale, il paradosso della “singola ora” è frutto di un equivoco interpretativo riguardante il fondamento del dies a quo. L’orologio normativo della Direttiva NIS2 non è universale né legato all’istante temporale oggettivo in cui si verifica tecnicamente l’effrazione iniziale da parte dell’attaccante. Al contrario, la norma stabilisce esplicitamente che le scadenze (24 ore, 72 ore, 1 mese) decorrono in modo soggettivo “dal momento in cui l’entità interessata viene a conoscenza (diventa consapevole) dell’incidente significativo”.

L’acquisizione dell’evidenza è un fattore individuale per ciascun soggetto giuridico coinvolto. Nel momento in cui l’Azienda A (il fornitore) notifica l’incidente all’Azienda B al traguardo della 23ª ora, è in quel preciso istante che si realizza l’acquisizione dell’evidenza per l’Azienda B. Dal punto di vista giuridico, il cronometro legale dell’Azienda B non subisce decurtazioni a causa dei ritardi del fornitore: esso si attiva ex novo al momento della ricezione della comunicazione. L’Azienda B beneficerà, pertanto, di 24 ore complete a partire dall’avviso ricevuto (estendendo la tempistica globale dell'incidente a 47 ore rispetto all'attacco originario) per provvedere all’invio della propria Allerta Preliminare al CSIRT.

Questa interpretazione giuridica è l’unica coerente con i principi generali del diritto e della responsabilità amministrativa, proteggendo il soggetto da incolpazioni per ritardi causati esclusivamente da inefficienze di terze parti su cui non ha un controllo operativo in tempo reale.

L’insostenibile impatto operativo e il rischio di conformità indotta

Tuttavia, pur constatando che la spada di Damocle sanzionatoria per l’Allerta Preliminare è giuridicamente scongiurata grazie al riavvio del cronometro, l’analisi operativa dimostra che la lentezza della supply chain nel comunicare un incidente compromette in modo irrimediabile la postura di sicurezza dell’Azienda B e la sua capacità di conformarsi alle fasi successive e più tecniche della Direttiva. Il ritardo di 23 ore, infatti, innesca una serie di conseguenze per il sistema di difesa.

In primo luogo, vi è il collasso della fase di Triage e Analisi dell’Impatto. Quando l’Azienda B riceve la comunicazione a ridosso delle 24 ore, l’infrastruttura del fornitore è già stata compromessa da un tempo considerevole, offrendo all’attaccante un ampio margine per consolidare la persistenza, esfiltrare dati o pivotare (lateral movement) direttamente verso i sistemi connessi dell’Azienda B. L’Azienda B dovrà utilizzare le sue 24 ore di salvaguardia non per una serena compilazione del modulo di Allerta Preliminare, ma per condurre una frenetica e gravosa analisi interna atta a determinare se il disservizio indotto dal fornitore superi la soglia di “grave perturbazione operativa” stabilita dall’ACN, requisito per qualificare l’evento come incidente significativo per la propria entità. Una comunicazione tardiva e, come spesso accade in fase embrionale, vaga da parte del fornitore paralizza questo giudizio, rischiando di spingere il cliente verso la sovra-segnalazione cautelare (intasando inutilmente le autorità) o la sotto-segnalazione colposa.

In secondo luogo, emerge una carenza strutturale di informazioni tecniche per la Notifica delle 72 Ore. Se l’Allerta Preliminare richiede informazioni sommarie, la Incident Notification da inviare entro 72 ore impone una profondità tecnica considerevole. L’Azienda B deve fornire al CSIRT la valutazione della severità, l’elenco degli asset compromessi, l’analisi dell’impatto transfrontaliero e, qualora disponibili, gli Indicatori di Compromissione (IoC) come indirizzi IP malevoli, firme malware o log di accesso anomali. Essendo l’infrastruttura compromessa di proprietà dell’Azienda A, l’Azienda B è completamente “cieca”. Se il fornitore ha dimostrato inefficienza nell’inviare il primo avviso, è inverosimile che sia in grado o disposto a condividere, in tempi compatibili con le successive scadenze del cliente, l’evidenza forense necessaria e l’analisi della causa scatenante (root cause). L’incapacità dell’Azienda B di corredare le notifiche a 72 ore e a 30 giorni con i dati tecnici richiesti esporrà quest’ultima a contestazioni regolatorie da parte dell’ACN per inidoneità delle procedure di gestione degli incidenti.

In terzo luogo, la frammentazione temporale genera un cortocircuito a livello sistemico per le Autorità Nazionali (CSIRT e EU-CyCLONe). La ratio legislativa dell’Allerta Preliminare a 24 ore risiede nella necessità delle autorità statali e comunitarie di ottenere una situational awareness immediata per diramare avvisi collettivi e neutralizzare l’espansione del contagio in altri settori critici. Qualora un incidente rilevante colpisca un fornitore chiave di software ERP, e tale fornitore consumi quasi 24 ore per notificare il problema ai propri 100 clienti (enti ospedalieri, reti idriche, PA), e ciascuno di questi consumi a sua volta ulteriori 24 ore per inoltrare l’Allerta al CSIRT, l’Autorità nazionale riceverà un volume eterogeneo e non sincronizzato di notifiche diluite lungo un arco di tre o quattro giorni. Questo ritardo a cascata annichilisce l’efficacia del meccanismo di risposta coordinata, precludendo a ENISA e alle reti di collegamento la possibilità di emettere contromisure efficaci (intelligence sharing) tempestivamente.

Infine, si ravvisa il grave rischio di interferenze e violazioni incrociate con il GDPR (Art. 33). Oggigiorno, la grande maggioranza degli attacchi informatici complessi (es. Ransomware a doppia estorsione) sfocia nella compromissione di dati personali. In uno scenario in cui l’incidente presso il fornitore comporti un Data Breach, il ritardo nella notifica o la reticenza nel condividere i registri di accesso (log) da parte del fornitore (che opera tipicamente in veste di Responsabile del Trattamento ex Art. 28 GDPR) renderà impossibile per l’Azienda B (Titolare del Trattamento) valutare tempestivamente il rischio per i diritti e le libertà degli interessati, violando con altissima probabilità il termine di 72 ore imposto dall’Art. 33 del GDPR e la conseguente comunicazione agli utenti impattati. L’inefficienza del fornitore si trasforma così in una responsabilità economica moltiplicata per l’azienda cliente, minacciata dai regimi sanzionatori di due diverse autorità di vigilanza.

Soluzioni contrattuali: gli SLA asimmetrici e le clausole “NIS2-compliant”

L’osservazione delle criticità descritte evidenzia come l’approccio difensivo dell’Azienda B non possa basarsi unicamente sulla corretta applicazione dell’orologio normativo, ma debba fondarsi su una profonda reingegnerizzazione della governance dei contratti di fornitura. La problematica dei tempi ridotti e dell’opacità informativa si risolve esclusivamente trasponendo le esigenze della NIS2 in solidi Service Level Agreement (SLA) e in stringenti requisiti contrattuali (clausole “NIS2-Compliant”).

L’approccio contrattuale tradizionale, caratterizzato da formule aleatorie quali la notifica “senza ingiustificato ritardo” o “nel più breve tempo possibile”, si rivela totalmente inidoneo nel contesto del D.Lgs. 138/2024, in quanto non offre parametri oggettivi per imporre l’adempimento e misurare la responsabilità. Le raccomandazioni dell’ENISA sulla sicurezza della catena di approvvigionamento e le determinazioni dell’ACN impongono di trasformare l’incident reporting da dichiarazione di policy a flusso di lavoro strettamente regolamentato, misurabile e verificabile.

La soluzione operativa fondamentale risiede nella riduzione asimmetrica delle tempistiche di notifica. I soggetti essenziali e importanti non devono replicare specularmente nei propri contratti i limiti temporali previsti dalla legge per le proprie comunicazioni verso il CSIRT (24 ore). Per dotarsi del necessario buffer temporale funzionale allo svolgimento del triage tecnico e legale interno, il contratto deve obbligare il fornitore a notificare qualsiasi evento anomalo o potenziale incidente in tempistiche significativamente più brevi: tipicamente tra le 4 e le 8 ore dall’identificazione iniziale di un’anomalia rilevante da parte dei sistemi di monitoraggio o del SOC del fornitore. Ottenendo un avviso qualificato entro 8 ore dall’inizio dell’evento, l’azienda cliente (Azienda B) disporrà delle restanti 16 ore della propria finestra legale iniziale per riunire il comitato di crisi, valutare la classificazione dell'impatto sui propri servizi e interagire proattivamente con le autorità.

Tuttavia, l’imposizione di SLA temporali rigorosi deve essere supportata da un’architettura contrattuale olistica che garantisca la profondità e la qualità delle informazioni, prevenendo condotte omissive.

L’inclusione di queste clausole richiede inevitabilmente una profonda convergenza tra i dipartimenti Legali, Approvvigionamento (Procurement) e Sicurezza IT (Cybersecurity), i quali devono operare sinergicamente per rinegoziare l’intero portafoglio contratti.

Emerge tuttavia una complessa disparità negoziale sul mercato. Se un’entità essenziale detiene un potere contrattuale sufficiente per imporre simili condizioni ai fornitori tecnologici nazionali o di medie dimensioni, la negoziazione diviene complessa e spesso irrealizzabile qualora la controparte sia un fornitore globale hyperscaler (Big Tech) con contratti di adesione standardizzati e monolitici. Tuttavia, la portata della Direttiva NIS2 e la magnitudo delle sanzioni applicabili spingeranno fisiologicamente anche le entità globali, nel momento in cui decidono di operare nel mercato interno europeo, a rivedere e uniformare unilateralmente i propri standard contrattuali e di Service Level alle metriche richieste, al fine di non perdere interi settori dell'economia continentale e non incorrere nelle sanzioni in veste di “soggetti importanti” o fornitori di infrastrutture digitali.

Ripartizione delle responsabilità secondo l’ACN e obblighi non delegabili

La stipula di SLA asimmetrici e clausole stringenti risolve il problema operativo dell’acquisizione delle informazioni tecniche in tempi utili, ma non sposta l’onere della responsabilità legale di notifica in caso di incidente. Il D.Lgs. 138/2024 e le comunicazioni ufficiali dell’Agenzia per la Cybersicurezza Nazionale hanno ribadito con estrema nettezza il principio di inalienabilità del dovere di comunicazione verso lo Stato, precludendo qualsiasi scappatoia derivante da architetture contrattuali.

Molteplici organizzazioni hanno erroneamente ipotizzato di poter delegare ai propri Managed Security Service Provider (MSSP), provider Cloud o SOC esternalizzati non solo la gestione tecnica dell’incidente, ma anche l’onere burocratico della notifica al CSIRT Italia, derubricando la cibersicurezza a un mero servizio in outsourcing. L’ACN ha destrutturato questa percezione introducendo una dicotomia chiara tra la “rilevazione materiale” dell'anomalia (delegabile a terzi) e “l’obbligo giuridico” di notifica (inderogabilmente in capo al titolare del servizio essenziale/importante).

Qualsiasi patto contrattuale che tenti di trasferire o escludere la responsabilità della notifica in favore del fornitore è considerato giuridicamente inefficace nei confronti dell’Autorità. Se il SOC esterno non rileva un’intrusione o ritarda l'analisi, e la notifica giunge al CSIRT oltre i limiti previsti (o non giunge affatto), le sanzioni amministrative pecuniarie colpiranno esclusivamente l’ente appaltante (il soggetto NIS), il quale potrà unicamente tentare una successiva ed incerta rivalsa civilistica contro il fornitore.

Per mitigare l’incertezza, le FAQ dell’ACN hanno esplicitato l’allocazione delle responsabilità notificatorie in diversi scenari architetturali comuni, con particolare riguardo ai modelli di adozione del Cloud Computing :

Questi chiarimenti istituzionali impongono una severa disciplina interna alle organizzazioni. Non è sufficiente inserire gli SLA contrattuali (che, come detto, mitigano la frammentazione temporale delle 23 ore), ma occorre che le organizzazioni costruiscano un framework di incident management interno maturo e testato. Le Linee Guida ACN sulla definizione del processo di gestione degli incidenti richiedono la designazione esplicita di un “Referente CSIRT” e di un suo sostituto, preposti esclusivamente all’interlocuzione con il CSIRT Italia.

L’allineamento alle direttive dell’ENISA raccomanda altresì la strutturazione del team interno secondo i profili definiti dallo European Cybersecurity Skills Framework (ECSF), assicurando che la componente tecnica dell’intervento sia costantemente integrata e controbilanciata da funzioni di conformità normativa (Cyber Legal and Compliance).

Conclusioni e implicazioni sistemiche

La Direttiva NIS2, recepita in Italia dal D.Lgs. 138/2024, non costituisce una mera evoluzione tecnica degli obblighi di cibersicurezza, ma un cambio di paradigma epocale che sposta la gestione del rischio digitale dai server informatici ai tavoli dei Consigli di Amministrazione. L’imposizione di un'architettura di notifica rigorosamente strutturata su tre scaglioni temporali perentori (24 ore per l’allerta preliminare, 72 ore per la notifica dettagliata, un mese per il rapporto conclusivo) mira a fornire agli Stati membri e all'Unione Europea la consapevolezza situazionale in tempo reale necessaria per arginare le crisi sistemiche.

L’analisi condotta evidenzia tuttavia come la concreta attuazione di tale impianto normativo incontri barriere operative importanti laddove si innesti sulla complessità delle moderne catene di approvvigionamento. Lo scenario critico di un fornitore che, a causa di reticenza o inefficienza, ritardi la comunicazione di un incidente fino a ridosso del compimento delle 24 ore previste per la sua notifica, ha permesso di delineare una distinzione fondamentale tra il piano del diritto e la cruda realtà operativa.

Se dal punto di vista giuridico il soggetto a valle non subisce una compressione illegittima dei propri tempi - poiché l’orologio delle sue 24 ore parte esclusivamente dal momento di effettiva presa di coscienza (l’avviso ricevuto a T+23) - sotto il profilo gestionale questo disallineamento lo condanna a una crisi di conformità. Costretta a fronteggiare indagini incomplete e priva degli Indicatori di Compromissione necessari per adempiere in modo inappuntabile all’imminente obbligo delle 72 ore, l’azienda rischia di esporsi a procedimenti sanzionatori e a gravi rischi operativi, non da ultimo la potenziale inosservanza parallela dei termini di notifica previsti dal GDPR.

La risoluzione di questa vulnerabilità sistemica non può, dunque, essere demandata all’interpretazione del legislatore, ma impone un’aggressiva revisione delle pratiche di procurement e della governance dei fornitori. L’unica contromisura strategica efficace consiste nel recidere l’allineamento tra tempistiche normative e scadenze di fornitura, imponendo nei contratti e negli accordi sul livello di servizio (SLA) vincoli di comunicazione asimmetrici (con finestre di notifica ridotte a 4-8 ore dall’evento). A ciò deve obbligatoriamente associarsi l’imposizione di un vincolo legale di cooperazione forense continua, diritti d’ispezione sul campo e l’introduzione di un sistema sanzionatorio privato capace di disincentivare alla radice ogni pratica dilatoria da parte dell’erogatore dei servizi IT.

Le linee guida dell’Agenzia per la Cybersicurezza Nazionale hanno sancito l’inamovibilità della responsabilità in capo al titolare del servizio essenziale. Delegare a terzi le operazioni tecniche è consentito e, sovente, necessario; delegare il rischio sanzionatorio o il governo delle interfacce con le autorità è un illecito.

Le entità che sapranno interpretare la NIS2 non come un costoso esercizio burocratico da superare formalmente, ma come il volano per ristrutturare in radice le procedure di risposta alle emergenze e la qualità delle proprie partnership tecnologiche, non solo eviteranno le sanzioni inibitorie e pecuniarie del D.Lgs. 138/2024, ma assicureranno la resilienza della propria infrastruttura e la salvaguardia del proprio patrimonio informativo, affermandosi come pilastri affidabili nel mutato ecosistema della sicurezza europea.