Evidenze per l'audit ISO 27001: cosa si aspetta l'auditor

In un audit ISO/IEC 27001 l'auditor non cerca una pila di carte: cerca prove attendibili che il sistema di gestione della sicurezza delle informazioni (SGSI) funzioni davvero. Servono documenti approvati, registrazioni di ciò che è successo ed evidenze che le decisioni siano state prese e applicate. Chi le raccoglie durante l'anno arriva all'audit con un archivio ordinato; chi le rincorre nelle ultime settimane rischia lacune, non conformità e un audit più lungo del necessario.

La scheda ufficiale ISO/IEC 27001 descrive la norma come l'insieme dei requisiti per istituire, attuare, mantenere e migliorare continuamente un SGSI, per organizzazioni di qualsiasi dimensione. La certificazione è una scelta e viene rilasciata da organismi di valutazione, idealmente accreditati: non è la norma a certificare un software, e nessun software certifica automaticamente l'organizzazione. Il testo della norma è a pagamento e non lo riproduciamo; qui trovi una guida pratica alle evidenze, da adattare con chi segue il tuo percorso.

Documento, registrazione, evidenza: tre cose diverse

Gran parte della confusione pre-audit nasce qui. Le tre categorie si usano insieme, ma rispondono a domande diverse.

Una politica scritta bene ma mai applicata non è un'evidenza di funzionamento: è solo un documento. L'evidenza nasce quando puoi mostrare, per esempio, che gli accessi descritti nella procedura sono stati effettivamente revocati a fine rapporto, con data e responsabile visibili.

Per essere attendibile, un'evidenza deve avere caratteristiche riconoscibili:

• provenienza: da quale sistema, processo o persona arriva;
• data e ora: quando il fatto è avvenuto o il documento è stato approvato;
• responsabile: chi ha deciso, eseguito o verificato;
• integrità: non è stata alterata dopo la produzione, o le modifiche sono tracciate;
• coerenza: corrisponde a ciò che dicono politiche e procedure.

Le richieste più comuni degli auditor

Ogni audit segue un programma definito con l'organismo di certificazione e dipende dal tuo campo di applicazione e dai tuoi rischi. L'elenco che segue è orientativo, non una ricostruzione della norma: serve ad arrivare preparato sulle aree che tornano più spesso.

• Campo di applicazione e analisi dei rischi: perimetro del SGSI, metodo di valutazione, registro dei rischi e piano di trattamento approvato.
• Dichiarazione di Applicabilità (SoA): quali controlli hai scelto, quali hai escluso e perché. Le esclusioni vanno motivate; ne parliamo nella guida alla Dichiarazione di Applicabilità.
• Riesame della direzione: verbali che mostrino partecipanti, temi trattati e decisioni prese. Vedi come preparare il riesame della direzione.
• Audit interni: programma, rapporti e seguito delle osservazioni, come descritto in audit interni del SGSI.
• Non conformità e azioni correttive: come sono state rilevate, corrette e verificate, con la causa radice. Approfondimento in non conformità e azioni correttive.
• Competenze e formazione: registri di corsi, mansionari, presa di conoscenza delle procedure.
• Gestione operativa: accessi concessi e revocati, gestione dei fornitori, incidenti gestiti, prove di ripristino dei backup, manutenzioni e cambiamenti rilevanti.

Nota il filo comune: per quasi ogni richiesta l'auditor vuole vedere insieme la regola (documento), il fatto (registrazione) e la decisione di una persona responsabile. Preparare una di queste tre componenti senza le altre lascia il cerchio aperto.

Raccolta continua: fonti, timestamp e responsabili

Il modo più semplice per non rincorrere le evidenze è farle nascere già pronte. Ogni volta che si conclude un'attività rilevante per il SGSI, l'elemento prodotto dovrebbe entrare in un archivio unico con tre informazioni minime: fonte (da dove arriva), data e ora e responsabile. Senza questi tre dati, a distanza di mesi anche una registrazione vera diventa difficile da difendere.

Un metodo pratico, adattabile a qualsiasi gestionale o archivio condiviso:

1. Indicizza per requisito e controllo. Organizza l'archivio sulle aree del SGSI (accessi, fornitori, incidenti, formazione, riesame), non per reparto o per data di scadenza dell'audit.
2. Collezione automatica dove possibile. Log di sistema, ticket e registri degli strumenti di sicurezza producono registrazioni con timestamp nativi: conservali, non ricopiarli a mano.
3. Fissa le ricorrenze. Riesame della direzione, audit interni, verifica degli accessi, prove di ripristino: ogni attività periodica ha bisogno di una scadenza, di un responsabile e di un posto dove finisce il verbale.
4. Cerca le lacune, non solo i documenti. Una verifica trimestrale che chiede «per ogni area, qual è l'evidenza più recente?» scopre i vuoti quando c'è ancora tempo per colmarli.
5. Prova il prelievo. Testa la prontezza con domande secche: «mostrami l'ultima revoca di accesso con data e responsabile», «mostrami quando è stato approvato il piano di trattamento». Se la risposta richiede ore, l'archivio non è pronto.

Esempio illustrativo: la rincorsa e l'alternativa

Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare il metodo; non racconta un audit avvenuto presso un'organizzazione reale.

Una società di servizi contabili con trenta dipendenti affronta il primo audit di certificazione. Sei settimane prima della data, il responsabile qualità scopre che le prove degli accessi revocati ai gestionali dei clienti sono sparse: alcune in email, alcune nei ticket del fornitore IT, altre solo nella memoria di chi le ha eseguite. Le due settimane successive passano a ricostruire mesi di attività, e due revoche restano senza riscontro.

L'alternativa, adottata l'anno seguente: ogni revoca di accesso viene chiusa con un ticket che riporta fonte, data e responsabile; i verbali di riesame vanno in un archivio indicizzato per area; una verifica trimestrale controlla che ogni area abbia evidenze recenti. All'audit successivo la domanda «mostrami le revoche dell'ultimo anno» trova risposta in minuti, e le due lacune residue erano già emerse — e state trattate come non conformità — mesi prima.

Il contributo di OverZeus: Mnemosyne e le evidenze operative

Sul piano operativo, gran parte delle evidenze nasce dalle attività quotidiane di sicurezza: segnalazioni esaminate, modifiche autorizzate, interventi eseguiti. In OverZeus questo è il compito di Mnemosyne, l'agente dedicato ad audit ed evidenze: conserva fonti, timeline, proposte, autorizzazioni ed esiti, e aiuta a ricostruire il percorso di ogni intervento. Quando una modifica risulta priva dell'approvazione associata, Mnemosyne segnala la lacuna senza inventare una ricostruzione: la mancanza resta visibile nel resoconto e spetta al responsabile completare il contesto o trattarla come anomalia.

Il meccanismo si appoggia al ciclo decisionale di OverZeus: prima di un intervento attivo il responsabile vede la proposta e le conseguenze, e l'approvazione prevista resta registrata insieme all'esito; il silenzio non autorizza l'azione. Ne risulta una cronologia di «chi ha deciso cosa, quando e con quale risultato» che alimenta l'archivio delle evidenze durante tutto l'anno, invece di essere ricostruita sotto audit.

Un perimetro da tenere fermo: le evidenze prodotte dagli agenti sono un contributo al tuo SGSI, non una garanzia. Il giudizio spetta all'auditor, la valutazione dei rischi e delle decisioni resta dell'organizzazione, e l'uso di OverZeus da solo non certifica l'azienda.

In sintesi

Documento, registrazione ed evidenza rispondono a domande diverse, e l'audit le vuole vedere insieme: la regola, il fatto e la decisione. Le richieste più comuni riguardano rischi, SoA, riesame, audit interni, non conformità e gestione operativa quotidiana. Il modo per non rincorrerle è uno solo: far nascere ogni evidenza con fonte, data e responsabile, in un archivio indicizzato, e verificarne la completezza durante l'anno.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus