NIS2 e UNI EN ISO 27001: cosa copre la certificazione e cosa manca per la conformità al KSC

In molte aziende il confronto sulla NIS2 parte dalla certificazione UNI EN ISO 27001. È comprensibile, ma per il management e i process owner non è il punto di partenza corretto. Prima occorre stabilire se l’organizzazione è soggetta agli obblighi, quali servizi e asset rientrano nel perimetro e chi ne assume la responsabilità. Solo dopo è possibile valutare con rigore cosa copre realmente l’attuale sistema di gestione per la sicurezza delle informazioni e quali lacune restano rispetto al KSC. È proprio qui che emerge la differenza tra un sistema strutturato e una costosa illusione di preparazione.

L’errore più costoso: confondere la certificazione con la conformità

L’errore principale non è la mancanza di una certificazione UNI EN ISO 27001, bensì presumere che il suo possesso determini automaticamente la conformità agli obblighi derivanti dalla NIS2 e dalle disposizioni nazionali di attuazione del KSC. La domanda corretta per il management non è «abbiamo la UNI EN ISO 27001?», ma «siamo soggetti agli obblighi, in quale veste e rispetto a quali servizi, processi e asset?». Solo dopo avere definito lo status dell’organizzazione, il perimetro delle attività interessate e le responsabilità del vertice si può stabilire in che misura il sistema esistente supporti effettivamente la conformità e dove, invece, produca soltanto una percezione di controllo.

Questa distinzione ha conseguenze dirette sul progetto e sul budget. Il certificato attesta la conformità del sistema di gestione ai requisiti della norma entro uno specifico campo di applicazione, normalmente indicato sul certificato e precisato nella Dichiarazione di Applicabilità. Non sostituisce però l’analisi degli obblighi di legge, l’identificazione dei servizi rilevanti, la valutazione delle dipendenze dai fornitori o la definizione degli adempimenti formali richiesti a un soggetto regolamentato. Il vertice dovrebbe quindi separare tre dimensioni che nella pratica vengono spesso confuse: sistema di gestione, conformità regolamentare e capacità operativa di agire sotto la pressione di un incidente.

I progetti più onerosi sono quelli condotti nell’ordine inverso. L’organizzazione prepara dapprima documenti e controlli in funzione dell’audit di certificazione, per poi scoprire che processi critici, obblighi di notifica degli incidenti, requisiti per i fornitori, responsabilità del management o prescrizioni settoriali sono rimasti fuori dal perimetro. A quel punto non basta integrare qualche procedura: occorre riprogettare il campo di applicazione del sistema, i ruoli decisionali e le modalità di risposta.

Dal punto di vista operativo, non basta quindi misurare il possesso del certificato. È più utile verificare tre elementi: l’allineamento tra campo di applicazione della certificazione e servizi critici, l’esito dell’autovalutazione sull’applicabilità del KSC e il numero di lacune tra quanto previsto dalle procedure e la capacità reale di intervenire. Il primo passo non consiste nell’aumentare la documentazione, ma nel determinare se l’organizzazione rientri nel perimetro degli obblighi e quali adempimenti formali siano richiesti. Questa sequenza è illustrata anche nell’approfondimento NIS2: autovalutazione e iscrizione nell’elenco KSC – cosa deve fare un’azienda manifatturiera?, perché è da qui che si comprende se l’impresa stia costruendo il sistema attorno a obblighi effettivi o a una rassicurante, ma costosa, illusione di preparazione.

Cosa copre realmente UNI EN ISO 27001

Il principale valore operativo di UNI EN ISO 27001 non risiede nel certificato in sé, ma nella capacità di un sistema ben implementato di governare la sicurezza come un processo manageriale. La norma offre il supporto più solido nelle aree che richiedono un approccio strutturato: valutazione e trattamento del rischio, politiche e criteri di controllo, attribuzione di ruoli e responsabilità, identificazione degli asset informativi, gestione degli incidenti, continuità operativa, riesame e miglioramento. Quando questi elementi funzionano nella pratica, e non soltanto in vista dell’audit, l’azienda dispone di una base robusta per dimostrare che la sicurezza non è un insieme di misure isolate, ma un sistema governato e collegato alle decisioni operative.

Il vertice non dovrebbe tuttavia valutare solo il certificato, bensì la sua utilità rispetto ai servizi, ai processi e alle dipendenze rilevanti sotto il profilo regolamentare. Lo stesso certificato può rappresentare un sistema maturo, esteso ai processi critici e sostenuto da riesami periodici, azioni correttive e un effettivo presidio dei process owner; oppure un assetto ristretto a una parte selezionata dell’organizzazione. Prima dell’autovalutazione rispetto a NIS2 e KSC è quindi opportuno esaminare non soltanto la Dichiarazione di Applicabilità, ma anche l’elenco dei processi inclusi nella valutazione del rischio, i risultati degli audit interni, gli output del riesame di direzione e l’effettivo impatto delle decisioni sul rischio in termini di budget, contratti, architettura dei servizi e modalità di risposta.

Il tema è particolarmente evidente nelle aziende inserite in catene di fornitura articolate. UNI EN ISO 27001 consente normalmente di strutturare requisiti contrattuali, classificazione delle informazioni, regole di accesso, responsabilità dei fornitori e gestione documentata delle eccezioni. È una base utile, soprattutto quando i clienti richiedono evidenze sul controllo dei partner. Non soddisfa però automaticamente tutte le aspettative di settore o i criteri specifici applicabili; una questione analoga viene affrontata nell’articolo UNI EN ISO 27001 o TISAX: quale scegliere quando il cliente richiede la sicurezza delle informazioni nella supply chain? In pratica, la certificazione struttura rapporti e responsabilità, ma non sostituisce la verifica degli obblighi da inserire nei contratti, nelle procedure di escalation e nel controllo dei servizi esternalizzati.

La conclusione è chiara: la certificazione può ridurre sensibilmente il percorso necessario per strutturare la sicurezza, ma non costituisce da sola una prova di adempimento agli obblighi del KSC. L’audit di certificazione valuta la conformità del sistema di gestione ai requisiti della norma entro un perimetro definito; non coincide con una verifica degli obblighi di legge e della preparazione operativa. L’organizzazione dovrebbe quindi accertare in parallelo che il sistema includa i processi rilevanti, che la valutazione del rischio sia aggiornata rispetto ai servizi e alle dipendenze reali e che le procedure per incidenti, continuità e fornitori funzionino concretamente.

Dove la certificazione non basta

La prima lacuna riguarda la conformità regolamentare in quanto tale. Un sistema di gestione per la sicurezza delle informazioni struttura regole, ruoli e controlli, ma non determina automaticamente se l’organizzazione sia stata correttamente qualificata rispetto agli obblighi del KSC, chi debba effettuare le notifiche formali, chi mantenga i rapporti con l’autorità competente e come le decisioni debbano essere sottoposte al vertice. Non si tratta dell’assenza di un singolo documento, ma di un difetto nel modello delle responsabilità. Se questi aspetti non vengono integrati nell’effettivo assetto operativo della società, il certificato offre ordine interno, ma non ancora una governance regolamentare efficace.

La seconda lacuna riguarda il perimetro. Molte organizzazioni dispongono di una certificazione limitata a una sede, una società, una funzione o una parte dei servizi di supporto. La valutazione della preparazione rispetto al KSC deve invece partire dalla mappa reale dei servizi, dei processi critici, degli asset e delle dipendenze, non dai confini dell’audit di certificazione. Se un servizio essenziale o importante è erogato da più società del gruppo, con il coinvolgimento di un data center esterno, di un team di manutenzione condiviso o di un processo distribuito di gestione degli incidenti, un certificato formalmente corretto può coprire soltanto una parte dell’insieme. In questo caso la decisione del management non riguarda semplicemente l’estensione del certificato, ma la scelta tra un unico progetto integrato di conformità e due flussi coordinati: uno certificativo e uno regolamentare.

La terza lacuna riguarda le evidenze e tende a emergere soltanto durante un incidente, un’esercitazione o un controllo. L’organizzazione dispone di procedure per la gestione degli incidenti, la continuità operativa e il presidio dei fornitori, ma non riesce a dimostrare che tali meccanismi siano operativi. Mancano il registro degli incidenti, la tracciabilità delle decisioni del management, i risultati delle esercitazioni, i riesami successivi agli eventi, gli indicatori di efficacia e le azioni correttive documentate. In queste condizioni il sistema è descritto, ma non dimostrato. È qui che gli interventi correttivi diventano più costosi, perché occorre modificare non solo le procedure, ma anche il reporting al vertice, la frequenza dei riesami e la responsabilità dei process owner. Lo stesso meccanismo si osserva in altri sistemi di gestione, come illustrato nell’articolo IATF 16949: quali requisiti incidono davvero sulla gestione quotidiana della qualità e come governarli senza una conformità solo apparente.

La quarta lacuna interessa la supply chain e le dipendenze esterne. La norma aiuta a organizzare i requisiti applicabili ai fornitori, ma la conformità al KSC può richiedere una mappatura più approfondita: quali servizi esterni sostengono l’erogazione del servizio critico, dove si trovano i single point of failure, quali scenari di interruzione sono plausibili e quanto siano sostituibili il fornitore, il personale o la sede. Nella pratica, è opportuno misurare non solo l’esistenza di contratti e valutazioni dei fornitori, ma anche la coerenza tra il campo di applicazione del certificato e la mappa effettiva dei servizi critici, la completezza dei registri di incidenti ed esercitazioni e l’aggiornamento delle verifiche su fornitori e dipendenze. Solo questo confronto consente di capire se l’organizzazione disponga di un sistema strutturato o soltanto della sua rappresentazione formale.

Il progetto di conformità deve partire dai servizi, non dai documenti

L’errore più frequente consiste nell’avviare il progetto esaminando politiche, procedure e registrazioni UNI EN ISO 27001, anziché chiedersi quali servizi debbano essere realmente mantenuti e quali obblighi regolamentari siano collegati a essi. La sequenza corretta è opposta: prima si identificano servizi, processi, asset e dipendenze critici per la continuità operativa e per le responsabilità derivanti dal KSC; solo successivamente si associano i requisiti del sistema e le evidenze necessarie. Questo approccio permette di distinguere i documenti effettivamente utili da quelli superflui.

Per il vertice ciò significa deliberare la costruzione di una mappa dei servizi critici, delle dipendenze da fornitori e sistemi e delle procedure esistenti che possono essere riutilizzate senza duplicare i controlli. Solo su questa base si comprende se il sistema attuale copra ciò che conta davvero per la continuità del servizio e per la conformità, oppure soltanto quanto è stato storicamente incluso nel campo di applicazione della certificazione.

Il secondo passaggio riguarda il modello delle responsabilità. Se la sicurezza delle informazioni è distribuita tra IT, qualità, compliance, manutenzione e acquisti senza una chiara attribuzione dei ruoli, il progetto si trasforma rapidamente in un insieme di iniziative locali. Occorre quindi stabilire chi possiede il rischio, chi gestisce gli incidenti, chi controlla i rapporti con i fornitori, chi assume le decisioni di livello manageriale e chi conserva le evidenze di conformità. In genere risultano efficaci una semplice matrice di ruoli e responsabilità e un unico ciclo di riesame direzionale, anziché percorsi di reporting paralleli. È anche il momento di decidere se istituire un unico comitato guida per conformità e sicurezza e se integrare la tecnologia operativa nello stesso modello di rischio.

Nelle organizzazioni manifatturiere e multisito questa logica è particolarmente importante. Un incidente non si limita alla perdita di riservatezza dei dati: può causare l’arresto di una linea, compromettere la pianificazione, interrompere la tracciabilità dei lotti o ridurre la capacità di erogare un servizio. La sicurezza delle informazioni deve quindi essere collegata alla continuità operativa, alla manutenzione e agli ambienti OT. Se il sistema di gestione copre esclusivamente l’ambiente d’ufficio e trascura i sistemi di controllo, l’assistenza remota, le dipendenze dagli integratori o le procedure di emergenza dello stabilimento, il quadro dei rischi sarà formalmente ordinato ma operativamente incompleto. La stessa disciplina progettuale ricorre in altri settori ad alta intensità di controllo, anche quando i riferimenti includono ASME, NQA-1 e ISO 19443 — tre sigle che un fornitore del settore nucleare deve conoscere.

Solo su queste basi conviene utilizzare UNI EN ISO 27001 come livello strutturale di partenza ed eseguire una gap analysis separata rispetto al KSC. L’obiettivo non è mettere in discussione il certificato, ma determinare dove esista una copertura effettiva e dove servano procedure, registri, percorsi di escalation o evidenze operative aggiuntive. Questo approccio riduce la documentazione ridondante e garantisce una maggiore coerenza dei controlli rispetto a implementazioni separate e concorrenti.

Come verificare la situazione reale prima di un audit o di un controllo

Prima di un audit, di un’autovalutazione o di un controllo non bisogna chiedersi se l’organizzazione «abbia la UNI EN ISO 27001», ma se sia in grado di dimostrare una reale capacità di risposta e la tracciabilità delle decisioni. È utile valutarla su quattro livelli: definire innanzitutto il perimetro e l’applicabilità degli obblighi; verificare poi la progettazione del sistema di gestione; valutarne l’efficacia operativa; controllare infine la completezza delle evidenze. Solo questa sequenza permette di distinguere l’ordine documentale dalla capacità di intervento.

Le domande più utili non sono quindi «abbiamo una procedura?», ma «sappiamo quando attivarla, chi prende la decisione, quali sono le soglie di escalation, come lo dimostreremo e abbiamo già testato lo scenario?». Se la gestione di un incidente dipende dalle conoscenze di una sola persona, i rapporti con i fornitori non includono criteri di sicurezza assegnati e il management riceve soltanto report generici privi di decisioni e scadenze, il sistema può essere formalmente coerente con la propria documentazione, ma restare impreparato ad agire sotto pressione.

Il riesame della preparazione dovrebbe quindi includere le interfacce tra vertice, operation, IT, manutenzione e fornitori, perché è soprattutto in questi passaggi che emergono le lacune non visibili nelle procedure. Nella pratica, lo strumento più efficace è una gap analysis impostata come un audit operativo. Si valutano non soltanto i documenti, ma anche il percorso decisionale, i flussi di escalation, le registrazioni degli incidenti, i risultati di test ed esercitazioni, il registro delle non conformità e delle osservazioni e lo stato delle azioni correttive.

Un test utile consiste nel simulare uno scenario semplice: si verifica un incidente presso un fornitore chiave oppure un’interruzione nell’ambiente produttivo. Occorre quindi stabilire chi qualifica l’evento, chi attiva la comunicazione, chi ne valuta l’impatto sul servizio e quali evidenze resteranno a supporto della decisione. Se le risposte sono frammentate e l’organizzazione fa riferimento a una «prassi» che nessuno riesce a ricostruire attraverso registrazioni, la preparazione è soltanto apparente, anche in presenza di un sistema di gestione formalmente mantenuto.

Se l’organizzazione conduce già audit interni UNI EN ISO 27001, può utilizzarli come veicolo per questa verifica, ampliando però i criteri di audit agli obblighi regolamentari e alle evidenze attese nell’ambito del KSC. Le competenze di audit sono molto utili, così come quelle sviluppate da chi si prepara al ruolo di lead auditor o auditor interno; un riferimento pertinente è il contenuto Lead Auditor UNI EN ISO 27001: guida completa alla certificazione e ai requisiti della norma. Occorre tuttavia mantenere la corretta sequenza: la competenza di audit aiuta a verificare il sistema, ma non sostituisce l’analisi degli obblighi legali e organizzativi effettivamente applicabili all’azienda.

La decisione del management: certificazione come base, non come alibi

L’approccio più razionale consiste nel considerare UNI EN ISO 27001 come il fondamento della governance, non come prova autonoma dell’adempimento a tutti gli obblighi derivanti da NIS2 e KSC. La certificazione struttura responsabilità, valutazione del rischio, gestione degli incidenti, audit e miglioramento, ma non esonera dal determinare quali obblighi si applichino all’organizzazione, entro quale perimetro e con quali evidenze debba essere dimostrata l’efficacia operativa.

Dal punto di vista del vertice, il rischio maggiore non è una lacuna documentale, ma l’illusione di essere pronti: ritenere che un sistema certificato sia automaticamente adeguato anche alle prescrizioni dell’ordinamento nazionale. La decisione non dovrebbe quindi limitarsi al mantenimento o all’estensione della certificazione. Occorre prima affrontare tre questioni di governance:

• confermare lo status dell’organizzazione e il perimetro degli obblighi,
• eseguire una gap analysis tra il sistema esistente e i requisiti del KSC,
• definire il modello di supervisione sull’attuazione delle azioni e sulle evidenze di efficacia.

Solo su questa base è possibile stabilire se l’impresa debba ampliare il campo di applicazione della certificazione oppure possa utilizzare l’attuale sistema UNI EN ISO 27001 senza modificarne il perimetro, integrandolo con i meccanismi organizzativi, legali e operativi mancanti. Nella pratica sono particolarmente utili tre strumenti di governance: il confronto tra il campo di applicazione aggiornato della certificazione e la mappa dei processi critici, un elenco delle lacune con valutazione dell’impatto su rischio e conformità e un piano d’azione con responsabili, scadenze e criteri di chiusura.

Per le organizzazioni che devono ancora scegliere il percorso, la sequenza delle attività non è universale. Quando la pressione dei clienti o i requisiti di gara sono elevati, costruire il sistema in funzione della certificazione può essere un primo passo giustificato, purché l’analisi degli obblighi regolamentari proceda in parallelo. Nelle aziende con un rischio operativo elevato o con responsabilità fortemente distribuite può invece essere più opportuno colmare prima le lacune regolamentari e successivamente riorganizzare il campo di applicazione della certificazione. Non è una questione di priorità formali, ma di ordine nella riduzione del rischio. In questa prospettiva, anche l’approfondimento Certificato ISO: benefici e processo di implementazione va considerato come parte di una decisione più ampia sul modello di gestione della conformità.

I risultati migliori derivano da un programma unitario nel quale sicurezza delle informazioni, continuità operativa, controllo dei fornitori e obblighi regolamentari siano gestiti come componenti del modello operativo aziendale, non come iniziative separate di funzioni diverse. Nel contesto polacco è spesso proprio la frammentazione delle responsabilità a indebolire la capacità di intervento e la disponibilità delle evidenze. La conclusione è semplice: la certificazione è utile e può accelerare sensibilmente la strutturazione del sistema, ma la conformità deve ancora essere progettata, implementata e dimostrata con evidenze adeguate al contesto NIS2 e KSC.