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

ISO 27001 come dorsale delle evidenze per NIS2 e DORA

Igor Petreski
14 min read
Dorsale dei controlli ISO 27001 per la mappatura di NIS2, DORA ed evidenze di audit

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:2022Rilevanza NIS2Rilevanza DORAElemento 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, SoAAspettative di governance e gestione dei rischi di cibersicurezzaGovernance ICT e quadro di riferimento per la gestione del rischio ICTPolitica 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 residuoMisure di cibersicurezza basate sul rischio ai sensi dell’Article 21Identificazione, protezione, prevenzione, rilevazione, risposta e ripristino del rischio ICTRegistro 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 violazioneCibersicurezza della catena di fornitura ai sensi dell’Article 21(2)(d)Gestione del rischio ICT di terze parti ai sensi degli Articles 28 to 30Politica 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 appreseGestione e segnalazione degli incidenti significativi ai sensi dell’Article 23Gestione e segnalazione degli incidenti connessi all’ICT ai sensi degli Articles 17 to 19Politica 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 correttiveDisponibilità delle evidenze ai fini della vigilanzaPreparazione alle ispezioni regolatorie e di vigilanzaPolitica 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:2022Perché è importanteValore per la conformità trasversale
5.1 Politiche per la sicurezza delle informazioniStabilisce l’indirizzo di sicurezza approvato dalla direzione e l’accountabilitySupporta 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 fornitoriDefinisce le aspettative di sicurezza dei fornitori lungo onboarding, monitoraggio e gestione del rapportoSupporta 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 informazioniCrea il quadro di riferimento per la gestione degli incidenti, i ruoli, i percorsi di escalation e le attività di preparazioneSupporta 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 informazioniAssicura che il personale possa segnalare rapidamente gli eventi sospetti tramite canali chiariSupporta 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 SoAFinalitàEsempio di voce
Driver normativoMostra se il controllo supporta NIS2, DORA, GDPR, contratti con i clienti o resilienzaNIS2, DORA, GDPR
ID rischio mappatoCollega il controllo al Registro dei rischiR-017 Indisponibilità del fornitore che incide sulla reportistica regolamentata
Proprietario dell’evidenzaIdentifica chi mantiene la provaResponsabile delle operation di sicurezza
Evidenza primariaDefinisce l’elemento che gli auditor devono ispezionare per primoPiano di risposta agli incidenti e log dei ticket di incidente
Evidenza operativaMostra che il controllo funziona nel tempoReport di esercitazione tabletop, test di notifica della violazione del fornitore
Stato dell’auditTraccia la preparazioneTestato, lacuna aperta, azione correttiva in scadenza

Applicalo ora al set di controlli principali.

Controllo ISO/IEC 27002:2022Driver normativoEvidenza primariaEvidenza operativaConclusione dell’auditor
5.1 Politiche per la sicurezza delle informazioniNIS2, DORA, GDPRPolitica per la sicurezza delle informazioni approvata, campo di applicazione del SGSI, assegnazione dei ruoliRegistrazione del riesame della politica, attestazione di formazione, verbali del riesame della direzioneLa governance esiste, la direzione ha approvato l’indirizzo e l’accountability è documentata
5.19 Sicurezza delle informazioni nei rapporti con i fornitoriNIS2, DORA, GDPRPolitica sui fornitori, registro dei fornitori, classificazione dei fornitoriRiesami di due diligence, valutazioni di criticità, riesami contrattuali, evidenza del diritto di auditIl rischio di terze parti è governato lungo onboarding, contrattualizzazione, monitoraggio e uscita
5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitoriNIS2, DORA, GDPRClausole contrattuali standard, allegato di sicurezza, termini sul trattamento dei datiCampionamento dei contratti, approvazioni delle eccezioni alle clausole, registrazioni del riesame legaleI requisiti di sicurezza sono integrati negli accordi con i fornitori
5.23 Sicurezza delle informazioni per l’uso dei servizi cloudDORA, NIS2, GDPRStandard di sicurezza cloud, valutazione del rischio cloud, approvazione dell’architetturaRiesame del fornitore cloud, riesame del rischio di concentrazione, test di incidente cloudIl rischio dei servizi cloud è identificato, governato, monitorato e testato
5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioniNIS2, DORA, GDPRPolitica di risposta agli incidenti, matrice di escalation, albero decisionale di notificaTicket di incidente, report tabletop, lezioni apprese, valutazioni di notificaGli incidenti possono essere rilevati, sottoposti a triage, escalati e valutati ai fini della segnalazione normativa
6.8 Segnalazione degli eventi di sicurezza delle informazioniNIS2, DORA, GDPRCanale di segnalazione, materiale di sensibilizzazione, procedura di segnalazione degli eventiSegnalazioni di phishing, log della hotline, registrazioni delle simulazioni, interviste al personaleIl 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à.

CartellaContenutiUso per la conformità trasversale
01 GovernanceCampo di applicazione del SGSI, politica per la sicurezza delle informazioni, assegnazione dei ruoli, verbali del riesame della direzioneGovernance NIS2, governance ICT DORA, accountability GDPR
02 Rischio e SoARegistro dei rischi, piano di trattamento del rischio, SoA, approvazioni del rischio residuoGestione del rischio NIS2, gestione del rischio ICT DORA
03 FornitoriRegistro dei fornitori, due diligence, contratti, classificazioni di criticità, registrazioni dei riesamiCatena di fornitura NIS2, rischio ICT di terze parti DORA, responsabili del trattamento GDPR
04 IncidentiTicket di incidente, valutazioni delle violazioni, decisioni di notifica, esercitazioni tabletopSegnalazione NIS2, gestione degli incidenti DORA, notifica delle violazioni GDPR
05 Audit e miglioramentoReport di audit interno, azioni correttive, campionamento delle evidenze, follow-up della direzionePreparazione 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:

  1. Chiedere a cinque dipendenti come segnalare una e-mail di phishing sospetta.
  2. Verificare se il canale di segnalazione è monitorato.
  3. Confermare se il sistema di ticketing dispone di una categoria per gli incidenti di sicurezza.
  4. Riesaminare l’ultima simulazione o esercitazione tabletop.
  5. 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’auditorDomanda probabileEvidenze atteseErrore comune
Auditor ISO 27001:2022Perché questo controllo è applicabile e funziona come descritto?Motivazione della SoA, collegamento al trattamento del rischio, politica, registrazioni operative, risultati dell’audit internoIl controllo esiste, ma la motivazione della SoA è vaga o non aggiornata
Valutatore orientato a NIS2Potete 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 fornitoriLa mappatura NIS2 esiste in un set di slide ma non nelle evidenze operative
Autorità di vigilanza orientata a DORAPotete 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 contrattualiLe registrazioni sui fornitori non distinguono i fornitori ICT critici dai fornitori ordinari
Auditor orientato a GDPRPotete 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 cifraturaI controlli di sicurezza sono implementati ma non collegati ai rischi sui dati personali
Auditor orientato a NISTPotete 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 ripristinoLe evidenze tecniche esistono, ma la titolarità di governance è debole
Auditor COBIT 2019 o in stile ISACASono definiti obiettivi di governance, responsabilità, monitoraggio delle prestazioni e attività di assurance?RACI, titolarità dei controlli, reportistica alla direzione, piano di audit, metriche, azioni correttiveI 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.

  1. Riesamina la tua SoA e aggiungi colonne sui driver normativi per NIS2, DORA e GDPR.
  2. Verifica in modo incrociato la SoA rispetto al tuo Registro dei rischi e al piano di trattamento del rischio.
  3. Mappa i fornitori critici sui controlli di sicurezza dei fornitori, sulle clausole contrattuali e sulle evidenze di monitoraggio.
  4. Testa il flusso di segnalazione degli incidenti con un’esercitazione tabletop.
  5. Centralizza le evidenze di audit per controllo, normativa, proprietario e stato del test.
  6. Usa Zenith Controls per tradurre i controlli ISO/IEC 27002:2022 in evidenze di conformità trasversale.
  7. Usa Zenith Blueprint per passare dal trattamento del rischio alla convalida della SoA pronta per l’audit.
  8. 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

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 di audit ISO 27001 per NIS2 e DORA

Evidenze di audit ISO 27001 per NIS2 e DORA

Scopri come utilizzare l’audit interno e il riesame della direzione ISO/IEC 27001:2022 come motore unitario di evidenze per NIS2, DORA, GDPR, rischio dei fornitori, assurance verso i clienti e responsabilità del consiglio di amministrazione.

SoA ISO 27001 per la preparazione a NIS2 e DORA

SoA ISO 27001 per la preparazione a NIS2 e DORA

Scopri come utilizzare la Dichiarazione di Applicabilità ISO 27001 come ponte pronto per l’audit tra NIS2, DORA, GDPR, trattamento del rischio, fornitori, risposta agli incidenti ed evidenze.

Roadmap DORA 2026 per rischio ICT, fornitori e TLPT

Roadmap DORA 2026 per rischio ICT, fornitori e TLPT

Una roadmap DORA 2026 pratica e pronta per l’audit per le entità finanziarie che implementano gestione del rischio ICT, governo delle terze parti, segnalazione degli incidenti, test di resilienza operativa e TLPT utilizzando le politiche Clarysec, Zenith Blueprint e Zenith Controls.