Le evidenze sono ciò che trasforma il tuo sistema di gestione della sicurezza in qualcosa che un auditor può verificare. Senza di esse, una politica approvata o un controllo ben progettato non contano ai fini della certificazione.
Il problema è che spesso sono sparse tra strumenti, cartelle ed email, e raccoglierle all’ultimo momento è una delle attività che richiedono più tempo in qualsiasi audit ISO 27001.
In questo articolo vedrai quali evidenze chiede l’auditor, come distingue un’evidenza valida da una che non lo è, l’elenco completo per requisito e per controllo dell’Allegato A e i passaggi per averle pronte in vista dell’audit.
Cosa sono le evidenze nella ISO 27001?
Un’evidenza è qualsiasi informazione verificabile che dimostra che il tuo sistema di gestione per la sicurezza delle informazioni (SGSI) funziona esattamente come lo hai descritto. Se la tua politica dice che i portatili sono cifrati, l’evidenza è il report che mostra quali dispositivi sono cifrati e da quando.
La norma parla di informazioni documentate e ne distingue due tipi.
- Informazioni da mantenere. Sono i documenti che descrivono come funziona il sistema, come la politica di sicurezza, il campo di applicazione o le procedure. Si aggiornano ogni volta che qualcosa cambia.
- Informazioni da conservare. Sono le registrazioni che provano ciò che è successo, come un rapporto di audit interno, un ticket di uscita di un dipendente o un log degli accessi. Non si modificano, si archiviano.
Con i documenti dimostri di aver progettato il sistema. Con le registrazioni dimostri di applicarlo. All’auditor servono entrambe le cose, ed è proprio nelle registrazioni che di solito emergono le lacune.
Se sei arrivato qui cercando il controllo 5.28 dell’Allegato A, conviene chiarire subito la differenza. Quel controllo si chiama «Raccolta delle evidenze» e riguarda un tema più specifico. Richiede una procedura per identificare, raccogliere e preservare le prove dopo un incidente di sicurezza, in modo che siano utilizzabili in un procedimento disciplinare o giudiziario. È un requisito che rientra nella gestione degli incidenti, e non ha nulla a che vedere con le evidenze che l’auditor esamina per rilasciarti la certificazione.
Quali tipi di evidenze esamina l'auditor?
L’audit di certificazione si svolge in due fasi. Nella fase 1 l’auditor esamina la documentazione del SGSI e verifica che tu sia pronto. Nella fase 2 controlla che quanto documentato venga applicato nella pratica quotidiana. Per farlo combina quattro tipi di evidenze.
| Tipo di evidenza | In cosa consiste | Esempio |
|---|---|---|
| Documentale | Politiche, procedure, verbali e piani approvati | Politica di controllo degli accessi firmata dalla direzione |
| Registrazioni tecniche | Esportazioni, log e report generati dai sistemi | Report delle patch in sospeso per dispositivo |
| Interviste | Domande ai responsabili di ciascun processo | Chiedere al team IT cosa fa quando qualcuno lascia l’azienda |
| Osservazione | Verifica diretta di come viene eseguito un controllo | Chiedere di mostrare a schermo la configurazione del blocco di un dispositivo |
L’auditor non controlla tutto, ma lavora a campione. Sceglie tre uscite dell’ultimo trimestre, cinque portatili a caso o un incidente specifico, e ricostruisce il percorso dall’inizio alla fine. Basta che un solo campione non corrisponda a quanto dice la politica perché scatti un rilievo.
Per questo non basta che l’evidenza esista. Perché l’auditor la consideri valida, deve rispettare alcune condizioni.
- Datata. Uno screenshot senza data non dimostra che il controllo fosse attivo durante il periodo oggetto di audit.
- Nel campo di applicazione. Deve riferirsi ai sistemi, alle sedi e ai processi inclusi nel SGSI.
- Tracciabile. Deve essere chiaro chi l’ha generata, chi ha approvato l’azione e a quale controllo si riferisce.
- Coerente con la politica. Se la politica prevede un riesame trimestrale degli accessi, l’auditor si aspetterà di trovarne quattro all’anno.
- Autentica. Generata al momento giusto e mai modificata. Una registrazione creata a posteriori è peggio che non averla affatto.
Elenco delle evidenze ISO 27001
L’elenco si divide in due blocchi. Le evidenze del SGSI rispondono ai capitoli dal 4 al 10 e sono obbligatorie per qualsiasi azienda. Le evidenze dei controlli dell’Allegato A dipendono dai controlli che hai dichiarato applicabili nella tua dichiarazione di applicabilità.
1. Le evidenze del SGSI
Sono quelle che dimostrano che il sistema di gestione esiste, ha un responsabile e viene riesaminato. Nessuno strumento tecnico le genera al posto tuo, per cui conviene sapere fin dall’inizio dove si trovano.
| Requisito | Cosa dimostra | Evidenza tipica |
|---|---|---|
| 4.3 Campo di applicazione | Cosa copre il SGSI e cosa resta escluso | Documento del campo di applicazione approvato, con sedi, processi, sistemi e interfacce |
| 5.2 Politica | L’impegno della direzione | Politica per la sicurezza delle informazioni firmata e comunicata al personale |
| 5.3 Ruoli | Chi è responsabile di cosa | Organigramma della sicurezza o matrice delle responsabilità |
| 6.1.2 Valutazione del rischio | Come identifichi e valuti i rischi | Metodologia documentata e risultati dell’ultima valutazione dei rischi |
| 6.1.3 Trattamento del rischio | Cosa decidi di fare con ciascun rischio | Piano di trattamento, dichiarazione di applicabilità e accettazione del rischio residuo da parte dei risk owner |
| 6.2 Obiettivi | Cosa vuoi ottenere e come lo misuri | Obiettivi di sicurezza con responsabile, scadenza e indicatore |
| 7.2 Competenza | Che le figure chiave sono preparate | Certificazioni, registri della formazione e mansionari |
| 7.3 Consapevolezza | Che il personale conosce la politica | Registri delle presenze e risultati delle sessioni formative |
| 8.1 Controllo operativo | Che i processi vengono eseguiti come pianificato | Registri delle modifiche, ticket e piani d’azione |
| 9.1 Monitoraggio e misurazione | Che misuri le prestazioni del SGSI | Cruscotto degli indicatori con i risultati per periodo |
| 9.2 Audit interno | Che verifichi il sistema prima di chiunque altro | Programma di audit, rapporto dell’ultimo audit interno e rilievi |
| 9.3 Riesame della direzione | Che la direzione supervisiona il sistema | Verbale dell’ultimo riesame con le decisioni e le azioni concordate |
| 10.2 Non conformità | Che correggi ciò che non funziona | Registro delle non conformità con analisi delle cause, azione correttiva e verifica dell’efficacia |
Il riesame della direzione e l’audit interno sono le due evidenze che si dimenticano più spesso alla prima certificazione. Entrambi devono essere stati svolti prima della fase 2, con il tempo necessario per chiudere i rilievi.
2. Le evidenze dei controlli dell’Allegato A
L’Allegato A della ISO/IEC 27001:2022 raccoglie 93 controlli suddivisi in quattro gruppi. Non tutti si applicano a tutte le aziende, ma ogni controllo che dichiari applicabile ha bisogno di almeno un’evidenza del suo funzionamento. Queste sono le più frequenti durante un audit.
Controlli organizzativi
| Controllo | Evidenza che l’auditor chiede di solito |
|---|---|
| 5.9 Inventario degli asset | Inventario aggiornato con un proprietario assegnato a ciascun asset e la data dell’ultimo riesame |
| 5.10 Utilizzo accettabile | Regole di utilizzo accettabile e registrazione della loro accettazione da parte del personale |
| 5.11 Restituzione degli asset | Registro della riconsegna dei dispositivi nelle ultime uscite |
| 5.15 a 5.18 Controllo degli accessi | Politica degli accessi, richieste approvate, riesami periodici dei permessi e revoca degli accessi nelle uscite |
| 5.19 a 5.22 Fornitori | Registro dei fornitori critici, clausole di sicurezza nei contratti e valutazioni periodiche |
| 5.23 Servizi cloud | Elenco dei servizi cloud in uso, responsabile di ciascuno e criteri di selezione |
| 5.24 a 5.27 Incidenti | Procedura di gestione degli incidenti, registro degli incidenti con cronologia e lezioni apprese |
| 5.29 e 5.30 Continuità | Piano di continuità e verbale dell’ultimo test effettuato |
Controlli relativi alle persone
| Controllo | Evidenza che l’auditor chiede di solito |
|---|---|
| 6.1 Screening | Procedura di verifica in fase di assunzione e registrazioni della sua applicazione |
| 6.2 Termini e condizioni di impiego | Contratti o allegati firmati con obblighi di sicurezza e riservatezza |
| 6.3 Formazione e consapevolezza | Piano formativo, presenze e risultati per dipendente |
| 6.5 Responsabilità dopo la cessazione | Checklist di offboarding completata per le uscite recenti |
| 6.7 Lavoro da remoto | Politica sullo smart working e configurazione di sicurezza dei dispositivi usati da remoto |
Controlli fisici
| Controllo | Evidenza che l’auditor chiede di solito |
|---|---|
| 7.1 e 7.2 Perimetro e accessi fisici | Registro degli accessi agli uffici o alle aree riservate |
| 7.9 Asset all’esterno delle sedi | Elenco dei dispositivi assegnati fuori dall’ufficio e misure applicate, come la cifratura o il blocco da remoto |
| 7.10 Supporti di memorizzazione | Politica sull’uso dei supporti rimovibili e sua applicazione tecnica |
| 7.14 Dismissione o riutilizzo delle apparecchiature | Registro della cancellazione sicura o certificato di distruzione dei dispositivi dismessi |
Controlli tecnologici
| Controllo | Evidenza che l’auditor chiede di solito |
|---|---|
| 8.1 Dispositivi endpoint degli utenti | Stato di conformità di ogni dispositivo rispetto alle politiche di sicurezza, come il blocco dello schermo, la password o la versione del sistema operativo |
| 8.2 Accessi privilegiati | Elenco degli account con privilegi di amministratore e relativa motivazione |
| 8.5 Autenticazione sicura | Configurazione dell’autenticazione a più fattori e sistemi in cui è attiva |
| 8.7 Protezione dai malware | Copertura della soluzione antimalware o EDR per dispositivo e registro degli alert |
| 8.8 Vulnerabilità tecniche | Report delle patch applicate e in sospeso, con le date |
| 8.9 Gestione della configurazione | Configurazioni di base approvate e verifica che i dispositivi le rispettino |
| 8.10 Cancellazione delle informazioni | Registrazioni della cancellazione dei dati sui dispositivi dismessi o riassegnati |
| 8.13 Backup delle informazioni | Politica di backup, registro delle esecuzioni e test di ripristino |
| 8.15 Logging | Log dei sistemi critici e periodo di conservazione |
| 8.24 Uso della crittografia | Stato della cifratura dei dischi per dispositivo e gestione delle chiavi di ripristino |
| 8.32 Gestione delle modifiche | Registro delle modifiche con valutazione, approvazione e test |
Se vuoi ripassare il contenuto di ciascun gruppo prima di costruire il tuo elenco, nell’articolo sui domini della ISO 27001 trovi il dettaglio di ognuno.
Come raccogliere le evidenze per l'audit?
Le aziende che superano l’audit senza sorprese hanno qualcosa in comune. Decidono quale evidenza corrisponde a ogni controllo molto prima che l’auditor la chieda. Questi sono i passaggi per riuscirci.
1. Parti dalla dichiarazione di applicabilità
La dichiarazione di applicabilità (SoA) riporta i controlli dell’Allegato A che hai deciso di applicare e la motivazione di ogni scelta. È il miglior punto di partenza, perché ti dice esattamente cosa dovrai dimostrare.
Scorri la SoA controllo per controllo e annota accanto a ciascuno l’evidenza che ne prova il funzionamento. Se un controllo applicabile non ha nessuna evidenza associata, hai già trovato la tua prima lacuna. E se dichiari un controllo come implementato ma non puoi mostrare nulla che lo supporti, l’auditor se ne accorgerà nella fase 2.
2. Assegna un responsabile e una frequenza a ogni evidenza
Un’evidenza senza responsabile finisce per non essere più aggiornata. Ogni evidenza ha bisogno di una persona che la generi e di un’altra che la verifichi, oltre che di una frequenza in linea con quanto previsto dalla tua politica.
Alcune evidenze si producono una volta all’anno, come il riesame della direzione. Altre cambiano ogni settimana, come lo stato delle patch. Riunire tutte queste informazioni in una mappa delle evidenze ti dà una visione immediata di cosa è coperto e cosa no. Può essere semplice come questa.
| Controllo | Evidenza | Fonte | Responsabile | Frequenza |
|---|---|---|---|---|
| 5.9 | Inventario degli asset con proprietario | Strumento di gestione degli asset | Responsabile IT | Continua, riesame trimestrale |
| 5.18 | Riesame dei permessi | Directory e applicazioni SaaS | Responsabili di area | Trimestrale |
| 8.8 | Report delle patch | MDM | Responsabile IT | Mensile |
| 9.3 | Verbale del riesame della direzione | Documento interno | CISO | Annuale |
3. Centralizza e automatizza le evidenze
Quando le evidenze sono sparse tra la posta elettronica, cartelle personali e diversi strumenti, ritrovarle richiede ore. E se l’unica persona che sa dove si trova tutto non è disponibile il giorno dell’audit, le cose si complicano parecchio.
Conservale in un unico repository, con una cartella per requisito o per controllo e la data nel nome di ogni file. Limita l’accesso a chi ne ha davvero bisogno, perché molte contengono informazioni sensibili.
Per le evidenze tecniche, come l’inventario degli asset, la cifratura dei dispositivi o le patch, la soluzione migliore è che arrivino direttamente dai tuoi strumenti di gestione dei dispositivi. Un’esportazione manuale diventa obsoleta nel giro di poche settimane, mentre un report automatico riflette sempre la situazione reale e riporta la propria data. Se stai ancora valutando quale soluzione adottare, nel nostro confronto dei migliori software per conformarsi alla ISO 27001 trovi le principali alternative.
4. Fai una simulazione su casi reali
Prima della fase 2, mettiti nei panni dell’auditor. Scegli un ingresso recente, un’uscita dell’ultimo trimestre e un portatile a caso, e verifica di riuscire a ricostruire l’intera catena per ciascun caso.
Per un’uscita, ad esempio, dovresti poter mostrare la comunicazione dell’ufficio HR, la revoca degli accessi, la riconsegna del dispositivo e la cancellazione dei dati, il tutto con le relative date. Se uno di questi passaggi manca o non torna con quanto dice la politica, meglio scoprirlo adesso. Quello che non trovi tu, non lo troverà nemmeno l’auditor.
5. Mantieni le evidenze tra un audit e l’altro
La certificazione ha una validità di tre anni, con un audit di sorveglianza ogni anno e una ricertificazione alla fine del ciclo. L’auditor esaminerà le evidenze dell’intero periodo trascorso dall’ultima visita, non solo del mese precedente.
Se le evidenze vengono prodotte solo quando l’audit si avvicina, ogni sorveglianza torna a essere una corsa contro il tempo. Quelle che si generano in modo continuo, con responsabili e frequenze ben definiti, eliminano il problema e fanno funzionare il sistema anche nel resto dell’anno.
Gli errori più comuni con le evidenze
La maggior parte delle non conformità che emergono durante un audit ha poco a che fare con controlli inesistenti. Di solito nasce da controlli che esistono ma che non si riesce a dimostrare. Questi sono gli errori più frequenti.
- Screenshot senza contesto. Un’immagine che mostra «cifratura attiva» non dice su quale dispositivo, in quale data né se vale per il resto del parco. Gli screenshot possono integrare altre evidenze, ma raramente bastano da soli.
- Evidenze create all’ultimo momento. Un verbale di riesame redatto la settimana prima dell’audit o un registro compilato con date passate si riconoscono facilmente. E finiscono per compromettere la credibilità del resto del sistema.
- La politica dice una cosa e la pratica un’altra. Se la politica prevede riesami trimestrali degli accessi e ce n’è solo uno all’anno, l’auditor solleverà una non conformità anche se il riesame è fatto bene. Meglio adattare la politica a una frequenza realistica che non rispettarla.
- Evidenze disperse. Approvazioni nella posta, esportazioni sul portatile di una persona e ticket in tre strumenti diversi. Quando chi sapeva dove si trovava tutto va in ferie o lascia l’azienda, le evidenze spariscono con lui.
- Asset che non compaiono nell’inventario. Un portatile che nessuno ha registrato o un’applicazione SaaS sottoscritta da un reparto senza passare dall’IT. Se l’asset non è nell’inventario degli asset, nessun controllo gli si applica, e l’auditor di solito lo scova incrociando i dati.
- Uscite non chiuse del tutto. L’account principale viene disattivato, ma l’accesso a uno strumento SaaS resta attivo o il portatile non è stato riconsegnato. Le uscite sono tra i primi campioni che chiede l’auditor, perché rivelano subito se i processi HR e IT sono collegati.
Come Factorial IT ti aiuta con le evidenze ISO 27001?
Buona parte delle evidenze dell’Allegato A è di natura tecnica. Descrivono lo stato dei dispositivi, degli accessi e degli asset aziendali in un momento preciso. Raccoglierle a mano obbliga a esportare i dati da diversi strumenti, incrociarli e ripetere tutto prima di ogni audit.
Factorial IT genera queste evidenze in modo continuo a partire dalla gestione quotidiana del parco dispositivi, e ogni report riporta la propria data.
- Inventario degli asset sempre aggiornato (5.9). I dispositivi vengono registrati automaticamente con il proprietario assegnato, su parchi misti macOS, Windows, Linux, iOS e Android. L’inventario si può scaricare con la data e la percentuale di copertura.
- Stato di sicurezza di ogni dispositivo (8.1, 8.9 e 8.24). Le politiche di sicurezza si applicano dall’MDM e lo stato di conformità di ogni dispositivo, cifratura del disco compresa, resta registrato.
- Patch e vulnerabilità (8.8). Visibilità sugli aggiornamenti applicati e in sospeso per dispositivo, con il relativo storico.
- Protezione dai malware (8.7). L’EDR integrato mostra la copertura per dispositivo e il registro degli alert e delle risposte.
- Uscite collegate all’HR (5.11, 6.5 e 7.14). Dato che Factorial IT è sincronizzato con gli ingressi e le uscite gestiti in Factorial, ogni uscita avvia la revoca degli accessi, la riconsegna del dispositivo e la cancellazione da remoto. Resta registrato il tempo tra l’uscita nel software HR e la chiusura dell’ultimo accesso, che è proprio il campione che l’auditor chiede più spesso.
- Applicazioni SaaS e accessi (5.15 e 5.23). Visibilità sulle applicazioni in uso, su chi ha accesso a ciascuna e rilevamento degli strumenti usati senza passare dall’IT.
- Modulo Compliance. Riunisce lo stato di questi controlli in un unico posto, così preparare l’audit significa controllare e scaricare invece di cercare.
È giusto essere chiari sul limite. Factorial IT lavora sul livello tecnico della conformità. Le evidenze del SGSI, come la valutazione dei rischi, la dichiarazione di applicabilità, l’audit interno o il riesame della direzione, dipendono dal tuo team e dal tuo processo di gestione. Nessuno strumento può sostituirle.
Per coprire questa parte, Factorial offre un servizio di certificazione ISO 27001 dall’inizio alla fine insieme a partner specializzati, che accompagna l’azienda dalla diagnosi fino all’audit. E se vuoi vedere controllo per controllo quale evidenza genera la piattaforma, trovi tutto nel dettaglio in come Factorial IT aiuta a conformarsi alla ISO 27001.
