NIS2 e oneri documentali e procedimentali

L'avvento della NIS2 ha introdotto una serie di nuovi oneri documentali e procedimentali in materia di cyber sicurezza.

1. Introduzione: la cybersicurezza come processo formale

L’avvento della Direttiva (UE) 2022/2555, comunemente nota come NIS2, e il suo recepimento nell’ordinamento italiano tramite il Decreto Legislativo 4 settembre 2024, n. 138, segnano un punto di svolta storico nella regolamentazione della sicurezza delle informazioni e delle reti. Se finora la sicurezza informatica era percepita prevalentemente come una disciplina tecnica, relegata ai dipartimenti IT e valutata sulla base della sua capacità di respingere attacchi, il nuovo quadro normativo eleva la cybersecurity a funzione critica di governance aziendale, permeata da obblighi formali, procedurali e documentali piuttosto stringenti.

Il presente articolo si pone l’obiettivo di realizzare un parallelismo tra il Regolamento (UE) 2016/679 (GDPR) e la nuova disciplina NIS2, specificamente in relazione alla sussistenza di un onere sanzionabile di “tenuta di procedure scritte”. Nel regime GDPR, è ormai consolidato il principio di accountability (responsabilizzazione), secondo cui il Titolare del trattamento non deve solo proteggere i dati, ma deve essere in grado di comprovare le misure adottate mediante documentazione probatoria (registri, nomine, valutazioni d'impatto). La mancanza di tale documentazione costituisce, di per sé, una violazione sanzionabile, indipendentemente dal verificarsi di un data breach.

L’analisi del testo del D.Lgs. 138/2024, integrata dalle recenti determinazioni dell’Agenzia per la Cybersicurezza Nazionale (ACN), conferma inequivocabilmente che un analogo onere sussiste anche nel perimetro della NIS2. Anzi, per certi aspetti, l’onere procedurale NIS2 appare ancora più pervasivo, in quanto non si limita a richiedere la mappatura di asset (come i dati nel GDPR), ma impone la codificazione dei processi operativi critici. La sicurezza informatica cessa di essere un risultato (l’assenza di incidenti) per divenire un processo documentato (la gestione del rischio).

Procederemo, quindi, a disaggregare le norme primarie e secondarie per identificare le disposizioni che impongono la formalizzazione scritta delle attività, così dimostrando come l’assenza di policy, procedure e registri esponga i Soggetti Essenziali e Importanti a rischi legali e sanzionatori paragonabili a quelli derivanti da un incidente tecnico.

1.1 Dalla NIS1 alla NIS2: la burocratizzazione della difesa

La direttiva NIS1 (recepita in Italia con il D.Lgs. 65/2018) aveva introdotto i primi obblighi per gli Operatori di Servizi Essenziali (OSE), ma lasciava ampi margini di discrezionalità e si concentrava molto sulla notifica degli incidenti. La NIS2 cambia radicalmente approccio, introducendo il principio dell’all-hazards approach (approccio multirischio), che richiede di considerare non solo gli attacchi informatici malevoli, ma anche errori umani, guasti sistemici e disastri naturali.

Per gestire una tale complessità, il legislatore europeo ha compreso che le misure tecniche (firewall, antivirus) non sono sufficienti se non sono governate da processi decisionali chiari. Di qui la necessità di imporre per legge l’adozione di “politiche”. L'uso del termine “politica” nel testo normativo non è casuale: nel linguaggio giuridico e degli standard internazionali (ISO/IEC), una politica è un documento formale, approvato dal vertice, che stabilisce intenti, direzioni e regole. Non può esistere una “politica orale”. Pertanto, ogni volta che il D.Lgs. 138/2024 menziona l’adozione di politiche, sta implicitamente ma necessariamente imponendo la creazione, l’approvazione e la conservazione di un documento scritto.

1.2 La gerarchia delle fonti e la forza cogente delle Determine ACN

Per comprendere la natura vincolante degli obblighi procedurali, è essenziale chiarire il rapporto tra le fonti. Il D.Lgs. 138/2024 funge da norma primaria, stabilendo i principi generali e le cornici sanzionatorie. Tuttavia, il legislatore ha delegato all’Agenzia per la Cybersicurezza Nazionale (ACN) il compito di definire il “come” attraverso atti amministrativi vincolanti (Determinazioni).

Le Determinazioni ACN, come la n. 379907/2025 relativa agli obblighi di base, non sono semplici linee guida di soft law o suggerimenti di best practice. Esse integrano il precetto penale/amministrativo in bianco contenuto nel decreto. In altre parole, quando l’articolo 24 del decreto impone misure “adeguate”, il parametro dell’adeguatezza è definito dalle specifiche tecniche dell’ACN. Se l’ACN stabilisce che una misura di sicurezza deve essere “documentata”, la mancanza del documento equivale alla mancata adozione della misura tout court, attivando il meccanismo sanzionatorio dell’articolo 38 del decreto.

2. Articolo 24: il cuore dell’obbligo procedurale

L’articolo 24 del D.Lgs. 138/2024, intitolato “Obblighi in materia di misure di gestione dei rischi per la sicurezza informatica”, rappresenta la chiave di volta dell’intero impianto normativo per quanto riguarda gli obblighi proattivi (diversi, quindi, dagli obblighi reattivi di notifica incidente ex art. 25).

2.1 La tassonomia delle misure

Il comma 2 dell’articolo 24 elenca una serie di ambiti in cui i soggetti devono adottare misure tecniche, operative e organizzative. L’aggettivo “organizzative” è il primo indicatore della necessità di procedure: l’organizzazione si fa con regole, ruoli e processi, che in enti complessi (come i Soggetti Essenziali e Importanti) devono necessariamente essere formalizzati per essere efficaci e verificabili.

Analizziamo le singole lettere del comma 2 alla luce dell’onere documentale.

Lettera a) “Politiche di analisi dei rischi e di sicurezza dei sistemi informativi e di rete”

Questa disposizione è la fondazione su cui poggia tutto il resto. L’obbligo non è semplicemente di analizzare i rischi, ma di avere una politica di analisi. Significa che l'azienda deve redigere un documento (Metodologia di Risk Assessment) che stabilisca:

• i criteri di accettazione del rischio (Risk Appetite);
• la scala di valutazione (es. Matrice Probabilità/Impatto);
• la frequenza delle analisi;
• i responsabili dell’approvazione.

Senza questo documento scritto, l’analisi dei rischi sarebbe un esercizio arbitrario e non ripetibile. Inoltre, il risultato dell’applicazione di questa politica è un altro documento obbligatorio: il Documento di Valutazione dei Rischi (DVR Cyber) o Risk Assessment Report. In sede di ispezione, l’ACN chiederà di vedere l’ultima versione approvata di questo documento. La sua assenza è una violazione diretta della lettera a).

Lettera b) “Gestione degli incidenti”

La gestione degli incidenti (Incident Handling) non è l’atto di rispondere all’incidente (che è la Response), ma l’intero processo di gestione. L’ACN ha emanato linee guida specifiche su questo punto, chiarendo che i soggetti devono dotarsi di una procedura che definisca:

• chi rileva l’evento;
• come viene classificato (incidente vs evento);
• chi decide di attivare il team di crisi;
• come si documentano le azioni intraprese.

La procedura di Incident Management deve essere scritta e nota al personale prima che l’incidente avvenga. Un’azienda che gestisce brillantemente un attacco ransomware grazie all’intuito di un sistemista, ma senza aver traccia di una procedura predefinita, è passibile di sanzione per violazione dell’art. 24 co. 2 lett. b), poiché la norma richiede un processo strutturato.

Lettera c) “Continuità operativa e gestione delle crisi”

Qui l’obbligo documentale è duplice e riguarda il Piano di Continuità Operativa (Business Continuity Plan - BCP) e il Piano di Ripristino (Disaster Recovery Plan - DRP).

Questi non sono concetti astratti, ma manuali operativi. Il D.Lgs. 138/2024 richiede esplicitamente la “gestione di backup e il ripristino”. Per dimostrare la conformità, l’ente deve esibire:

1. le policy di backup (frequenza, retention, cifratura);
2. i registri dei test di ripristino. La norma richiede misure “adeguate”, e nella prassi (ISO 22301) un piano non testato non è adeguato. Pertanto, il verbale del test di ripristino diventa un documento obbligatorio per provare l’adempimento.

Lettera d) “Sicurezza della catena di approvvigionamento”

La Supply Chain Security è una delle grandi novità della NIS2. L’obbligo è di gestire la sicurezza nei rapporti con i fornitori diretti. Questo si traduce in un onere documentale importante:

• procedure di qualifica: documenti che descrivono come vengono valutati i fornitori sotto il profilo cyber prima della contrattualizzazione;
• contratti: integrazione dei contratti con clausole di sicurezza (SLA, diritto di audit, obbligo di notifica breach);
• audit: report di controllo sui fornitori.
• L’assenza di clausole contrattuali scritte o di procedure di verifica dei fornitori costituisce una violazione autonoma. Non basta che il fornitore sia sicuro, deve esserci evidenza scritta che il soggetto NIS2 ha verificato tale sicurezza.

Lettera e) “Sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete”

Questa lettera impone la formalizzazione del ciclo di vita del software (SDLC). Richiede procedure scritte per:

• lo sviluppo sicuro (Secure Coding Guidelines);
• la gestione delle vulnerabilità (Vulnerability Management Policy);
• la gestione delle patch.

È impensabile dimostrare la conformità a questa lettera senza policy che stabiliscano, ad esempio, “le patch critiche devono essere applicate entro 72 ore”.

Lettera f) “Politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi per la sicurezza informatica”

Questa disposizione introduce l’obbligo di audit interno e verifica. L’uso della parola “procedure” è esplicito. L’ente deve avere un piano di audit e procedure per testare la sicurezza (es. Penetration Test periodici). I report di questi test sono i documenti probatori richiesti.

Lettera g) “Pratiche di igiene di base e di formazione in materia di sicurezza informatica”

L’igiene informatica (Cyber Hygiene) riguarda le pratiche quotidiane di base. Questo richiede policy scritte su:

• gestione delle password (lunghezza, complessità, rotazione);
• gestione degli aggiornamenti software;
• politiche di Clean Desk e Clear Screen.
• Inoltre, la formazione deve essere documentata. La norma richiede formazione obbligatoria per gli organi di amministrazione e per i dipendenti. L’azienda deve tenere un “Registro della Formazione” che elenchi chi è stato formato, su quali argomenti e quando. La mancata esibizione di questo registro espone a sanzioni, anche se il personale è soggettivamente competente.

2.2 La differenza tra “fare” e “documentare di fare”

L’analisi dell’articolo 24 dimostra che la NIS2 sposta l’asse della conformità dal piano fattuale a quello probatorio. In un contenzioso o in un procedimento sanzionatorio ACN, vale il principio quod non est in actis non est in mundo. Se una misura di sicurezza non è descritta in una procedura approvata e non è tracciata in un registro operativo, per l’autorità di vigilanza quella misura non esiste, o quantomeno non è “adeguata” ai sensi della normativa, che richiede sistematicità e governance.

3. Le specifiche tecniche ACN: la prova della “procedura obbligatoria”

L’Agenzia per la Cybersicurezza Nazionale ha emanato atti che dettagliano gli obblighi generici del decreto. In particolare, la Determinazione n. 379907/2025 e le Linee Guida correlate costituiscono il “parametro tecnico” della legalità.

3.1 Analisi della Determinazione sugli “Obblighi di Base”

La Determinazione 379907/2025 stabilisce le misure minime che i soggetti devono implementare. Questo atto amministrativo ha forza cogente per i destinatari.

Analizzando il contenuto tecnico (spesso allineato al Framework Nazionale per la Cybersecurity e allo standard NIST), emerge che ogni controllo di sicurezza richiesto presuppone una componente documentale.

Ad esempio, per il controllo degli accessi, la determinazione non chiede solo che ci siano password, ma che ci sia una “gestione formale del ciclo di vita delle utenze” (creazione, modifica, revoca). Questo implica necessariamente una procedura scritta di Onboarding/Offboarding delle risorse umane (cfr. Art. 24 lett. i). Senza un modulo (anche digitale) di richiesta accesso e un log di revoca, la misura è considerata non conforme.

3.2 Le Linee Guida sulla Gestione degli Incidenti

Le “Linee guida NIS – Specifiche di base – Definizione del processo di gestione degli incidenti di sicurezza informatica” affermano testualmente che l’obiettivo è supportare i soggetti NIS... nella definizione del processo. L’ACN fornisce modelli di processo che includono fasi di classificazione, triaging e analisi.

Un passaggio chiave delle linee guida recita: “A tal fine, sono predisposte e rese pubbliche politiche e procedure”. L’uso dell'indicativo presente (“sono predisposte”) in un testo normativo/regolamentare ha valore imperativo. Non dice “sarebbe opportuno predisporre”, ma dà per assunto che la conformità passi attraverso la predisposizione di tali documenti.

Inoltre, le linee guida specificano che la documentazione deve essere disponibile per le attività di vigilanza. Se l’autorità può chiedere il documento, allora l’ente ha l’obbligo giuridico di averlo creato.

3.3 Il Portale delle Notifiche ACN

L’interazione con il CSIRT Italia avviene tramite una piattaforma digitale. La struttura stessa dei form di notifica (Notifica Iniziale, Intermedia, Finale) impone una raccolta dati strutturata.

Per poter compilare una notifica entro 24 ore (Early Warning) o 72 ore (Notification), un’organizzazione deve avere procedure interne che garantiscano il flusso delle informazioni dai tecnici al “Punto di Contatto NIS”. Se non c’è una procedura scritta che obbliga il sistemista a segnalare l’anomalia al CISO entro X minuti, l'organizzazione fallirà sistematicamente il rispetto dei termini di legge. L’ACN, analizzando i ritardi nelle notifiche, potrà risalire alla causa radice: l’assenza di procedure interne di escalation, sanzionando quindi la carenza organizzativa (Art. 24) oltre al ritardo in sé (Art. 25).

4. Confronto NIS2 vs GDPR: analogie e differenze nell’onere probatorio

L’analogia è non solo pertinente, ma strutturale, dato che la NIS2 è stata scritta con l’intento di allineare la cybersecurity al modello di compliance della privacy.

4.1 Principio di Accountability (Responsabilizzazione)

• GDPR: l’art. 5(2) e l’art. 24 impongono al Titolare di essere in grado di dimostrare la conformità. Lo strumento principe è il Registro delle Attività di Trattamento (Art. 30).
• NIS2: sebbene non usi il termine “Registro dei Trattamenti”, l’art. 24 impone “Politiche di gestione dei rischi”. La funzione è identica: creare un layer documentale che provi la diligenza dell'ente. Nella NIS2, l’equivalente del Registro dei Trattamenti è l’insieme composto dall’Inventario degli Asset (obbligatorio per l'analisi dei rischi) e dal Registro degli Incidenti (obbligatorio per tracciare anche i “quasi-incidenti” o near misses).

4.2 L’approccio al rischio

• GDPR: la valutazione d’impatto (DPIA, Art. 35) è obbligatoria per rischi elevati. Deve essere documentata.
• NIS2: l’analisi dei rischi (Art. 24 lett. a) è sempre obbligatoria per tutti i sistemi informatici e di rete dei soggetti rientranti nel perimetro. L’onere NIS2 è quindi più esteso, coprendo l’intera infrastruttura ICT e non solo i dati personali. Anche qui, l’analisi deve essere documentata per provare che le misure adottate sono “proporzionate” al rischio rilevato.

4.3 Le sanzioni per inadempimenti formali

• GDPR: prevede sanzioni amministrative fino a 10M€ o 2% del fatturato per violazioni “formali” (es. mancata tenuta del registro, mancata nomina DPO) anche in assenza di danno ai diritti degli interessati.
• NIS2: l’art. 38 del D.Lgs. 138/2024 12 prevede sanzioni per la violazione dell’Art. 24. Poiché l’Art. 24 richiede l’adozione di “politiche” (documenti), la mancata adozione di tali politiche è una violazione sostanziale della norma.
  • Sanzione Soggetti Essenziali: Fino a 10M€ o 2% del fatturato.
  • Sanzione Soggetti Importanti: Fino a 7M€ o 1,4% del fatturato.
  • La struttura sanzionatoria è identica: si punisce la mancata governance. Se l’ACN ispeziona un’azienda e non trova le procedure di Incident Response, irroga la sanzione anche se l’azienda non ha mai subito un attacco. Il bene giuridico tutelato è la resilienza preventiva, che si fonda sull'organizzazione procedurale.

Tabella comparativa: obblighi documentali GDPR vs NIS2

5. Governance e responsabilità personale: il ruolo cruciale della documentazione

Un aspetto distintivo della NIS2 rispetto al GDPR è l’enfasi sulla responsabilità diretta delle persone fisiche che compongono gli organi di amministrazione. L’articolo 23 del D.Lgs. 138/2024 è chiaro: gli organi di amministrazione devono approvare le misure e sovraintendere alla loro applicazione.

5.1 La procedura scritta come atto di esonero da responsabilità

Come può un Consiglio di Amministrazione (CdA) dimostrare di aver “approvato” le misure di gestione del rischio? L’approvazione richiede necessariamente un atto formale: una delibera del CdA che approva un documento allegato (la “Policy di Sicurezza delle Informazioni” o il “Piano Strategico di Cybersecurity”).

In questo contesto, la procedura scritta diventa lo strumento di tutela legale per il management.

• Se c'è la procedura approvata: in caso di incidente grave, il manager può dire: “Ho adempiuto al mio dovere (Art. 23), ho approvato una procedura conforme allo stato dell’arte e ho stanziato il budget per attuarla (Art. 24). L’incidente è dovuto a causa di forza maggiore o errore di esecuzione, non a mia negligenza di supervisione”.
• Se NON c'è la procedura: il manager è indifendibile. L’ACN, applicando l’art. 38, può non solo sanzionare l’azienda, ma per i soggetti essenziali può interdire temporaneamente il manager dall’esercizio delle funzioni direttive (incapacità temporanea). Questa sanzione personale è legata alla violazione dei doveri di governance, la cui prova regina è l’assenza di atti formali (procedure) approvati.

5.2 L’obbligo di formazione documentata

Gli organi di amministrazione hanno l’obbligo di seguire una formazione specifica (Art. 23 co. 2). Anche qui, l’onere è procedurale: l’azienda deve avere una procedura per identificare i bisogni formativi del board e registrare l’avvenuta formazione. Senza attestati o registri, l’obbligo si considera non assolto, esponendo l’azienda a sanzioni e i manager a responsabilità.

6. Il sistema di vigilanza ACN: come vengono rilevate le carenze documentali

Il Capo V del D.Lgs. 138/2024 disciplina i poteri di vigilanza. È qui che l’obbligo astratto diventa verifica concreta.

6.1 Audit documentali e ispezioni

L’ACN ha il potere di sottoporre i soggetti a:

1. Audit di sicurezza: verifiche tecniche e organizzative.
2. Richieste di informazioni: l’art. 32 (Soggetti Essenziali) e 33 (Soggetti Importanti) conferiscono all’ACN il potere di richiedere accesso a “documenti”.L’ispettore ACN inizierà richiedendo l’organigramma di sicurezza, le policy approvate, i report di risk assessment e i registri degli incidenti. La mancata esibizione di questi documenti costituisce “mancata collaborazione” e, nel merito, prova la violazione dell’Art. 24.
3. La norma distingue tra controlli ex ante (possibili per i soggetti essenziali) ed ex post (per i soggetti importanti, attivati solo dopo un indizio di violazione o incidente). Tuttavia, quando il controllo scatta, l’oggetto della verifica è lo stesso.

6.2 Gli Ordini di esecuzione

L’ACN può emanare ordini vincolanti per imporre rimedi. Tipicamente, se un’azienda ha subito un incidente a causa di una gestione patch carente, l’ACN ordinerà di adottare e rendere operativa una procedura di Patch Management. Questo ordine conferma retroattivamente che l’assenza di tale procedura era una violazione. Inoltre, l’ACN può ordinare di informare i clienti della violazione, causando un danno reputazionale enorme. Avere procedure scritte e certificate (magari ISO 27001) è l’argomento migliore per evitare la gogna mediatica.

7. Conclusioni

L’analisi normativa condotta sul D.Lgs. 138/2024 e sulle Determinazioni dell’ACN conferma che sussiste nella NIS2 un onere di tenuta di procedure scritte per la gestione delle attività di cibersicurezza, analogo e per certi versi superiore a quello previsto dal GDPR.

Tale onere non è una mera formalità burocratica, ma la sostanza stessa dell’adempimento normativo. La legge non punisce solo l’insicurezza di fatto (l’incidente), ma l’insicurezza organizzativa (la mancanza di regole scritte).

L’articolo 38 del decreto, sanzionando la violazione dell’articolo 24 (che prescrive l’adozione di “politiche”), rende la mancata tenuta della procedura una fattispecie sanzionabile autonoma.

Inoltre, la responsabilità personale degli amministratori (Art. 23) trasforma la documentazione scritta nell’unico “scudo” legale efficace per dimostrare la diligenza e la supervisione richieste.

Pertanto, per i Soggetti Essenziali e Importanti, la redazione, l’approvazione e l’aggiornamento costante di un corpus documentale di policy e procedure non è un optional, ma un prerequisito fondamentale per operare nella legalità ed evitare sanzioni amministrative, interdittive e reputazionali.