Responsabilità del Consiglio di amministrazione ai sensi di NIS2: evidenze ISO 27001

L’e-mail arrivò nella casella di Maria alle 08:15 di un lunedì mattina. Come CISO di un fornitore europeo di servizi cloud in forte crescita, era abituata ai messaggi urgenti, ma questo era diverso.
Il CFO aveva inoltrato un questionario di sicurezza di un cliente al CEO, al segretario del Consiglio e a Maria. L’oggetto era breve: “Evidenze richieste sulla responsabilità dell’organo di gestione NIS2 prima del rinnovo”.
Il cliente non chiedeva un ulteriore rapporto di penetration test. Voleva sapere se il Consiglio avesse approvato le misure di gestione dei rischi di cibersicurezza, come ne fosse vigilata l’attuazione, se i dirigenti avessero ricevuto formazione sul rischio cyber, come venissero escalati gli incidenti significativi e come i rischi dei fornitori fossero riesaminati a livello direzionale. Il CEO aggiunse una sola riga: “Maria, qual è la nostra esposizione e come dimostriamo la dovuta diligenza? Al Consiglio serve entro la prossima settimana.”
È il momento in cui NIS2 diventa concreta per molti fornitori SaaS, cloud, MSP, MSSP, data center, fintech e infrastrutture digitali. La Direttiva (UE) 2022/2555 non tratta la cibersicurezza come un problema del dipartimento tecnico. Trasforma il rischio cyber in una responsabilità dell’organo di gestione.
NIS2 Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, vigilare sulla loro attuazione e seguire una formazione. Consente inoltre agli Stati membri di stabilire responsabilità per le violazioni. Article 21 definisce poi la baseline operativa: analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, valutazione dell’efficacia, igiene cyber, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione.
Per le organizzazioni che già utilizzano ISO/IEC 27001:2022, la struttura è familiare. Cambiano il pubblico e l’onere probatorio. La domanda non è più soltanto: “Abbiamo controlli di sicurezza?” Diventa: “Il Consiglio può dimostrare di aver approvato, compreso, finanziato, riesaminato, messo in discussione e migliorato quei controlli?”
È qui che ISO/IEC 27001:2022 diventa un sistema di governance difendibile. L’approccio di Clarysec consiste nell’utilizzare ISO/IEC 27001:2022 come dorsale delle evidenze, Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint come percorso di attuazione, le politiche Clarysec come artefatti pronti per il Consiglio e Zenith Controls: The Cross-Compliance Guide Zenith Controls come guida di mappatura trasversale tra framework per NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 e aspettative di audit.
Perché la responsabilità del Consiglio ai sensi di NIS2 cambia il dialogo sulla cibersicurezza
NIS2 non chiede agli amministratori di diventare ingegneri di firewall. Chiede loro di governare. La distinzione è sostanziale.
Un CISO può mostrare report sulle vulnerabilità, copertura MFA, cruscotti di protezione degli endpoint e punteggi del livello di sicurezza cloud. Sono segnali operativi utili, ma non dimostrano automaticamente la vigilanza dell’organo di gestione. Un’autorità di regolamentazione, un cliente enterprise, un auditor di certificazione o un valutatore del settore finanziario cercherà una catena di evidenze di governance:
- L’organizzazione ha valutato se NIS2 si applica e ne ha documentato la base.
- Il Consiglio o l’alta direzione ha approvato il quadro per la gestione del rischio di cibersicurezza.
- Sono state definite la propensione al rischio e le soglie di tolleranza.
- I rischi cyber elevati sono stati sottoposti a escalation e riesaminati.
- Le decisioni di trattamento del rischio sono state approvate, incluso il rischio residuo accettato.
- Le procedure di segnalazione degli incidenti riflettono, ove applicabile, gli obblighi di preallarme a 24 ore, notifica a 72 ore e rapporto finale.
- Le dipendenze da fornitori e cloud sono mappate e governate.
- Il riesame della direzione include risultanze dell’audit, tendenze degli incidenti, metriche e azioni di miglioramento.
- I dirigenti hanno ricevuto una formazione adeguata alla loro responsabilità.
- Decisioni, eccezioni ed escalation sono tracciabili.
È qui che molti vecchi playbook di sicurezza falliscono. Acquistare uno strumento “conforme a NIS2” non dimostra la vigilanza del Consiglio. Firmare una politica e archiviarla non dimostra l’attuazione. Delegare integralmente la cibersicurezza al CISO non soddisfa il dovere di vigilanza di un organo di gestione.
ISO/IEC 27001:2022 risolve questo problema perché inquadra la sicurezza delle informazioni come un sistema di gestione strategico e basato sul rischio, integrato nei processi dell’organizzazione. Le sue clausole su contesto, parti interessate, obblighi legali, ambito di applicazione, leadership, valutazione del rischio, trattamento del rischio, controllo operativo, valutazione delle prestazioni, audit interno, riesame della direzione e miglioramento continuo creano la struttura necessaria al Consiglio per dimostrare la dovuta diligenza.
Il Zenith Blueprint rende tutto questo operativo nella fase Fondazione e leadership del SGSI, Step 3:
“La Clause 5.1 riguarda leadership e impegno. ISO 27001 richiede che l’alta direzione dimostri leadership approvando il SGSI, fornendo risorse, promuovendo la sensibilizzazione, assicurando l’assegnazione dei ruoli, integrando il SGSI nei processi aziendali e sostenendo il miglioramento continuo.”
Questo è il modello operativo alla base di NIS2 Article 20. Il Consiglio non deve approvare ogni ticket tecnico, ma deve approvare il modello di governance, comprendere i rischi significativi, garantire le risorse e vigilare sull’attuazione.
Il pacchetto di evidenze del Consiglio realmente richiesto da NIS2
Un errore comune consiste nel trattare le evidenze NIS2 come un parere legale più una cartella di politiche. Raramente basta a soddisfare un valutatore rigoroso. La responsabilità del Consiglio richiede prova di governance attiva, non documentazione passiva.
Un solido pacchetto di evidenze NIS2 per il Consiglio dovrebbe collegare gli obblighi legali alle decisioni del Consiglio, ai controlli e ai cicli di riesame.
| Evidenza | Domanda sulla responsabilità del Consiglio a cui risponde | Riferimento ISO/IEC 27001:2022 | Fonte Clarysec |
|---|---|---|---|
| Valutazione di applicabilità NIS2 | Siamo essenziali, importanti, indirettamente esposti o fuori ambito? | Clauses 4.1 to 4.4 | Zenith Blueprint, Step 1 and Step 2 |
| Campo di applicazione del SGSI e mappa delle dipendenze | Quali servizi, sedi, fornitori, interfacce e processi sono governati? | Clauses 4.1 to 4.4 | Zenith Blueprint, fase Fondazione del SGSI |
| Registro dei rischi cyber | Quali sono i nostri principali rischi cyber e chi ne è titolare? | Clauses 6.1.1 and 6.1.2 | Politica di gestione del rischio |
| Piano di trattamento del rischio e SoA | Quali controlli sono selezionati, perché e chi ha approvato il rischio residuo? | Clause 6.1.3 | Zenith Blueprint, Step 13 |
| Verbali del Consiglio e registro delle decisioni | La direzione ha approvato, messo in discussione e vigilato sulle misure? | Clauses 5.1, 5.3, 9.3 | Politica sui ruoli e sulle responsabilità di governance |
| Procedura di escalation e segnalazione degli incidenti | Possiamo rispettare le tempistiche di segnalazione a fasi previste da NIS2? | Clauses 8.1, 9.1, controlli sugli incidenti dell’Annex A | Toolkit di risposta agli incidenti e riesame della direzione |
| Cruscotto dei rischi dei fornitori | I fornitori critici e le dipendenze cloud sono governati? | Clause 8.1 e controlli sui fornitori dell’Annex A | Mappatura trasversale di Zenith Controls |
| Registrazioni della formazione dei dirigenti | I membri dell’organo di gestione hanno seguito una formazione appropriata? | Clause 7.2 e controlli di sensibilizzazione | Politica di consapevolezza e formazione sulla sicurezza delle informazioni |
| Output di audit interno e riesame della direzione | L’attuazione è verificata in modo indipendente e migliorata? | Clauses 9.2, 9.3, 10.1 | Politica di audit e monitoraggio della conformità - PMI |
La forza di questo pacchetto è la tracciabilità. Ogni evidenza risponde a una domanda di governance e rimanda a un meccanismo ISO/IEC 27001:2022. Questo offre a CISO, CEO e Consiglio una narrazione difendibile: la cibersicurezza non è una raccolta di strumenti, è un sistema governato.
Trasformare le politiche in responsabilità a livello di Consiglio
Nello scenario iniziale, il CEO di Maria potrebbe essere tentato di rispondere al cliente con un certificato ISO e alcune politiche. Non è sufficiente per la responsabilità dell’organo di gestione ai sensi di NIS2. L’organizzazione ha bisogno di evidenze che la responsabilità sia assegnata, le decisioni siano registrate e i rischi siano sottoposti a escalation in modo oggettivo.
Le politiche Clarysec sono progettate per creare questa tracciabilità.
Per le organizzazioni più piccole, Politica per la sicurezza delle informazioni - PMI Politica per la sicurezza delle informazioni - PMI, clause 4.1.1, afferma che l’alta direzione:
“Mantiene la responsabilità complessiva per la sicurezza delle informazioni.”
Questa frase è importante. Previene un anti-pattern frequente, in cui fondatori, CEO o team esecutivi delegano informalmente tutta la responsabilità della sicurezza all’IT senza mantenere una vigilanza significativa.
Per le organizzazioni più grandi, Politica di gestione del rischio Politica di gestione del rischio, clause 4.1.1, afferma che la leadership:
“Approva il quadro per la gestione del rischio e definisce la propensione al rischio accettabile e le soglie di tolleranza.”
Questa è un’evidenza pronta per il Consiglio ai fini di NIS2 Article 20. Una dichiarazione di propensione al rischio, soglie di tolleranza e un modello formale di deleghe di rischio mostrano come approvazione ed escalation funzionano nella pratica.
La clause 5.6 della stessa politica aggiunge:
“La Matrice delle deleghe di rischio deve definire chiaramente le soglie di escalation verso l’alta direzione o il Consiglio.”
È uno degli artefatti più importanti per la governance NIS2. Senza soglie di escalation, il Consiglio vede solo ciò che qualcuno decide di portare alla sua attenzione. Con le soglie, rischio residuo elevato, vulnerabilità critiche non risolte, concentrazione significativa dei fornitori, incidenti rilevanti, risultanze dell’audit ed eccezioni oltre la tolleranza entrano automaticamente nella vigilanza esecutiva.
La Politica sui ruoli e sulle responsabilità di governance Politica sui ruoli e sulle responsabilità di governance rafforza la catena delle evidenze:
“La governance deve supportare l’integrazione con altre discipline (ad es. rischio, legale, IT, HR) e le decisioni del SGSI devono essere tracciabili fino alla loro fonte (ad es. registrazioni di audit, log di riesame, verbali di riunione).”
Per le PMI, Politica sui ruoli e sulle responsabilità di governance - PMI Politica sui ruoli e sulle responsabilità di governance - PMI afferma:
“Tutte le decisioni di sicurezza significative, le eccezioni e le escalation devono essere registrate e tracciabili.”
Queste clausole trasformano la vigilanza del Consiglio da conversazione a traccia di audit.
La catena di evidenze ISO/IEC 27001:2022 per NIS2 Article 20
Un Consiglio può rendere operativo NIS2 Article 20 tramite una chiara catena di evidenze ISO/IEC 27001:2022.
Primo, stabilire contesto e ambito di applicazione. ISO/IEC 27001:2022 richiede all’organizzazione di determinare fattori interni ed esterni, parti interessate, requisiti legali, normativi e contrattuali, confini del SGSI, interfacce, dipendenze e processi interagenti. Per un fornitore SaaS o cloud, il campo di applicazione del SGSI dovrebbe identificare esplicitamente servizi UE, ambienti cloud, operazioni di supporto, fornitori critici, segmenti di clienti regolamentati ed esposizione NIS2.
Secondo, dimostrare leadership. ISO/IEC 27001:2022 richiede all’alta direzione di allineare gli obiettivi di sicurezza alla direzione strategica, integrare i requisiti del SGSI nei processi aziendali, fornire risorse, comunicarne l’importanza, assegnare responsabilità e promuovere il miglioramento continuo. Per NIS2, ciò diventa evidenza che l’organo di gestione ha approvato e vigilato sulle misure di gestione dei rischi di cibersicurezza.
Terzo, eseguire una valutazione e un trattamento del rischio ripetibili. ISO/IEC 27001:2022 richiede criteri di rischio, identificazione del rischio, titolari del rischio, analisi di probabilità e conseguenze, opzioni di trattamento, selezione dei controlli, confronto con l’Annex A, una Dichiarazione di Applicabilità, un Piano di trattamento del rischio e l’approvazione del rischio residuo.
Il Zenith Blueprint, fase Gestione del rischio, Step 13, esplicita il punto di approvazione:
“Approvazione della direzione: le decisioni di trattamento del rischio e la SoA dovrebbero essere riesaminate e approvate dall’alta direzione. La direzione dovrebbe ricevere un briefing sui rischi principali e sui trattamenti proposti, sui rischi proposti per l’accettazione e sui controlli pianificati per l’attuazione.”
Per NIS2, questo briefing non dovrebbe essere una tantum. Il pacchetto per il Consiglio dovrebbe mostrare principali rischi correnti, andamento, avanzamento del trattamento, rischio residuo accettato, azioni scadute, esposizione a fornitori critici, temi ricorrenti degli incidenti e principali metriche di efficacia.
Quarto, operare e conservare le evidenze. ISO/IEC 27001:2022 clause 8.1 richiede pianificazione operativa e controllo. I controlli dell’Annex A supportano sicurezza dei fornitori, governance cloud, risposta agli incidenti, continuità operativa, gestione delle vulnerabilità, backup, registrazione, monitoraggio, sviluppo sicuro, sicurezza delle applicazioni, architettura, test, outsourcing, segregazione e gestione delle modifiche.
Quinto, valutare e migliorare. Audit interno, misurazione, riesame della direzione, azione correttiva e miglioramento continuo trasformano un catalogo di controlli in un sistema governato.
La Politica per la sicurezza delle informazioni aziendale Politica per la sicurezza delle informazioni incorpora questa aspettativa di riesame della direzione:
“Le attività di riesame della direzione (ai sensi di ISO/IEC 27001 Clause 9.3) devono essere condotte almeno annualmente e devono includere:”
Il valore non sta solo nello svolgimento della riunione. Il valore sta nel fatto che il riesame crea evidenze: input, decisioni, azioni, responsabili, scadenze e follow-up.
La Politica di audit e monitoraggio della conformità - PMI Politica di audit e monitoraggio della conformità - PMI, clause 5.4.3, chiude il ciclo:
“Le risultanze dell’audit e gli aggiornamenti di stato devono essere inclusi nel processo di riesame della direzione del SGSI.”
Questa è la differenza tra “abbiamo svolto un audit” e “la direzione ha riesaminato i risultati dell’audit e indirizzato le azioni correttive”.
Mappatura trasversale della conformità: NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019
NIS2 raramente arriva da sola. Un fornitore cloud può trattare dati personali ai sensi del GDPR. Un cliente fintech può imporre requisiti dei fornitori derivanti da DORA. Un cliente enterprise statunitense può richiedere l’allineamento a NIST CSF 2.0. Un comitato di audit del Consiglio può utilizzare il linguaggio di COBIT 2019.
La risposta non è creare cartelle di conformità separate. La risposta è usare ISO/IEC 27001:2022 come sistema centrale delle evidenze.
Zenith Controls aiuta i team a consolidare la conformità mappando il controllo ISO/IEC 27002:2022 5.4, Responsabilità della direzione, tra standard, regolamenti e metodi di audit.
In Zenith Controls, la voce relativa al controllo ISO/IEC 27002:2022 5.4 “Responsabilità della direzione” classifica il tipo di controllo come “Preventivo”, lo collega a riservatezza, integrità e disponibilità e lo colloca sotto una capacità operativa focalizzata sulla governance.
Questo è importante perché NIS2 Article 20 è governance preventiva. L’approvazione e la vigilanza della leadership riducono la probabilità che il rischio cyber diventi invisibile, sottofinanziato o non gestito.
Zenith Controls collega inoltre le responsabilità della direzione ai controlli ISO/IEC 27002:2022 correlati: 5.1 Politiche per la sicurezza delle informazioni, 5.2 Ruoli e responsabilità per la sicurezza delle informazioni, 5.35 Riesame indipendente della sicurezza delle informazioni, 5.36 Conformità a politiche, regole e standard per la sicurezza delle informazioni e 5.8 Sicurezza nella gestione dei progetti. La responsabilità del Consiglio non può reggersi da sola. Ha bisogno di politiche, ruoli, assurance, monitoraggio della conformità e integrazione a livello di progetto.
La mappatura più ampia è particolarmente utile per la reportistica esecutiva.
| Tema del requisito | NIS2 | DORA | GDPR | NIST CSF 2.0 | COBIT 2019 | Focus delle evidenze Clarysec |
|---|---|---|---|---|---|---|
| Responsabilità della direzione | Article 20 approvazione, vigilanza, formazione, responsabilità | Articles 5 and 6 responsabilità dell’organo di gestione e quadro di gestione dei rischi ICT | Article 5(2) responsabilizzazione e Article 24 responsabilità | GOVERN, in particolare GV.RR, GV.RM e GV.OV | EDM03 ottimizzazione del rischio | Verbali del Consiglio, mandati di ruolo, registrazioni della formazione |
| Misure di gestione del rischio | Article 21 misure tecniche, operative e organizzative | Quadro di gestione dei rischi ICT | Article 32 sicurezza del trattamento | GOVERN, IDENTIFY, PROTECT | APO13 sicurezza gestita | Registro dei rischi, piano di trattamento, SoA |
| Segnalazione degli incidenti | Article 23 preallarme, notifica dell’incidente, rapporto finale | Articles 17 to 20 segnalazione degli incidenti rilevanti connessi all’ICT | Articles 33 and 34 notifica di violazione dei dati personali ove applicabile | RESPOND e RECOVER | DSS02 richieste di servizio e incidenti gestiti | Matrice di escalation, playbook, simulazioni |
| Governance dei fornitori | Article 21(2)(d) sicurezza della catena di fornitura | Articles 28 to 30 rischio ICT di terze parti | Obblighi del responsabile del trattamento e di sicurezza | GV.SC gestione del rischio di cibersicurezza della catena di fornitura | APO10 fornitori gestiti | Registro dei fornitori, due diligence, controlli contrattuali |
| Efficacia e assurance | Article 21(2)(f) politiche e procedure per valutare l’efficacia | Article 6 riesame del quadro di gestione dei rischi ICT e aspettative di audit | Article 32(1)(d) test e valutazione periodici | GV.OV vigilanza, ID.RA valutazione del rischio, DE.CM monitoraggio continuo | MEA01 e MEA03 monitoraggio e conformità | Audit interno, riesame della direzione, azioni correttive |
DORA merita particolare attenzione. NIS2 Article 4 riconosce che atti giuridici settoriali dell’UE possono prevalere su disposizioni NIS2 sovrapposte quando si applicano misure equivalenti di gestione dei rischi di cibersicurezza o di notifica degli incidenti. DORA è l’esempio principale per le entità finanziarie. Si applica dal 17 gennaio 2025 e crea per i servizi finanziari un quadro uniforme di gestione dei rischi ICT, segnalazione degli incidenti, test di resilienza, gestione del rischio di terze parti e vigilanza.
Un fornitore SaaS o cloud potrebbe non essere regolamentato direttamente come una banca, ma DORA può comunque arrivare tramite i contratti dei clienti. Le entità finanziarie devono gestire il rischio ICT di terze parti, mantenere registri dei contratti di servizi ICT, svolgere due diligence, valutare il rischio di concentrazione, includere diritti di audit e ispezione, definire diritti di risoluzione e mantenere strategie di uscita. Ciò significa che i fornitori che servono clienti finanziari dovrebbero aspettarsi richieste di evidenze molto simili alle domande NIS2 sulla governance del Consiglio.
Il GDPR aggiunge la responsabilizzazione per i dati personali. Article 5(2) richiede ai titolari del trattamento di essere responsabili della conformità e in grado di dimostrarla. Article 32 richiede la sicurezza del trattamento, inclusi test, verifica e valutazione periodici dell’efficacia delle misure tecniche e organizzative. Quando sono interessati dati personali, i flussi di lavoro sugli incidenti devono integrare la valutazione della violazione ai fini GDPR con l’escalation degli incidenti significativi NIS2.
NIST CSF 2.0 aggiunge un linguaggio accessibile ai dirigenti tramite la funzione GOVERN. Enfatizza contesto organizzativo, strategia di gestione del rischio, ruoli e responsabilità, politica, vigilanza e gestione del rischio della catena di fornitura. COBIT 2019 aggiunge un vocabolario di governance familiare ai comitati di audit, in particolare tramite EDM03 per l’ottimizzazione del rischio e gli obiettivi MEA per monitoraggio e assurance.
Sprint di 90 giorni per le evidenze NIS2 del Consiglio
Uno sprint pratico sulle evidenze può aiutare le organizzazioni a procedere rapidamente senza creare una burocrazia parallela.
Giorni 1-30: stabilire la responsabilità
Iniziare con un registro delle responsabilità NIS2 che riporti:
- Analisi di classificazione del soggetto, inclusa la motivazione per essenziale, importante, esposizione indiretta o fuori ambito.
- Servizi nel campo di applicazione, come SaaS, cloud, servizi gestiti, data center, DNS, servizi fiduciari o servizi connessi alle comunicazioni.
- Stati membri dell’UE in cui i servizi sono erogati.
- Settori dei clienti interessati, in particolare servizi finanziari, sanità, trasporti, energia, pubblica amministrazione e infrastrutture digitali.
- Obblighi applicabili, inclusi NIS2 Article 20, Article 21 e Article 23.
- Obblighi correlati derivanti da DORA, GDPR, contratti con i clienti e assicurazione cyber.
- Titolare gestionale e frequenza di reportistica al Consiglio.
Collegare questo registro al contesto ISO/IEC 27001:2022, alle parti interessate, al Registro di conformità e al campo di applicazione del SGSI. Aggiornare quindi la Matrice delle deleghe di rischio usando il requisito della Politica di gestione del rischio secondo cui le soglie di escalation devono essere definite per l’alta direzione o il Consiglio.
Criteri di attivazione dell’escalation utili includono rischio residuo oltre la propensione al rischio, vulnerabilità critiche non accettate oltre gli SLA, rischio di concentrazione dei fornitori, risultanze dell’audit elevate non risolte, incidenti che possono attivare la segnalazione NIS2, eccezioni ai requisiti di MFA, backup, registrazione, cifratura o risposta agli incidenti e modifiche significative dell’architettura cloud.
Giorni 31-60: approvare il trattamento del rischio
Usare Zenith Blueprint Step 13 per preparare un pacchetto decisionale del Consiglio relativo al Piano di trattamento del rischio e alla Dichiarazione di Applicabilità. Il pacchetto dovrebbe includere:
- I 10 principali rischi cyber.
- Opzione di trattamento proposta per ciascun rischio.
- Gruppi di controlli selezionati.
- Rischio residuo dopo il trattamento.
- Rischi proposti per l’accettazione.
- Decisioni di budget o risorse richieste.
- Dipendenze da fornitori, funzione legale, HR, prodotto e IT.
- Decisione richiesta alla direzione.
L’output dovrebbe essere un’approvazione firmata o verbalizzata. Un set di slide da solo non basta.
Mappare inoltre le misure di NIS2 Article 21 alle clausole ISO/IEC 27001:2022 e ai controlli dell’Annex A. Questo consente all’organizzazione di mostrare che NIS2 è gestita tramite il SGSI e non tramite una checklist scollegata.
Giorni 61-90: testare la segnalazione degli incidenti e riesaminare le evidenze
NIS2 Article 23 richiede una segnalazione a fasi per gli incidenti significativi: preallarme entro 24 ore, notifica dell’incidente entro 72 ore, aggiornamenti intermedi ove richiesti o domandati e rapporto finale entro un mese dalla notifica.
Eseguire un’esercitazione tabletop con lo sponsor del Consiglio, CEO, CISO, legale, comunicazioni, team di successo clienti e operations. Utilizzare uno scenario realistico, ad esempio una configurazione errata del cloud che esponga metadati dei clienti, interrompa la disponibilità del servizio e incida su un cliente regolamentato.
Testare chi decide se l’incidente possa essere significativo, chi contatta il consulente legale, chi notifica le autorità competenti o il CSIRT ove richiesto, chi approva le comunicazioni ai clienti, come sono preservate le evidenze, come vengono valutati in parallelo gli obblighi GDPR in materia di violazione e come il Consiglio viene aggiornato durante le prime 24 ore.
Tenere quindi un riesame formale della direzione. Il Zenith Blueprint, fase Audit, riesame e miglioramento, Step 28, spiega perché:
“Il riesame della direzione non è solo una presentazione; riguarda l’assunzione di decisioni.”
Quel riesame dovrebbe includere risultanze dell’audit, avanzamento del trattamento del rischio, preparazione agli incidenti, rischi dei fornitori, metriche, decisioni, azioni assegnate e responsabili del follow-up.
La riunione di riesame della direzione che funziona davvero
Molti riesami della direzione falliscono perché sono strutturati come aggiornamenti di stato. Un riesame della direzione pronto per NIS2 dovrebbe essere una riunione decisionale.
L’agenda dovrebbe includere:
- Cambiamenti nei requisiti NIS2, DORA, GDPR, contrattuali e dei clienti.
- Cambiamenti nel contesto aziendale, nei servizi, nelle acquisizioni, nei fornitori, nell’architettura cloud e nei segmenti di clienti regolamentati.
- Stato dei principali rischi per la sicurezza delle informazioni e rischio residuo rispetto alla propensione al rischio.
- Avanzamento del Piano di trattamento del rischio e azioni scadute.
- Tendenze degli incidenti, eventi significativi, quasi incidenti e preparazione alla segnalazione.
- Rischi dei fornitori e delle dipendenze ICT, inclusi aspetti di concentrazione e uscita.
- Risultati di audit interni, audit esterni, valutazioni dei clienti e penetration test.
- Completamento della formazione sulla consapevolezza della sicurezza e della formazione dei dirigenti.
- Metriche per controllo degli accessi, gestione delle vulnerabilità, backup, registrazione, monitoraggio, sviluppo sicuro e test di continuità.
- Decisioni richieste, incluse accettazione del rischio, budget, personale, eccezioni alle politiche, remediation dei fornitori e miglioramenti dei controlli.
La formazione dei dirigenti è particolarmente importante. NIS2 Article 20 richiede ai membri dell’organo di gestione di seguire una formazione. La Politica di consapevolezza e formazione sulla sicurezza delle informazioni Politica di consapevolezza e formazione sulla sicurezza delle informazioni, clause 5.1.2.4, include esplicitamente temi di formazione per i dirigenti:
“Dirigenti (ad es. governance, accettazione del rischio, obblighi legali)”
La formazione cyber per i dirigenti dovrebbe concentrarsi su diritti decisionali, responsabilità, escalation, propensione al rischio, governance della crisi, segnalazione degli incidenti e obblighi normativi. Non dovrebbe limitarsi alla sensibilizzazione al phishing.
Come auditor e clienti testeranno la vigilanza del Consiglio
Valutatori diversi useranno linguaggi diversi, ma testeranno la stessa domanda di fondo: la cibersicurezza è governata?
Zenith Controls è utile perché include mappature delle metodologie di audit. Per le responsabilità della direzione, rimanda ai principi e alla conduzione degli audit ISO/IEC 19011:2018, alle pratiche di audit del SGSI ISO/IEC 27007:2020, a ISO/IEC 27001:2022 clause 5.1, COBIT 2019 EDM01 ed EDM03, ISACA ITAF Section 1401 e NIST SP 800-53A PM-1 e PM-2. Per il riesame indipendente, mappa le clausole ISO/IEC 27001:2022 9.2 e 9.3, la pianificazione degli audit e le pratiche sulle evidenze ISO/IEC 27007, ISACA ITAF Section 2400 e i metodi di valutazione NIST. Per la conformità alle politiche, mappa le clausole ISO/IEC 27001:2022 9.1, 9.2 e 10.1, la raccolta delle evidenze ISO/IEC 19011, COBIT 2019 MEA01 e la valutazione del monitoraggio continuo NIST.
| Prospettiva dell’auditor | Cosa chiederà | Evidenze attese | Errore comune |
|---|---|---|---|
| Auditor ISO/IEC 27001:2022 | In che modo l’alta direzione dimostra leadership, approva il trattamento del rischio e riesamina le prestazioni del SGSI? | Approvazioni delle politiche, Registro dei rischi, approvazione della SoA, verbali del riesame della direzione, output dell’audit interno | Il riesame della direzione esiste ma non contiene decisioni o tracciamento delle azioni |
| Valutatore focalizzato su NIS2 | L’organo di gestione ha approvato le misure di cibersicurezza e vigilato sull’attuazione? | Verbali del Consiglio, matrice di escalation, registrazioni della formazione dei dirigenti, mappatura della baseline Article 21 | Misure di sicurezza approvate solo dal CISO, senza tracciabilità verso il Consiglio |
| Valutatore NIST CSF 2.0 | Gli esiti di governance, la propensione al rischio, i ruoli, le risorse, la vigilanza e il rischio della catena di fornitura sono integrati nella gestione del rischio aziendale? | Profili correnti e target, piano sulle lacune, reportistica alla leadership, metriche | NIST usato come checklist senza titolarità di governance |
| Auditor COBIT 2019 o ISACA | La governance valuta, indirizza e monitora la gestione del rischio cyber? | Mandati di governance, propensione al rischio, reportistica direzionale, risultati di assurance | Il Consiglio riceve metriche tecniche ma nessun contesto decisionale di rischio |
| Cliente DORA o valutatore del settore finanziario | Rischi ICT, incidenti, resilienza e dipendenze da terze parti sono governati e documentati? | Mappa delle dipendenze ICT, Registro dei fornitori, due diligence, diritti di audit, ciclo di vita degli incidenti | Il rischio dei fornitori è basato solo su questionari, senza analisi di concentrazione o uscita |
| Auditor GDPR o valutatore privacy | L’organizzazione può dimostrare sicurezza e responsabilizzazione per il trattamento dei dati personali? | Mappe dei dati, modello della base giuridica, processo di valutazione delle violazioni, controlli di sicurezza | Le evidenze privacy e sicurezza sono separate e incoerenti |
La lezione è semplice. La responsabilità del Consiglio non è dimostrata dalla sola presenza in riunione. È dimostrata da decisioni informate, approvazioni documentate, prioritizzazione basata sul rischio, allocazione di risorse e follow-up.
Errori comuni che interrompono la catena delle evidenze
Le organizzazioni che faticano con la responsabilità dell’organo di gestione ai sensi di NIS2 ricadono di solito in schemi prevedibili.
Primo, confondono l’operatività dei controlli tecnici con la governance. Copertura MFA, allerte SIEM, deployment EDR e tassi di successo dei backup contano, ma il Consiglio ha bisogno di contesto di rischio, decisioni di trattamento e assurance che i controlli funzionino.
Secondo, approvano politiche ma non il trattamento del rischio. Una politica di sicurezza firmata non dimostra che il Consiglio abbia approvato misure di cibersicurezza proporzionate. Il Piano di trattamento del rischio e la SoA sono evidenze più forti perché collegano rischi, controlli, rischio residuo e approvazione della direzione.
Terzo, mancano soglie di escalation. Senza una Matrice delle deleghe di rischio, l’escalation dipende dalle persone. La governance NIS2 richiede criteri oggettivi di attivazione.
Quarto, separano la risposta agli incidenti dalla segnalazione normativa. I flussi di lavoro di segnalazione NIS2, DORA e GDPR devono essere integrati prima di una crisi.
Quinto, ignorano la governance dei fornitori. NIS2 Article 21 include la sicurezza della catena di fornitura e considerazioni sulle vulnerabilità dei fornitori. I clienti guidati da DORA possono aspettarsi una governance più approfondita delle terze parti ICT, inclusi due diligence, diritti di audit, rischio di concentrazione, diritti di risoluzione e strategie di uscita.
Sesto, non formano i dirigenti. La formazione cyber dei dirigenti non è un elemento facoltativo di facciata ai sensi di NIS2. Fa parte della catena delle evidenze di governance.
Come si presenta una buona impostazione
Dopo 90 giorni, una cartella credibile di evidenze NIS2 per il Consiglio dovrebbe contenere:
- Valutazione di applicabilità.
- Campo di applicazione del SGSI e Registro di conformità.
- Dichiarazione di impegno della leadership.
- Propensione al rischio e soglie di tolleranza.
- Matrice delle deleghe di rischio.
- Registro dei rischi cyber.
- Piano di trattamento del rischio.
- Dichiarazione di Applicabilità.
- Verbali di approvazione del Consiglio.
- Registrazioni della formazione dei dirigenti.
- Rapporto dell’esercitazione tabletop sugli incidenti.
- Cruscotto dei rischi dei fornitori.
- Rapporto di audit interno.
- Verbali del riesame della direzione e registro di tracciamento delle azioni.
Questa cartella risponde al questionario cliente ricevuto da Maria il lunedì mattina. Soprattutto, aiuta il Consiglio a governare il rischio cyber prima che un incidente, un audit o un’autorità di regolamentazione metta pubblicamente alla prova l’organizzazione.
Trasformare la responsabilità del Consiglio NIS2 in governance pronta per l’audit
NIS2 ha cambiato il dialogo sulla cibersicurezza. Gli organi di gestione devono approvare le misure di gestione dei rischi di cibersicurezza, vigilare sull’attuazione e seguire una formazione. Article 21 richiede un insieme integrato di misure tecniche, operative e organizzative. Article 23 comprime la segnalazione degli incidenti in una sequenza a fasi che richiede preparazione prima della crisi.
ISO/IEC 27001:2022 fornisce il sistema di gestione. Clarysec fornisce il percorso di attuazione, il linguaggio delle politiche, le mappature trasversali di conformità e il modello delle evidenze di audit.
Se il vostro Consiglio si sta chiedendo: “Che cosa dobbiamo approvare e come dimostriamo la vigilanza?”, iniziate con tre azioni:
- Usare Zenith Blueprint Step 3, Step 13 e Step 28 per strutturare l’impegno della leadership, l’approvazione del trattamento del rischio e il riesame della direzione.
- Usare politiche Clarysec come Politica di gestione del rischio, Politica sui ruoli e sulle responsabilità di governance, Politica per la sicurezza delle informazioni e gli equivalenti per PMI per formalizzare responsabilità e tracciabilità.
- Usare Zenith Controls per mappare la vigilanza del Consiglio NIS2 su ISO/IEC 27001:2022, ISO/IEC 27002:2022, DORA, GDPR, NIST CSF 2.0, COBIT 2019 e aspettative delle metodologie di audit.
Clarysec può aiutarvi a costruire il pacchetto per il Consiglio, aggiornare la catena delle evidenze del SGSI, preparare il riesame della direzione e trasformare la responsabilità NIS2 in un processo ripetibile di governance del rischio cyber comprensibile per auditor, clienti e dirigenti. Scaricate i toolkit Clarysec pertinenti o richiedete una valutazione per trasformare la responsabilità del Consiglio in evidenze pronte per l’audit.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


