La policy NIS 2 c’è. Qualcuno l’ha scritta, qualcun altro l’ha approvata. Ora sta in una cartella condivisa che quasi nessuno apre. Nella maggior parte delle organizzazioni in perimetro NIS 2 il problema non è l’assenza di documentazione. È la distanza tra quello che le policy operative dicono e quello che accade ogni giorno: nei sistemi, negli accessi, nei comportamenti delle persone.
Una policy che non viene applicata non protegge. Peggio: crea una falsa sensazione di copertura. Quando arriva un incidente, o un audit, quella distanza diventa un problema concreto, documentato e sanzionabile.
Perché le policy restano sulla carta
Esistono sostanzialmente due tipi di policy di sicurezza. Le prime sono scritte bene, in modo generico, con principi condivisibili che però non si traducono mai in istruzioni operative. Le seconde sono copiate da template standard, adattate il minimo indispensabile e distribuite come atto formale. In entrambi i casi il risultato pratico è lo stesso: un documento che descrive uno scenario ideale, non la realtà dell’organizzazione. Le procedure scritte non corrispondono ai processi reali. I controlli previsti non vengono verificati. I responsabili indicati spesso non sanno di esserlo.
Una policy è un criterio di audit, nel senso della UNI EN ISO 19011:2018. Se non è applicata non è un documento di sicurezza: è una non conformità in attesa di essere rilevata. Il D.Lgs. 138/2024 non chiede solo di avere delle policy. Chiede di dimostrare che i controlli funzionano. L’art. 21 stabilisce obblighi precisi su gestione del rischio, controllo degli accessi, patch management, sicurezza della supply chain. Non è sufficiente affermare di averli implementati: servono evidenze oggettive. Se non hai ancora una fotografia chiara della tua infrastruttura, leggi prima questo articolo sul primo passo dell’adeguamento NIS 2: è da lì che si parte.
Come si porta a terra una policy NIS 2: 4 step operativi
Mettere a terra una policy non è un esercizio burocratico. È un processo strutturato che parte dalla realtà dell’organizzazione e arriva a controlli verificabili.
Step 1: gap analysis tra policy NIS 2 scritta e pratica reale
Il primo passo è confrontare ciò che la policy prescrive con ciò che accade davvero. Una policy operativa deve essere completa (contiene tutti i controlli attesi), corretta rispetto ai requisiti normativi, coerente con gli altri documenti interni e aggiornata rispetto all’infrastruttura reale. In pratica, significa analizzare ogni controllo e chiedersi: questo requisito è traducibile in un’azione concreta? Chi la esegue? Con quale frequenza? Come si dimostra? Se una di queste domande non ha risposta, il controllo è formale, non operativo.
Step 2: mappatura sui processi reali
Ogni controllo va agganciato a un processo reale dell’organizzazione: chi fa cosa, quando, con quali strumenti, sotto quale responsabilità. È il passaggio più critico e più spesso saltato. Un esempio concreto: una policy che prevede la revoca tempestiva degli accessi degli utenti cessati non è operativa finché non si risponde a domande precise: chi riceve la notifica di fine rapporto, in quale sistema, entro quanto tempo deve agire e chi verifica che l’azione sia stata eseguita. Senza queste risposte il controllo esiste solo sulla carta.
La mappatura produce una matrice di responsabilità per ciascun controllo: processo collegato, owner, frequenza, evidenza attesa. Quel documento è la base su cui si costruisce tutto il resto.
Step 3: verifica sul campo tramite tecniche di audit
Qui si raccolgono evidenze oggettive, non dichiarazioni né autovalutazioni. I metodi principali sono tre, combinabili in base al controllo da verificare. Le interviste strutturate vengono condotte con i responsabili operativi dei processi, non solo con il management: la domanda chiave non è “avete una policy?” ma “mi descriva come gestisce concretamente questo processo”. L’osservazione diretta verifica sul campo le configurazioni effettive di sistema, i log di accesso, i registri di patching, i workflow reali di approvazione: non ciò che dovrebbe essere, ciò che è. Il riesame delle informazioni documentate analizza registrazioni, report, ticket, audit trail: ogni controllo operativo lascia una traccia e se la traccia non c’è, il controllo non è dimostrabile, che ai fini NIS 2 è lo stesso che non eseguirlo.
L’approccio è risk-based: si concentra il campionamento sui controlli ad alto impatto come gestione degli accessi privilegiati, patch management, backup e recovery e notifica degli incidenti, prima di verificare quelli a minore criticità.
Step 4: aggiornamento delle policy operative
La verifica produce due tipi di risultanze: conformità, quando il controllo funziona ed è dimostrabile, e non conformità, quando il controllo non funziona o funziona ma non è dimostrabile. Per ogni non conformità si definisce un’azione correttiva con owner e scadenza. Ma l’intervento non si limita al processo: va aggiornata anche la policy, che deve rispecchiare la realtà operativa corretta. Una policy che descrive ciò che l’organizzazione fa davvero, e può dimostrarlo, è uno strumento di difesa. Una policy che descrive ciò che si vorrebbe fare è un rischio.
Il ciclo si ripete con cadenza definita in base alla criticità dei controlli, ai cambiamenti all’infrastruttura e alle scadenze normative. Non è un progetto una tantum: è un programma di audit interno continuo.
Chi deve governare questo processo
La NIS 2 assegna agli organi di amministrazione la responsabilità di supervisionare l’efficacia delle policy operative NIS 2. Non basta approvare un documento: il management deve essere in grado di dimostrare che quella policy produce controlli reali e verificati. Per capire come strutturare questo ruolo a livello di board, leggi la nostra guida NIS 2 e governance per il board. Nella pratica, il processo coinvolge il CISO o responsabile IT per la parte tecnica, il legal/compliance per l’allineamento normativo e i process owner per la parte operativa. La governance di questo processo, cioè chi coordina, chi ha autorità sulle non conformità e chi firma le azioni correttive, deve essere definita prima di avviare qualsiasi attività di audit.
Un’organizzazione che arriva a un audit esterno o a un incidente senza aver mai eseguito verifiche interne non è solo esposta dal punto di vista tecnico. È esposta dal punto di vista della responsabilità personale degli organi direttivi, come previsto esplicitamente dal D.Lgs. 138/2024.
Come può aiutarti Key Partner
Il percorso che abbiamo descritto, dalla gap analysis alla mappatura, dalla verifica sul campo all’aggiornamento delle policy operative, non è teorico. È il lavoro concreto che separa un’organizzazione che dichiara di essere conforme da una che può dimostrarlo. Il Posture Assessment NIS 2 di Key Partner Cyber integra l’analisi di maturità dell’infrastruttura con la verifica dell’efficacia reale dei controlli: non solo cosa hai, ma se ciò che hai funziona e, soprattutto, se è dimostrabile.
Contattaci per richiedere una prima valutazione.
Domande frequenti
Con quale frequenza vanno verificate le policy NIS 2?
Il D.Lgs. 138/2024 non prescrive una frequenza universale. Richiede che le misure di sicurezza siano adeguate e proporzionate al rischio e vengano aggiornate in caso di modifiche significative all’infrastruttura o all’organizzazione. Un programma strutturato prevede verifiche ad alta frequenza per i controlli critici come accessi privilegiati, patch management e notifica degli incidenti, e verifiche periodiche, tipicamente annuali, per i controlli a minore impatto.
Cosa si intende per evidenza oggettiva ai fini NIS 2?
Un’evidenza oggettiva è qualsiasi dato verificabile che dimostri l’applicazione di un controllo: log di sistema, registri di accesso, ticket di richiesta e approvazione, screenshot di configurazioni, verbali di riunione, report di patching. Non sono evidenze le dichiarazioni non supportate da documentazione o le autovalutazioni senza riscontro. In un audit NIS 2, sia interno che da parte dell’ACN, ciò che non è dimostrabile non è considerato conforme.
La verifica delle policy NIS 2 è diversa da un audit ISO 27001?
L’approccio metodologico è simile: entrambi si basano su criteri di audit, raccolta di evidenze e produzione di risultanze. Le differenze sono nel perimetro e nei criteri di riferimento. L’ISO 27001 copre un sistema di gestione della sicurezza su base volontaria. La NIS 2 è un obbligo normativo con requisiti tecnici e organizzativi specifici definiti dall’art. 21 e dalle linee guida ACN. Le due cose sono complementari: una certificazione ISO 27001 può costituire evidenza di conformità NIS 2, ma non la garantisce automaticamente su tutti i controlli richiesti.
Serve un consulente esterno per verificare le policy NIS 2, o basta una risorsa interna?
Entrambe le opzioni sono valide, con vantaggi diversi. Una verifica interna è più rapida e contestualizzata, ma richiede indipendenza dall’attività verificata: chi gestisce un processo non può auditare sé stesso in modo credibile. Un consulente esterno porta obiettività, esperienza su più contesti e una visione comparativa rispetto allo stato dell’arte del settore. Per le prime verifiche o per le aree più critiche, il supporto esterno garantisce maggiore credibilità delle risultanze sia verso il management che verso l’autorità di vigilanza.
