Evidenze di audit ISO 27001 per NIS2 e DORA

Sono le 08:17 di martedì e il Responsabile della sicurezza delle informazioni di una società fintech SaaS in forte crescita ha tre messaggi in attesa.

Il primo arriva da un importante cliente bancario: “Inviateci l’ultimo rapporto di audit interno, i verbali del riesame della direzione, lo stato delle azioni correttive, la procedura di notifica degli incidenti, il registro dei fornitori e le evidenze della vigilanza del consiglio di amministrazione.”

Il secondo arriva dal direttore finanziario: “Rientriamo nell’ambito di applicazione di NIS2 o DORA e quali evidenze abbiamo già?”

Il terzo arriva dall’amministratore delegato: “Possiamo dichiarare di essere pronti agli audit?”

In molte organizzazioni la risposta scomoda non è che non stia accadendo nulla. È peggio. Le attività di sicurezza sono ovunque, ma le evidenze non sono da nessuna parte. Esistono controlli, ma non una traccia di audit. Esistono ticket, ma non un collegamento chiaro ai rischi. Esistono aggiornamenti alla leadership, ma non output formali del riesame della direzione. Esistono discussioni con i fornitori, ma non un registro dei fornitori, un riesame contrattuale o una strategia di uscita difendibili.

Questo divario è esattamente il punto in cui l’audit interno e il riesame della direzione ISO/IEC 27001:2022 diventano più di semplici attività di certificazione. Diventano il ritmo operativo per NIS2, DORA, GDPR, assurance verso i clienti, assicurazione cyber e responsabilità del consiglio di amministrazione.

I team SaaS, cloud, MSP, MSSP e fintech raramente falliscono perché mancano attività di sicurezza. Falliscono perché le attività sono disperse tra Slack, Jira, fogli di calcolo, portali dei fornitori, ticket SOC, file di procurement e presentazioni al consiglio. Un’autorità di regolamentazione, un auditor esterno o un cliente enterprise non vuole una spiegazione eroica. Vuole evidenze oggettive.

La soluzione pratica non è eseguire programmi di audit separati per ogni quadro di riferimento. È utilizzare il SGSI ISO 27001 come motore centrale delle evidenze, quindi etichettare tali evidenze per NIS2, DORA, GDPR e requisiti contrattuali. Se impostati correttamente, un ciclo di audit interno e un ciclo di riesame della direzione possono rispondere a molte domande di conformità.

Dalla frammentazione dei quadri di riferimento a un modello unitario di evidenze del SGSI

Molti Responsabili della sicurezza delle informazioni affrontano una variante del problema di Maria. Maria guida la sicurezza di una società SaaS B2B con clienti del settore finanziario. Il suo team ha superato un audit di certificazione ISO/IEC 27001:2022 sei mesi fa. Il SGSI sta maturando, le politiche sono seguite e i responsabili dei controlli comprendono le proprie responsabilità. Poi l’amministratore delegato inoltra due articoli, uno sulla Direttiva NIS2 e uno su DORA, con una domanda sintetica: “Siamo coperti?”

La risposta dipende da ambito di applicazione, servizi, clienti e soggetti giuridici. Ma la risposta operativa è chiara: se Maria tratta NIS2 e DORA come progetti di conformità separati, creerà lavoro duplicato, evidenze incoerenti e una crescente fatica da audit. Se li tratta come requisiti delle parti interessate all’interno del SGSI, può usare ISO 27001 per assorbirli, testarli e dimostrare la preparazione.

ISO/IEC 27001:2022 è progettata per questo. La clausola 4 richiede all’organizzazione di comprendere il proprio contesto e i requisiti delle parti interessate, inclusi gli obblighi legali, normativi, contrattuali e derivanti dalle dipendenze. La clausola 5 richiede leadership e integrazione nei processi aziendali. La clausola 6 richiede valutazione e trattamento del rischio. La clausola 9 richiede la valutazione delle prestazioni tramite monitoraggio, audit interno e riesame della direzione. La clausola 10 richiede miglioramento e azione correttiva.

NIS2 e DORA si inseriscono naturalmente in questa struttura.

NIS2 richiede ai soggetti essenziali e importanti di attuare misure tecniche, operative e organizzative adeguate e proporzionate per la gestione dei rischi di cibersicurezza. Attribuisce inoltre agli organi di gestione la responsabilità di approvare tali misure, supervisionarne l’attuazione e poter essere chiamati a rispondere in caso di violazioni. Le misure minime coprono analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, gestione delle vulnerabilità, valutazione dell’efficacia, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e, ove appropriato, autenticazione a più fattori (MFA) o autenticazione continua.

DORA si applica dal 17 gennaio 2025 e istituisce un regime settoriale di resilienza operativa digitale per i soggetti finanziari. Richiede la responsabilità dell’organo di gestione per la gestione del rischio ICT, un quadro documentato di gestione del rischio ICT, una strategia di resilienza operativa digitale, piani di continuità e ripristino ICT, test di resilienza, governance degli incidenti ICT e gestione del rischio delle terze parti ICT. Per i fornitori SaaS e cloud che servono soggetti finanziari, DORA può emergere tramite obblighi contrattuali, audit dei clienti e aspettative di gestione del rischio delle terze parti ICT, anche quando il fornitore non è esso stesso un soggetto finanziario.

GDPR aggiunge il livello di accountability. Quando dati personali sono trattati nell’ambito di applicazione del GDPR, le organizzazioni devono poter dimostrare la conformità ai principi di protezione dei dati e l’adozione di misure tecniche e organizzative adeguate.

ISO 27001 non è un certificato magico di conformità per questi obblighi. È il sistema di gestione che può organizzarli, documentarli con evidenze e migliorarli.

La questione dell’ambito: che cosa stai dimostrando e per chi?

Prima di costruire un pacchetto di evidenze pronto per l’audit, la leadership deve rispondere a una domanda di base: quali obblighi rientrano nell’ambito di applicazione?

Per le imprese SaaS e cloud, il campo di applicazione di NIS2 può essere più ampio del previsto. NIS2 si applica a soggetti pubblici o privati appartenenti ai settori elencati che soddisfano le soglie dimensionali, nonché ad alcuni soggetti ad alto impatto indipendentemente dalla dimensione. I settori rilevanti possono includere infrastruttura digitale, fornitori di servizi di cloud computing, fornitori di servizi di data center, reti di distribuzione dei contenuti, prestatori di servizi fiduciari, fornitori di reti pubbliche di comunicazione elettronica e fornitori B2B di gestione dei servizi ICT, come prestatori di servizi gestiti e prestatori di servizi di sicurezza gestiti. I fornitori SaaS devono prestare particolare attenzione a come i servizi sono erogati, quali settori supportano e se abilitano amministrazione on demand e accesso remoto ampio a risorse informatiche condivise e scalabili.

Per i fornitori fintech e di servizi al settore finanziario, DORA deve essere analizzato separatamente. DORA copre direttamente un’ampia gamma di soggetti finanziari, inclusi enti creditizi, istituti di pagamento, prestatori di servizi di informazione sui conti, istituti di moneta elettronica, imprese di investimento, prestatori di servizi per cripto-attività, sedi di negoziazione, gestori di fondi, imprese di assicurazione e riassicurazione e prestatori di servizi di crowdfunding. Anche i fornitori terzi di servizi ICT fanno parte dell’ecosistema DORA, perché i soggetti finanziari devono gestire le proprie dipendenze ICT, mantenere registri degli accordi contrattuali e includere specifiche disposizioni contrattuali per i servizi ICT che supportano funzioni critiche o importanti.

NIS2 e DORA interagiscono anche tra loro. Quando un atto giuridico settoriale dell’UE impone requisiti equivalenti di gestione del rischio di cibersicurezza o di notifica degli incidenti, le corrispondenti disposizioni NIS2 possono non applicarsi a tali soggetti per quelle aree. DORA è il regime settoriale di resilienza operativa per i soggetti finanziari. Questo non rende NIS2 irrilevante per tutti i fornitori circostanti. Significa che il modello di evidenze deve distinguere se l’organizzazione è un soggetto finanziario direttamente soggetto a DORA, un fornitore terzo di servizi ICT che supporta soggetti finanziari, un fornitore SaaS nell’ambito di NIS2 o un gruppo con più soggetti giuridici e linee di servizio.

Questa analisi dell’ambito appartiene al contesto del SGSI e al registro delle parti interessate. Senza di essa, il piano di audit testerà gli elementi sbagliati.

Una traccia di audit, molte domande di conformità

Un errore frequente consiste nel creare pacchetti di evidenze separati per ISO 27001, NIS2, DORA, GDPR, assicurazione cyber e audit dei clienti. Questo approccio genera duplicazioni e risposte confliggenti. Un approccio migliore è un unico modello di evidenze con più prospettive.

Al centro c’è il SGSI. Attorno a esso si collocano cinque famiglie di evidenze.

Questa struttura è allineata a Zenith Blueprint: roadmap in 30 passi per l’auditor Zenith Blueprint. Nella fase Audit, riesame e miglioramento, lo Step 25 si concentra sul programma di audit interno, lo Step 26 sull’esecuzione dell’audit, lo Step 28 sul riesame della direzione e lo Step 29 sul miglioramento continuo.

Le indicazioni dello Step 25 del Blueprint sono deliberatamente pratiche:

“Sviluppare un piano che descriva quando si svolgeranno gli audit e che cosa copriranno.”

“Utilizzare il modello di piano di audit interno, se fornito; può trattarsi di un semplice documento o foglio di calcolo che elenca date degli audit, ambito di applicazione e auditor assegnati.”

Da Zenith Blueprint, fase Audit, riesame e miglioramento, Step 25: programma di audit interno Zenith Blueprint

Quel semplice piano di audit diventa potente quando è basato sul rischio ed etichettato rispetto agli obblighi NIS2, DORA e GDPR.

I controlli ISO 27001 che fondano la preparazione agli audit

Ai fini della preparazione agli audit, tre controlli ISO/IEC 27002:2022 sono particolarmente importanti quando interpretati tramite Zenith Controls: guida alla conformità trasversale Zenith Controls:

• 5.4 Responsabilità della direzione
• 5.35 Riesame indipendente della sicurezza delle informazioni
• 5.36 Conformità alle politiche, alle regole e agli standard per la sicurezza delle informazioni

Questi non sono “controlli Zenith” separati. Sono controlli ISO/IEC 27002:2022 che Zenith Controls aiuta a mappare, sottoporre ad audit e interpretare attraverso più quadri di riferimento.

Il controllo 5.4 chiede se le responsabilità di sicurezza delle informazioni siano assegnate e comprese. Il controllo 5.35 chiede se la sicurezza delle informazioni sia riesaminata in modo indipendente. Il controllo 5.36 chiede se l’organizzazione rispetti le proprie politiche, regole e standard.

Zenith Controls classifica il controllo 5.35 con un orientamento all’assurance:

Il controllo ISO/IEC 27002:2022 5.35, “Riesame indipendente della sicurezza delle informazioni”, è trattato in Zenith Controls come “Preventivo, Correttivo”, a supporto di Riservatezza, Integrità e Disponibilità tramite i concetti di cibersicurezza “Identificare” e “Proteggere”, con capacità operativa in “Assurance della sicurezza delle informazioni”. Zenith Controls

Questo è rilevante perché l’audit interno è sia preventivo sia correttivo. Previene i punti ciechi testando il SGSI prima del controllo esterno e corregge le debolezze mediante azioni documentate.

La mappatura più ampia parte dai requisiti NIS2 e DORA e poi identifica le evidenze ISO 27001 che possono dimostrarli.

La mappatura dei controlli è utile solo quando le evidenze sono solide. Se la registrazione è debole, nessuna matrice di correlazione la salverà. Se la registrazione è completa, la stessa evidenza può rispondere a domande in stile ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 e COBIT 2019.

Le evidenze di policy che Clarysec si aspetta siano conservate dalle organizzazioni

Le policy Clarysec trasformano la teoria del SGSI in aspettative sulle evidenze.

Per le PMI, Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme richiede approvazione della leadership e disciplina di audit:

“Il Direttore generale (GM) deve approvare un piano di audit annuale.”

Da Audit and Compliance Monitoring Policy-sme, requisiti di governance, clausola 5.1.1 Audit and Compliance Monitoring Policy-sme

Stabilisce inoltre una cadenza minima:

“Gli audit interni o i riesami di conformità devono essere condotti almeno annualmente.”

Da Audit and Compliance Monitoring Policy-sme, requisiti di governance, clausola 5.2.1

E collega le risultanze alla correzione e al riesame della direzione:

“Il GM deve approvare un piano di azione correttiva e monitorarne l’attuazione.”

Da Audit and Compliance Monitoring Policy-sme, requisiti di governance, clausola 5.4.2

“Le risultanze dell’audit e gli aggiornamenti di stato devono essere inclusi nel processo di riesame della direzione del SGSI.”

Da Audit and Compliance Monitoring Policy-sme, requisiti di governance, clausola 5.4.3

Anche la conservazione delle evidenze è esplicita:

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

Da Audit and Compliance Monitoring Policy-sme, requisiti di applicazione della policy, clausola 6.2.4

Per le organizzazioni più grandi, Politica di audit e monitoraggio della conformità Politica di audit e monitoraggio della conformità, indicata in alcuni materiali Clarysec anche come P33 Audit and Compliance Monitoring Policy, amplia la struttura:

“Un piano di audit basato sul rischio deve essere sviluppato e approvato annualmente, tenendo conto di:”

Da Politica di audit e monitoraggio della conformità, requisiti di governance, clausola 5.2 Politica di audit e monitoraggio della conformità

“L’organizzazione deve mantenere un registro degli audit contenente:”

Da Politica di audit e monitoraggio della conformità, requisiti di governance, clausola 5.4

“Gli audit interni devono seguire una procedura documentata che includa:”

Da Politica di audit e monitoraggio della conformità, requisiti di applicazione della policy, clausola 6.1.1

“Tutte le risultanze devono generare una CAPA documentata che includa:”

Da Politica di audit e monitoraggio della conformità, requisiti di applicazione della policy, clausola 6.2.1

Il riesame della direzione è ancorato alla Politica per la sicurezza delle informazioni Politica per la sicurezza delle informazioni, indicata in alcuni materiali Clarysec anche come P01 Information Security Policy:

“Le attività di riesame della direzione (ai sensi della clausola 9.3 di ISO/IEC 27001) devono essere condotte almeno annualmente e devono includere:”

Da Politica per la sicurezza delle informazioni, requisiti di governance, clausola 5.3 Politica per la sicurezza delle informazioni

Questi requisiti creano la catena di evidenze attesa dagli auditor: piano approvato, procedura definita, registro degli audit, risultanze, CAPA, conservazione e riesame della leadership.

Costruire il pacchetto di evidenze pronto per l’audit

Un pacchetto di evidenze pronto per l’audit non è una cartella enorme creata due giorni prima dell’audit. È una struttura viva, mantenuta durante tutto l’anno.

Il pacchetto di evidenze deve essere mappato alle clausole ISO/IEC 27001:2022 e ai controlli dell’Appendice A, ma etichettato per rilevanza normativa. Una registrazione di audit di un fornitore, ad esempio, può supportare i controlli sui fornitori dell’Appendice A, la sicurezza della catena di fornitura NIS2 e la gestione del rischio delle terze parti ICT DORA. Una registrazione di esercitazione tabletop su un incidente può supportare la gestione degli incidenti ISO 27001, la preparazione alla notifica a fasi NIS2 e la governance dei gravi incidenti connessi all’ICT ai sensi di DORA.

Come eseguire l’audit interno integrato

Lo Step 26 di Zenith Blueprint enfatizza le evidenze oggettive:

“Eseguire l’audit raccogliendo evidenze oggettive per ciascun elemento della checklist.”

“Intervistare il personale rilevante.”

“Riesaminare la documentazione.”

“Osservare le pratiche.”

“Eseguire campionamenti e controlli a campione.”

Da Zenith Blueprint, fase Audit, riesame e miglioramento, Step 26: esecuzione dell’audit Zenith Blueprint

È esattamente ciò che richiede la preparazione a NIS2 e DORA. Autorità di regolamentazione e clienti non accetteranno “riteniamo che funzioni”. Chiederanno come lo sapete.

Un audit ben condotto testa quattro dimensioni delle evidenze.

Consideriamo un evento ransomware simulato su un server di staging. L’auditor verifica se il processo di risposta agli incidenti può soddisfare i requisiti ISO 27001, le aspettative di segnalazione a fasi NIS2 e gli obblighi verso i clienti ai sensi di DORA.

NIS2 prevede una struttura di segnalazione a fasi per gli incidenti significativi, inclusi preallarme entro 24 ore dalla consapevolezza, notifica dell’incidente entro 72 ore e rapporto finale entro un mese dalla notifica dell’incidente. DORA dispone di un proprio quadro di classificazione e segnalazione degli incidenti connessi all’ICT per i soggetti finanziari. L’audit interno deve verificare che i playbook acquisiscano momento della consapevolezza, criteri di gravità, servizi interessati, indicatori di compromissione, azioni di mitigazione, causa radice, obblighi di notifica ai clienti e dati per la reportistica finale.

Trasformare una risultanza di audit in evidenze NIS2 e DORA

Una risultanza realistica relativa a un fornitore mostra come dovrebbero fluire le evidenze.

Durante l’audit interno, l’auditor campiona cinque fornitori critici. Un fornitore cloud di logging supporta il monitoraggio antifrode e gli avvisi di sicurezza per la piattaforma fintech. Il fornitore è elencato nell’inventario, ma non esiste un piano di uscita documentato, non vi sono evidenze del riesame di sicurezza annuale e non c’è conferma che il contratto includa assistenza in caso di incidente o diritto di audit.

L’auditor registra una non conformità rispetto ai requisiti di sicurezza dei fornitori e uscita dal cloud. Una risposta debole direbbe “riesame del fornitore mancante”. Una risposta solida crea una catena di evidenze per la conformità trasversale:

1. Registrare la risultanza nel rapporto di audit, includendo dimensione del campione, nome del fornitore, riferimento contrattuale ed evidenze mancanti.
2. Aggiungere una voce CAPA con causa radice, ad esempio “la checklist di onboarding dei fornitori non includeva la classificazione della criticità o il trigger del piano di uscita”.
3. Assegnare il responsabile del fornitore e il responsabile del rischio.
4. Aggiornare il registro dei fornitori per contrassegnare il servizio come supporto a una funzione critica o importante.
5. Eseguire una valutazione del rischio che copra interruzione del servizio, accesso ai dati, rischio di concentrazione, dipendenza per la notifica degli incidenti e lacune contrattuali.
6. Aggiornare il piano di trattamento del rischio e la dichiarazione di applicabilità, ove pertinente.
7. Ottenere un addendum contrattuale aggiornato o un’accettazione del rischio documentata.
8. Creare o testare un piano di uscita.
9. Rieseguire l’audit delle evidenze del fornitore dopo la remediation.
10. Riportare risultanza, rischio e fabbisogni di risorse nel riesame della direzione.

Questa singola catena supporta molteplici obblighi. NIS2 si aspetta sicurezza della catena di fornitura e considerazione delle vulnerabilità dei fornitori, delle pratiche di cibersicurezza e delle procedure di sviluppo sicuro. DORA richiede ai soggetti finanziari di gestire il rischio delle terze parti ICT, mantenere registri degli accordi contrattuali, valutare i fornitori prima della contrattualizzazione, includere diritto di audit e ispezione ove appropriato, mantenere diritti di risoluzione e documentare strategie di uscita per i servizi ICT che supportano funzioni critiche o importanti. GDPR può essere rilevante anche se il fornitore tratta dati personali.

La registrazione di audit non è più soltanto evidenza di conformità. È evidenza di resilienza.

Riesame della direzione: dove le evidenze diventano responsabilità

L’audit interno accerta la realtà. Il riesame della direzione decide che cosa farne.

Lo Step 28 di Zenith Blueprint descrive il pacchetto di input per il riesame della direzione:

“ISO 27001 specifica diversi input richiesti per il riesame della direzione. Preparare un breve rapporto o una presentazione che copra questi punti.”

Il Blueprint elenca lo stato delle azioni precedenti, i cambiamenti nelle questioni esterne e interne, le prestazioni e l’efficacia del SGSI, incidenti o non conformità, opportunità di miglioramento e fabbisogni di risorse.

Da Zenith Blueprint, fase Audit, riesame e miglioramento, Step 28: riesame della direzione Zenith Blueprint

Per NIS2 e DORA, il riesame della direzione è il punto in cui la responsabilità a livello di consiglio diventa visibile. Il riesame non deve limitarsi a dire “si è discusso di sicurezza”. Deve mostrare che la leadership ha riesaminato:

• Modifiche ai requisiti NIS2, DORA, GDPR, dei clienti e contrattuali.
• Modifiche dell’ambito, inclusi nuovi Paesi, prodotti, clienti regolamentati o dipendenze ICT.
• Risultati degli audit interni, incluse non conformità maggiori e minori.
• Stato delle CAPA e azioni scadute.
• Obiettivi e metriche di sicurezza.
• Tendenze degli incidenti, mancati incidenti e lezioni apprese.
• Rischi di concentrazione dei fornitori e cloud.
• Risultati dei test di continuità operativa e backup.
• Prestazioni di gestione delle vulnerabilità e applicazione delle patch.
• Fabbisogni di risorse, inclusi personale, strumenti, formazione e budget.
• Rischi residui che richiedono accettazione formale.
• Decisioni di miglioramento e responsabili assegnati.

Qui Maria può trasformare un rapporto tecnico in assurance strategica. Invece di dire “abbiamo trovato una lacuna nel processo di incidente”, può dire: “L’audit ha identificato una non conformità minore nei nostri criteri decisionali per la notifica degli incidenti NIS2. La CAPA aggiorna la procedura, aggiunge una matrice decisionale e richiede un’esercitazione tabletop entro 30 giorni. Serve l’approvazione della direzione per il riesame legale e il tempo di formazione.”

Questo è il tipo di registrazione che supporta governance, vigilanza e decisioni difendibili.

Azione correttiva: la differenza tra una risultanza e la maturità

Un audit interno senza azione correttiva è solo una diagnosi.

Lo Step 29 di Zenith Blueprint indica alle organizzazioni di usare un registro CAPA:

“Compilarlo con ciascun problema: descrizione del problema, causa radice, azione correttiva, responsabile, data obiettivo di completamento, stato.”

Da Zenith Blueprint, fase Audit, riesame e miglioramento, Step 29: miglioramento continuo Zenith Blueprint

Introduce inoltre una distinzione importante:

“In termini di audit: la correzione risolve il sintomo, l’azione correttiva risolve la causa. Entrambe sono importanti.”

Da Zenith Blueprint, fase Audit, riesame e miglioramento, Step 29: miglioramento continuo

Se mancano evidenze di ripristino dei backup, la correzione può essere eseguire e documentare un test di ripristino questa settimana. L’azione correttiva consiste nel modificare la procedura di backup affinché i test di ripristino siano pianificati trimestralmente, generino automaticamente ticket, siano riesaminati dal responsabile del servizio e siano inclusi nelle metriche del riesame della direzione.

Gli auditor cercano questa maturità. Un auditor ISO 27001 verifica la conformità al SGSI e ai controlli selezionati. Un revisore NIS2 chiede se le misure di gestione del rischio siano efficaci e sottoposte a vigilanza. Un revisore DORA cerca integrazione del quadro di rischio ICT, test di resilienza, gestione delle dipendenze da terze parti e remediation. Un valutatore NIST Cybersecurity Framework 2.0 può chiedere se gli esiti di governance, identificazione, protezione, rilevamento, risposta e ripristino siano operativi. Un auditor COBIT 2019 può concentrarsi su obiettivi di governance, titolarità, indicatori di prestazione e assurance.

La stessa registrazione CAPA può soddisfare queste prospettive se include causa radice, responsabile, impatto sul rischio, azione correttiva, scadenza, evidenza dell’attuazione, riesame dell’efficacia e visibilità alla direzione.

Le molte prospettive dell’auditor

Auditor diversi leggono la stessa evidenza in modo diverso. Zenith Controls aiuta ad anticipare tali domande agendo come guida alla conformità trasversale per i controlli ISO/IEC 27002:2022 e i quadri di riferimento correlati.

Il controllo 5.36 è un buon esempio. L’auditor ISO 27001 può concentrarsi sul fatto che i riesami di conformità avvengano e alimentino l’azione correttiva. Il revisore NIS2 può chiedere se tali riesami testino le misure legali di cibersicurezza, non solo le regole interne. Il revisore DORA può concentrarsi sul fatto che i riesami di conformità includano fornitori ICT critici e applicazione contrattuale.

Per questo le evidenze devono essere progettate fin dall’inizio per più lettori.

Uno sprint pratico di 30 giorni per la preparazione agli audit

Se l’amministratore delegato chiede se l’organizzazione può essere pronta per l’audit in 30 giorni, la risposta onesta è: è possibile costruire una baseline di evidenze credibile se la leadership supporta lo sprint e l’ambito è realistico.

Questo sprint non sostituisce la maturità di lungo periodo. Crea una baseline operativa difendibile. Il vero valore emerge quando l’organizzazione ripete il ciclo trimestralmente o semestralmente, non solo una volta all’anno.

Errori comuni sulle evidenze riscontrati da Clarysec

Le stesse debolezze compaiono negli audit SaaS, cloud e fintech:

• Il piano di audit esiste, ma non è basato sul rischio.
• La checklist di audit testa le clausole ISO ma ignora NIS2, DORA, GDPR e gli obblighi verso i clienti.
• I verbali del riesame della direzione esistono, ma non mostrano decisioni, allocazione delle risorse o accettazione del rischio.
• Le registrazioni CAPA elencano azioni ma non la causa radice.
• Le risultanze sono chiuse senza verifica dell’efficacia.
• I riesami dei fornitori vengono eseguiti, ma i fornitori critici non sono distinti dai fornitori a basso rischio.
• I playbook degli incidenti esistono, ma nessuno può dimostrare che il flusso di notifica a 24 o 72 ore funzionerebbe.
• I job di backup sono verdi, ma i test di ripristino non sono supportati da evidenze.
• I riesami degli accessi vengono esportati, ma le eccezioni non sono tracciate fino alla chiusura.
• I log sono raccolti, ma nessuno può dimostrare monitoraggio, escalation o risposta.
• Le evidenze sono conservate in cartelle personali invece che in un repository controllato.
• I requisiti di conservazione sono poco chiari o incoerenti con i contratti dei clienti.

Questi errori sono correggibili. Richiedono un’architettura strutturata delle evidenze del SGSI, non una rincorsa documentale dell’ultimo minuto.

Che cosa significa “ben fatto” per il consiglio di amministrazione

Quando il Responsabile della sicurezza delle informazioni torna dall’amministratore delegato e dal direttore finanziario, la risposta più forte non è “abbiamo superato una checklist di audit”. È:

“Abbiamo un piano di audit approvato. Abbiamo eseguito un audit interno basato sul rischio. Abbiamo identificato risultanze con evidenze oggettive. Abbiamo approvato CAPA con responsabili e scadenze. Abbiamo portato rischi significativi, incidenti, dipendenze dai fornitori e fabbisogni di risorse nel riesame della direzione. Abbiamo mappato le evidenze a ISO/IEC 27001:2022, NIS2, DORA e GDPR. Possiamo mostrare la traccia di audit.”

Questa risposta cambia la conversazione. Dà all’amministratore delegato fiducia verso i clienti. Dà al direttore finanziario chiarezza sull’esposizione normativa. Dà al consiglio di amministrazione una registrazione di vigilanza difendibile. Dà al Responsabile della sicurezza delle informazioni una roadmap prioritaria invece di un cumulo di richieste scollegate.

Soprattutto, sposta l’organizzazione dalla rappresentazione della conformità alla resilienza operativa.

Prossimi passi con Clarysec

Il tuo prossimo audit non dovrebbe essere una corsa dell’ultimo minuto. Dovrebbe essere una prova visibile che il tuo SGSI funziona, che la leadership è coinvolta e che l’organizzazione è pronta per ISO 27001, NIS2, DORA, GDPR e assurance verso i clienti.

Clarysec può aiutarti a:

• Costruire un piano di audit interno basato sul rischio usando Zenith Blueprint: roadmap in 30 passi per l’auditor Zenith Blueprint.
• Mappare le evidenze di audit tramite Zenith Controls: guida alla conformità trasversale Zenith Controls.
• Implementare la governance degli audit per PMI o enterprise usando Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme oppure Politica di audit e monitoraggio della conformità Politica di audit e monitoraggio della conformità.
• Preparare pacchetti di riesame della direzione allineati alla Politica per la sicurezza delle informazioni Politica per la sicurezza delle informazioni e alle aspettative della clausola 9.3 di ISO/IEC 27001:2022.
• Trasformare le risultanze in registrazioni CAPA, decisioni della direzione e miglioramento misurabile.

Scarica i toolkit Clarysec, prenota una valutazione della preparazione o richiedi una demo per trasformare il tuo prossimo audit interno in evidenze pronte per il consiglio di amministrazione a supporto di ISO 27001, NIS2, DORA e oltre.