Documenti obbligatori ISO 27001: l'elenco per l'audit

La ISO/IEC 27001 non elenca documenti per nome: chiede informazioni documentate nei punti dal 4 al 10, che non si possono escludere, compresa la Dichiarazione di Applicabilità. Il nucleo obbligatorio: campo di applicazione, politica, metodo e risultati della valutazione e del trattamento del rischio, SoA, obiettivi, prove di competenza, monitoraggio, audit interni, riesame e azioni correttive.

Tutto il resto (procedure, registri, istruzioni operative) dipende dai controlli che scegli nella SoA e da quello che serve davvero a far funzionare il sistema. Qui trovi l'elenco ordinato secondo la struttura della norma, i documenti legati ai controlli, cosa guarda l'organismo di certificazione e gli errori che allungano l'audit.

Cosa intende la norma per documento obbligatorio

In Italia la norma è pubblicata come UNI CEI EN ISO/IEC 27001:2024+A1:2024, che riprende il testo della ISO/IEC 27001:2022 e del suo aggiornamento Amd 1:2024. Tre elementi del testo ufficiale, leggibili nell'anteprima UNI, spiegano come ragionare sui documenti.

• Non si parla di documenti ma di informazioni documentate. È il titolo del punto 7.5, diviso in tre parti: Generalità, Creazione e aggiornamento delle informazioni documentate, Controllo delle informazioni documentate. Nella pratica il formato è libero: un file, una pagina wiki, una registrazione in uno strumento.
• I punti dal 4 al 10 non si escludono. Il punto 1 della norma stabilisce che l'esclusione di uno qualunque dei requisiti di quei punti non è accettabile per chi dichiara la conformità. Le informazioni documentate richieste lì sono quindi obbligatorie per tutti, a prescindere da dimensione e settore.
• La struttura è comune agli altri sistemi di gestione. L'introduzione (punto 0.2) spiega che la norma usa la struttura, i titoli e il testo dell'Annex SL delle Direttive ISO/IEC, la stessa delle altre norme sui sistemi di gestione che adottano l'Annex SL. Chi ha già la ISO 9001 riconosce metà dell'impianto: audit interni, riesame, azioni correttive.

Nella pratica i documenti obbligatori si dividono in due famiglie: quelli che descrivono (campo, politica, metodo di rischio) e si mantengono aggiornati, e le registrazioni che provano che il sistema ha funzionato (risultati del rischio, audit, riesame) e si conservano. L'auditor legge i primi per capire cosa hai deciso e i secondi per verificare che lo fai.

L'elenco dei documenti obbligatori, punto per punto

L'ordine segue l'indice della norma, e i titoli dei punti sono quelli della versione UNI. Il legame fra ogni punto e il documento che ne nasce, e la descrizione di cosa contiene, sono la lettura usata negli audit di certificazione: la confermi sul testo integrale della norma, che è a pagamento.

Contesto dell'organizzazione (punto 4)

• Campo di applicazione del SGSI, dal punto 4.3 Determinare il campo di applicazione del sistema di gestione per la sicurezza delle informazioni. Dice quali sedi, processi, servizi e sistemi sono dentro il perimetro, e dove stanno i confini con fornitori e altre società del gruppo. È il primo documento che l'organismo legge, perché da lì dipendono la durata dell'audit e il testo del certificato. Se il concetto di sistema di gestione ti è nuovo, parti da cos'è un SGSI.

Leadership (punto 5)

• Politica per la sicurezza delle informazioni, dal punto 5.2 Politica. Nella prassi è approvata dalla direzione e comunicata al personale. Come si scrive e cosa contiene è spiegato nella guida alla politica di sicurezza delle informazioni.
• Ruoli e responsabilità, dal punto 5.3 Ruoli, responsabilità e autorità. Non sempre è un documento a sé: nella prassi un organigramma della sicurezza o una matrice delle responsabilità è il modo più semplice per mostrare all'auditor chi fa cosa.

Pianificazione (punto 6)

• Metodo di valutazione del rischio, dal punto 6.1.2 Valutazione del rischio relativo alla sicurezza delle informazioni: criteri, scale, soglia di accettazione. Il metodo passo per passo è nella guida all'analisi del rischio ISO 27001.
• Metodo di trattamento del rischio e piano di trattamento, dal punto 6.1.3 Trattamento del rischio relativo alla sicurezza delle informazioni: per ogni rischio non accettabile, quali controlli, chi, entro quando, e chi accetta il rischio residuo.
• Dichiarazione di Applicabilità (SoA), che nasce nello stesso punto 6.1.3: elenca i controlli scelti, li confronta con l'Appendice A e motiva inclusioni ed esclusioni. In Italia pesa anche sul certificato: la Circolare tecnica Accredia DC n. 22/2026 stabilisce che Lo scopo di certificazione rilasciato dall’OdC deve contenere espresso riferimento alla SoA ed al suo stato di aggiornamento. Struttura ed esempi nella guida alla Dichiarazione di Applicabilità.
• Obiettivi per la sicurezza delle informazioni, dal punto 6.2 Obiettivi per la sicurezza delle informazioni e pianificazione per conseguirli: pochi, misurabili, con responsabile, scadenza e modo di valutarli.

Supporto (punto 7)

• Prove di competenza, dal punto 7.2 Competenze: requisiti di competenza per i ruoli che toccano la sicurezza e le evidenze che chi li ricopre li ha (formazione, attestati, esperienza).
• I documenti che servono al sistema. Nella prassi rientrano qui anche le informazioni documentate che l'organizzazione decide di tenere perché il SGSI funzioni; il punto 7.5.3, Controllo delle informazioni documentate, riguarda come si gestiscono: versione, approvazione, distribuzione, conservazione.

Attività operative (punto 8)

• Evidenze di pianificazione e controllo operativi, dal punto 8.1 Pianificazione e controllo operativi: quanto basta a mostrare che i processi sono stati eseguiti come pianificato, compresi quelli affidati all'esterno.
• Risultati della valutazione del rischio (punto 8.2) e risultati del trattamento (punto 8.3): il registro dei rischi aggiornato quando cambiano perimetro, sistemi o minacce, e lo stato del piano di trattamento.

Valutazione delle prestazioni (punto 9)

• Risultati di monitoraggio e misurazione, dal punto 9.1 Monitoraggio, misurazione, analisi e valutazione: cosa misuri, con quale frequenza, e i valori ottenuti.
• Programma e risultati degli audit interni, dal punto 9.2.2 Programma degli audit interni. Come si costruiscono è nella guida all'audit interno ISO 27001.
• Risultati del riesame di direzione, dal punto 9.3.3 Risultati del riesame di direzione: decisioni su miglioramento e su eventuali modifiche al sistema.

Miglioramento (punto 10)

• Nonconformità e azioni correttive, dal punto 10.2 Nonconformità e azioni correttive: cosa è successo, cosa hai fatto, se ha funzionato.

I documenti che dipendono dai controlli dell'Appendice A

L'Appendice A della norma, di tipo normativo, contiene il prospetto A.1 dei controlli di riferimento. Qui non esiste un elenco fisso: un controllo che la SoA dichiara applicabile porta spesso con sé una regola scritta o una registrazione, un controllo escluso con motivazione no. I documenti che compaiono più spesso sono:

• inventario delle informazioni e degli asset, con i proprietari;
• regole di uso accettabile e di classificazione delle informazioni;
• regole di controllo degli accessi e registrazioni dei riesami delle utenze;
• procedure operative documentate per i sistemi critici;
• procedura di gestione degli incidenti e registro degli incidenti;
• requisiti di sicurezza per i fornitori e verifiche sui fornitori;
• piani di continuità ICT e prove eseguite;
• gestione delle vulnerabilità tecniche, con report e azioni.

Sull'ultimo punto Accredia è esplicita. La stessa circolare DC n. 22/2026, richiamando i requisiti 6.1.2, 8.2 e il controllo A.8.8, chiede all'organismo di accertare se l'organizzazione si sottopone periodicamente a vulnerability assessment o penetration test in base al livello di rischio, e di verificare che siano conservate registrazioni sulla qualifica di chi li esegue e sulle azioni prese per ridurre l'esposizione. Che il test lo faccia il tuo personale o un fornitore, il rapporto da solo non basta: servono anche le prove su chi l'ha fatto e su cosa hai corretto dopo.

Vale lo stesso per il cloud. La circolare chiede all'organismo di verificare come l'organizzazione garantisce la sicurezza delle infrastrutture usate, compresi servizi cloud, housing e hosting; i certificati accreditati in ambito EA/MLA dei fornitori sono presunzione di conformità, altrimenti l'organismo deve fare audit del sito. Tenere nel fascicolo fornitori i certificati dei tuoi provider fa risparmiare tempo a entrambi.

Cosa guarda davvero l'organismo di certificazione

L'auditor non conta i documenti: segue un filo. Parte dal campo di applicazione, passa al registro dei rischi, arriva alla SoA e da una riga della SoA chiede di vedere il controllo funzionare. Se il filo si interrompe, il problema è lì, anche se ogni documento preso da solo è in ordine.

La circolare Accredia aggiunge due indicazioni utili per chi si prepara:

• le riduzioni dei tempi di audit vanno giustificate in modo dettagliato e supportate da evidenze documentate;
• avere altre certificazioni, anche dello stesso organismo, non basta da solo a considerare il sistema maturo, se non c'è evidenza di risultati positivi dall'ultimo audit di terza parte e di audit interni efficaci.

Per questo le registrazioni contano quanto le procedure. Una politica impeccabile senza un audit interno svolto e un riesame di direzione verbalizzato non regge all'audit di certificazione.

Gli errori che vediamo più spesso

• Kit di modelli copiati. Decine di documenti scaricati, rinominati e mai usati. L'auditor li riconosce perché non citano nessun rischio, sistema o persona dell'azienda.
• Documentare controlli esclusi. Se la SoA esclude un controllo con una motivazione valida, la procedura relativa è carta in più da mantenere.
• Procedure senza registrazioni. La procedura di gestione incidenti esiste, il registro degli incidenti è vuoto da un anno. Per l'auditor è un segnale, non una buona notizia.
• Versioni non controllate. Tre copie della politica con date diverse in tre cartelle. Il controllo delle informazioni documentate è il punto 7.5.3.
• Audit interno e riesame lasciati per ultimi. Sono registrazioni obbligatorie e richiedono tempo per essere fatte bene: vanno pianificati prima dell'audit di certificazione, non la settimana prima.

Come organizzarli senza annegare nella carta

1. Parti da perimetro e rischio. Campo di applicazione e metodo di valutazione decidono quanto sarà grande tutto il resto.
2. Scrivi la SoA dopo il registro dei rischi. È lei a dirti quali documenti dei controlli servono.
3. Tieni un indice dei documenti. Per ognuno: proprietario, revisione, data di approvazione, dove sta. È anche la prova più rapida del controllo delle versioni.
4. Raccogli le evidenze dai sistemi, non a mano. Le piattaforme di compliance collegate a cloud, identità e strumenti di sviluppo registrano in continuo configurazioni e riesami, e riducono il lavoro a ridosso dell'audit.
5. Riusa quello che hai. Con la ISO 9001 già attiva, audit interni, riesame e azioni correttive seguono la stessa struttura e si possono integrare.

Per capire quanto manca rispetto a questo elenco, il passo più rapido è una gap analysis ISO 27001.

In sintesi

I documenti obbligatori della ISO 27001 sono le informazioni documentate richieste nei punti dal 4 al 10, che non si possono escludere, compresa la Dichiarazione di Applicabilità, che in Italia entra anche nello scopo del certificato. Gli altri dipendono dai controlli scelti nella SoA. Contano meno il numero e il formato, conta il filo che lega perimetro, rischi, controlli ed evidenze. Il quadro completo della norma è nella guida completa alla ISO 27001.

Se vuoi capire quali documenti ti mancano e costruirli sui rischi reali della tua azienda, puoi vedere come lavoriamo sul percorso ISO 27001.