Monitoraggio continuo della conformità per NIS2 e DORA

La domanda del venerdì pomeriggio a cui ogni CISO deve saper rispondere

Alle 16:40 di un venerdì, il CISO di una piattaforma di pagamenti basata sul cloud riceve tre messaggi nel giro di dieci minuti.

Il primo arriva dal CFO: “Il nostro partner bancario vuole evidenze aggiornate che dimostrino il rispetto delle aspettative DORA sul rischio ICT di terze parti e sulla segnalazione degli incidenti.”

Il secondo arriva dal consulente legale interno: “Il nostro servizio di sicurezza gestito potrebbe farci rientrare nell’ambito della normativa nazionale di recepimento di NIS2. Possiamo dimostrare la supervisione della direzione e l’efficacia dei controlli?”

Il terzo arriva dal responsabile dell’ingegneria: “Abbiamo corretto la vulnerabilità critica, ma il backlog mostra 38 rilievi medi scaduti. Dobbiamo attivare un’escalation?”

È il momento in cui la conformità annuale mostra tutti i suoi limiti.

Un PDF di una policy, un registro dei rischi aggiornato l’ultima volta prima dell’audit precedente e una cartella di screenshot non bastano per NIS2 e DORA. Questi regimi richiedono governance effettiva, supervisione della direzione, flussi di gestione degli incidenti, visibilità sui fornitori, test di resilienza, azioni correttive ed efficacia dei controlli dimostrabile.

Per molti CISO, la pressione non è teorica. Il recepimento di NIS2 negli Stati membri dell’UE ha trasformato la cibersicurezza da programma tecnico a tema di responsabilità della direzione. DORA si applica dal 17 gennaio 2025 e fornisce agli enti finanziari un corpus di regole settoriali sulla resilienza operativa per rischio ICT, segnalazione degli incidenti, test e rischio di terze parti. Anche fornitori cloud, SaaS, servizi gestiti, servizi di sicurezza gestiti, data center, content delivery, servizi fiduciari e reti o servizi pubblici di comunicazione elettronica possono essere soggetti a obblighi diretti o indiretti in base ad ambito, dimensione, settore, classificazione nazionale e contratti con i clienti.

La domanda pratica non è più: “Abbiamo un controllo?”

È: “Chi è responsabile del controllo, quale metrica dimostra che funziona, con quale frequenza raccogliamo le evidenze e cosa succede quando la metrica non è rispettata?”

Questo è il nucleo del monitoraggio continuo della conformità per NIS2 e DORA. Nelle implementazioni Clarysec usiamo ISO/IEC 27001:2022 come dorsale del sistema di gestione, ISO/IEC 27002:2022 come linguaggio dei controlli, Zenith Blueprint: la roadmap in 30 passaggi per l’auditor come sequenza di attuazione e Zenith Controls: la guida alla conformità trasversale come bussola di cross-compliance che collega le evidenze ISO/IEC 27001:2022 a NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 e alle aspettative di audit.

Perché NIS2 e DORA rendono insufficiente la conformità periodica

NIS2 e DORA differiscono per struttura giuridica, modello di vigilanza e ambito di applicazione, ma generano la stessa pressione operativa. La cibersicurezza e la resilienza ICT devono essere governate in modo continuativo.

NIS2 richiede ai soggetti essenziali e importanti di applicare misure tecniche, operative e organizzative adeguate e proporzionate, adottando un approccio multi-rischio. Tali misure comprendono analisi dei rischi, politiche di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, gestione delle crisi, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione a più fattori ove appropriato. Gli organi di gestione devono approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione.

DORA rende questo aspetto ancora più esplicito per gli enti finanziari. Richiede assetti interni di governance e controllo per il rischio ICT, un quadro documentato di gestione del rischio ICT, responsabilità dell’organo di gestione, gestione e segnalazione degli incidenti connessi all’ICT, test di resilienza operativa digitale, gestione del rischio ICT di terze parti, follow-up degli audit, formazione e modalità di comunicazione. DORA chiarisce inoltre che gli enti finanziari restano responsabili della conformità quando ricorrono a fornitori terzi di servizi ICT.

Questo crea una nuova realtà di conformità. Un CISO non può attendere il mese dell’audit per scoprire che:

• i riesami degli accessi privilegiati sono stati saltati per due trimestri;
• i piani di uscita dai fornitori sono stati documentati ma mai testati;
• i criteri di gravità degli incidenti non sono mappati alle soglie di segnalazione normativa;
• i backup sono configurati, ma mancano evidenze di ripristino;
• la direzione non ha mai riesaminato i trattamenti del rischio scaduti;
• i contratti cloud non includono diritti di audit, visibilità sui subappaltatori o clausole di notifica degli incidenti.

Il vecchio modello basato su progetti genera cicli di panico. I team si affrettano prima di un audit, raccolgono screenshot, aggiornano le date delle policy e sperano che le evidenze raccontino una storia coerente. NIS2 e DORA sono progettati per far fallire questo approccio. Puntano su responsabilità, proporzionalità, resilienza ed evidenza del funzionamento operativo.

ISO/IEC 27001:2022 fornisce il sistema operativo per affrontare questo problema. Le sue clausole richiedono alle organizzazioni di comprendere il contesto, le parti interessate, i requisiti legali e contrattuali, l’ambito di applicazione, la leadership, i ruoli, la valutazione del rischio, il trattamento del rischio, la Dichiarazione di Applicabilità, la pianificazione operativa, la valutazione delle prestazioni, l’audit interno, il riesame della direzione, la gestione delle non conformità e il miglioramento continuo. Questa struttura è ideale per combinare NIS2, DORA, GDPR, assurance verso i clienti e rischio interno in un unico modello di monitoraggio continuo.

La conformità continua non significa avere più dashboard. Significa definire una cadenza governata delle evidenze.

Costruire il motore della conformità su ISO/IEC 27001:2022

Molte organizzazioni interpretano erroneamente ISO/IEC 27001:2022 come un semplice framework di certificazione. In pratica, è un sistema di gestione del rischio che rende la governance della sicurezza ripetibile, misurabile e verificabile.

Questo è importante perché NIS2 e DORA non sono checklist isolate. Richiedono un modello operativo capace di recepire i requisiti legali, tradurli in controlli, assegnare le responsabilità, monitorare le prestazioni e migliorare quando emergono lacune.

Le clausole fondamentali di ISO/IEC 27001:2022 forniscono tale modello:

Per una FinTech, un fornitore SaaS, un servizio di sicurezza gestito o un fornitore ICT di enti finanziari, questa struttura evita progetti di conformità duplicati. Un solo SGSI può mappare gli obblighi ai controlli una volta sola, quindi riutilizzare le evidenze per NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, certificazione ISO/IEC 27001:2022 e riesami di assurance dei clienti.

Iniziare dalla responsabilità dei controlli, non dagli strumenti

Il primo schema di fallimento nella conformità continua è l’implementazione guidata dagli strumenti. Un’azienda acquista una piattaforma GRC, importa centinaia di requisiti, assegna tutto a “Sicurezza” e lo chiama monitoraggio continuo. Sei mesi dopo, la dashboard è rossa, l’ingegneria contesta le evidenze sulle vulnerabilità, il legale segnala documentazione dei fornitori incompleta e la direzione non vede con chiarezza il rischio residuo.

ISO/IEC 27001:2022 evita questo problema richiedendo che responsabilità e autorità siano assegnate e comunicate. NIS2 e DORA rafforzano la stessa aspettativa attraverso responsabilità della direzione, ruoli definiti e supervisione.

La Politica sui ruoli e sulle responsabilità di governance - SME di Clarysec stabilisce:

Ogni ruolo con responsabilità di sicurezza deve essere registrato in un log centrale e confermato per iscritto.

Questa clausola è più importante della maggior parte delle dashboard. Se test di backup, remediation delle vulnerabilità, due diligence sui fornitori, classificazione degli incidenti e riesame degli accessi privilegiati non hanno responsabili nominativi, non esiste una cadenza affidabile delle evidenze.

La Politica per la sicurezza delle informazioni rende questo principio operativo per gli ambienti enterprise:

Raccogliere e conservare le evidenze di audit per audit e riesami dei controlli.

Richiede inoltre ai responsabili dei controlli di:

Segnalare al Responsabile del SGSI le prestazioni dei controlli ed eventuali lacune o problematiche.

In Zenith Controls, questo tema è mappato direttamente al controllo ISO/IEC 27002:2022 5.2 Ruoli e responsabilità per la sicurezza delle informazioni, 5.35 Riesame indipendente della sicurezza delle informazioni e 5.36 Conformità a politiche, regole e standard per la sicurezza delle informazioni.

Il Zenith Blueprint offre un punto di partenza pratico nella fase ISMS Foundation & Leadership, Step 4: Roles and Responsibilities in the ISMS. Raccomanda nomina formale, aggiornamento delle descrizioni delle mansioni, allineamento ai KPI, comunicazione a livello organizzativo e responsabilità a livello di dipartimento.

Una registrazione di nomina tipica può indicare:

“Con effetto immediato, lei è nominato Responsabile della sicurezza delle informazioni con responsabilità di supervisionare e coordinare il SGSI, incluse gestione del rischio, attuazione dei controlli e monitoraggio della conformità.”

Questa nomina non è burocrazia. È evidenza di audit per leadership e assegnazione dei ruoli ai sensi di ISO/IEC 27001:2022. Supporta inoltre la supervisione della direzione NIS2 e la governance DORA. Autorità di regolamentazione, auditor di certificazione e clienti bancari vogliono vedere che la responsabilità non è implicita. Deve essere assegnata, accettata, dotata di risorse e monitorata.

Un registro pratico dei responsabili dei controlli dovrebbe includere questi campi:

Questo registro diventa il ponte tra policy ed evidenza.

Definire KPI e KRI che dimostrano l’efficacia dei controlli

Una volta individuati i responsabili, questi devono sapere cosa significa “funzionare bene”. Il monitoraggio continuo della conformità si basa su indicatori significativi, non su intenzioni generiche.

“Migliorare il patching” non è un KPI. “Riesaminare regolarmente i fornitori” non è un’evidenza. “Mantenere la resilienza” non è un controllo misurabile.

Clarysec distingue chiaramente i due tipi di indicatori:

• KPI, Key Performance Indicator, misura se il processo opera come previsto.
• KRI, Key Risk Indicator, segnala un aumento del rischio o il superamento di una soglia che richiede escalation.

La Politica di gestione del rischio enterprise stabilisce:

I KRI (Indicatori chiave di rischio) e le metriche di sicurezza devono essere definiti per i rischi critici e monitorati mensilmente.

Richiede inoltre una logica di escalation:

I trigger di escalation devono essere incorporati nella logica di monitoraggio, ad esempio quando il rischio residuo aumenta di oltre un livello o le scadenze del trattamento non sono rispettate.

Per le organizzazioni più piccole, la Politica di gestione del rischio - SME di Clarysec adotta un approccio proporzionato:

L’avanzamento della mitigazione del rischio deve essere riesaminato trimestralmente.

Consente inoltre metriche leggere:

Possono essere tracciate metriche informali, ad esempio numero di rischi aperti, azioni scadute, nuovi incidenti.

Questa proporzionalità è essenziale. Una banca multinazionale e un fornitore FinTech di 60 persone non hanno bisogno della stessa telemetria, ma entrambi hanno bisogno di responsabilità assegnata, misurazione ripetibile, soglie di escalation ed evidenze di azione correttiva.

Un modello pratico di KPI e KRI per NIS2 e DORA è il seguente:

Queste metriche supportano più della certificazione ISO/IEC 27001:2022. Supportano anche le misure di gestione dei rischi di cibersicurezza NIS2, la preparazione alla segnalazione degli incidenti NIS2, la gestione del rischio ICT DORA, il rischio di terze parti DORA, l’accountability GDPR, gli esiti di governance NIST CSF 2.0 e la gestione delle prestazioni in stile COBIT.

Stabilire una cadenza delle evidenze prima che la richieda l’audit

Molte organizzazioni raccolgono evidenze in modo casuale. Uno screenshot compare in un canale Teams. Un ticket Jira viene collegato in un’e-mail. Un questionario fornitore è archiviato nell’area acquisti. Un test di backup è descritto verbalmente. Durante la settimana dell’audit, il Responsabile del SGSI diventa un investigatore forense.

La conformità continua richiede una cadenza pianificata e una gestione ordinata delle evidenze.

La Politica di audit e monitoraggio della conformità - SME di Clarysec stabilisce:

Ogni audit deve includere ambito di applicazione, obiettivi, personale responsabile ed evidenze richieste chiaramente definiti.

Aggiunge inoltre:

Le evidenze devono essere conservate per almeno due anni, o più a lungo ove richiesto da certificazioni o accordi con i clienti.

Per le organizzazioni enterprise, la Politica di audit e monitoraggio della conformità aggiunge aspettative di automazione:

Devono essere implementati strumenti automatizzati per monitorare la conformità della configurazione, la gestione delle vulnerabilità, lo stato delle patch e gli accessi privilegiati.

L’automazione deve essere mirata. I controlli ad alto rischio e ad alta frequenza non devono dipendere da screenshot manuali. Il miglior modello di evidenze combina telemetria automatizzata, attestazioni dei responsabili, registri delle eccezioni, registrazioni del sistema di ticketing, risultati dei test e verbali del riesame della direzione.

Anche la convenzione di denominazione è importante. Le evidenze devono essere recuperabili senza sforzi straordinari. Ad esempio:

• report settimanale sulle vulnerabilità: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• riesame mensile degli accessi privilegiati: YYYY-MM_IAM-Privileged-Review_Attestation
• riesame trimestrale dei fornitori: YYYY-QX_Critical-Supplier-Review
• pacchetto incidente: INC-YYYY-###_Timeline-Classification-RCA-CAPA

È qui che la policy diventa operativa. La conservazione delle evidenze non è un’attività di archivio. Fa parte del controllo.

Mappare un elemento di evidenza a molti obblighi

La conformità continua diventa potente quando un singolo elemento di evidenza soddisfa più framework. Per questo Zenith Controls è centrale nell’approccio di cross-compliance di Clarysec.

Consideriamo la gestione degli incidenti. Ai sensi di NIS2, gli incidenti significativi richiedono segnalazioni a fasi, compreso preallarme entro 24 ore dalla conoscenza, notifica entro 72 ore e relazione finale entro un mese, fatti salvi l’attuazione nazionale e i fatti dell’incidente. DORA richiede agli enti finanziari di gestire, classificare, sottoporre a escalation e segnalare i gravi incidenti connessi all’ICT mediante processi e template richiesti. GDPR richiede ai titolari del trattamento di valutare e gestire le violazioni dei dati personali quando sono interessate riservatezza, integrità o disponibilità dei dati personali.

Un unico pacchetto di evidenze dell’incidente può supportare tutti e tre se include:

• cronologia dell’incidente e momento della conoscenza;
• motivazione della classificazione;
• servizi e giurisdizioni interessati;
• impatto su clienti, transazioni o utenti;
• valutazione dell’impatto sui dati personali;
• causa radice;
• azioni di mitigazione e ripristino;
• comunicazioni e notifiche;
• registrazione dell’escalation alla direzione;
• voce di azione correttiva.

La stessa logica di cross-compliance si applica al rischio dei fornitori. NIS2 richiede sicurezza della catena di fornitura e attenzione ai rapporti diretti con fornitori e prestatori di servizi. DORA richiede strategia per il rischio ICT di terze parti, registri, due diligence precontrattuale, clausole contrattuali, diritti di audit, livelli di servizio, strategie di uscita e monitoraggio del rischio di concentrazione. NIST CSF 2.0 tratta il rischio della catena di fornitura come una disciplina di governance del ciclo di vita. ISO/IEC 27001:2022 collega questi requisiti ad ambito di applicazione, requisiti delle parti interessate, trattamento del rischio e controllo operativo dei processi forniti esternamente.

Una matrice pratica delle evidenze aiuta i responsabili dei controlli a capire perché le evidenze sono importanti:

Questo approccio evita lavoro di conformità duplicato. L’organizzazione raccoglie un set di evidenze solido, quindi lo mappa a più obblighi.

Il modello di monitoraggio Clarysec, dall’obbligo al responsabile fino alla prova

Un modello di monitoraggio robusto segue una sequenza semplice.

Primo, definire l’obbligo. Ad esempio, DORA richiede che il rischio ICT di terze parti sia gestito come parte della gestione del rischio ICT, con registri, due diligence, requisiti contrattuali, diritti di audit e strategie di uscita per funzioni critiche o importanti. NIS2 richiede sicurezza della catena di fornitura e azione correttiva adeguata.

Secondo, tradurre l’obbligo nei requisiti del SGSI ISO/IEC 27001:2022. Ciò include requisiti delle parti interessate, ambito di applicazione, valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità, controllo operativo, monitoraggio, audit interno, riesame della direzione e miglioramento.

Terzo, selezionare i controlli operativi. In Zenith Controls, i controlli di governance principali per la conformità continua includono i controlli ISO/IEC 27002:2022 5.2, 5.35 e 5.36. I controlli di supporto includono spesso 5.19 Sicurezza delle informazioni nei rapporti con i fornitori, 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT, 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud, 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, 5.26 Risposta agli incidenti di sicurezza delle informazioni, 5.30 Prontezza ICT per la continuità operativa, 5.31 Requisiti legali, statutari, normativi e contrattuali, 8.8 Gestione delle vulnerabilità tecniche, 8.13 Backup delle informazioni, 8.15 Registrazione, 8.16 Attività di monitoraggio e 8.9 Gestione della configurazione.

Quarto, assegnare responsabile e cadenza. Il rischio dei fornitori può coinvolgere Approvvigionamento, Legale, Sicurezza e il Responsabile del servizio aziendale, ma un unico responsabile accountable deve mantenere il registro e segnalare le eccezioni.

Quinto, definire KPI, KRI ed evidenze. I KPI dei fornitori possono includere la percentuale di fornitori ICT critici con due diligence completata, la percentuale con clausole contrattuali approvate, il numero senza piani di uscita testati e il numero di riesami dei fornitori scaduti. I KRI possono includere rilievi ad alto rischio dei fornitori non risolti, rischio di concentrazione oltre la tolleranza o assenza di diritti di audit per un servizio a supporto di una funzione critica o importante.

Sesto, effettuare reportistica ed escalation. Le dashboard mensili del SGSI non devono limitarsi a mostrare stati verdi. Devono identificare evidenze scadute, movimento del rischio, scadenze di trattamento non rispettate e decisioni richieste alla direzione.

Settimo, svolgere audit e migliorare. Le lacune nelle evidenze diventano azioni correttive, non giustificazioni.

Questo è allineato alla fase Audit, Review & Improvement del Zenith Blueprint. Lo Step 25, Internal Audit Program, raccomanda di coprire i processi e i controlli SGSI pertinenti nel ciclo di audit, con un audit annuale a pieno ambito e controlli a campione trimestrali più contenuti per le aree ad alto rischio, ove appropriato. Lo Step 28, Management Review, richiede input quali modifiche ai requisiti, risultati del monitoraggio e della misurazione, risultati degli audit, incidenti, non conformità, opportunità di miglioramento e fabbisogni di risorse. Lo Step 29, Continual Improvement, usa il log CAPA per acquisire descrizione del problema, causa radice, azione correttiva, responsabile accountable, data obiettivo e stato.

Questa è la conformità continua nella pratica.

Uno scenario pratico: vulnerabilità critica su una API pubblica

Alle 02:15 scatta un’allerta SIEM. Una scansione di vulnerabilità ha identificato una vulnerabilità critica di esecuzione remota di codice su un gateway API esposto pubblicamente che supporta un servizio di pagamento regolamentato.

Il modello di monitoraggio continuo deve rispondere senza attendere una riunione.

Primo, l’inventario degli asset classifica il gateway come critico. Parte il conteggio temporale del KPI di gestione delle vulnerabilità. Il KRI per le vulnerabilità critiche non corrette aumenta. Se l’asset è esposto a Internet e l’exploit è attivo, la soglia di escalation viene attivata immediatamente.

Secondo, il ticket viene instradato al team DevOps reperibile. Il responsabile DevOps, in qualità di responsabile del controllo di gestione delle vulnerabilità, riceve una notifica automatica. Il SOC Manager verifica l’esistenza di indicatori di exploit. Il Responsabile del SGSI monitora se sono soddisfatti i criteri di incidente.

Terzo, le evidenze sono raccolte come sottoprodotto del workflow. Allerta SIEM, scansione di vulnerabilità, classificazione dell’asset, timestamp del ticket, chat di risposta, registrazione della patch, scansione di validazione e approvazione di chiusura sono allegati al pacchetto di evidenze.

Quarto, il team valuta se l’evento è solo una vulnerabilità, un evento di sicurezza o un incidente. Se esistono impatto sul servizio, indicatori di compromissione, impatto sui clienti o esposizione di dati personali, il workflow degli incidenti attiva le valutazioni di segnalazione NIS2, DORA, GDPR e contrattuali.

Quinto, la direzione riceve un report sintetico. Se la vulnerabilità è stata corretta entro quattro ore, le evidenze supportano l’efficacia del controllo. Se lo SLA non è stato rispettato, il log CAPA registra causa radice, azione correttiva, responsabile, data obiettivo e stato.

Questo singolo evento genera evidenze utili per gestione delle vulnerabilità, preparazione agli incidenti, monitoraggio, accesso agli asset critici, riesame della direzione e miglioramento continuo.

Come auditor e autorità di regolamentazione testeranno lo stesso modello di monitoraggio

Un programma maturo di conformità continua deve resistere a diverse prospettive di audit. Le evidenze non cambiano, ma cambiano le domande.

Per il controllo ISO/IEC 27002:2022 5.35 Riesame indipendente della sicurezza delle informazioni, un auditor ISO/IEC 27001:2022 si concentrerà su piano di audit interno, ambito, competenze, rilievi e azioni correttive. Un’autorità NIS2 o DORA si concentrerà sul fatto che la direzione abbia compreso i rilievi, finanziato la remediation e ridotto il rischio sistemico. Un valutatore NIST CSF 2.0 può mappare il riesame alla funzione GOVERN, inclusi supervisione e adeguamento delle prestazioni.

Lo stesso set di evidenze serve tutti questi interlocutori se è completo, aggiornato e collegato alla responsabilità.

Errori comuni che indeboliscono la conformità continua

Il primo errore è trattare NIS2 e DORA come progetti separati. Questo crea registri duplicati, metriche confliggenti e responsabili dei controlli sovraccarichi. Usa ISO/IEC 27001:2022 come dorsale del SGSI e mappa gli obblighi attraverso un’unica libreria di controlli.

Il secondo errore è assegnare i controlli a team invece che a persone. “IT possiede i backup” non basta. Un responsabile nominativo deve attestare, segnalare eccezioni ed effettuare escalation del rischio.

Il terzo errore è raccogliere evidenze senza valutare l’efficacia. Uno screenshot di successo del backup non prova la recuperabilità. Un test di ripristino sì. Un questionario fornitore non prova la resilienza di terze parti. Clausole contrattuali, diritti di audit, termini di notifica degli incidenti, report di prestazione e pianificazione dell’uscita producono evidenze più solide.

Il quarto errore è misurare attività invece del rischio. Contare le vulnerabilità è utile. Tracciare le vulnerabilità critiche scadute su sistemi esposti a Internet è meglio. Contare i fornitori è utile. Tracciare i fornitori critici senza piani di uscita è meglio.

Il quinto errore è una disciplina debole sulle azioni correttive. Lo Zenith Blueprint Step 29 chiarisce che i rilievi richiedono descrizione del problema, causa radice, azione correttiva, responsabile accountable, data obiettivo e stato. Se il log CAPA non viene riesaminato, la conformità continua diventa accumulo continuo di debolezze note.

Cosa deve vedere la direzione ogni mese

Gli organi di gestione ai sensi di NIS2 e DORA non hanno bisogno di esportazioni grezze dagli scanner. Hanno bisogno di una vista decisionale sul rischio cyber e ICT.

Una dashboard mensile per consiglio o direzione dovrebbe includere:

• principali rischi cyber e ICT con movimento del rischio residuo;
• trattamenti del rischio scaduti e scadenze non rispettate;
• incidenti significativi, potenziali gravi incidenti connessi all’ICT e lezioni apprese;
• eccezioni di rischio dei fornitori critici;
• prestazioni SLA sulle vulnerabilità per gli asset critici;
• stato dei test di backup e ripristino;
• eccezioni nel riesame degli accessi privilegiati;
• tasso di completamento delle evidenze di conformità;
• rilievi dell’audit e stato CAPA;
• decisioni sulle risorse richieste.

Questo supporta direttamente il riesame della direzione ISO/IEC 27001:2022 e le aspettative di governance di NIS2 e DORA. È inoltre allineato a NIST CSF 2.0, in cui i dirigenti definiscono priorità, responsabilità, risorse e propensione al rischio, mentre i manager traducono tali priorità in profili target e piani di azione.

Costruire questa settimana il ritmo delle evidenze NIS2 e DORA

Non è necessario “far bollire l’oceano” per iniziare. Una prima settimana utile può essere semplice.

Giorno 1: creare un registro dei responsabili dei controlli per cinque domini: governance e gestione del rischio, gestione e segnalazione degli incidenti, gestione delle vulnerabilità e delle patch, rischio dei fornitori e del cloud, continuità operativa e ripristino.

Giorno 2: definire un KPI e un KRI per ciascun dominio. Devono essere specifici, misurabili e collegati alla propensione al rischio.

Giorno 3: mappare ciascun elemento di evidenza al valore per NIS2, DORA, ISO/IEC 27001:2022, GDPR e assurance verso i clienti.

Giorno 4: definire cadenza delle evidenze, posizione di archiviazione, convenzione di denominazione, regola di conservazione e responsabile del riesame.

Giorno 5: eseguire un’escalation tabletop. Usare uno scenario di indisponibilità cloud o di vulnerabilità critica. Confermare classificazione, valutazione della segnalazione normativa, comunicazione ai clienti, archiviazione delle evidenze e creazione della CAPA.

Se la tua organizzazione gestisce ancora NIS2 e DORA tramite fogli di calcolo, workshop annuali e cartelle di evidenze sparse, è il momento di passare a un ritmo operativo monitorato.

Inizia con tre azioni:

1. Costruisci un registro dei responsabili dei controlli per i domini a rischio più elevato.
2. Definisci un KPI, un KRI, un elemento di evidenza e una cadenza per ciascun controllo.
3. Esegui un riesame delle evidenze di 30 minuti e apri elementi CAPA per ciò che manca.

Clarysec può aiutarti ad accelerare il passaggio con Zenith Blueprint per la sequenza di attuazione, Zenith Controls per la mappatura di cross-compliance e la libreria di policy Clarysec, incluse Politica per la sicurezza delle informazioni, Politica di gestione del rischio, Politica di audit e monitoraggio della conformità, Politica sui ruoli e sulle responsabilità di governance - SME, Politica di gestione del rischio - SME e Politica di audit e monitoraggio della conformità - SME.

L’obiettivo non è produrre più documentazione di conformità. L’obiettivo è rispondere con sicurezza alla domanda del venerdì pomeriggio:

“Sì, sappiamo chi è responsabile del controllo, conosciamo il KPI, abbiamo le evidenze, conosciamo le eccezioni e la direzione ha riesaminato il rischio.”

Contatta Clarysec per costruire un modello di monitoraggio continuo della conformità pronto per l’audit, pronto per il consiglio e sufficientemente resiliente per NIS2, DORA e la prossima normativa che arriverà.