⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

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

Igor Petreski
14 min read
Diagramma della responsabilità del Consiglio ai sensi di NIS2 e delle evidenze di governance 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:

  1. L’organizzazione ha valutato se NIS2 si applica e ne ha documentato la base.
  2. Il Consiglio o l’alta direzione ha approvato il quadro per la gestione del rischio di cibersicurezza.
  3. Sono state definite la propensione al rischio e le soglie di tolleranza.
  4. I rischi cyber elevati sono stati sottoposti a escalation e riesaminati.
  5. Le decisioni di trattamento del rischio sono state approvate, incluso il rischio residuo accettato.
  6. Le procedure di segnalazione degli incidenti riflettono, ove applicabile, gli obblighi di preallarme a 24 ore, notifica a 72 ore e rapporto finale.
  7. Le dipendenze da fornitori e cloud sono mappate e governate.
  8. Il riesame della direzione include risultanze dell’audit, tendenze degli incidenti, metriche e azioni di miglioramento.
  9. I dirigenti hanno ricevuto una formazione adeguata alla loro responsabilità.
  10. 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.

EvidenzaDomanda sulla responsabilità del Consiglio a cui rispondeRiferimento ISO/IEC 27001:2022Fonte Clarysec
Valutazione di applicabilità NIS2Siamo essenziali, importanti, indirettamente esposti o fuori ambito?Clauses 4.1 to 4.4Zenith Blueprint, Step 1 and Step 2
Campo di applicazione del SGSI e mappa delle dipendenzeQuali servizi, sedi, fornitori, interfacce e processi sono governati?Clauses 4.1 to 4.4Zenith Blueprint, fase Fondazione del SGSI
Registro dei rischi cyberQuali sono i nostri principali rischi cyber e chi ne è titolare?Clauses 6.1.1 and 6.1.2Politica di gestione del rischio
Piano di trattamento del rischio e SoAQuali controlli sono selezionati, perché e chi ha approvato il rischio residuo?Clause 6.1.3Zenith Blueprint, Step 13
Verbali del Consiglio e registro delle decisioniLa direzione ha approvato, messo in discussione e vigilato sulle misure?Clauses 5.1, 5.3, 9.3Politica sui ruoli e sulle responsabilità di governance
Procedura di escalation e segnalazione degli incidentiPossiamo rispettare le tempistiche di segnalazione a fasi previste da NIS2?Clauses 8.1, 9.1, controlli sugli incidenti dell’Annex AToolkit di risposta agli incidenti e riesame della direzione
Cruscotto dei rischi dei fornitoriI fornitori critici e le dipendenze cloud sono governati?Clause 8.1 e controlli sui fornitori dell’Annex AMappatura trasversale di Zenith Controls
Registrazioni della formazione dei dirigentiI membri dell’organo di gestione hanno seguito una formazione appropriata?Clause 7.2 e controlli di sensibilizzazionePolitica di consapevolezza e formazione sulla sicurezza delle informazioni
Output di audit interno e riesame della direzioneL’attuazione è verificata in modo indipendente e migliorata?Clauses 9.2, 9.3, 10.1Politica 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 requisitoNIS2DORAGDPRNIST CSF 2.0COBIT 2019Focus delle evidenze Clarysec
Responsabilità della direzioneArticle 20 approvazione, vigilanza, formazione, responsabilitàArticles 5 and 6 responsabilità dell’organo di gestione e quadro di gestione dei rischi ICTArticle 5(2) responsabilizzazione e Article 24 responsabilitàGOVERN, in particolare GV.RR, GV.RM e GV.OVEDM03 ottimizzazione del rischioVerbali del Consiglio, mandati di ruolo, registrazioni della formazione
Misure di gestione del rischioArticle 21 misure tecniche, operative e organizzativeQuadro di gestione dei rischi ICTArticle 32 sicurezza del trattamentoGOVERN, IDENTIFY, PROTECTAPO13 sicurezza gestitaRegistro dei rischi, piano di trattamento, SoA
Segnalazione degli incidentiArticle 23 preallarme, notifica dell’incidente, rapporto finaleArticles 17 to 20 segnalazione degli incidenti rilevanti connessi all’ICTArticles 33 and 34 notifica di violazione dei dati personali ove applicabileRESPOND e RECOVERDSS02 richieste di servizio e incidenti gestitiMatrice di escalation, playbook, simulazioni
Governance dei fornitoriArticle 21(2)(d) sicurezza della catena di fornituraArticles 28 to 30 rischio ICT di terze partiObblighi del responsabile del trattamento e di sicurezzaGV.SC gestione del rischio di cibersicurezza della catena di fornituraAPO10 fornitori gestitiRegistro dei fornitori, due diligence, controlli contrattuali
Efficacia e assuranceArticle 21(2)(f) politiche e procedure per valutare l’efficaciaArticle 6 riesame del quadro di gestione dei rischi ICT e aspettative di auditArticle 32(1)(d) test e valutazione periodiciGV.OV vigilanza, ID.RA valutazione del rischio, DE.CM monitoraggio continuoMEA01 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:

  1. Cambiamenti nei requisiti NIS2, DORA, GDPR, contrattuali e dei clienti.
  2. Cambiamenti nel contesto aziendale, nei servizi, nelle acquisizioni, nei fornitori, nell’architettura cloud e nei segmenti di clienti regolamentati.
  3. Stato dei principali rischi per la sicurezza delle informazioni e rischio residuo rispetto alla propensione al rischio.
  4. Avanzamento del Piano di trattamento del rischio e azioni scadute.
  5. Tendenze degli incidenti, eventi significativi, quasi incidenti e preparazione alla segnalazione.
  6. Rischi dei fornitori e delle dipendenze ICT, inclusi aspetti di concentrazione e uscita.
  7. Risultati di audit interni, audit esterni, valutazioni dei clienti e penetration test.
  8. Completamento della formazione sulla consapevolezza della sicurezza e della formazione dei dirigenti.
  9. Metriche per controllo degli accessi, gestione delle vulnerabilità, backup, registrazione, monitoraggio, sviluppo sicuro e test di continuità.
  10. 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’auditorCosa chiederàEvidenze atteseErrore comune
Auditor ISO/IEC 27001:2022In 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 internoIl riesame della direzione esiste ma non contiene decisioni o tracciamento delle azioni
Valutatore focalizzato su NIS2L’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 21Misure di sicurezza approvate solo dal CISO, senza tracciabilità verso il Consiglio
Valutatore NIST CSF 2.0Gli 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, metricheNIST usato come checklist senza titolarità di governance
Auditor COBIT 2019 o ISACALa governance valuta, indirizza e monitora la gestione del rischio cyber?Mandati di governance, propensione al rischio, reportistica direzionale, risultati di assuranceIl Consiglio riceve metriche tecniche ma nessun contesto decisionale di rischio
Cliente DORA o valutatore del settore finanziarioRischi 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 incidentiIl rischio dei fornitori è basato solo su questionari, senza analisi di concentrazione o uscita
Auditor GDPR o valutatore privacyL’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 sicurezzaLe 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:

  1. 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.
  2. 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à.
  3. 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

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

Share this article

Related Articles

Evidenze DORA TLPT con i controlli ISO 27001

Evidenze DORA TLPT con i controlli ISO 27001

Una guida pratica per gli enti finanziari che devono collegare DORA TLPT, test di resilienza, controlli ISO 27001, assurance sui fornitori, evidenze di ripristino e reporting al Consiglio di amministrazione in un’unica catena di evidenze pronta per l’audit.