Le nuove FAQ pubblicate nei giorni scorsi da ACN sulla direttiva NIS2 chiariscono chi è tenuto a notificare un incidente significativo al CSIRT Italia quando entrano in gioco relazioni cliente–fornitore tra soggetti NIS e quando l’infrastruttura coinvolta è cloud. Il principio che emerge è che la responsabilità non migra automaticamente con il contratto, ma si sposta solo quando la norma lo prevede in modo esplicito.

Uno dei passaggi chiave, spesso sottovalutato nella pratica, è la distinzione tra chi rileva l’incidente e chi è obbligato a notificarlo. Nella realtà operativa, i due ruoli raramente coincidono. Un SOC esterno può individuare un’anomalia, un MSSP può confermare una compromissione, un outsourcer può risalire all’origine di un disservizio. Questo però non significa che l’obbligo di notifica si trasferisca automaticamente a chi ha visto per primo il problema. ACN ribadisce infatti che il supporto operativo, anche totale, non equivale alla presa in carico della responsabilità regolatoria.

Nel primo scenario affrontato dalle FAQ, l’incidente avviene sui sistemi del cliente, che è soggetto NIS, mentre uno o più fornitori erogano servizi, anche gestiti. Qui la risposta di ACN è netta: la notifica spetta al cliente. Il fornitore deve essere coinvolto nella gestione tecnica, ma non diventa titolare dell’obbligo. Il punto più delicato, però, è che il cliente deve essersi assicurato, a monte, che il fornitore segnali tempestivamente gli eventi di sicurezza rilevanti.

Se questo non accade, il cliente rischia di notificare in ritardo o in modo incompleto, senza poter invocare l’alibi dell’esternalizzazione. In altre parole, i servizi gestiti non proteggono dalla responsabilità, ma la rendono semplicemente più dipendente dalla qualità della governance contrattuale.

acn nis2

Crediti: Shutterstock

Il secondo scenario è quello storicamente più insidioso. L’incidente nasce sui sistemi del fornitore, ma produce un impatto diretto sul cliente, perché quei servizi sono parte integrante delle sue attività o della sua continuità operativa. In questo caso, ACN chiarisce che il fornitore soggetto NIS deve notificare l’incidente, ma aggiunge che anche il cliente deve notificare se per lui l’evento assume la forma di un incidente significativo.

Ciò obbliga cliente e fornitore ad allinearsi rapidamente su una cronologia condivisa, su una valutazione coerente dell’impatto e su un set minimo di informazioni verificabili, dal momento che la compliance, in questo contesto, coincide con la qualità delle decisioni sotto pressione.

Sul cloud, le FAQ fanno finalmente chiarezza, smettendo di trattarlo come un concetto monolitico. La regola generale prevede l’obbligo di notifica sia per il cliente sia per il fornitore, se entrambi sono soggetti NIS. Tuttavia, nel caso di servizi IaaS o di hosting dell’infrastruttura del cliente, ACN precisa che l’obbligo ricade esclusivamente sul cliente. Una distinzione che impone alle organizzazioni di sapere con precisione cosa stanno acquistando e come il servizio è strutturato. Se tutto viene genericamente etichettato come “cloud”, al momento dell’incidente mancheranno le basi stesse per decidere correttamente.

Un chiarimento analogo riguarda i gruppi societari. La registrazione ai fini NIS2 non è “di gruppo”, ma riguarda le singole persone giuridiche che rientrano nel perimetro. Le policy possono essere centralizzate, così come i controlli e il monitoraggio, ma l’adempimento e la responsabilità restano individuali. Tentare scorciatoie organizzative significa esporsi inutilmente al primo controllo serio.

Nel complesso, queste FAQ aggiornate segnano il passaggio definitivo dalla teoria alla pratica. La direttiva NIS2 smette cioè di essere un esercizio interpretativo e diventa una disciplina operativa che non lascia spazio a deleghe implicite. Le organizzazioni che reggeranno meglio saranno quelle che, nel mezzo di un incidente, sapranno chi decide, chi comunica e chi notifica, senza doverlo scoprire nel momento peggiore.