ISO 27001 come dorsale delle evidenze per NIS2 e DORA

La collisione del lunedì mattina sulla conformità
Alle 08:12 di lunedì, Maria, CISO di un prestatore europeo di servizi di pagamento, riceve tre messaggi che sembrano non avere alcuna relazione tra loro.
Il responsabile dell’audit interno chiede evidenza che la Dichiarazione di Applicabilità ISO 27001:2022 sia aggiornata. Il team legale inoltra il questionario di un partner bancario sulla supervisione del rischio ICT di terze parti ai sensi di DORA. Il direttore operativo chiede se lo stesso playbook di gestione degli incidenti possa supportare le aspettative di notifica NIS2 per un’unità aziendale dell’UE acquisita di recente.
Alle 09:00, la lavagna nell’ufficio di Maria è coperta di acronimi: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. La sua organizzazione dispone di controlli. Dispone di gestione degli accessi, backup, questionari per i fornitori, cifratura, risposta agli incidenti, approvazioni delle politiche, riesami della direzione e registrazioni della formazione. Ciò che manca è un’unica dorsale di evidenze pronta per l’audit che spieghi perché quei controlli esistono, quali rischi trattano, quali normative supportano, chi ne è responsabile e dove si trovano le prove.
Questo problema sta diventando comune in tutta Europa. NIS2 insiste su gestione dei rischi di cibersicurezza, governance, gestione degli incidenti e resilienza della catena di fornitura. DORA aggiunge requisiti dettagliati di gestione del rischio ICT, test di resilienza, segnalazione degli incidenti e supervisione ICT di terze parti per le entità finanziarie. GDPR continua a richiedere accountability, sicurezza del trattamento, governance dei responsabili del trattamento e valutazione delle violazioni dei dati personali.
La risposta sbagliata consiste nel costruire tre programmi di conformità paralleli. Questo genera controlli duplicati, evidenze incoerenti e team sovraccarichi.
La risposta più solida consiste nell’usare ISO 27001:2022 come dorsale dei controlli. Non come certificato appeso alla parete, ma come sistema operativo per rischio, politiche, governance dei fornitori, risposta agli incidenti, mappatura della conformità ed evidenze di audit.
Il modello operativo di Clarysec è semplice: usare il SGSI ISO 27001:2022 come sistema organizzativo, usare la Dichiarazione di Applicabilità come collegamento, usare le politiche come regole operative applicabili e usare Zenith Controls: la guida alla conformità trasversale come bussola per la conformità trasversale. Costruire una volta, mappare con cura, dimostrare in modo continuo.
Perché ISO 27001:2022 funziona come dorsale della conformità
NIS2 e DORA hanno ambiti di applicazione, meccanismi giuridici e modelli di supervisione diversi. NIS2 si applica a soggetti essenziali e importanti in diversi settori. DORA si applica alle entità finanziarie e introduce requisiti dettagliati per la resilienza operativa digitale. GDPR si concentra sul trattamento dei dati personali e sull’accountability.
Tuttavia, le domande operative alla base di questi quadri di riferimento si sovrappongono:
- La cibersicurezza è governata da politiche approvate dalla direzione?
- I rischi per la sicurezza delle informazioni e i rischi ICT sono identificati, valutati e trattati?
- I controlli sono selezionati in base al rischio, al contesto aziendale e agli obblighi legali?
- I fornitori sono governati tramite due diligence, contratti, monitoraggio e controlli di uscita?
- Il personale è in grado di riconoscere e segnalare tempestivamente gli eventi di sicurezza?
- Gli incidenti possono essere sottoposti a triage, escalation, indagine e valutazione ai fini della notifica normativa?
- L’organizzazione può recuperare rapidamente le evidenze durante un audit, un riesame da parte di un cliente o una richiesta dell’autorità di vigilanza?
ISO 27001:2022 offre alla leadership un sistema di gestione per rispondere in modo coerente a queste domande. ISO/IEC 27007:2022 tratta la Dichiarazione di Applicabilità come un elenco verificabile in audit dei controlli di sicurezza delle informazioni selezionati, inclusi i controlli dell’Allegato A di ISO 27001:2022, di altri standard o misure specifiche dell’organizzazione, con una motivazione documentata per l’inclusione o l’esclusione. ISO/IEC 27006-1:2024 rafforza il principio secondo cui la SoA e la documentazione SGSI correlata costituiscono una base di evidenze fondamentale per mostrare quali controlli sono richiesti, come sono assegnate le responsabilità e come le politiche sono attuate e comunicate.
Questo rende la SoA molto più di un foglio di calcolo. Diventa il contratto dei controlli tra rischio, conformità, operation, legale, procurement, audit e consiglio di amministrazione.
La [P01] Politica per la sicurezza delle informazioni di Clarysec ancora questo requisito di governance:
L’organizzazione deve implementare e mantenere un Sistema di gestione della sicurezza delle informazioni (SGSI) in conformità alle clausole da 4 a 10 di ISO/IEC 27001:2022.
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.1.1.
Questo è importante perché le richieste di evidenze NIS2 e DORA raramente arrivano nel linguaggio ISO. Un’autorità di regolamentazione, un cliente o un comitato del consiglio di amministrazione possono chiedere prove della gestione dei rischi di cibersicurezza, della governance ICT, della supervisione delle dipendenze da terze parti, dell’escalation degli incidenti o dei test di resilienza operativa. Il SGSI ISO 27001:2022 dà struttura a queste risposte.
La SoA è il collegamento, non un esercizio documentale
In Zenith Blueprint: roadmap in 30 passi per l’auditor, fase Gestione del rischio, Step 13, Clarysec inquadra la SoA come il principale meccanismo di tracciabilità tra trattamento del rischio e controlli implementati:
La SoA è di fatto un documento di collegamento: collega la valutazione/il trattamento del rischio ai controlli effettivamente presenti.
Questa frase è il nucleo della conformità trasversale. Un controllo privo di tracciabilità diventa un elemento isolato. Un controllo collegato a un rischio, a un obbligo legale, a una politica, a un responsabile, a una registrazione dell’evidenza e a un risultato di test diventa pronto per l’audit.
Lo Step 13 raccomanda inoltre di aggiungere riferimenti ai controlli negli scenari di rischio, ad esempio collegando uno scenario di violazione di una banca dati clienti al controllo degli accessi, alla crittografia, alla gestione delle vulnerabilità, alla risposta agli incidenti e ai controlli sui fornitori. Raccomanda inoltre di indicare quando i controlli supportano requisiti esterni come GDPR, NIS2 o DORA.
La [P06] Politica di gestione del rischio di Clarysec rende esplicita questa regola operativa:
Le decisioni sui controlli derivanti dal processo di trattamento del rischio devono essere riportate nella SoA.
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.5.1.
Per le organizzazioni più piccole, la Politica di gestione del rischio - PMI applica la stessa logica:
Assicura che la gestione del rischio sia una componente attiva della pianificazione, dell’esecuzione dei progetti, della selezione dei fornitori e della risposta agli incidenti, in allineamento con ISO 27001, ISO 31000 e i requisiti normativi applicabili.
Dalla sezione “Finalità”, clausola della politica 1.2.
Se un trattamento del rischio di terze parti DORA, una misura di gestione degli incidenti NIS2 o un requisito di sicurezza per un responsabile del trattamento GDPR non è riportato nella SoA o nel relativo Registro di conformità, l’organizzazione potrebbe comunque svolgere le attività necessarie. Tuttavia, faticherà a dimostrarle in modo coerente.
Una mappatura pratica ISO 27001:2022 per NIS2 e DORA
La seguente mappatura non costituisce consulenza legale. È un modello pratico di evidenze per CISO, responsabili della conformità, auditor interni e titolari dell’attività che devono allineare le evidenze ISO 27001:2022 alle aspettative NIS2 e DORA.
ENISA, in collaborazione con la Commissione europea e il gruppo di cooperazione NIS, ha fornito indicazioni consultive di correlazione che aiutano ad allineare i requisiti di cibersicurezza dell’UE agli standard internazionali e nazionali, incluso ISO 27001. Tali indicazioni non sono giuridicamente vincolanti e devono essere integrate con le istruzioni delle autorità nazionali, le regole di settore e il riesame legale. Tuttavia, supportano un approccio di mappatura difendibile.
| Domanda di conformità | Evidenza della dorsale ISO 27001:2022 | Rilevanza NIS2 | Rilevanza DORA | Elemento di evidenza Clarysec |
|---|---|---|---|---|
| La cibersicurezza è governata da politiche approvate dalla direzione? | Politica per la sicurezza delle informazioni, campo di applicazione del SGSI, ruoli, registrazioni dei riesami della direzione, SoA | Aspettative di governance e gestione dei rischi di cibersicurezza | Governance ICT e quadro di riferimento per la gestione del rischio ICT | Politica per la sicurezza delle informazioni, SoA, pacchetto per il riesame della direzione |
| I rischi sono valutati e trattati? | Registro dei rischi, piano di trattamento del rischio, motivazioni della SoA, approvazioni del rischio residuo | Misure di cibersicurezza basate sul rischio ai sensi dell’Article 21 | Identificazione, protezione, prevenzione, rilevazione, risposta e ripristino del rischio ICT | Registro dei rischi, Piano di trattamento del rischio, SoA_Builder.xlsx |
| I fornitori sono controllati? | Politica sui fornitori, registrazioni di due diligence, contratti, diritto di audit, clausole di notifica della violazione | Cibersicurezza della catena di fornitura ai sensi dell’Article 21(2)(d) | Gestione del rischio ICT di terze parti ai sensi degli Articles 28 to 30 | Politica di sicurezza delle terze parti e dei fornitori, registro dei fornitori |
| Gli incidenti sono rilevati, sottoposti a escalation e segnalati? | Piano di risposta agli incidenti, canale di segnalazione, registrazioni di triage, esercitazioni tabletop, lezioni apprese | Gestione e segnalazione degli incidenti significativi ai sensi dell’Article 23 | Gestione e segnalazione degli incidenti connessi all’ICT ai sensi degli Articles 17 to 19 | Politica di risposta agli incidenti, ticket di incidente, report di esercitazione |
| Le evidenze sono centralizzate e verificabili in audit? | Programma di audit interno, repository delle evidenze, Registro di conformità, azioni correttive | Disponibilità delle evidenze ai fini della vigilanza | Preparazione alle ispezioni regolatorie e di vigilanza | Politica di audit e monitoraggio della conformità, cartella di audit centrale |
La mappatura funziona perché non crea controlli duplicati per ciascuna normativa. Usa ISO 27001:2022 come dorsale dei controlli e aggiunge tag normativi, titolarità e aspettative sulle evidenze.
Tre controlli ISO 27001:2022 che sbloccano la dorsale
Diversi controlli sono rilevanti per NIS2 e DORA, ma tre controlli ISO/IEC 27002:2022 diventano spesso la spina dorsale del modello di evidenze: 5.1, 5.19 e 5.24. Un quarto controllo, 6.8, spesso determina se la segnalazione degli incidenti funziona davvero.
| Controllo ISO/IEC 27002:2022 | Perché è importante | Valore per la conformità trasversale |
|---|---|---|
| 5.1 Politiche per la sicurezza delle informazioni | Stabilisce l’indirizzo di sicurezza approvato dalla direzione e l’accountability | Supporta la governance NIS2, la governance ICT DORA, l’accountability GDPR e le evidenze delle politiche ISO 27001 |
| 5.19 Sicurezza delle informazioni nei rapporti con i fornitori | Definisce le aspettative di sicurezza dei fornitori lungo onboarding, monitoraggio e gestione del rapporto | Supporta la cibersicurezza della catena di fornitura NIS2, il rischio ICT di terze parti DORA e la supervisione dei responsabili del trattamento GDPR |
| 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni | Crea il quadro di riferimento per la gestione degli incidenti, i ruoli, i percorsi di escalation e le attività di preparazione | Supporta la gestione degli incidenti NIS2, la segnalazione degli incidenti connessi all’ICT DORA e la valutazione delle violazioni GDPR |
| 6.8 Segnalazione degli eventi di sicurezza delle informazioni | Assicura che il personale possa segnalare rapidamente gli eventi sospetti tramite canali chiari | Supporta la rilevazione precoce, l’escalation, la valutazione della notifica e la qualità delle evidenze sugli incidenti |
In Zenith Controls, il controllo ISO/IEC 27002:2022 5.1, Politiche per la sicurezza delle informazioni, è qualificato come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con governance e gestione delle politiche come capacità operative fondamentali. La mappatura trasversale spiega che gli Articles 5(2), 24 e 32 del GDPR richiedono accountability, responsabilità e sicurezza del trattamento. Mappa inoltre lo stesso controllo alle aspettative NIS2 di gestione dei rischi di cibersicurezza e governance, nonché ai requisiti DORA di governance ICT e quadro di riferimento per la gestione del rischio.
Per questo motivo la politica per la sicurezza delle informazioni non è solo un’altra politica. Un valutatore NIS2 può leggerla come evidenza di governance. Un’autorità di vigilanza DORA può leggerla come evidenza del quadro di riferimento per il rischio ICT. Un auditor GDPR può leggerla come evidenza di accountability. Un auditor ISO 27001:2022 può leggerla come parte della struttura delle politiche del SGSI.
Il controllo 5.19, Sicurezza delle informazioni nei rapporti con i fornitori, è il punto in cui procurement, legale, sicurezza, privacy e resilienza convergono. Zenith Controls lo mappa agli obblighi GDPR dei responsabili del trattamento, alla cibersicurezza della catena di fornitura NIS2 e alla gestione del rischio ICT di terze parti DORA. Per DORA, questa evidenza diventa ancora più solida quando è supportata dai controlli 5.20, Gestione della sicurezza delle informazioni negli accordi con i fornitori, 5.21, Gestione della sicurezza delle informazioni nella catena di fornitura ICT, e 5.23, Sicurezza delle informazioni per l’uso dei servizi cloud.
Il controllo 5.24, Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, è il motore operativo della preparazione agli incidenti. Zenith Controls lo mappa alla gestione e alla notifica degli incidenti NIS2, alla notifica delle violazioni dei dati personali GDPR e alla gestione e segnalazione degli incidenti connessi all’ICT DORA. Le sue evidenze non si limitano a una politica di risposta agli incidenti. Includono canali di segnalazione, criteri di triage, registrazioni di escalation, valutazioni legali di notifica, esercitazioni tabletop, ticket di incidente e lezioni apprese.
Il controllo 6.8, Segnalazione degli eventi di sicurezza delle informazioni, colma il divario tra il piano scritto e il comportamento umano. Se il personale non sa come segnalare sospetti di phishing, perdite di dati, indisponibilità dei fornitori o attività di sistema sospette, l’organizzazione può perdere tempo critico prima ancora che inizino le valutazioni legali o regolatorie di notifica.
Un incidente del fornitore, una catena coordinata di evidenze
Immagina che un fornitore di analisi cloud utilizzato dal prestatore di servizi di pagamento di Maria rilevi un accesso non autorizzato a un portale di supporto. Il fornitore ospita dati pseudonimizzati sull’utilizzo da parte dei clienti e supporta un flusso di reportistica critico per l’attività. L’incidente può incidere sui dati personali, sulla resilienza ICT regolamentata e sulla disponibilità del servizio.
Un programma di conformità frammentato apre tre flussi di lavoro separati: una valutazione della violazione GDPR, un riesame dell’incidente ICT DORA e un ticket fornitore ISO 27001. Ogni team chiede evidenze simili in un formato diverso. Il procurement cerca il contratto. Il legale chiede se il fornitore sia un responsabile del trattamento. La sicurezza chiede se l’incidente soddisfi le soglie di segnalazione. La funzione di conformità apre un nuovo foglio di calcolo.
Una dorsale ISO 27001:2022 matura apre una sola catena coordinata di evidenze.
In primo luogo, l’evento viene registrato nell’ambito del processo di risposta agli incidenti. Il segnalante usa un canale definito, il team di sicurezza esegue il triage dell’evento e il legale valuta gli obblighi di notifica. La [P30] Politica di risposta agli incidenti di Clarysec richiede che gli incidenti relativi a dati regolamentati siano valutati dalla funzione legale e dal DPO:
Se un incidente comporta l’esposizione confermata o probabile di dati personali o altri dati regolamentati, la funzione legale e il DPO devono valutare l’applicabilità di:
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.4.1.
Per le organizzazioni più piccole, la Politica di risposta agli incidenti per PMI assegna lo stesso punto decisionale pratico:
Quando sono coinvolti dati dei clienti, il Direttore generale deve valutare gli obblighi legali di notifica in base all’applicabilità di GDPR, NIS2 o DORA.
Dalla sezione “Trattamento del rischio ed eccezioni”, clausola della politica 7.4.1.
In secondo luogo, viene riesaminato il rapporto con il fornitore. Il fornitore era classificato come critico? Il contratto includeva obblighi di notifica della violazione, diritto di audit, responsabilità in materia di protezione dei dati, aspettative di continuità del servizio e disposizioni di uscita? La Politica di sicurezza delle terze parti e dei fornitori di Clarysec stabilisce questa aspettativa:
Integrare requisiti di sicurezza standardizzati in tutti i contratti con i fornitori, inclusi obblighi di notifica della violazione, diritto di audit e responsabilità in materia di protezione dei dati.
Dalla sezione “Obiettivi”, clausola della politica 3.2.
Per le PMI, la Politica di sicurezza delle terze parti e dei fornitori per PMI rende esplicita la finalità di conformità trasversale:
Supportare la conformità agli obblighi ISO/IEC 27001:2022, GDPR, NIS2 e DORA relativi alla governance dei fornitori.
Dalla sezione “Obiettivi”, clausola della politica 3.6.
In terzo luogo, il Registro dei rischi, il piano di trattamento e la SoA vengono aggiornati se l’incidente rivela una lacuna. Forse il contratto con il fornitore non prevede una tempistica specifica di notifica normativa. Forse la frequenza di monitoraggio del fornitore è troppo bassa per un fornitore ICT critico. Forse il piano di risposta agli incidenti non distingue chiaramente i criteri di violazione dei dati personali dai criteri di interruzione del servizio ICT.
Il punto non è creare un nuovo universo di conformità. Il punto è aggiornare una catena integrata di evidenze affinché le stesse registrazioni possano rispondere a più domande di audit.
Trasformare la SoA in una mappa di evidenze per NIS2 e DORA
Una SoA standard spesso risponde bene alle domande ISO: quali controlli sono applicabili, perché sono selezionati e se sono implementati. Per trasformarla in una mappa pratica di evidenze NIS2 e DORA, arricchiscila con campi normativi e operativi relativi alle evidenze.
Apri il file SoA_Builder.xlsx dell’Audit Ready Toolkit richiamato in Zenith Blueprint, fase Audit, riesame e miglioramento, Step 24. Lo Step 24 spiega che gli auditor spesso campionano un controllo dalla SoA e chiedono perché sia stato implementato. La colonna della motivazione e il rischio o requisito collegato devono rispondere a questa domanda.
Aggiungi queste colonne:
| Nuova colonna SoA | Finalità | Esempio di voce |
|---|---|---|
| Driver normativo | Mostra se il controllo supporta NIS2, DORA, GDPR, contratti con i clienti o resilienza | NIS2, DORA, GDPR |
| ID rischio mappato | Collega il controllo al Registro dei rischi | R-017 Indisponibilità del fornitore che incide sulla reportistica regolamentata |
| Proprietario dell’evidenza | Identifica chi mantiene la prova | Responsabile delle operation di sicurezza |
| Evidenza primaria | Definisce l’elemento che gli auditor devono ispezionare per primo | Piano di risposta agli incidenti e log dei ticket di incidente |
| Evidenza operativa | Mostra che il controllo funziona nel tempo | Report di esercitazione tabletop, test di notifica della violazione del fornitore |
| Stato dell’audit | Traccia la preparazione | Testato, lacuna aperta, azione correttiva in scadenza |
Applicalo ora al set di controlli principali.
| Controllo ISO/IEC 27002:2022 | Driver normativo | Evidenza primaria | Evidenza operativa | Conclusione dell’auditor |
|---|---|---|---|---|
| 5.1 Politiche per la sicurezza delle informazioni | NIS2, DORA, GDPR | Politica per la sicurezza delle informazioni approvata, campo di applicazione del SGSI, assegnazione dei ruoli | Registrazione del riesame della politica, attestazione di formazione, verbali del riesame della direzione | La governance esiste, la direzione ha approvato l’indirizzo e l’accountability è documentata |
| 5.19 Sicurezza delle informazioni nei rapporti con i fornitori | NIS2, DORA, GDPR | Politica sui fornitori, registro dei fornitori, classificazione dei fornitori | Riesami di due diligence, valutazioni di criticità, riesami contrattuali, evidenza del diritto di audit | Il rischio di terze parti è governato lungo onboarding, contrattualizzazione, monitoraggio e uscita |
| 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori | NIS2, DORA, GDPR | Clausole contrattuali standard, allegato di sicurezza, termini sul trattamento dei dati | Campionamento dei contratti, approvazioni delle eccezioni alle clausole, registrazioni del riesame legale | I requisiti di sicurezza sono integrati negli accordi con i fornitori |
| 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud | DORA, NIS2, GDPR | Standard di sicurezza cloud, valutazione del rischio cloud, approvazione dell’architettura | Riesame del fornitore cloud, riesame del rischio di concentrazione, test di incidente cloud | Il rischio dei servizi cloud è identificato, governato, monitorato e testato |
| 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni | NIS2, DORA, GDPR | Politica di risposta agli incidenti, matrice di escalation, albero decisionale di notifica | Ticket di incidente, report tabletop, lezioni apprese, valutazioni di notifica | Gli incidenti possono essere rilevati, sottoposti a triage, escalati e valutati ai fini della segnalazione normativa |
| 6.8 Segnalazione degli eventi di sicurezza delle informazioni | NIS2, DORA, GDPR | Canale di segnalazione, materiale di sensibilizzazione, procedura di segnalazione degli eventi | Segnalazioni di phishing, log della hotline, registrazioni delle simulazioni, interviste al personale | Il personale sa come segnalare rapidamente gli eventi di sicurezza sospetti |
Esegui quindi una traccia campione. Seleziona un incidente di fornitore dell’ultimo anno e seguilo dal ticket di incidente al contratto del fornitore, dalla classificazione del fornitore al Registro dei rischi, dal trattamento del rischio alla SoA e dalla SoA al riesame della direzione.
Se la catena si interrompe, non è un fallimento. È un’azione correttiva precisa prima che un auditor, un cliente, un’autorità di regolamentazione o un comitato del consiglio di amministrazione individui la lacuna.
Le evidenze centralizzate sono l’acceleratore sottovalutato
Molte organizzazioni dispongono di controlli adeguati ma di un recupero delle evidenze debole. Le prove sono disperse tra e-mail, sistemi di ticketing, cartelle SharePoint, repository contrattuali, piattaforme HR, strumenti GRC e portali dei fornitori. Durante la stagione degli audit, il team di conformità trascorre settimane a cercare screenshot.
Questa non è preparazione agli audit. È recupero d’emergenza per l’audit.
La [P33S] Politica di audit e monitoraggio della conformità per PMI di Clarysec stabilisce:
Tutte le evidenze devono essere archiviate in una cartella di audit centralizzata.
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.
Una cartella di audit centralizzata non significa un deposito incontrollato. Significa un repository strutturato allineato a SGSI, SoA, Registro dei rischi, Piano di audit e Registro di conformità.
| Cartella | Contenuti | Uso per la conformità trasversale |
|---|---|---|
| 01 Governance | Campo di applicazione del SGSI, politica per la sicurezza delle informazioni, assegnazione dei ruoli, verbali del riesame della direzione | Governance NIS2, governance ICT DORA, accountability GDPR |
| 02 Rischio e SoA | Registro dei rischi, piano di trattamento del rischio, SoA, approvazioni del rischio residuo | Gestione del rischio NIS2, gestione del rischio ICT DORA |
| 03 Fornitori | Registro dei fornitori, due diligence, contratti, classificazioni di criticità, registrazioni dei riesami | Catena di fornitura NIS2, rischio ICT di terze parti DORA, responsabili del trattamento GDPR |
| 04 Incidenti | Ticket di incidente, valutazioni delle violazioni, decisioni di notifica, esercitazioni tabletop | Segnalazione NIS2, gestione degli incidenti DORA, notifica delle violazioni GDPR |
| 05 Audit e miglioramento | Report di audit interno, azioni correttive, campionamento delle evidenze, follow-up della direzione | Preparazione agli audit ISO 27001:2022, preparazione ai fini della vigilanza |
La Politica di conformità legale e normativa per PMI di Clarysec affronta direttamente il problema della mappatura:
Quando una normativa si applica a più aree (ad es. GDPR si applica a conservazione, sicurezza e privacy), ciò deve essere chiaramente mappato nel Registro di conformità e nei materiali formativi.
Dalla sezione “Requisiti di governance”, clausola della politica 5.2.2.
È esattamente così che ISO 27001:2022 diventa la dorsale dei controlli per NIS2 e DORA. Non ci si affida alla conoscenza informale. Si mappano le normative su processi, politiche, controlli, evidenze e formazione.
La segnalazione degli incidenti inizia dalle persone, non dai portali
Una debolezza di audit comune emerge quando il piano di risposta agli incidenti appare solido, ma i dipendenti non sanno quando o come segnalare. Questo è rischioso per NIS2, DORA e GDPR perché le tempistiche di valutazione normativa dipendono da rilevazione, escalation e classificazione.
In Zenith Blueprint, fase Controlli in azione, Step 16, Clarysec enfatizza la segnalazione degli incidenti guidata dal personale ai sensi del controllo ISO/IEC 27002:2022 6.8. Le linee guida affermano che la risposta agli incidenti inizia dalle persone. Le organizzazioni devono creare un canale di segnalazione chiaro, semplice e accessibile, come un indirizzo e-mail monitorato, un portale interno, una hotline o una categoria del sistema di ticketing. Raccomandano inoltre formazione e sensibilizzazione, una cultura della segnalazione senza colpevolizzazione, riservatezza, segnalazione a bassa soglia e simulazioni periodiche.
L’impatto sulla conformità trasversale è diretto. Zenith Blueprint collega questa capacità di segnalazione del personale al GDPR Article 33, al NIS2 Article 23 e al DORA Article 17. Se i dipendenti esitano a segnalare attività sospette, l’organizzazione può perdere tempo critico prima che i team legali, di sicurezza o regolatori possano valutare gli obblighi di notifica.
Un test pratico del controllo è semplice:
- Chiedere a cinque dipendenti come segnalare una e-mail di phishing sospetta.
- Verificare se il canale di segnalazione è monitorato.
- Confermare se il sistema di ticketing dispone di una categoria per gli incidenti di sicurezza.
- Riesaminare l’ultima simulazione o esercitazione tabletop.
- Verificare che le lezioni apprese siano state riesaminate nel riesame della direzione.
Se una risposta non è chiara, aggiornare la scheda di istruzioni sugli incidenti, il materiale formativo, il canale di segnalazione e il riferimento alle evidenze nella SoA.
Come auditor diversi ispezionano la stessa dorsale
Le evidenze di conformità trasversale devono reggere a prospettive di audit diverse. Lo stesso controllo può essere testato in modo diverso in base al mandato dell’auditor.
| Prospettiva dell’auditor | Domanda probabile | Evidenze attese | Errore comune |
|---|---|---|---|
| Auditor ISO 27001:2022 | Perché questo controllo è applicabile e funziona come descritto? | Motivazione della SoA, collegamento al trattamento del rischio, politica, registrazioni operative, risultati dell’audit interno | Il controllo esiste, ma la motivazione della SoA è vaga o non aggiornata |
| Valutatore orientato a NIS2 | Potete dimostrare misure di cibersicurezza basate sul rischio e coordinamento degli incidenti? | Registro dei rischi, politica di governance, piano per gli incidenti, flusso di segnalazione, evidenze del rischio dei fornitori | La mappatura NIS2 esiste in un set di slide ma non nelle evidenze operative |
| Autorità di vigilanza orientata a DORA | Potete dimostrare gestione del rischio ICT, classificazione degli incidenti, test e supervisione delle terze parti? | Registro dei rischi ICT, criticità dei fornitori, classificazione degli incidenti, test di resilienza, clausole contrattuali | Le registrazioni sui fornitori non distinguono i fornitori ICT critici dai fornitori ordinari |
| Auditor orientato a GDPR | Potete dimostrare accountability, sicurezza del trattamento, controlli sui responsabili del trattamento e valutazione delle violazioni? | Mappatura della protezione dei dati, clausole con i responsabili del trattamento, registrazioni delle valutazioni delle violazioni, evidenze di accesso e cifratura | I controlli di sicurezza sono implementati ma non collegati ai rischi sui dati personali |
| Auditor orientato a NIST | Potete mostrare governance, identificazione del rischio, protezione, rilevazione, risposta e ripristino? | Governance delle politiche, registrazioni degli asset e dei rischi, log di rilevazione, evidenze di incidente e ripristino | Le evidenze tecniche esistono, ma la titolarità di governance è debole |
| Auditor COBIT 2019 o in stile ISACA | Sono definiti obiettivi di governance, responsabilità, monitoraggio delle prestazioni e attività di assurance? | RACI, titolarità dei controlli, reportistica alla direzione, piano di audit, metriche, azioni correttive | I controlli sono tecnici ma non governati tramite accountability misurabile |
È qui che Zenith Controls aggiunge valore oltre una semplice tabella di mappatura. Aiuta a tradurre i controlli ISO/IEC 27002:2022 in prospettive rilevanti per l’audit, inclusi attributi dei controlli, relazioni normative e aspettative sulle evidenze. Per il controllo 5.1, gli attributi supportano governance, gestione delle politiche, accountability e obiettivi di sicurezza. Per il controllo 5.24, gli attributi supportano i concetti di risposta e ripristino, preparazione agli incidenti e azione correttiva. Per il controllo 5.19, gli attributi relativi al rapporto con i fornitori collegano governance, rischio dell’ecosistema, protezione e supervisione di terze parti.
Cosa deve vedere il consiglio di amministrazione
Il consiglio di amministrazione non ha bisogno di ogni singola riga della SoA. Ha però bisogno della storia che la SoA racconta.
Un pacchetto efficace per il consiglio di amministrazione sull’allineamento tra ISO 27001:2022, NIS2 e DORA deve includere:
- Campo di applicazione del SGSI e servizi aziendali coperti.
- Principali rischi per la sicurezza delle informazioni e rischi ICT.
- Sintesi dei controlli applicabili per dominio.
- Stato della mappatura NIS2, DORA e GDPR.
- Fornitori critici e rischi di concentrazione.
- Metriche di segnalazione degli incidenti ed esiti delle esercitazioni tabletop.
- Azioni correttive aperte e trattamenti del rischio scaduti.
- Decisioni necessarie su accettazione del rischio, budget, titolarità e risorse.
Questo trasforma la conformità in evidenza di governance. Si allinea inoltre alla finalità del controllo 5.1 in Zenith Controls, in cui le politiche per la sicurezza delle informazioni supportano l’indirizzo a livello esecutivo, l’accountability e gli obiettivi di sicurezza.
Errori comuni da evitare
Il primo errore consiste nel presumere che la certificazione ISO 27001:2022 dimostri automaticamente la conformità a NIS2 o DORA. Non è così. ISO 27001:2022 offre un sistema di gestione e una dorsale dei controlli solidi, ma servono comunque perimetrazione normativa, analisi legale, interpretazione specifica di settore, flussi di notifica e consapevolezza delle aspettative delle autorità nazionali.
Il secondo errore consiste nel trattare la SoA come statica. La SoA deve evolvere quando emergono nuovi fornitori, sistemi, incidenti, normative, servizi o rischi. Zenith Blueprint, Step 24, raccomanda di verificare in modo incrociato la SoA rispetto al Registro dei rischi e al piano di trattamento, assicurando che ogni controllo selezionato abbia una motivazione basata su rischio mappato, requisito legale o esigenza aziendale.
Il terzo errore consiste nel mappare a un livello troppo alto. Una slide che afferma “ISO 27001 si mappa su DORA” non è evidenza di audit. Una specifica voce della SoA che collega la sicurezza dei rapporti con i fornitori a un rischio relativo a un fornitore ICT critico, a una clausola contrattuale, a una registrazione di riesame del fornitore e a un’aspettativa DORA di supervisione di terze parti è molto più solida.
Il quarto errore consiste nel non centralizzare le evidenze. Se il responsabile della conformità impiega due settimane a raccogliere screenshot prima di ogni audit, l’organizzazione ha un problema di recupero delle evidenze.
Il quinto errore consiste nell’ignorare i controlli relativi al personale. Segnalazione degli incidenti, onboarding dei fornitori, riesame degli accessi, accettazione della politica ed escalation dipendono tutti dal comportamento umano. Un processo impeccabile che nessuno segue crollerà sotto il campionamento dell’audit.
Il modello operativo Clarysec per la conformità trasversale
Il metodo Clarysec collega la storia della conformità dalla strategia alle evidenze:
- In Zenith Blueprint, fase Gestione del rischio, Step 13, mappi i controlli sui rischi e costruisci la SoA come documento di collegamento.
- In Zenith Blueprint, fase Gestione del rischio, Step 14, referenzi in modo incrociato i requisiti GDPR, NIS2 e DORA rispetto a politiche e controlli.
- In Zenith Blueprint, fase Controlli in azione, Step 16, rendi operativa la segnalazione degli incidenti guidata dalle persone affinché l’escalation inizi tempestivamente.
- In Zenith Blueprint, fase Audit, riesame e miglioramento, Step 24, finalizzi e testi la SoA, la verifichi in modo incrociato rispetto al piano di trattamento del rischio e la prepari come uno dei primi documenti che un auditor richiederà.
Questo metodo è supportato dalle politiche Clarysec che trasformano i principi in regole operative: governance della sicurezza delle informazioni, trattamento del rischio, sicurezza dei fornitori, risposta agli incidenti, mappatura legale e normativa e archiviazione delle evidenze.
Il risultato non è solo la preparazione a ISO 27001:2022. È un sistema riutilizzabile di evidenze di conformità per NIS2, DORA, GDPR, assurance dei clienti, audit interno e supervisione del consiglio di amministrazione.
Prossimi passi: costruire una volta, dimostrare molte volte
Se la tua organizzazione affronta NIS2, DORA, GDPR, audit dei clienti o pressione per la certificazione ISO 27001:2022, inizia dalla dorsale.
- Riesamina la tua SoA e aggiungi colonne sui driver normativi per NIS2, DORA e GDPR.
- Verifica in modo incrociato la SoA rispetto al tuo Registro dei rischi e al piano di trattamento del rischio.
- Mappa i fornitori critici sui controlli di sicurezza dei fornitori, sulle clausole contrattuali e sulle evidenze di monitoraggio.
- Testa il flusso di segnalazione degli incidenti con un’esercitazione tabletop.
- Centralizza le evidenze di audit per controllo, normativa, proprietario e stato del test.
- Usa Zenith Controls per tradurre i controlli ISO/IEC 27002:2022 in evidenze di conformità trasversale.
- Usa Zenith Blueprint per passare dal trattamento del rischio alla convalida della SoA pronta per l’audit.
- Implementa il set di politiche Clarysec, incluse la Politica per la sicurezza delle informazioni, la Politica di gestione del rischio, la Politica di sicurezza delle terze parti e dei fornitori e la Politica di risposta agli incidenti, per accelerare l’applicazione.
Il percorso più rapido non consiste in ulteriori checklist scollegate. Consiste in un SGSI integrato, una SoA tracciabile, un modello centralizzato di evidenze e un ritmo operativo unico per la conformità trasversale.
Clarysec può aiutarti a trasformare ISO 27001:2022 da progetto di certificazione a dorsale pratica dei controlli per NIS2 e DORA. Scarica Zenith Blueprint, esplora Zenith Controls oppure prenota una valutazione Clarysec per costruire un modello di evidenze pronto per l’audit prima che la prossima autorità di regolamentazione, il prossimo cliente o il prossimo comitato del consiglio di amministrazione chieda prove.
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


