C’è un equivoco che vedo ripetersi con una costanza quasi commovente: “Abbiamo un fornitore che gestisce la sicurezza/l’infrastruttura/il cloud, quindi in caso di incidente ci penserà lui”.
È una convinzione comoda. Peccato che, quando arriva un incidente significativo, quella comodità diventi un rischio: legale, organizzativo e reputazionale.
Sulla NIS2, le nuove FAQ di ACN servono proprio a questo: eliminare l’ambiguità su chi deve notificare al CSIRT Italia quando l’incidente coinvolge una relazione cliente–fornitore tra soggetti NIS e quando entrano in gioco servizi cloud.
E lo fanno con una logica molto semplice: la responsabilità non si sposta perché hai firmato un contratto o perché hai esternalizzato un pezzo di operatività. Si sposta (solo) se la norma lo prevede, chiarendo così il perimetro con più nettezza.
Indice degli argomenti
Il punto vero: “chi rileva” non coincide con “chi notifica”
Nella vita reale, chi vede per primo l’incidente spesso non è chi poi è obbligato a notificarlo.
Un SOC esterno può intercettare un comportamento anomalo, un MSSP può confermare una compromissione, un outsourcer può scoprire l’origine di un disservizio.
Ma sulla Nis2 ACN, con le FAQ, ribadisce un concetto che va digerito una volta per tutte: il fatto che un fornitore ti supporti (o addirittura gestisca) non significa che si prenda in carico l’obbligo di notifica al posto tuo.
Questo non è un dettaglio da giuristi: è la differenza tra un processo che regge sotto stress e un processo che collassa nel momento peggiore, quando devi decidere in poche ore cosa dichiarare, con quali tempi e con quali informazioni minime.
Scenario 1 (FAQ ISB.F.1): incidente sui sistemi del cliente, con fornitore che eroga servizi
ACN parte dallo scenario più comune: il cliente è un soggetto NIS e ha uno o più fornitori che erogano servizi, anche gestiti (pensiamo a un SOC, a servizi IT gestiti, o persino a servizi “non IT” ma con componenti digitali rilevanti). L’incidente però accade sui sistemi informativi e di rete del cliente.
Qui la risposta è asciutta: la notifica al CSIRT Italia è in capo al cliente soggetto NIS. Il fornitore può e deve essere coinvolto nella gestione dell’incidente, ma non è lui il titolare dell’obbligo.
Il passaggio interessante, però, è quello che spesso viene ignorato finché non si finisce in emergenza: ACN richiama la necessità, nella definizione dei requisiti di sicurezza della fornitura, che il cliente si assicuri che il fornitore segnali tempestivamente gli eventi di sicurezza che impattano i servizi del cliente.
Tradotto in lingua “da management”: se il tuo fornitore vede e non ti avvisa in tempo, tu rischi di arrivare tardi o male alla notifica. E quel ritardo non lo giustifichi dicendo “eh, ma era in mano al provider”. Perché l’obbligo, secondo ACN, restava tuo.
Questa è una di quelle frasi che sembrano innocue, finché non le leggi con gli occhi di chi deve governare fornitori e contratti: i servizi gestiti non sono una coperta che ti protegge dalla responsabilità, sono un acceleratore… a patto che siano governati con clausole e processi coerenti.
Scenario 2 (FAQ ISB.F.2): incidente sui sistemi del fornitore, con impatto sul cliente
Qui si entra nella zona dove, storicamente, le aziende inciampano: l’incidente non accade dal cliente, accade dal lato fornitore, ma l’impatto “ricade” sul cliente perché quei servizi alimentano processi, attività o continuità operativa.
ACN chiarisce una cosa che farà discutere, ma che era necessaria: il fornitore soggetto NIS deve notificare l’incidente al CSIRT Italia, e fin qui, molti annuiscono.
Poi arriva la seconda parte, quella che cambia davvero la dinamica: anche il cliente è tenuto a notificare se l’incidente, per il cliente, si configura come incidente significativo in relazione ai servizi e alle attività del cliente stesso.
In pratica: non è detto che basti “la notifica del fornitore”. Potreste dover notificare entrambi.
Il rischio qui non è la duplicazione in sé, ma il caos che la duplicazione può generare se non è governata.
Due notifiche scollegate, con tempi diversi e contenuti non allineati, significano una cosa molto concreta: racconti differenti dello stesso evento.
E quando un’autorità riceve racconti differenti, non li interpreta come “collaborazione”, spesso li interpreta come “disordine”, oppure come “mancanza di controllo”, oppure come “qualcuno non ha capito cosa sta facendo”. Tutte etichette che non vuoi addosso nel mezzo di un incidente.
Questo scenario obbliga a una maturità che molte organizzazioni non hanno ancora: cliente e fornitore devono essere in grado di coordinarsi rapidamente su una timeline condivisa, una descrizione coerente dell’impatto e un set minimo di evidenze.
Non perché “fa bello”, ma perché la compliance, qui, è anche qualità del processo decisionale.
Scenario 3 (FAQ ISB.F.3): cloud tra soggetti NIS, e l’eccezione che conta
Sul cloud ACN fa una cosa utile: smette di trattare “cloud” come parola magica e introduce un discrimine che obbliga tutti a essere precisi.
La regola generale è: l’obbligo di notifica al CSIRT Italia è in capo sia al cliente soggetto NIS sia al fornitore soggetto NIS. Quindi, di base, ancora una volta: non è che “se è cloud notificherà il cloud provider”.
Ma ACN inserisce un’eccezione netta, e qui bisogna stare molto attenti: se il servizio cloud è di tipo IaaS o di hosting dell’infrastruttura del cliente, allora l’obbligo di notifica è solo del cliente.
È una distinzione che, detta così, sembra tecnica. In realtà è politica e organizzativa: ACN sta dicendo che prima di discutere di obblighi e responsabilità devi sapere con esattezza che cosa stai comprando e come è costruito il servizio.
Perché se nel contratto e nella governance interna è tutto ridotto a “cloud”, senza distinguere modelli e confini, quando arriva l’incidente non saprai nemmeno da che parte cominciare a ragionare in modo corretto.
E anche qui torna il tema “fornitore che segnala tempestivamente”: l’obbligo legale può essere tuo, ma senza un fornitore che ti alimenta informazioni in modo strutturato e rapido, tu stai giocando a scacchi bendato.
Registrazione nei gruppi (FAQ 3.15): la scorciatoia “di gruppo” non esiste
ACN ribadisce poi un concetto che, nei gruppi societari, viene spesso trattato come un fastidio: gli adempimenti NIS2 sono relativi alle singole persone giuridiche che rientrano nell’ambito di applicazione.
Quindi, in sostanza, la registrazione va fatta da ciascuna legal entity interessata, anche se parte dello stesso gruppo.
Questo non significa che la governance debba essere frammentata. Anzi: ha senso centralizzare policy, processi, controlli e monitoraggio. Ma l’adempimento formale e la responsabilità restano ancorati alla singola entità giuridica.
È una di quelle cose che, se provi a “semplificare” troppo, ti si ritorcono contro al primo giro serio.
La NIS2 entra davvero nella fase operativa e toglie alibi
Queste FAQ non aggiungono teoria: tolgono alibi. Dicono chiaramente che:
- se l’incidente è sui sistemi del cliente, notifica il cliente;
- se l’incidente è sui sistemi del fornitore ma impatta il cliente, potrebbero dover notificare entrambi;
- sul cloud, in generale notificano entrambi, ma in IaaS/hosting dell’infrastruttura del cliente resta solo il cliente;
- nei gruppi, la registrazione non è “di gruppo”: è per legal entity.
La conseguenza pratica, per board e direzioni, è brutale ma salutare: se la tua catena cliente–fornitore non è governata con chiarezza (requisiti, tempi di segnalazione, flussi informativi, responsabilità interne), l’incidente non ti colpisce una volta sola. Ti colpisce due volte: prima tecnicamente, poi sulla capacità di dimostrare controllo.
E nel 2025, con la NIS2 che entra davvero nella fase “operativa”, l’azienda che vince non è quella che parla meglio di cyber security.
È quella che, quando succede qualcosa, sa chi decide, cosa comunica, a chi e con quali informazioni, senza chiamare tre persone per capire chi “deve fare la notifica”.
Perché a quel punto la partita l’hai già iniziata male.
