Verifica di conformità NIS2 e KSC: documenti, registri e test per costruire evidenze coerenti

La verifica di conformità a NIS2 e KSC non si limita alla presentazione di policy e procedure. L’autorità di vigilanza può accertare se l’organizzazione ha definito correttamente il perimetro degli obblighi, assegnato le responsabilità, attuato le misure di sicurezza e raccolto evidenze aggiornate sul loro effettivo funzionamento, inclusi registri, risultati dei test e decisioni della direzione. La preparazione deve quindi seguire una catena probatoria coerente: dall’obbligo e dal rischio alla misura adottata, fino alla registrazione dell’attività, alla valutazione dell’efficacia e alla gestione degli scostamenti.

La verifica riguarda il sistema, non il fascicolo documentale

Il punto di partenza non è il numero di policy e procedure disponibili, ma la corretta definizione del perimetro degli obblighi. L’organizzazione deve saper indicare quali servizi, processi, sistemi informativi, sedi e dipendenze dai fornitori rientrano nei requisiti KSC, nonché il fondamento della valutazione effettuata. Prima di riordinare la documentazione, la direzione dovrebbe quindi confermare lo status del soggetto e il perimetro dei servizi erogati, nominando poi un responsabile del coordinamento delle attività preparatorie.

Il rischio probatorio più rilevante si presenta quando la documentazione descrive soluzioni che l’organizzazione non applica realmente o non è in grado di dimostrare mediante registrazioni. Ciò riguarda soprattutto le revisioni delle autorizzazioni, le valutazioni dei rischi, i backup, il controllo dei fornitori e i test di continuità operativa. Le evidenze devono formare una sequenza coerente: requisito o rischio, decisione, misura adottata, responsabilità, registrazione dell’esecuzione, risultato della valutazione di efficacia e risposta allo scostamento rilevato.

L’autorità può partire da un documento di livello generale e passare successivamente a un campione operativo. Se la procedura di gestione degli incidenti definisce modalità di classificazione ed escalation degli eventi, occorre prevedere l’esame delle segnalazioni, dei tempi di risposta, delle decisioni adottate, delle comunicazioni, della chiusura dei casi e delle lezioni apprese. Il perimetro del sistema non si dimostra solo con una descrizione: servono anche una mappa dei servizi e delle dipendenze, un inventario degli asset, l’assegnazione dei rispettivi responsabili e la coerenza di tali informazioni con i registri operativi.

Documentazione NIS2 e KSC prima della verifica: quali policy, registri ed evidenze sono realmente necessari deve rappresentare un meccanismo di gestione effettivamente operativo, non un semplice catalogo di modelli. Occorre inoltre distinguere la verifica dell’autorità di vigilanza dall’audit di un sistema di gestione. Entrambe le attività possono utilizzare evidenze analoghe, ma la verifica serve ad accertare l’adempimento degli obblighi previsti dalla normativa applicabile e dal relativo ambito di vigilanza, mentre l’audit valuta conformità ed efficacia del sistema rispetto a criteri prestabiliti. L’esito positivo di un’attività non sostituisce l’altra.

Perimetro e responsabilità sotto esame

Il primo gruppo di evidenze deve chiarire perché l’organizzazione è soggetta a determinati obblighi e dove si collocano i confini dell’ambiente sottoposto a vigilanza. L’autorità può richiedere la motivazione della qualificazione del soggetto, l’identificazione dei servizi interessati dalla normativa e l’indicazione dei processi, degli asset informativi, dei sistemi, delle sedi e dei fornitori correlati. Il perimetro non dovrebbe essere descritto unicamente attraverso la denominazione dell’attività. Deve consentire di seguire l’erogazione del servizio dal processo aziendale agli asset che lo supportano, comprese le dipendenze esterne.

La preparazione dovrebbe basarsi su una descrizione aggiornata del perimetro, approvata dalla direzione e integrata dalla mappa di servizi e processi, dall’inventario degli asset critici e dalla struttura delle responsabilità. I documenti che istituiscono i ruoli devono specificare non solo le denominazioni delle funzioni, ma anche l’autorità necessaria per accettare i rischi, attivare le misure di emergenza, effettuare l’escalation degli incidenti e assumere decisioni nei confronti dei fornitori. I responsabili di servizi, asset e rischi devono essere individuati in coerenza con l’effettiva distribuzione delle competenze.

Una tipica incoerenza si verifica quando il registro indica un responsabile formale del rischio, ma la decisione di accettazione viene assunta da un’altra persona, priva della necessaria autorità o senza un’adeguata registrazione. Lo stesso problema riguarda le deroghe alle misure di sicurezza, la continuità operativa e l’approvazione dei fornitori. Verbali delle riunioni, delibere, approvazioni delle valutazioni dei rischi, decisioni di budget e riesami della direzione devono dimostrare che il vertice conosce i rischi rilevanti, decide sulle questioni che superano le competenze operative e controlla l’attuazione delle decisioni assunte.

Le modalità di qualificazione, l’iscrizione nell’elenco pertinente e le competenze dell’autorità devono essere determinate caso per caso sulla base della normativa vigente e della situazione specifica del soggetto. Un approfondimento operativo è disponibile in NIS2: autovalutazione e iscrizione nell’Elenco KSC – cosa deve fare un’impresa manifatturiera? Se l’organizzazione è qualificata come soggetto essenziale, la valutazione del perimetro dovrebbe essere collegata anche al contenuto Audit KSC obbligatorio: quali soggetti essenziali devono prepararsi alla prima valutazione di conformità. Lo status, da solo, non dimostra tuttavia che la direzione abbia approvato i confini delle responsabilità e ne garantisca il riesame periodico.

I registri dimostrano la prassi operativa

Un registro costituisce evidenza di una gestione continuativa solo quando riflette le decisioni e le attività realmente svolte nei processi, anziché essere un allegato alla procedura aggiornato occasionalmente. Prima di scegliere lo strumento occorre definire i campi necessari, le fonti dei dati, i responsabili delle registrazioni e le modalità di approvazione delle modifiche. Un foglio di calcolo può essere sufficiente se garantisce controllo degli accessi, tracciabilità delle modifiche, responsabilità univoche e protezione da alterazioni non autorizzate. Anche uno strumento complesso non rende affidabili i dati se non è chiaro chi aggiorna il registro, quando lo fa e sulla base di quale evento.

Il registro dei rischi dovrebbe collegare gli scenari di minaccia ai servizi e agli asset, indicando il responsabile, le misure esistenti, il risultato della valutazione, la decisione di trattamento e lo stato di avanzamento delle azioni. L’autorità può verificare se un rischio indicato come oggetto di mitigazione dispone di un’attività assegnata, di una scadenza e di un’evidenza di completamento e se un rischio accettato è stato approvato da una persona dotata dell’autorità necessaria. Tra gli indicatori gestionali utili rientrano il numero di rischi aperti, le azioni non concluse e le decisioni in attesa di riesame. Si tratta di indicatori definiti dall’organizzazione, non di soglie stabilite dalla legge.

Il registro degli incidenti e degli eventi deve consentire di ricostruire tutte le fasi: rilevazione, classificazione, escalation, decisione sulla notifica, comunicazione, ripristino dell’operatività e chiusura formale con le relative conclusioni. Le evidenze collegate comprendono i registri delle vulnerabilità, delle patch e delle eccezioni approvate, delle revisioni delle autorizzazioni, dell’esecuzione e del ripristino dei backup, delle modifiche di configurazione, delle attività degli amministratori, della formazione e delle esercitazioni.

Il rinvio di una patch deve essere tracciabile dalla vulnerabilità identificata, passando per la valutazione dell’impatto e la decisione di deroga, fino alla definizione delle misure compensative, della data di rivalutazione e della conferma di chiusura. Un semplice elenco delle patch arretrate non permette di stabilire se il ritardo sia effettivamente sotto controllo.

La stessa coerenza è necessaria per la supervisione della catena di fornitura. Un elenco di contratti non sostituisce la classificazione dei fornitori, la valutazione delle dipendenze di servizi e asset dai soggetti esterni, la definizione dei requisiti di sicurezza, le registrazioni dei riesami o le decisioni relative alle carenze non accettabili. Il registro dovrebbe indicare chi ha approvato il fornitore, quali deroghe sono state autorizzate e quando si svolgerà la successiva valutazione. Occorre monitorare in particolare i fornitori privi di una valutazione aggiornata e le azioni non completate dopo i riesami. Il tema rimane rilevante anche nell’attuazione del programma Attuazione della NIS2 dopo l’iscrizione nell’Elenco KSC – piano d’azione fino al 3 aprile 2027.

Le regole di conservazione, accesso e approvazione delle modifiche devono essere differenziate in funzione del tipo di registrazione, della sua rilevanza probatoria, dei requisiti legali e contrattuali e delle esigenze di analisi degli incidenti. Non è opportuno adottare un unico periodo di conservazione per tutti i registri senza aver svolto tale valutazione. I termini di notifica degli incidenti e le modalità di protezione delle evidenze devono essere verificati caso per caso in base alle disposizioni vigenti e alle indicazioni dell’autorità competente. Un catalogo più ampio dei materiali è descritto in Documentazione NIS2 e KSC prima della verifica: quali policy, registri ed evidenze sono realmente necessari. La maturità operativa dipende tuttavia dalle registrazioni prodotte nel lavoro quotidiano e dalla tracciabilità del percorso che collega una prescrizione al risultato del controllo e alla conseguente azione correttiva.

Ogni test deve concludersi con una decisione

L’autorità di vigilanza può chiedere non solo il piano di continuità operativa, la procedura di risposta agli incidenti o la conferma dell’esecuzione dei backup. Sono rilevanti anche le evidenze che tali soluzioni siano state verificate in condizioni coerenti con i servizi, le tecnologie e le dipendenze dai fornitori effettivamente presenti. Il programma dei test dovrebbe derivare dalla valutazione dei rischi, dalla criticità dei servizi, dai cambiamenti dell’ambiente e dai requisiti legali e contrattuali. Non esiste un’unica frequenza corretta per tutte le misure. Le verifiche dovrebbero essere più frequenti negli ambiti a elevato impatto, soggetti a rapidi cambiamenti o nei quali test precedenti abbiano evidenziato scostamenti significativi.

Prima di ogni prova occorre definirne l’oggetto e i criteri di superamento. La registrazione dovrebbe comprendere perimetro, scenario, partecipanti, ambiente, criteri di accettazione e tolleranze ammesse; dopo l’esecuzione, deve riportare il risultato, gli scostamenti e l’impatto effettivo o potenziale sul servizio. In presenza di carenze, le evidenze devono indicare le azioni correttive, i relativi responsabili, i termini di completamento e la data della successiva verifica.

Tra gli indicatori utili rientrano il tempo effettivo di ripristino, il punto di ripristino raggiunto, il tempo di escalation e la percentuale di azioni chiuse dopo la prova. L’errore organizzativo più grave consiste nel ripetere periodicamente i test senza criteri di successo o senza chiudere le non conformità emerse.

Le prove principali comprendono il ripristino dei dati dai backup, il passaggio alle soluzioni di emergenza, le esercitazioni di risposta agli incidenti, i test della comunicazione di crisi, le revisioni delle autorizzazioni, il ripristino delle configurazioni e le verifiche tecniche delle vulnerabilità, inclusi gli scan e, in funzione del rischio, i penetration test. Il risultato prodotto da un fornitore può costituire una parte dell’evidenza, ma non sostituisce la prova svolta dall’organizzazione se non copre i suoi processi, le integrazioni, le responsabilità e le effettive condizioni operative.

Dopo ogni test, il responsabile del servizio dovrebbe assumere una decisione documentata: accettare il risultato, introdurre una correzione, stabilire una misura compensativa, ripetere la prova oppure accettare il rischio nel rispetto delle autorità assegnate.

La corretta esecuzione del backup di una banca dati non dimostra, da sola, la capacità di ripristinare il servizio. Durante una prova può emergere che l’applicazione richiede una versione di configurazione non documentata, che il sistema di gestione delle identità non funziona nell’ambiente di emergenza, che le chiavi non sono disponibili o che l’unica persona a conoscenza della sequenza di avvio dei componenti non partecipa al ripristino. Solo una verifica dell’intera catena delle dipendenze permette di confrontare il tempo e il punto di ripristino effettivi con i criteri adottati, valutare l’impatto sul servizio e decidere se il livello di preparazione sia adeguato o richieda interventi.

Questo metodo di documentazione delle prove è rilevante in ogni settore, anche nell’analisi del tema NIS2 per le imprese manifatturiere: a chi si applica, quali obblighi introduce e come preparare l’organizzazione senza ridurre il tema alla sola funzione IT. Il perimetro delle evidenze attese deve essere rapportato agli obblighi applicabili all’organizzazione, ai suoi servizi e alla normativa vigente. Resta essenziale una sequenza coerente: rischio identificato, test pianificato, criterio misurabile, risultato documentato, decisione del responsabile e conferma dell’efficace chiusura delle azioni.

Le incoerenze aumentano il costo della verifica

Una documentazione formalmente completa perde valore se non corrisponde alla situazione effettiva. L’autorità può confrontare le dichiarazioni contenute nelle policy con le configurazioni dei sistemi, le registrazioni dei ticket, i contratti, gli elenchi degli accessi, i risultati degli scan, i verbali dei test e le spiegazioni fornite dai responsabili dei processi. Non si tratta di uniformità redazionale, ma della possibilità di ricostruire la decisione dall’obbligo e dal rischio identificati fino alla misura attuata, alla registrazione del suo funzionamento e alla risposta allo scostamento.

La simulazione interna precedente all’avvio delle attività dell’autorità dovrebbe basarsi su un campione mirato di servizi, incidenti, fornitori e autorizzazioni, seguendo poi la documentazione fino ai dati di origine. Questo approccio consente di individuare inventari degli asset non aggiornati, denominazioni differenti dello stesso servizio nei vari documenti, rischi privi di responsabile, incidenti non registrati, fornitori senza una valutazione documentata e azioni correttive chiuse senza verifica dell’efficacia. Le discrepanze devono essere risolte accertando lo stato effettivo e il responsabile della registrazione, non mediante un allineamento documentale effettuato solo per l’occasione.

In un’impresa manifatturiera, il riesame non dovrebbe fermarsi all’ambiente informatico d’ufficio. Per un servizio selezionato può includere manutenzione, automazione industriale, accesso remoto dell’assistenza, gestione della configurazione e dipendenze tra i sistemi di produzione. L’elenco degli accessi potrebbe, per esempio, non includere l’account utilizzato da un tecnico esterno, sebbene il contratto, il log della connessione e la configurazione del dispositivo ne confermino l’esistenza. La rilevanza di tali dipendenze è approfondita nel contenuto NIS2 per le imprese manifatturiere: a chi si applica, quali obblighi introduce e come preparare l’organizzazione senza ridurre il tema alla sola funzione IT.

La certificazione di un sistema di gestione può strutturare la gestione dei rischi, il controllo della documentazione, gli audit e le azioni correttive, ma non sostituisce l’analisi del perimetro giuridico né le evidenze dell’adempimento degli obblighi specifici KSC. Questo confine è trattato in NIS2 e UNI EN ISO 27001: cosa offre la certificazione e cosa manca ancora per la conformità al KSC. L’assenza di una singola registrazione non determina automaticamente una non conformità, ma richiede una valutazione della rilevanza dell’evidenza, della causa della lacuna e della possibilità di confermare il funzionamento della misura mediante altre registrazioni affidabili.

Il costo della verifica aumenta soprattutto quando le evidenze sono disperse, le deleghe non sono chiare e nessuno coordina le risposte e l’approvazione dei materiali trasmessi. In tali circostanze, i gruppi di lavoro iniziano a riconciliare manualmente dati contraddittori durante le attività ispettive. La preventiva nomina di un coordinatore, l’individuazione dei responsabili delle singole evidenze e la definizione delle regole per risolvere le discrepanze riducono il carico operativo e il rischio di fornire all’autorità spiegazioni incoerenti.

La preparazione si costruisce con una simulazione della verifica

La simulazione interna dovrebbe iniziare dalla conferma dello status del soggetto, del perimetro dei servizi interessati dagli obblighi e delle responsabilità della direzione e dei responsabili di processo. Successivamente, il coordinatore dei rapporti con l’autorità dovrebbe predisporre una matrice di conformità che colleghi ciascun obbligo al relativo responsabile e alle evidenze disponibili. Solo su questa base si procede all’esame di campioni di registrazioni, ai colloqui con i soggetti responsabili e alla ricostruzione di uno specifico incidente o test. È opportuno affidare il ruolo di coordinatore a una persona che abbia accesso alla direzione e la capacità di risolvere le discrepanze, senza sostituirsi ai responsabili tecnici delle evidenze.

Ogni responsabile di un obbligo dovrebbe essere in grado di indicare:

• il documento di riferimento che definisce le modalità operative,
• la registrazione che dimostra l’esecuzione dell’obbligo,
• l’indicatore di efficacia della misura adottata,
• l’ultima decisione assunta a seguito del riesame.

L’assenza di uno di questi elementi rappresenta un’interruzione della catena probatoria. Una procedura di risposta agli incidenti non è sufficiente se l’organizzazione non può presentare il registro dell’evento, il tempo di risposta, la valutazione degli impatti, il risultato dell’analisi delle cause e la decisione relativa alla modifica delle misure di sicurezza. La ricostruzione del caso permette inoltre di verificare se le spiegazioni del personale siano coerenti con le registrazioni e con l’effettivo svolgimento delle attività.

La simulazione dovrebbe comprendere anche gli aspetti organizzativi della verifica: ricezione e registrazione della richiesta, definizione del termine e del responsabile della risposta, approvazione dei materiali, protezione delle informazioni sensibili, identificazione delle versioni trasmesse e registrazione delle interlocuzioni con l’autorità. È utile simulare una situazione nella quale una registrazione richiesta contenga dati estranei all’oggetto della verifica o necessiti di una spiegazione contestuale. In questo modo si stabilisce chi decide l’estensione della divulgazione e come l’organizzazione mantiene la tracciabilità dei materiali trasmessi.

Il piano di miglioramento dovrebbe classificare le lacune in base all’impatto sul servizio, all’esposizione giuridica, alla probabilità che siano rilevate e al tempo necessario per ottenere evidenze affidabili di efficacia, non in funzione della facilità con cui è possibile redigere un’ulteriore procedura. La direzione approva priorità, risorse e livello di rischio accettabile. Un’azione può essere chiusa solo dopo una nuova verifica della misura.

Il programma temporale deve essere definito sulla base dello status effettivo del soggetto, delle comunicazioni con l’autorità e delle disposizioni vigenti. Una volta determinato lo status, l’analisi può essere integrata dai contenuti NIS2: autovalutazione e iscrizione nell’Elenco KSC – cosa deve fare un’impresa manifatturiera? e Attuazione della NIS2 dopo l’iscrizione nell’Elenco KSC – piano d’azione fino al 3 aprile 2027. Le date e gli obblighi indicati in tali materiali devono essere sempre confermati alla luce della normativa aggiornata.