Mappatura delle evidenze NIS2 su ISO 27001:2022 per il 2026

Il problema NIS2 del 2026 non è la consapevolezza, ma la prova

È lunedì mattina, 08:35. Maria, da poco nominata Responsabile della sicurezza delle informazioni (CISO) di un fornitore B2B di servizi cloud e gestiti in rapida crescita, partecipa alla riunione trimestrale del Consiglio di amministrazione sui rischi con una corposa valutazione delle lacune NIS2 aperta sul laptop. La prima slide sembra rassicurante. Le politiche esistono. Una valutazione del rischio esiste. La risposta agli incidenti è documentata. I fornitori sono elencati. Le scansioni di vulnerabilità vengono eseguite ogni mese.

Poi il presidente pone la domanda che cambia la riunione:

“Possiamo dimostrare che queste misure hanno operato nell’ultimo trimestre e possiamo mostrare quali controlli ISO 27001:2022, titolari e registrazioni supportano ciascun obbligo NIS2?”

La sala resta in silenzio.

La funzione legale sa che l’azienda rientra nel perimetro NIS2 perché fornisce servizi ICT gestiti e servizi cloud a clienti dell’UE. La funzione conformità sa che Article 21 richiede misure tecniche, operative e organizzative di gestione dei rischi di cibersicurezza. Le funzioni operative sanno che il team applica patch ai sistemi, riesamina i fornitori e monitora i log. Ma le evidenze sono disperse tra sistemi di ticketing, esportazioni SIEM, cartelle delle politiche, fogli di calcolo, console cloud, portali dei fornitori e note di riunione.

Nessuno è in grado di mostrare rapidamente una catena difendibile da NIS2 Article 21 ad ambito di applicazione ISO 27001:2022, rischio, controllo, politica, titolare, procedura, registrazione operativa e risultanza di audit.

Questa è la vera sfida del 2026.

Molte organizzazioni non si chiedono più: “Rientriamo nell’ambito NIS2?” Si pongono una domanda più difficile: “Possiamo dimostrare che le nostre misure tecniche NIS2 funzionano davvero?” La risposta non può essere un foglio di calcolo di mappatura una tantum. Deve essere un modello operativo vivo all’interno del Sistema di gestione della sicurezza delle informazioni, in cui gli obblighi legali vengono tradotti in rischi, politiche, controlli, titolari, evidenze e miglioramento continuo.

Il modello Clarysec utilizza ISO/IEC 27001:2022 come asse portante del sistema di gestione, NIS2 Article 21 come insieme di obblighi regolatori, le clausole delle politiche come regole operative, Zenith Blueprint: roadmap in 30 passaggi per l’auditor come percorso di attuazione e Zenith Controls: la guida alla conformità trasversale come mappa di conformità trasversale per ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF e assurance in stile COBIT.

Iniziare dall’ambito di applicazione, perché le evidenze NIS2 vengono prima dei controlli

Un errore frequente in ambito NIS2 è passare direttamente a MFA, logging, risposta agli incidenti e gestione delle vulnerabilità prima di confermare ambito dell’entità, ambito dei servizi e ambito giurisdizionale.

NIS2 si applica a entità pubbliche e private ricomprese nei settori regolamentati che soddisfano criteri dimensionali e di attività, con alcune tipologie di entità incluse indipendentemente dalla dimensione. Le categorie digitali e ICT rilevanti includono fornitori di servizi di cloud computing, fornitori di servizi di data center, fornitori di reti per la distribuzione di contenuti, prestatori di servizi fiduciari, fornitori di reti pubbliche di comunicazione elettronica, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, mercati online, motori di ricerca online e piattaforme di social networking.

Per fornitori cloud, piattaforme SaaS, MSP, MSSP e fornitori di infrastrutture digitali, questo lavoro di definizione dell’ambito non è teorico. Article 3 richiede agli Stati membri di distinguere tra entità essenziali e importanti. Article 27 richiede a ENISA di mantenere un registro per diversi fornitori digitali e ICT, tra cui fornitori di servizi DNS, registri dei nomi TLD, fornitori di servizi di registrazione dei nomi di dominio, fornitori di servizi di cloud computing, fornitori di servizi di data center, fornitori di reti per la distribuzione di contenuti, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, mercati online, motori di ricerca online e piattaforme di social networking.

ISO 27001:2022 fornisce la struttura corretta. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere fattori esterni e interni, parti interessate, requisiti, interfacce e dipendenze, e quindi di definire il campo di applicazione del SGSI. NIS2 deve essere acquisita qui, non relegata a un promemoria legale.

Una registrazione pratica dell’ambito NIS2 dovrebbe includere:

• Analisi dell’entità giuridica e dello stabilimento nell’UE
• Settore NIS2 e categoria di servizio
• Stato di entità essenziale o importante, ove confermato dal diritto nazionale o dalla designazione dell’autorità
• Rilevanza per il registro ENISA, ove applicabile
• Servizi critici erogati ai clienti
• Sistemi di rete e informativi a supporto di tali servizi
• Dipendenze da fornitori cloud, data center, telecomunicazioni, monitoraggio della sicurezza, identità e software
• Collegamenti a DORA, GDPR, contratti con i clienti e obblighi settoriali specifici
• Repository delle evidenze, titolari dei sistemi e cadenza del riesame

Questo è anche il punto in cui DORA deve essere separata correttamente. NIS2 riconosce che, quando un atto giuridico settoriale dell’UE impone obblighi equivalenti di gestione dei rischi di cibersicurezza o di notifica degli incidenti, tale regime settoriale si applica al posto delle corrispondenti disposizioni NIS2. Per le entità finanziarie ricomprese, DORA è in genere il regime operativo per la cibersicurezza e la segnalazione degli incidenti ICT. DORA si applica dal 17 gennaio 2025 e copre gestione del rischio ICT, segnalazione degli incidenti, test di resilienza operativa digitale, rischio ICT di terze parti e sorveglianza sui fornitori terzi critici di servizi ICT.

Un gruppo fintech può quindi avere trattamenti di conformità diversi all’interno della stessa struttura societaria. L’entità di pagamento può ricadere principalmente sotto DORA. La controllata MSP può essere direttamente soggetta a NIS2. Una piattaforma cloud condivisa può supportare entrambe. La risposta matura non consiste nel duplicare i controlli. Consiste in un unico modello di evidenze SGSI in grado di servire più prospettive regolatorie.

ISO 27001:2022 come sistema operativo della conformità NIS2

NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi per i sistemi di rete e informativi e per prevenire o ridurre al minimo l’impatto degli incidenti sui destinatari dei servizi e su altri servizi.

ISO 27001:2022 è particolarmente adatta a rendere operativo tale requisito perché impone tre discipline.

Primo, la governance. Le clausole da 5.1 a 5.3 richiedono impegno dell’alta direzione, allineamento alla direzione strategica, risorse, comunicazione, assegnazione delle responsabilità e una politica per la sicurezza delle informazioni documentata. Ciò si allinea direttamente a NIS2 Article 20, che richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione.

Secondo, il trattamento del rischio. Le clausole da 6.1.1 a 6.1.3 richiedono un processo ripetibile di valutazione del rischio, titolari del rischio, valutazione del rischio, opzioni di trattamento, selezione dei controlli, una Dichiarazione di Applicabilità, un Piano di trattamento del rischio e l’approvazione del rischio residuo.

Terzo, il controllo operativo. La clausola 8.1 richiede all’organizzazione di pianificare, attuare e controllare i processi del SGSI, mantenere informazioni documentate, controllare le modifiche e gestire processi, prodotti e servizi forniti dall’esterno rilevanti per il SGSI.

Questo trasforma NIS2 da checklist legale a modello operativo di controllo.

Ogni riga richiede un titolare, una fonte delle registrazioni e un metodo di campionamento. Se questi elementi mancano, l’organizzazione ha un’intenzione di controllo, non un controllo.

Le politiche sono il punto in cui NIS2 diventa comportamento operativo

Le politiche sono spesso trattate come modelli. Per NIS2, questo è pericoloso. Un’autorità di regolamentazione o un auditor non sarà convinto da una cartella di politiche se le politiche non assegnano la titolarità, non definiscono le registrazioni, non si collegano ai rischi e non producono evidenze.

La Politica di conformità legale e normativa enterprise stabilisce il fondamento nella clausola 6.2.1:

Tutti gli obblighi legali e regolamentari devono essere mappati su politiche, controlli e titolari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).

Quella clausola è il ponte tra NIS2 e ISO 27001:2022. NIS2 Article 21 non viene semplicemente elencato come requisito esterno. Viene scomposto in obblighi di policy, mappato sui controlli, assegnato a titolari e verificato tramite evidenze.

Per le organizzazioni più piccole, la Politica di conformità legale e normativa per PMI mantiene lo stesso concetto in forma leggera. La clausola 5.1.1 richiede:

Il Direttore generale (GM) deve mantenere un Registro di conformità semplice e strutturato che elenchi:

La frase è volutamente pratica. Le PMI non hanno bisogno di una complessa implementazione GRC per iniziare. Hanno bisogno di un Registro di conformità che acquisisca obbligo, applicabilità, titolare, politica, evidenza e cadenza di riesame.

Il trattamento del rischio converte quindi l’obbligo in azione. La Politica di gestione del rischio enterprise, clausola 6.4.2, stabilisce:

Il Responsabile del rischio deve assicurare che i trattamenti siano realistici, limitati nel tempo e mappati sui controlli dell’Annex A ISO/IEC 27001.

Per le PMI, la Politica di gestione del rischio - PMI, clausola 5.1.2, fornisce la registrazione minima praticabile del rischio:

Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, titolare e Piano di trattamento del rischio.

Queste clausole sono importanti perché NIS2 è esplicitamente basata sul rischio e proporzionata. Article 21 si aspetta che le misure riflettano lo stato dell’arte, gli standard rilevanti, i costi di attuazione, l’esposizione al rischio, la dimensione, la probabilità e la gravità degli incidenti, compreso l’impatto sociale ed economico. Un registro dei rischi privo di titolari e Piani di trattamento del rischio non può dimostrare la proporzionalità.

La Politica per la sicurezza delle informazioni enterprise completa il principio delle evidenze nella clausola 6.6.1:

Tutti i controlli attuati devono essere verificabili, supportati da procedure documentate ed evidenze operative conservate.

Questa è la differenza tra avere un programma NIS2 e avere un programma NIS2 basato su evidenze.

Il percorso Clarysec dalla mappatura all’operatività

Lo Zenith Blueprint è utile perché riflette il modo di ragionare degli auditor. Non chiedono soltanto se un controllo esiste. Chiedono perché è stato selezionato, dove è documentato, come opera, chi ne è titolare, quali evidenze lo dimostrano e come l’organizzazione lo migliora.

Nella fase di Gestione del rischio, lo Step 13 indica ai team di aggiungere tracciabilità tra rischi, controlli e clausole:

✓ Mappare i controlli sui rischi: nel piano di trattamento del Registro dei rischi sono stati elencati determinati controlli per ciascun rischio. È possibile aggiungere a ogni rischio una colonna “Riferimento al controllo Annex A” ed elencare i numeri dei controlli.

Per NIS2, ciò significa che il registro dei rischi e la Dichiarazione di Applicabilità dovrebbero mostrare perché controlli come 8.8 Gestione delle vulnerabilità tecniche, 5.19 Sicurezza delle informazioni nei rapporti con i fornitori e 5.24 Pianificazione e preparazione della gestione degli incidenti sono applicabili.

Lo Step 14 dello Zenith Blueprint rende esplicita la mappatura normativa:

Per ciascuna regolamentazione, se applicabile, è possibile creare una semplice tabella di mappatura (che può essere un’appendice di un report) che elenchi i principali requisiti di sicurezza della regolamentazione e i corrispondenti controlli/politiche nel proprio SGSI.

Questo evita la frammentazione. La sicurezza dei dati personali GDPR, la segnalazione degli incidenti NIS2, i test di resilienza ICT DORA e gli impegni di sicurezza verso i clienti possono basarsi tutti sulle stesse evidenze: riesami degli accessi, remediation delle vulnerabilità, registrazioni di logging, test di backup, riesami dei fornitori e report sugli incidenti.

Lo Step 19 passa dalla progettazione all’operatività:

Collegare ciascuno di questi documenti al controllo appropriato nella propria SoA o nel manuale SGSI. Questi documenti serviranno come prova dell’attuazione e riferimento interno.

L’insieme documentale dello Step 19 include sicurezza degli endpoint, gestione degli accessi, autenticazione, baseline di configurazione sicura, logging e monitoraggio, gestione delle patch, gestione delle vulnerabilità, pianificazione della capacità e reportistica delle operazioni IT. Sono esattamente i documenti operativi necessari per rendere verificabili le misure tecniche NIS2.

Lo Step 26 spiega come devono essere raccolte le evidenze di audit:

Man mano che si raccolgono evidenze, registrare le risultanze. Annotare dove gli elementi sono conformi al requisito (risultanze positive) e dove non lo sono (potenziali non conformità od osservazioni).

Per NIS2, ciò significa campionare le evidenze prima che le richieda un’autorità di regolamentazione, un valutatore del cliente o un auditor di certificazione.

Il ruolo di conformità trasversale di Zenith Controls

Zenith Controls non è un quadro di controllo separato. È la guida Clarysec alla conformità trasversale per mappare i controlli ISO/IEC 27001:2022 e ISO/IEC 27002:2022 su controlli correlati, aspettative di audit e framework esterni. Aiuta i team a comprendere come un singolo controllo ISO 27001:2022 possa supportare NIS2, DORA, GDPR, NIST CSF 2.0 e assurance in stile COBIT.

Tre controlli ISO 27001:2022 sono particolarmente importanti per la mappatura delle evidenze NIS2.

Il controllo 5.1 Politiche per la sicurezza delle informazioni è il punto di ingresso perché NIS2 Article 21 include analisi dei rischi e politiche di sicurezza dei sistemi informativi. Se una misura tecnica NIS2 non è riflessa in una politica, è difficile governarla e auditarla in modo coerente.

Il controllo 5.36 Conformità a politiche, regole e standard per la sicurezza delle informazioni è la verifica di realtà. Collega i requisiti delle politiche alla conformità effettiva a regole interne, standard e obblighi esterni. In termini NIS2, questo è il punto in cui un’organizzazione si chiede se sta facendo ciò che la sua mappatura di Article 21 dichiara.

Il controllo 8.8 Gestione delle vulnerabilità tecniche è una delle aree di test più difficili del 2026. La gestione delle vulnerabilità è direttamente rilevante per acquisizione sicura, sviluppo, manutenzione, trattamento e divulgazione delle vulnerabilità. Supporta inoltre i test e la remediation DORA, la responsabilizzazione dimostrabile della sicurezza secondo GDPR, gli esiti Identify e Protect del NIST CSF e il campionamento di audit ISO 27001.

Gli standard di supporto possono affinare il disegno senza richiedere certificazioni aggiuntive. ISO/IEC 27002:2022 fornisce linee guida di attuazione per i controlli dell’Annex A. ISO/IEC 27005 supporta la gestione dei rischi per la sicurezza delle informazioni. ISO/IEC 27017 supporta la sicurezza cloud. ISO/IEC 27018 supporta la protezione dei dati personali identificabili in scenari di responsabile del trattamento nel cloud pubblico. ISO 22301 supporta la continuità operativa. ISO/IEC 27035 supporta la gestione degli incidenti. ISO/IEC 27036 supporta la sicurezza nei rapporti con i fornitori.

L’obiettivo non è aumentare gli standard per il loro solo valore formale. L’obiettivo è progettare evidenze migliori.

Esempio operativo: costruire un pacchetto di evidenze NIS2 sulle vulnerabilità

Consideriamo la piattaforma SaaS di Maria. Serve clienti manifatturieri dell’UE e dipende da servizi cloud, componenti open source, pipeline CI/CD e monitoraggio gestito. Il suo report sulle lacune dichiara “gestione delle vulnerabilità implementata”, ma le evidenze sono disperse tra scanner, Jira, GitHub, strumenti di configurazione cloud e ticket di modifica.

Un pacchetto di evidenze pronto per NIS2 può essere costruito in uno sprint mirato.

Step 1: Definire lo scenario di rischio

Rischio: una vulnerabilità sfruttabile in un’applicazione esposta a Internet, in una dipendenza o in un componente cloud causa interruzione del servizio, accesso non autorizzato o esposizione dei dati dei clienti.

Il registro dei rischi dovrebbe includere descrizione, probabilità, impatto, punteggio, titolare e Piano di trattamento del rischio. Il Piano di trattamento del rischio dovrebbe fare riferimento al controllo ISO 27001:2022 8.8 Gestione delle vulnerabilità tecniche, oltre ai controlli correlati per inventario degli asset, sviluppo sicuro, logging, controllo degli accessi, gestione dei fornitori e risposta agli incidenti.

Step 2: Mappare il rischio su NIS2 Article 21

Il rischio supporta i requisiti di Article 21 relativi ad acquisizione, sviluppo e manutenzione sicuri, trattamento e divulgazione delle vulnerabilità, analisi dei rischi, gestione degli incidenti, sicurezza della catena di fornitura e valutazione dell’efficacia dei controlli.

Step 3: Ancorare le regole operative nella politica

Utilizzare una procedura di gestione delle vulnerabilità, uno standard di sviluppo sicuro, requisiti di gestione delle patch, una politica di Test di sicurezza e regole sulle evidenze di audit.

La Politica di Test di sicurezza e red teaming enterprise, clausola 6.1, stabilisce:

Tipologie di test: il programma di Test di sicurezza deve includere, come minimo: (a) scansione delle vulnerabilità, consistente in scansioni automatizzate settimanali o mensili di reti e applicazioni per identificare vulnerabilità note; (b) test di penetrazione, consistenti in test manuali approfonditi di specifici sistemi o applicazioni svolti da tester qualificati per identificare debolezze complesse; e (c) esercitazioni red team, consistenti in simulazioni basate su scenari di attacchi reali, inclusi ingegneria sociale e altre tattiche, per testare nel complesso le capacità di rilevazione e risposta dell’organizzazione.

Quella clausola crea una baseline di test difendibile. Si allinea inoltre all’aspettativa DORA di test ricorrenti e basati sul rischio della resilienza operativa digitale per le entità finanziarie ricomprese.

Step 4: Definire i metadati delle evidenze

La Politica di audit e monitoraggio della conformità - PMI, clausola 6.2.3, stabilisce:

I metadati (ad es. chi li ha raccolti, quando e da quale sistema) devono essere documentati.

Per le evidenze sulle vulnerabilità, il pacchetto dovrebbe acquisire:

• Nome e configurazione dello scanner
• Data e ora della scansione
• Ambito degli asset ed esclusioni
• Risultanze critiche e alte
• Numero di ticket e titolare
• Decisione di applicazione della patch o mitigazione
• Decisione di accettazione del rischio, ove applicabile
• Data di remediation
• Scansione di convalida
• Collegamento alla registrazione della modifica
• Titolare dell’eccezione e data di scadenza

Step 5: Aggiungere evidenze di logging

La Politica di logging e monitoraggio - PMI, clausola 5.4.4, include log di sistema quali:

Log di sistema: modifiche di configurazione, azioni amministrative, installazioni software, attività di patching

Un ticket di patch da solo potrebbe non dimostrare che la modifica sia avvenuta. I log di configurazione, le azioni amministrative e le registrazioni di installazione del software rafforzano la catena delle evidenze.

Step 6: Eseguire un audit a campione

Selezionare cinque vulnerabilità critiche o alte del trimestre precedente. Per ciascun elemento, verificare che l’asset fosse presente nell’inventario, che lo scanner abbia rilevato la risultanza, che un ticket sia stato aperto entro lo SLA, che sia stato assegnato un titolare, che la remediation fosse coerente con gravità e sfruttabilità, che i log mostrino la modifica, che la convalida confermi la chiusura e che qualsiasi eccezione abbia l’approvazione del titolare del rischio con una data di scadenza.

Quello sprint produce un pacchetto di evidenze sulle vulnerabilità pronto per NIS2 e un campione di audit interno ISO 27001:2022.

La sicurezza dei fornitori è governance dell’ecosistema

NIS2 Article 21 richiede sicurezza della catena di fornitura, compresi gli aspetti di sicurezza relativi ai rapporti con fornitori diretti e prestatori di servizi. Si aspetta inoltre che le organizzazioni considerino vulnerabilità dei fornitori, qualità dei prodotti, pratiche di cibersicurezza dei fornitori e pratiche di sviluppo sicuro.

È qui che la prima versione del report sulle lacune di Maria era più debole. Elencava i fornitori, ma non dimostrava due diligence, clausole contrattuali di sicurezza, monitoraggio o preparazione all’uscita.

La Politica di sicurezza delle terze parti e dei fornitori fornisce l’ancoraggio di policy. L’attuazione correlata può essere supportata dalla Politica di sviluppo sicuro, dalla Politica di consapevolezza e formazione sulla sicurezza delle informazioni, dalla Politica di gestione delle vulnerabilità e delle patch, dalla Politica sui controlli crittografici, dalla Politica di controllo degli accessi e dalla Politica di lavoro da remoto.

Un singolo registro delle evidenze dei fornitori può supportare NIS2, DORA e ISO 27001:2022.

Questa tabella evita questionari duplicati, registri duplicati e titolarità dei controlli contraddittorie.

Un unico flusso di gestione degli incidenti per NIS2, DORA e GDPR

NIS2 Article 23 richiede che gli incidenti significativi siano notificati senza indebito ritardo. Stabilisce una sequenza temporale a fasi: allerta precoce entro 24 ore dalla consapevolezza, notifica dell’incidente entro 72 ore con valutazione iniziale di gravità o impatto e indicatori di compromissione disponibili, aggiornamenti intermedi se richiesti e un rapporto finale non oltre un mese dalla notifica dell’incidente.

DORA ha un ciclo di vita simile per le entità finanziarie: rilevazione, classificazione, registrazione, valutazione della gravità, escalation, comunicazione ai clienti, segnalazione all’autorità, analisi della causa radice e remediation. GDPR aggiunge l’analisi della violazione dei dati personali, inclusi ruoli di titolare e responsabile del trattamento, impatto sugli interessati e termine di notifica di 72 ore ove applicabile.

Il disegno corretto non prevede tre processi di gestione degli incidenti. Prevede un unico flusso di gestione degli incidenti con diramazioni decisionali regolatorie.

La Politica di risposta agli incidenti - PMI, clausola 5.4.1, stabilisce:

Tutte le indagini sugli incidenti, le risultanze e le azioni correttive devono essere registrate in un registro degli incidenti mantenuto dal Direttore generale.

Un registro degli incidenti robusto dovrebbe includere:

Il collegamento con GDPR non deve essere sottovalutato. Le autorità competenti NIS2 possono informare le autorità di controllo GDPR quando carenze nella gestione dei rischi di cibersicurezza o nella segnalazione possono comportare una violazione dei dati personali. Il SGSI dovrebbe quindi rendere la valutazione privacy parte del triage degli incidenti, non un ripensamento successivo.

Come auditor e autorità testeranno le evidenze NIS2

Un’organizzazione pronta per il 2026 dovrebbe aspettarsi che lo stesso controllo sia testato attraverso prospettive diverse.

Un auditor ISO 27001:2022 partirà dal SGSI. Chiederà se gli obblighi NIS2 sono identificati come requisiti delle parti interessate, se l’ambito di applicazione del SGSI copre servizi e dipendenze rilevanti, se i rischi sono valutati e trattati, se la Dichiarazione di Applicabilità giustifica i controlli applicabili e se le registrazioni provano l’operatività.

Un’autorità competente NIS2 si concentrerà sugli esiti legali. Potrebbe chiedere se tutte le misure di Article 21 sono coperte, se i controlli sono adeguati e proporzionati, se la direzione ha approvato e supervisiona le misure e se la segnalazione degli incidenti può rispettare le tempistiche richieste.

Un supervisore DORA, per le entità finanziarie ricomprese, testerà gestione del rischio ICT, classificazione degli incidenti, test di resilienza, rischio di terze parti, accordi contrattuali, rischio di concentrazione e strategie di uscita.

Un revisore GDPR testerà se le misure tecniche e organizzative proteggono i dati personali, se la valutazione delle violazioni è incorporata nella gestione dell’incidente, se i ruoli di titolare e responsabile del trattamento sono chiari e se esistono registrazioni di accountability.

Un valutatore in stile NIST CSF 2.0 o COBIT 2019 si concentrerà su governance, titolarità del rischio, metriche di prestazione, esiti attuali e target, capacità di processo e allineamento con la propensione al rischio aziendale.

La Politica di audit e monitoraggio della conformità enterprise, clausola 3.4, descrive la finalità delle evidenze:

Generare evidenze difendibili e una pista di audit a supporto di richieste delle autorità di regolamentazione, procedimenti legali o richieste di assurance dei clienti.

Questo è lo standard operativo verso cui i team NIS2 dovrebbero costruire.

Responsabilità della direzione: il Consiglio di amministrazione non può delegare NIS2 e considerarla risolta

NIS2 Article 20 richiede agli organi di gestione delle entità essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. I membri degli organi di gestione possono essere ritenuti responsabili delle violazioni, fatte salve le norme nazionali sulla responsabilità.

Ciò si allinea ai requisiti di leadership di ISO 27001:2022. L’alta direzione deve assicurare che la politica e gli obiettivi per la sicurezza delle informazioni siano allineati alla direzione strategica, integrare i requisiti del SGSI nei processi aziendali, fornire risorse, comunicare l’importanza, assegnare responsabilità e promuovere il miglioramento continuo.

Un Consiglio di amministrazione non ha bisogno di esportazioni grezze degli scanner o di log SIEM completi. Ha bisogno di assurance utilizzabile per decidere.

Un pacchetto trimestrale di evidenze NIS2 per il Consiglio di amministrazione dovrebbe includere:

1. Variazioni dell’ambito di applicazione e dello stato regolatorio
2. Principali rischi NIS2 e stato del trattamento
3. Dashboard dell’efficacia dei controlli di Article 21
4. Incidenti significativi, quasi incidenti e decisioni di segnalazione
5. Eccezioni di rischio relative a fornitori e cloud
6. Risultanze dell’audit interno, azioni correttive ed evidenze scadute

Questo pacchetto fornisce alla direzione le informazioni necessarie per approvare le misure, contestare le eccezioni e accettare il rischio residuo.

Il modello operativo Clarysec per il 2026

Rendere operative le misure tecniche NIS2 con ISO 27001:2022 richiede un modello semplice ma disciplinato:

• Includere obblighi NIS2, DORA, GDPR e contrattuali all’interno del SGSI
• Mappare gli obblighi su rischi, politiche, controlli, titolari ed evidenze
• Utilizzare la Dichiarazione di Applicabilità come fonte di verità dei controlli
• Costruire pacchetti di evidenze per le aree ad alto rischio di Article 21
• Integrare la segnalazione degli incidenti in un unico flusso regolatorio
• Trattare la sicurezza dei fornitori come un ciclo di vita, non come un questionario
• Eseguire audit interni utilizzando campioni reali
• Rendicontare l’efficacia dei controlli agli organi di gestione
• Migliorare sulla base di incidenti, risultanze dell’audit, test e modifiche normative

Per Maria, il punto di svolta è stato comprendere che non aveva bisogno di un progetto NIS2 separato. Aveva bisogno di un motore di evidenze SGSI più solido.

Le politiche Clarysec, Zenith Blueprint e Zenith Controls sono progettati per lavorare insieme. Le politiche definiscono comportamento atteso e registrazioni. Lo Zenith Blueprint fornisce il percorso di attuazione e audit in 30 passaggi. Zenith Controls offre la mappatura di conformità trasversale, affinché NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF e assurance in stile COBIT possano essere gestiti come un programma coerente.

Prossimo passo: costruire la mappa delle evidenze da NIS2 a ISO 27001:2022

Se il lavoro NIS2 vive ancora in un foglio di calcolo delle lacune, il 2026 è l’anno per renderlo operativo.

Iniziare con una misura tecnica ad alto rischio, come gestione delle vulnerabilità, gestione degli incidenti o sicurezza dei fornitori. Mapparla su rischi ISO 27001:2022, politiche, controlli dell’Annex A, titolari, procedure ed evidenze. Quindi campionare le registrazioni dell’ultimo trimestre e porsi una domanda difficile: soddisferebbe un’autorità di regolamentazione, un valutatore del cliente e un auditor ISO 27001:2022?

Clarysec può aiutare a costruire questa risposta utilizzando la libreria di politiche, Zenith Blueprint e Zenith Controls.

L’obiettivo non è produrre più documentazione. L’obiettivo è disporre di evidenze difendibili e ripetibili che dimostrino che le misure tecniche NIS2 funzionano davvero.