I gruppi d’impresa, soprattutto se di ridotte dimensioni, tendono a centralizzare la funzione IT presso una singola società per evidenti ragioni di efficienza gestionale ed economica. Tale assetto ha fatto emergere alcuni aspetti problematici nel percorso di adeguamento al D.Lgs. n. 138/2024 (Decreto NIS2). Di seguito si analizza una soluzione strutturale per gestire la conformità in contesti centralizzati.
Indice degli argomenti
Il quadro normativo di riferimento
Nell’ambito del recepimento nazionale della Direttiva NIS2, l’art. 3 (commi 4 e 10) individua i criteri di inclusione per le società facenti parte di un gruppo. In termini pratici, le società del gruppo possono rientrare nel perimetro della norma per due motivi principali:
- Per attività: se rientrano nell’elenco dei settori ad alta criticità o altri settori critici (Allegato I e II).
- Per funzione: in qualità di fornitore di servizi ICT alle altre società del gruppo (indipendentemente dai limiti dimensionali).
È fondamentale precisare che la NIS2 non prevede regole particolari per “i gruppi societari” al di fuori del calcolo dei limiti dimensionali, ciò significa che la conformità e la responsabilità restano in capo alla singola organizzazione. Solo gruppi particolarmente strutturati creano una funzione IT in ciascuna società, ma ciò non rappresenta la normalità.
Uno degli obiettivi della NIS è stato quello di portare la gestione IT a livello di decisione strategica che compete al board; l’anomalia che si crea nei gruppi è che tali decisioni devono essere approvate da tutti i consigli di amministrazione delle società che usufruiscono dei servizi IT. Tale situazione dovrà essere regolamentata internamente al fine di consentire all’organo amministrativo di valutare scelte e conseguenze, visto che ne sono responsabili.
Scenario di analisi: il gruppo “centralizzato”
Il presente articolo vuol porre all’attenzione la situazione tipica dei gruppi italiani dove la funzione IT, essendo considerata “ausiliare” alle altre attività aziendali, viene accentrata sulla capogruppo o su una controllata specifica, con un’infrastruttura logica spesso univoca (stesso dominio, reti non segregate, ecc.).
In questo scenario, le scelte strategiche e tecnologiche sono demandate al Responsabile ICT della società erogante. In alcune realtà, solo i sistemi OT (Operational Technology) restano gestiti localmente dalle singole società, con un affidamento a terzi. Questo è lo scenario su cui è stata posta l’attenzione.
La responsabilità degli organi direttivi
L’analisi di tale situazione deve partire dall’art. 23 del D.Lgs. 138/2024, che stabilisce la responsabilità diretta e personale degli organi direttivi per la mancata approvazione delle misure di gestione dei rischi. La conseguenza è che gli amministratori non possono limitarsi a una delega “in bianco” verso la funzione IT centrale; la stessa norma impone loro di acquisire competenze specifiche tramite una formazione obbligatoria.
In un contesto di gruppo, ciò significa che i board delle singole società devono essere messi in condizione di approvare consapevolmente le politiche di sicurezza. Senza un flusso informativo strutturato, il rischio è quello di una firma “al buio”, che non esonera l’amministratore dal sistema sanzionatorio previsto dalla stessa norma.
Obblighi in materia di misure di gestione dei rischi
Un primo aspetto problematico è rappresentato dalla definizione da parte della funzione IT delle misure di sicurezza previste dall’art. 24 del D.Lgs. 138/2024, in quanto la società che eroga i servizi IT deve farlo facendo riferimento ai servizi offerti a tutte le società del gruppo e alle attività svolte dalle diverse società (quindi non deve far riferimento alla sola società che eroga il servizio). Tenuto conto che le misure devono essere proporzionate ai rischi, è consigliabile “partire” da un modello di risk analysis di gruppo dove vengono prese in considerazione anche le attività svolte da ciascuna società.
Lo strumento dell’accordo infragruppo
Per rendere operative le regole previste dalla normativa, lo strumento principe è l’Accordo Infragruppo (Service Level Agreement). Normalmente tale accordo è già presente nei gruppi, ma è necessario aggiornarlo per tener conto della normativa NIS2.
In primis l’accordo deve essere integrato per assegnare formalmente i compiti alle figure previste dalla Determinazione ACN 37887/2025:
- Il Punto di Contatto (PoC);
- Il sostituto del punto di contatto;
- Il referente CSIRT e i relativi sostituti.
Considerata l’unicità della funzione ICT per l’intero gruppo, l’accordo può prevedere che le persone fisiche preposte a ricoprire tali ruoli siano le medesime per tutte le società del gruppo; la stessa Determinazione ACN prevede che: “qualora il soggetto sia parte di un gruppo di imprese, le funzioni di punto di contatto possono essere svolte da un dipendente di un’altra impresa del gruppo”. Tale scelta è motivata dal fatto che l’organigramma ICT è il medesimo per tutte le società, non essendoci una funzione ICT nelle altre società.
I contenuti operativi dell’accordo infragruppo
L’accordo infragruppo dovrà declinare anche i seguenti aspetti operativi:
- Governance: devono essere indicati i piani e programmi operativi da sottoporre ad approvazione dei singoli board, come ad esempio il piano di trattamento del rischio o il piano di gestione degli incidenti, in generale tutte le informazioni che necessitano al consiglio di amministrazione per prendere le decisioni.
- Scambio di informazioni: deve essere previsto un sistema di reportistica periodica che permetta ai singoli board di monitorare l’efficacia delle misure adottate (es. esiti di vulnerability assessment o penetration test).
- Procedura di escalation e notifiche: devono essere stabiliti i tempi e i modi con cui la società erogante avvisa le altre società in caso di incidente, rilevante o meno. Normalmente in tali situazioni un incidente ha riflessi su tutte le società del gruppo con conseguente notifica a nome delle diverse società. Si precisa che la procedura di gestione degli incidenti deve essere approvata dai singoli consigli di amministrazione.
- Adozione dei framework di sicurezza: la società che svolge l’attività ICT deve garantire il rispetto degli standard (es. ISO/IEC 27001 o NIST) stabiliti a livello di gruppo.
- Sicurezza della supply chain: è necessario definire i criteri di monitoraggio dei fornitori critici che impattano sull’intero perimetro.
- Gestione della piattaforma ACN e adempimenti comunicativi: vengono definite le modalità di gestione della piattaforma informatica ACN.
- Possibilità di ispezioni e audit: considerata la responsabilità dei singoli consigli di amministrazione, è opportuno inserire tale possibilità.
Comunicazione tramite la piattaforma ACN nei gruppi
Le informazioni oggetto di comunicazione all’ACN in alcune situazioni possono anche coincidere fra le diverse società del gruppo, come in caso di utilizzo in comune del nome del dominio e dell’indirizzamento IP pubblico.
Con riferimento alla comunicazione dei fornitori critici, da effettuarsi entro il 31 maggio, possono valere le seguenti considerazioni:
- La società del gruppo che fornisce i servizi ICT dovrà indicare tutti i fornitori individuati come critici;
- La società che riceve i servizi ICT dovrà indicare i dati identificativi della società del gruppo fornitrice del servizio. Si ritiene che il codice CPV di riferimento possa essere il 72510000-3 – Servizi di gestione connessi all’informatica, integrato da altri codici di attività per definirne meglio il perimetro.
Tenuto conto che sono fornitori critici quelli di cui all’art. 3, c. 9, lett. f) del decreto, che li definisce come “quale elemento sistemico della catena degli approvvigionamenti”, ed in mancanza di chiarimenti, si ritiene che debbano essere indicati anche i fornitori comunicati dalla stessa società del gruppo che eroga i servizi IT (in pratica questi rappresentano dei sub-fornitori delle altre società), critici anche per le società riceventi il servizio.
Accordi di condivisione delle informazioni ai sensi dell’art. 17
Segnalo che l’accordo infragruppo stipulato fra le società va notificato all’ACN tramite la relativa piattaforma, in quanto l’accordo regolamenta anche lo scambio di informazioni attinenti la sicurezza informatica e la gestione degli incidenti informatici.
Conclusioni: perimetro IT allargato e autonomia documentale
Nei gruppi che accentrano il servizio IT è necessario, per gli aspetti tecnici, ragionare in termini di perimetro IT allargato, mentre per gli aspetti legali, ciascuna società è tenuta a creare un proprio sistema documentale.
