Audit interno ISO 27001 per NIS2 e DORA
È la prima riunione del comitato audit del 2026. Sarah, CISO di FinSecure, fornitore SaaS e FinTech in rapida crescita, ha quindici minuti all’ordine del giorno. Il consiglio di amministrazione ha cinque domande.
Siamo pronti per l’audit di sorveglianza ISO/IEC 27001:2022? Rientriamo nell’ambito NIS2 come fornitore di servizi gestiti? DORA ci riguarda perché supportiamo clienti del settore finanziario? Possiamo dimostrare che segnalazione degli incidenti, due diligence sui fornitori e continuità operativa funzionano? E perché il riesame degli accessi dello scorso trimestre ha ancora individuato account che avrebbero dovuto essere rimossi?
Sarah dispone di evidenze, ma sono frammentate. Il team di sviluppo ha le esportazioni delle scansioni di vulnerabilità. Acquisti ha i questionari dei fornitori. L’ufficio Legale ha le clausole contrattuali. Il responsabile della conformità ha un registro GDPR. Il SOC ha i ticket sugli incidenti. Nulla è evidentemente errato, ma nulla racconta una storia di assurance coerente.
È il momento in cui un programma di audit interno ISO 27001 diventa un motore strategico di evidenze oppure resta una corsa annuale dell’ultimo minuto.
Per le organizzazioni interessate da NIS2 e DORA, l’audit interno non può più essere una checklist formale. Deve diventare un sistema di assurance basato sul rischio, capace di confermare se l’ambito del SGSI è corretto, se i controlli operano nella pratica, se i requisiti normativi sono mappati, se le risultanze sono classificate in modo coerente e se le azioni correttive arrivano al riesame della direzione. Nel 2026, i programmi più maturi non si limiteranno a chiedere: “Abbiamo svolto un audit?”. Chiederanno: “Possiamo dimostrare, mese dopo mese, che governance della cibersicurezza, resilienza ICT, sicurezza dei fornitori e preparazione agli incidenti funzionano?”.
È questo l’approccio che Clarysec integra in Zenith Blueprint: roadmap in 30 passi per auditor, Zenith Controls: la guida cross-compliance e nella suite di politiche Clarysec. L’obiettivo non è creare progetti separati per ISO, NIS2 e DORA. L’obiettivo è arricchire il SGSI affinché un unico programma di audit produca evidenze riutilizzabili per molteplici esigenze di assurance.
Perché i programmi di audit interno 2026 devono cambiare
NIS2 e DORA hanno spostato la conversazione sull’audit dalla documentazione alla resilienza governata.
NIS2 si applica a molte organizzazioni medie e grandi in settori critici e importanti, tra cui infrastrutture digitali, fornitori di servizi di cloud computing, fornitori di data center, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, marketplace online, motori di ricerca online e piattaforme di social network. Gli Stati membri hanno iniziato ad applicare le misure nazionali da ottobre 2024 e, entro il 2026, molte organizzazioni operano nel primo anno pieno di aspettative NIS2 mature.
DORA si applica dal 17 gennaio 2025 a un’ampia gamma di entità finanziarie, tra cui enti creditizi, istituti di pagamento, istituti di moneta elettronica, imprese di investimento, prestatori di servizi per cripto-attività, imprese di assicurazione e riassicurazione, fornitori di servizi di crowdfunding e pertinenti fornitori terzi di servizi ICT. DORA è il regime settoriale di resilienza operativa digitale per le entità finanziarie coperte. Anche i fornitori ICT che servono entità finanziarie possono essere coinvolti da DORA tramite contratti, diritto di audit, partecipazione ai test, supporto agli incidenti, controlli sul subappalto e requisiti di uscita.
Entrambe le normative rafforzano la responsabilizzazione. NIS2 Article 20 richiede agli organi di gestione di approvare e supervisionare le misure di gestione dei rischi di cibersicurezza e di ricevere formazione sulla cibersicurezza. DORA Article 5 rende l’organo di gestione ultimo responsabile del rischio ICT, inclusi approvazione e supervisione della strategia di resilienza operativa digitale, delle politiche ICT, degli accordi di continuità e del rischio di terze parti.
ISO 27001 è particolarmente adatta a questo contesto perché è un sistema di gestione. Richiede all’organizzazione di comprendere il proprio contesto, definire parti interessate e requisiti, stabilire il campo di applicazione del SGSI, valutare e trattare i rischi, monitorare le prestazioni, svolgere audit interni e promuovere il miglioramento continuo. Il punto non è forzare NIS2 e DORA dentro una struttura “a forma di ISO”. Il punto è usare ISO 27001 come sistema operativo per un’assurance ripetibile.
Partire dall’ambito: sottoporre ad audit il sistema su cui il consiglio fa affidamento
Un programma di audit interno debole parte da un ambito vago, come “sicurezza delle informazioni”. Un programma robusto parte dal perimetro aziendale e normativo.
ISO 27001 richiede che il campo di applicazione del SGSI consideri fattori interni ed esterni, requisiti delle parti interessate e interfacce o dipendenze con altre organizzazioni. È rilevante perché gli obblighi NIS2 e DORA spesso si collocano ai margini dell’organizzazione: piattaforme cloud, fornitori SOC esternalizzati, Managed Detection and Response, sistemi di pagamento, API fintech, trattamento dei dati dei clienti, servizi di backup e partner di escalation degli incidenti.
La Politica di audit e monitoraggio della conformità per PMI di Clarysec definisce la baseline di governance:
Il Direttore generale (GM) deve approvare un piano di audit annuale.
Dalla sezione “Requisiti di governance”, clausola di politica 5.1.1.
Per ambienti più grandi, la Politica di audit e monitoraggio della conformità di Clarysec innalza l’aspettativa:
Deve essere sviluppato e approvato annualmente un Piano di audit basato sul rischio, tenendo conto di:
Dalla sezione “Requisiti di governance”, clausola di politica 5.2.
L’ambito, quindi, non è una semplice preferenza dell’auditor. È un impegno di assurance approvato dalla direzione.
Un programma di audit interno ISO 27001 per il 2026 a supporto di NIS2 e DORA dovrebbe includere:
- Clausole e processi del SGSI, inclusi contesto, leadership, gestione del rischio, obiettivi, supporto, operatività, valutazione delle prestazioni e miglioramento.
- Aree di controllo pertinenti dell’Appendice A ISO/IEC 27001:2022, inclusi rapporti con i fornitori, gestione degli incidenti, continuità operativa, obblighi legali, privacy, registrazione, monitoraggio, gestione delle vulnerabilità, controllo degli accessi, crittografia, sviluppo sicuro, gestione delle modifiche e governance cloud.
- Overlay normativi, inclusi NIS2 Articles 20, 21 e 23, DORA Articles 5, 6, 8 to 14, 17 to 19, 24 to 27 e 28 to 30, oltre ai requisiti GDPR di sicurezza e accountability.
- Servizi e processi aziendali chiave, in particolare funzioni critiche o importanti, servizi essenziali, piattaforme rivolte ai clienti e sistemi a supporto di clienti regolamentati.
- Dipendenze da terze parti, inclusi fornitori ICT, cloud provider, sviluppo esternalizzato, SOC, MSSP, responsabili del trattamento e subappaltatori critici.
- Processi che producono evidenze, incluse valutazioni del rischio, riesami degli accessi, remediation delle vulnerabilità, esercitazioni sugli incidenti, test di ripristino dei backup, riesami dei fornitori, test di continuità e riesami della direzione.
Il Zenith Blueprint rafforza questo punto nella fase Audit, riesame e miglioramento, Step 25, Programma di audit interno:
Decidi l’ambito del tuo programma di audit interno. In definitiva, nel corso di un anno devi coprire tutti i processi e i controlli pertinenti del SGSI.
Dalla fase Audit, riesame e miglioramento, Step 25: Programma di audit interno.
Non è necessario sottoporre tutto ad audit ogni mese. Tuttavia, nel ciclo annuale, dovresti coprire tutti i processi e i controlli pertinenti del SGSI, con attività più frequenti sulle aree ad alto rischio e regolamentate.
Costruire l’universo di audit sui temi di controllo NIS2 e DORA
NIS2 Article 21 richiede misure tecniche, operative e organizzative appropriate e proporzionate. La sua baseline include analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, gestione dei backup, disaster recovery, gestione delle crisi, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset, MFA o autenticazione continua ove appropriato e comunicazioni sicure.
DORA segue un ciclo operativo analogo. Richiede alle entità finanziarie di identificare e classificare funzioni aziendali supportate dall’ICT, patrimoni informativi, asset ICT, dipendenze e interconnessioni con terze parti. Richiede inoltre protezione, rilevamento, classificazione degli incidenti, risposta, ripristino, backup, test, apprendimento post-incidente, comunicazione e gestione del rischio ICT di terze parti.
Un universo di audit unificato evita l’errore comune di sottoporre ad audit ISO 27001 separatamente da NIS2 e DORA.
| Dominio di audit | Ancoraggio audit ISO 27001 | Rilevanza NIS2 e DORA | Evidenze tipiche |
|---|---|---|---|
| Governance e obblighi legali | Contesto, leadership, trattamento del rischio, requisiti legali e contrattuali | Supervisione del consiglio ai fini NIS2, responsabilità dell’organo di gestione ai fini DORA, accountability GDPR | Registro normativo, registro delle parti interessate, campo di applicazione del SGSI, propensione al rischio, verbali del consiglio, riesame della direzione |
| Valutazione e trattamento del rischio | Valutazione del rischio, Dichiarazione di applicabilità, piano di trattamento | Misure appropriate e proporzionate NIS2, quadro per la gestione del rischio ICT DORA | Registro dei rischi, criteri di rischio, approvazioni del trattamento, accettazione del rischio residuo |
| Inventario di asset e dipendenze | Gestione degli asset, governance dei servizi cloud, servizi dei fornitori | Asset ICT e interconnessioni DORA, sistemi di erogazione dei servizi NIS2 | CMDB, mappe dei flussi di dati, registro dei fornitori, inventario cloud, classificazione della criticità |
| Controllo degli accessi e identità | Sicurezza HR, gestione degli accessi, MFA, accesso privilegiato | Controllo degli accessi e MFA NIS2, principio del minimo privilegio e autenticazione forte DORA | Ticket del processo Joiner-Mover-Leaver, riesami degli accessi, report MFA, log degli account privilegiati |
| Logging, monitoraggio e rilevamento | Registrazione, monitoraggio, valutazione degli eventi | Rilevamento delle anomalie e classificazione degli incidenti DORA, preparazione agli incidenti NIS2 | Allerte SIEM, regole di rilevamento, registrazioni del triage degli incidenti, cruscotti di monitoraggio |
| Gestione degli incidenti | Pianificazione degli incidenti, risposta, raccolta delle evidenze, lezioni apprese | Workflow di segnalazione NIS2, ciclo di vita degli incidenti ICT DORA | Registro degli incidenti, matrice di gravità, modelli di notifica, report di causa radice, registrazioni delle esercitazioni |
| Continuità operativa e ripristino | Prontezza ICT, backup, sicurezza in caso di interruzione | Backup e gestione delle crisi NIS2, continuità e ripristino DORA | BIA, piani di continuità, test di backup, registrazioni RTO e RPO, test di comunicazione di crisi |
| Fornitori e rischio ICT di terze parti | Accordi con i fornitori, catena di fornitura ICT, acquisizione cloud e uscita | Sicurezza della catena di fornitura NIS2, registro ICT di terze parti e clausole contrattuali DORA | Due diligence sui fornitori, contratti, diritto di audit, piani di uscita, analisi del rischio di concentrazione |
| Sviluppo sicuro e vulnerabilità | Acquisizione sicura, sviluppo, modifiche, gestione delle vulnerabilità | Gestione delle vulnerabilità NIS2, applicazione delle patch e test DORA | Scansioni di vulnerabilità, SLA di remediation, ticket di modifica, revisione del codice, rapporti di test di penetrazione |
| Monitoraggio della conformità e azione correttiva | Monitoraggio, audit interno, non conformità e azione correttiva | Misure correttive NIS2, audit e follow-up della remediation DORA | Rapporti di audit, registro CAPA, dashboard KPI, azioni del riesame della direzione |
Questa struttura trasforma ogni dominio di audit in un oggetto di assurance condiviso. L’auditor interno verifica il requisito ISO 27001 e registra quindi se la stessa evidenza supporta anche le aspettative NIS2, DORA, GDPR, NIST CSF e COBIT 2019.
Pianificare l’anno in base al rischio, non alla documentazione
Il Zenith Blueprint offre ai team una sequenza pratica per trasformare l’audit in miglioramento:
- Step 25, Programma di audit interno: pianificare ambito, frequenza, indipendenza e priorità basate sul rischio.
- Step 26, Esecuzione dell’audit: raccogliere evidenze oggettive tramite interviste, riesame documentale, osservazione e campionamento.
- Step 27, Risultanze dell’audit, analisi e causa radice: classificare le risultanze e identificare la causa radice.
- Step 28, Riesame della direzione: portare risultati degli audit, incidenti, non conformità, obiettivi, rischi e fabbisogni di risorse nel riesame della leadership.
- Step 29, Miglioramento continuo: costruire azioni correttive che eliminino le cause, non solo i sintomi.
Il Zenith Blueprint è esplicito sull’indipendenza:
Idealmente, l’auditor interno non dovrebbe auditare il proprio lavoro.
Dalla fase Audit, riesame e miglioramento, Step 25: Programma di audit interno.
Per una società SaaS o fintech più piccola, ciò può significare chiedere a un responsabile di un’altra funzione di verificare i processi di sicurezza, ruotare i responsabili dei controlli o utilizzare un consulente esterno. L’elemento chiave è documentare competenza e indipendenza, soprattutto quando le evidenze NIS2 e DORA potrebbero essere successivamente riesaminate da clienti, autorità di regolamentazione, organismi di vigilanza o auditor esterni.
La Politica di audit e monitoraggio della conformità per PMI definisce anche la struttura minima dell’audit:
Ogni audit deve includere un ambito definito, obiettivi, personale responsabile ed evidenze richieste.
Dalla sezione “Requisiti di governance”, clausola di politica 5.2.3.
Una struttura trimestrale pratica per un fornitore SaaS o ICT in forte crescita potrebbe essere:
| Trimestre | Focus principale dell’audit | Enfasi normativa | Output principali |
|---|---|---|---|
| Q1 | Gestione e segnalazione degli incidenti | NIS2 Article 23, DORA Articles 17 to 19 | Rapporto di audit sugli incidenti, test del workflow di notifica, riesame della matrice di gravità |
| Q2 | Gestione del rischio ICT di terze parti | NIS2 Article 21, DORA Articles 28 to 30 | Campione di fornitori, riesame dei contratti, evidenze di due diligence, riesame della pianificazione di uscita |
| Q3 | Test di continuità operativa e resilienza | NIS2 Article 21, DORA Articles 11, 12, 24 to 27 | Evidenze di ripristino dei backup, esercitazione di continuità, remediation dei test di resilienza |
| Q4 | Governance, rischio e conformità | NIS2 Article 20, DORA Articles 5 and 6, ISO 27001 Clauses 5, 9 and 10 | Pacchetto per il riesame della direzione, stato CAPA, decisioni sul rischio residuo, piano di audit per l’anno successivo |
Questo non sostituisce la raccolta mensile delle evidenze. Fornisce all’anno un ritmo di assurance chiaro.
Campionamento: quanta evidenza è sufficiente?
Il campionamento è il punto in cui molti audit interni diventano troppo superficiali o troppo costosi. Negli ambienti ICT regolamentati, il campionamento deve essere basato sul rischio, spiegabile e documentato.
Il Zenith Blueprint, Step 26, fornisce il principio pratico:
Campiona ed esegui controlli a campione: non puoi verificare tutto, quindi usa il campionamento.
Dalla fase Audit, riesame e miglioramento, Step 26: Esecuzione dell’audit.
La politica enterprise di Clarysec rende questo aspetto auditabile:
Documentazione della strategia di campionamento, dell’ambito dell’audit e delle limitazioni
Dalla sezione “Requisiti di governance”, clausola di politica 5.5.3.
Per NIS2 e DORA, il campionamento deve considerare criticità, rischio, rilevanza del fornitore, periodo di tempo, storia degli incidenti, geografia e se il processo campionato supporta funzioni critiche o importanti.
| Area di controllo | Popolazione | Campione suggerito | Adeguamento basato sul rischio |
|---|---|---|---|
| Provisioning degli accessi | Tutti i nuovi account utente nel trimestre | 10 account o il 10%, a seconda di quale valore sia maggiore | Includere tutti gli account privilegiati e gli amministratori di applicazioni critiche |
| Rimozione degli accessi dei leaver | Tutti gli utenti cessati nel trimestre | 100% per utenti privilegiati, 10 utenti standard | Aumentare il campione se l’integrazione HR o IAM è cambiata |
| Due diligence sui fornitori | Fornitori ICT attivi | Tutti i fornitori critici, 5 fornitori a rischio medio, 3 fornitori a basso rischio | Includere fornitori che supportano clienti finanziari o servizi essenziali |
| Remediation delle vulnerabilità | Risultanze critiche e alte chiuse nel trimestre | 15 ticket distribuiti sui sistemi | Includere sistemi esposti a Internet ed eccezioni ricorrenti |
| Gestione degli incidenti | Tutti gli incidenti di sicurezza del trimestre | Tutti gli incidenti maggiori, 5 incidenti minori, 3 esempi di triage falso positivo | Includere incidenti con dati personali, impatto sui clienti o rilevanza transfrontaliera |
| Ripristino dei backup | Test di backup eseguiti nel trimestre | Tutti i test dei sistemi critici, 3 sistemi non critici | Includere sistemi a supporto di funzioni critiche o importanti |
| Gestione delle modifiche | Modifiche in produzione nel trimestre | 15 modifiche, incluse modifiche di emergenza | Includere modifiche che incidono su autenticazione, registrazione, cifratura o dati dei clienti |
| Formazione sulla sicurezza | Dipendenti e collaboratori esterni attivi nel periodo | 20 utenti distribuiti tra dipartimenti | Includere membri dell’organo di gestione e ruoli tecnici privilegiati |
Per gli ambienti interessati da DORA, le evidenze di test meritano particolare attenzione. DORA richiede test di resilienza operativa digitale per le entità finanziarie, con test più avanzati, come il penetration test guidato dalle minacce, per entità selezionate almeno ogni tre anni. Il campione di audit dovrebbe includere non solo i report di test, ma anche evidenze che le risultanze siano state prioritizzate, sanate e ritestate.
Esempio pratico di audit: rischio ICT di terze parti
La sicurezza dei fornitori è spesso il modo più rapido per esporre le lacune tra documentazione e realtà operativa. DORA Articles 28 to 30 richiedono gestione del rischio ICT di terze parti, contenuto contrattuale e registri delle informazioni. NIS2 Article 21 richiede sicurezza della catena di fornitura che tenga conto delle vulnerabilità e delle prassi dei fornitori diretti.
Per un audit Q2, Sarah campiona cinque fornitori critici, tre nuovi fornitori inseriti negli ultimi sei mesi e due fornitori con contratti rinnovati di recente. L’auditor intervista Acquisti, ufficio Legale, responsabili dei servizi e responsabili dei controlli di sicurezza.
| Requisito DORA o NIS2 | Ancoraggio del controllo ISO 27001:2022 | Domanda di audit | Evidenze da raccogliere |
|---|---|---|---|
| DORA Article 28, registro ICT di terze parti | A.5.19 Sicurezza delle informazioni nei rapporti con i fornitori | Esiste un registro completo e aggiornato degli accordi con fornitori terzi ICT? | Registro dei fornitori in esercizio e registrazioni campionate dei fornitori critici |
| DORA Article 28, valutazione del rischio precontrattuale | A.5.19 Sicurezza delle informazioni nei rapporti con i fornitori | La due diligence è stata svolta prima della firma o del rinnovo dei contratti con i fornitori? | Report di due diligence, valutazioni del rischio e registrazioni di approvazione |
| DORA Article 30, contenuto contrattuale | A.5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori | I contratti includono misure di sicurezza, diritto di audit, assistenza sugli incidenti e supporto alla cessazione ove richiesto? | Contratti, addendum, allegati di sicurezza e note di riesame legale |
| NIS2 Article 21, sicurezza della catena di fornitura | A.5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT | Le prassi di sicurezza dei fornitori, il subappalto e le dipendenze di servizio sono compresi? | Questionari dei fornitori, disclosure dei subappaltatori e mappe delle dipendenze |
| Monitoraggio continuo dei fornitori | A.5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori | Le prestazioni e la sicurezza dei fornitori sono riesaminate nel tempo? | Verbali QBR, report SLA, rapporti di audit e registrazioni dei riesami annuali |
Questa tabella non si limita a guidare la raccolta delle evidenze. Dimostra che l’organizzazione ha tradotto il testo normativo in criteri di audit allineati a ISO ed evidenze concrete.
Risultanze: scriverle in modo che la direzione possa agire
Una risultanza dell’audit non deve sembrare una lamentela generica. Deve essere strutturata a sufficienza perché la direzione comprenda il rischio, assegni la titolarità e approvi l’azione correttiva.
La Politica di audit e monitoraggio della conformità per PMI stabilisce:
Tutte le risultanze dell’audit devono essere documentate con classificazioni di rischio e azioni proposte.
Dalla sezione “Requisiti di governance”, clausola di politica 5.4.1.
La Politica di audit e monitoraggio della conformità enterprise aggiunge la disciplina dell’azione correttiva:
Tutte le risultanze devono generare una CAPA documentata che includa:
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.2.1.
Nel Zenith Blueprint, lo Step 27 raccomanda di classificare le risultanze come non conformità maggiori, non conformità minori o osservazioni, quindi svolgere l’analisi della causa radice. Una non conformità maggiore indica una lacuna grave o un fallimento sistemico. Una non conformità minore è un’anomalia isolata in un processo altrimenti conforme. Un’osservazione è un’opportunità di miglioramento.
Una risultanza solida include:
- Requisito o aspettativa di controllo.
- Condizione osservata.
- Evidenza campionata.
- Rischio e impatto sul business.
- Rilevanza normativa.
- Classificazione e rating di rischio.
- Causa radice.
- Responsabile dell’azione correttiva e data di scadenza.
Esempio di risultanza:
Risultanza NC-2026-07, non conformità minore, ritardo nel riesame della sicurezza dei fornitori
Requisito: I riesami della sicurezza dei fornitori per i provider ICT critici devono essere svolti almeno annualmente, a supporto dei controlli ISO 27001 sui fornitori, delle aspettative NIS2 sulla catena di fornitura e degli obblighi DORA di gestione del rischio ICT di terze parti.
Condizione: Due dei dodici fornitori ICT critici non avevano completato i riesami di sicurezza 2026 entro la data richiesta.
Evidenza: Esportazione del registro dei fornitori datata 15 giugno 2026, registro dei riesami dei vendor, intervista con il responsabile Procurement e due registrazioni di riesame mancanti.
Rischio: Il ritardo nel riesame dei fornitori può impedire l’identificazione tempestiva di vulnerabilità, cambiamenti nel subappalto, lacune nel supporto agli incidenti o non conformità contrattuali che incidono sui servizi critici.
Causa radice: Acquisti non veniva avvisata automaticamente all’avvicinarsi delle date di riesame dei fornitori e la titolarità delle evidenze sui fornitori relative a DORA non era assegnata.
Azione correttiva: Configurare promemoria automatici di riesame, assegnare responsabili dei controlli nominativi per tutti i fornitori ICT critici, completare i riesami scaduti entro il 31 luglio 2026 ed eseguire controlli trimestrali a campione.
Per l’analisi della causa radice, la tecnica dei “5 perché” è utile. Se una valutazione precontrattuale è stata omessa, la vera causa potrebbe non essere un errore individuale. Potrebbe essere che il workflow di acquisto consentiva ai contratti ICT di basso valore di aggirare il riesame di sicurezza, anche se le aspettative DORA e NIS2 si applicano in base a rischio e dipendenza, non solo alla spesa.
Il calendario delle evidenze 2026
Un calendario delle evidenze 2026 trasforma l’audit interno in un ritmo operativo. Distribuisce la produzione delle evidenze lungo l’anno ed evita la corsa di fine anno.
La Politica per la sicurezza delle informazioni di Clarysec prevede il riesame di governance di:
Riesame degli Indicatori chiave di prestazione (KPI) della sicurezza, degli incidenti, delle risultanze dell’audit e dello stato del rischio
Dalla sezione “Requisiti di governance”, clausola di politica 5.3.2.
Le evidenze non sono raccolte solo per gli auditor. Alimentano decisioni su rischio, budget, risorse, fornitori, strumenti, formazione e azione correttiva.
| Mese | Focus di audit ed evidenze | Output chiave delle evidenze |
|---|---|---|
| Gennaio | Confermare ambito normativo, campo di applicazione del SGSI e piano di audit 2026 | Piano di audit approvato, riesame del campo di applicazione del SGSI, valutazione di applicabilità NIS2 e DORA, aggiornamento del registro normativo |
| Febbraio | Governance, propensione al rischio e formazione dell’organo di gestione | Verbali del consiglio, registrazioni della formazione, criteri di rischio, registro dei rischi aggiornato |
| Marzo | Inventario di asset, dati e dipendenze | Esportazione CMDB, mappe dei flussi di dati, elenco dei servizi critici, mappa delle interconnessioni con fornitori ICT |
| Aprile | Audit su controllo degli accessi e MFA | Registrazioni dei riesami degli accessi, campione di accessi privilegiati, report di copertura MFA, test sui leaver |
| Maggio | Vulnerabilità, applicazione delle patch e gestione sicura delle modifiche | Metriche di vulnerabilità, evidenze di remediation, campione di ticket di modifica, approvazioni delle eccezioni |
| Giugno | Governance dei fornitori e dei servizi cloud | Campione di due diligence sui fornitori, riesame delle clausole contrattuali, diritto di audit, piani di uscita, note sul rischio di concentrazione |
| Luglio | Esercitazione di gestione e segnalazione degli incidenti | Simulazione di incidente, classificazione di gravità, test del workflow di segnalazione NIS2, test di escalation degli incidenti DORA |
| Agosto | Logging, monitoraggio e rilevamento | Casi d’uso SIEM, tuning degli alert, copertura del monitoraggio, campione di escalation |
| Settembre | Backup, ripristino e continuità operativa | Registrazioni dei test di backup, evidenze RTO e RPO, esercitazione di continuità, test di comunicazione di crisi |
| Ottobre | Sviluppo sicuro e sicurezza delle applicazioni | Evidenze SDLC, campione di revisione del codice, risultati dei test di sicurezza, riesame dello sviluppo esternalizzato |
| Novembre | Audit interno completo del SGSI e riesame cross-compliance | Rapporto di audit interno, registro delle risultanze, mappatura NIS2 e DORA, evidenze di accountability GDPR |
| Dicembre | Riesame della direzione e chiusura delle azioni correttive | Verbali del riesame della direzione, stato CAPA, accettazione del rischio residuo, input per il piano di audit 2027 |
Questo calendario fornisce al comitato audit un piano di assurance prospettico e offre ai responsabili dei controlli il tempo per creare evidenze attraverso le normali attività operative.
La dorsale ISO 27002:2022: 5.31, 5.35 e 5.36
Zenith Controls è la guida cross-compliance di Clarysec. Mappa le aree di controllo ISO/IEC 27001:2022 e ISO/IEC 27002:2022 su altri standard, regolamenti, aspettative di audit e pattern di evidenze. È particolarmente utile per collegare riesame interno, obblighi legali e conformità alle politiche.
Tre aree di controllo ISO/IEC 27002:2022 formano la dorsale di un programma di audit interno unificato:
| Area ISO 27002:2022 evidenziata in Zenith Controls | Domanda di audit | Valore per NIS2 e DORA |
|---|---|---|
| 5.31 Requisiti legali, statutari, regolamentari e contrattuali | Sappiamo quali obblighi si applicano e li abbiamo mappati su controlli ed evidenze? | Supporta applicabilità NIS2, obblighi ICT DORA, contratti con i clienti e accountability GDPR |
| 5.35 Riesame indipendente della sicurezza delle informazioni | I riesami sono oggettivi, pianificati, competenti e seguiti da azioni? | Supporta assurance sulle misure di cibersicurezza, sui test di resilienza ICT e sulla supervisione della direzione |
| 5.36 Conformità alle politiche, alle regole e agli standard per la sicurezza delle informazioni | Le regole interne sono seguite nella pratica e monitorate in modo continuativo? | Supporta applicazione della politica, igiene informatica, controllo degli accessi, preparazione agli incidenti e azione correttiva |
Il controllo 5.35 è la pietra angolare dell’assurance perché valida se il SGSI viene riesaminato in modo indipendente. Il controllo 5.36 conferma che le politiche non sono solo approvate, ma effettivamente rispettate. Il controllo 5.31 collega il SGSI agli obblighi legali, normativi e contrattuali, inclusi NIS2, DORA, GDPR e requisiti di sicurezza dei clienti.
Mappatura cross-compliance: un audit, molte prospettive di assurance
Una carta di lavoro matura dell’audit interno dovrebbe mostrare esplicitamente come un singolo elemento di evidenza supporti diverse aspettative di assurance.
| Evidenza di audit | Assurance ISO 27001 | Rilevanza NIS2 | Rilevanza DORA | Rilevanza GDPR, NIST e COBIT |
|---|---|---|---|---|
| Registro legale e normativo | Contesto e obblighi di conformità | Ambito, status dell’entità, driver Article 21 | Obblighi settoriali di resilienza ICT | Accountability GDPR, NIST CSF GOVERN, conformità esterna COBIT |
| Registro dei rischi e piano di trattamento | Valutazione del rischio, trattamento, Dichiarazione di applicabilità | Misure appropriate e proporzionate | Quadro per la gestione del rischio ICT e tolleranza | Gestione del rischio NIST, ottimizzazione del rischio COBIT |
| Report di esercitazione tabletop sugli incidenti | Preparazione agli incidenti e lezioni apprese | Preparazione del workflow di segnalazione | Classificazione, escalation, segnalazione e causa radice | Preparazione alle violazioni GDPR, NIST CSF RESPOND, gestione degli incidenti COBIT |
| Fascicolo di due diligence sui fornitori | Rapporto con i fornitori e catena di fornitura ICT | Vulnerabilità e prassi dei fornitori | Registro ICT di terze parti, due diligence, pianificazione di uscita | NIST C-SCRM, governance dei fornitori COBIT |
| Test di ripristino dei backup | Prontezza ICT e continuità | Backup, disaster recovery, gestione delle crisi | Obiettivi di ripristino e controlli di integrità | Disponibilità GDPR, NIST CSF RECOVER, continuità COBIT |
| Riesame degli accessi | Controllo degli accessi e sicurezza HR | Controllo degli accessi e aspettative MFA | Principio del minimo privilegio e autenticazione forte | Integrità e riservatezza GDPR, NIST CSF PROTECT |
Questo consente al CISO di dire al consiglio: “Il nostro audit sugli incidenti di luglio ha prodotto evidenze per ISO 27001, NIS2, assurance clienti DORA, preparazione alle violazioni GDPR, risultati di risposta NIST CSF e governance degli incidenti COBIT”.
Riesame della direzione: dove l’audit diventa accountability
L’audit interno ha poco valore se le risultanze non arrivano alla direzione. Il riesame della direzione ISO 27001 fornisce il meccanismo, mentre NIS2 e DORA rendono esplicita l’aspettativa di governance.
La Politica di audit e monitoraggio della conformità per PMI richiede:
Le risultanze dell’audit e gli aggiornamenti di stato devono essere inclusi nel processo di riesame della direzione del SGSI.
Dalla sezione “Requisiti di governance”, clausola di politica 5.4.3.
Stabilisce inoltre:
Il GM deve approvare un piano di azioni correttive e tracciarne l’attuazione.
Dalla sezione “Requisiti di governance”, clausola di politica 5.4.2.
Il riesame della direzione dovrebbe rispondere a queste domande:
- Gli obblighi NIS2, DORA, GDPR e contrattuali sono ancora correttamente riflessi nel campo di applicazione del SGSI?
- I controlli ad alto rischio sono auditati con frequenza sufficiente?
- Quali risultanze indicano una debolezza sistemica anziché un errore isolato?
- Le azioni correttive sono in ritardo?
- I responsabili del rischio stanno accettando consapevolmente il rischio residuo?
- Fornitori, segnalazione degli incidenti, continuità e test dispongono di risorse adeguate?
- Le tendenze degli audit suggeriscono modifiche a politiche, strumenti, budget o formazione?
Se queste risposte non sono documentate, l’organizzazione può avere evidenza di attività, ma non evidenza di governance.
Errori comuni da evitare nel 2026
L’errore più comune è trattare l’audit interno ISO 27001 come separato dall’assurance normativa. Questo genera duplicazioni e punti ciechi.
Altri errori includono:
- L’ambito esclude fornitori critici, piattaforme cloud o servizi SOC esternalizzati.
- L’applicabilità di NIS2 o DORA non è documentata nel registro normativo.
- Il piano di audit non è approvato dalla direzione.
- Il campionamento viene svolto ma non documentato.
- Gli auditor interni riesaminano il proprio lavoro senza mitigazioni.
- Le risultanze descrivono sintomi ma non cause radice.
- Le azioni correttive aggiornano documenti ma non correggono processi.
- Il riesame della direzione riceve i risultati dell’audit ma non prende decisioni.
- Le esercitazioni sugli incidenti testano la risposta tecnica ma non la notifica normativa.
- Gli audit sui fornitori riesaminano questionari ma non contratti, piani di uscita o rischio di concentrazione.
- Le evidenze di backup mostrano job riusciti ma non l’integrità del ripristino.
- I riesami degli accessi sono eseguiti, ma le eccezioni non sono tracciate fino alla chiusura.
Ogni errore può diventare una non conformità minore o maggiore in base alla gravità e all’impatto sistemico. Soprattutto, ciascuno indebolisce la capacità dell’organizzazione di dimostrare resilienza ai sensi di NIS2, DORA e sotto lo scrutinio dei clienti.
Trasformare il piano di audit 2026 in un motore di evidenze
Se il tuo programma di audit interno è ancora un singolo evento annuale, è il momento di riprogettarlo.
Parti da un piano di audit approvato dalla direzione. Definisci il campo di applicazione del SGSI intorno a servizi reali, obblighi regolamentati e dipendenze da terze parti. Costruisci un universo di audit basato sul rischio. Documenta il campionamento. Classifica le risultanze in modo coerente. Usa l’analisi della causa radice. Traccia la CAPA. Porta i risultati nel riesame della direzione. Mantieni un calendario mensile delle evidenze.
Clarysec può aiutarti ad accelerare con:
- Zenith Blueprint: roadmap in 30 passi per auditor per pianificazione dell’audit, esecuzione, risultanze, riesame della direzione e miglioramento continuo.
- Zenith Controls: la guida cross-compliance per mappare l’assurance ISO 27001 sulle aspettative NIS2, DORA, GDPR, NIST CSF e COBIT.
- Politica di audit e monitoraggio della conformità e Politica di audit e monitoraggio della conformità per PMI per pianificazione degli audit e gestione delle risultanze pronte per la governance.
- Politica per la sicurezza delle informazioni per il riesame a livello di direzione di KPI, incidenti, risultanze dell’audit e stato del rischio.
Scegli un dominio ad alto rischio, come la segnalazione degli incidenti o la governance dei fornitori ICT, ed esegui un audit interno mirato utilizzando la struttura Clarysec per ambito, campionamento e risultanze. Entro un ciclo saprai se le tue evidenze sono pronte per l’audit, se i controlli operano e se l’organo di gestione dispone delle informazioni necessarie per governare il rischio di cibersicurezza.
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
