Checklist ISO 27001: cosa preparare per la certificazione

Una checklist ISO 27001 per prepararsi alla certificazione segue i punti dal 4 al 10 della norma e i controlli dell'Appendice A scelti in base al rischio: perimetro e contesto, direzione e ruoli, rischio e SoA, risorse e documenti, controlli attuati, audit interno, riesame di direzione e azioni correttive. Ogni voce si spunta solo con un'evidenza datata e un responsabile.

Questa checklist è pensata per chi vuole arrivare al primo audit dell'organismo di certificazione senza sorprese. Per capire prima come funziona la norma nel suo insieme, parti dalla guida completa alla ISO 27001. In Italia la norma si acquista come UNI CEI EN ISO/IEC 27001:2024+A1:2024, cioè il testo della ISO/IEC 27001:2022 con l'emendamento 1 del 2024 (premesse della scheda UNI). I numeri dei punti citati qui sotto sono quelli dell'indice della norma.

Prima di spuntare: tre regole d'uso

• L'ordine è pratico, non obbligatorio. L'introduzione della norma precisa che l'ordine in cui sono presentati i requisiti non ne indica l'importanza né l'ordine di attuazione. La sequenza di questa checklist è quella che di solito evita di rifare lavoro: prima il perimetro, poi il rischio, poi i controlli.
• I punti dal 4 al 10 non si escludono. Secondo il punto 1 della norma, chi dichiara la conformità non può escludere nessun requisito di quei punti. I controlli dell'Appendice A, invece, si selezionano in base al rischio e le scelte si motivano nella SoA.
• Una voce vale l'evidenza che la regge. Per ogni riga servono tre cose: il documento o la registrazione, chi ne risponde, la data dell'ultima revisione. Se molte righe restano vuote, conviene misurare la distanza con una gap analysis ISO 27001 prima di fissare la data dell'audit.

Fase 1: perimetro e contesto (punto 4)

• Contesto dell'organizzazione (4.1). Fattori interni ed esterni che incidono sulla sicurezza delle informazioni, scritti e datati. La Circolare tecnica Accredia DC n. 22/2026 ricorda che l'emendamento del 2024 ha integrato i punti 4.1 e 4.2 con un riferimento ai cambiamenti climatici: nella prassi l'analisi del contesto registra se il tema è pertinente per l'azienda e perché.
• Parti interessate (4.2). Elenco di clienti, autorità, fornitori e altre parti rilevanti, con i loro requisiti: clausole contrattuali, GDPR, eventuali obblighi NIS2 o richieste dei clienti nei questionari fornitori.
• Campo di applicazione (4.3). Documento di scope con processi, sedi, sistemi, persone e dipendenze da fornitori esterni. È la voce da chiudere per prima, perché decide quanto è grande tutto il resto.
• Sistema di gestione (4.4). Una mappa dei processi del SGSI e di come si collegano tra loro: chi valuta i rischi, chi gestisce gli incidenti, chi fa gli audit, chi riferisce alla direzione.

Fase 2: direzione, politica e ruoli (punto 5)

• Leadership e impegno (5.1). Un verbale della direzione o del consiglio che avvia il progetto, assegna risorse e nomina chi lo guida. In audit l'impegno si dimostra con decisioni registrate, non con dichiarazioni.
• Politica (5.2). La politica per la sicurezza delle informazioni approvata, datata e comunicata al personale, con un riscontro di chi l'ha ricevuta.
• Ruoli, responsabilità e autorità (5.3). Organigramma della sicurezza, responsabile del SGSI, proprietari dei rischi e degli asset, con incarichi assegnati per iscritto.

Fase 3: rischio, SoA e obiettivi (punto 6)

• Criteri di rischio approvati. Scala di probabilità e impatto, soglia di accettazione, chi può accettare un rischio residuo. Vanno decisi prima di valutare, altrimenti il registro non è ripetibile.
• Valutazione del rischio (6.1.2). Registro dei rischi con asset o processi, minacce, vulnerabilità, probabilità, impatto e proprietario. Il metodo passo per passo è nell'articolo sull'analisi del rischio ISO 27001.
• Trattamento del rischio (6.1.3). Piano di trattamento con azioni, responsabili e date, e accettazione formale dei rischi residui da parte dei proprietari.
• Dichiarazione di Applicabilità. Ogni controllo dell'Appendice A con applicabilità, motivazione, stato di attuazione, numero di revisione e data. Per la Circolare Accredia DC n. 22/2026 lo scopo del certificato deve fare espresso riferimento alla SoA e al suo stato di aggiornamento, quindi revisione e data non sono un dettaglio. Come si scrive è nell'articolo sulla SoA ISO 27001.
• Obiettivi (6.2). Obiettivi di sicurezza misurabili, con indicatore, responsabile e scadenza.
• Pianificazione delle modifiche (6.3). Come si decidono e si registrano i cambiamenti del sistema di gestione.

Fase 4: risorse, persone e documenti (punto 7)

• Risorse (7.1). Persone e budget assegnati al SGSI, scritti in un documento della direzione.
• Competenze (7.2). Requisiti di competenza per i ruoli chiave e le prove che sono soddisfatti: curriculum, attestati, formazione svolta.
• Consapevolezza (7.3). Piano di formazione e registro delle presenze. Una verifica semplice: chiunque in perimetro sa dov'è la politica e come segnala un incidente.
• Comunicazione (7.4). Chi comunica cosa, a chi e quando, verso l'interno e verso clienti, fornitori e autorità.
• Informazioni documentate (7.5). Elenco dei documenti con versione, approvazione, luogo di conservazione e chi può modificarli.

Fase 5: i controlli dell'Appendice A e le evidenze attese

L'Appendice A della norma riporta i controlli di riferimento nel prospetto A.1. Non si applicano tutti per forza: si scelgono col trattamento del rischio. I raggruppamenti qui sotto seguono la tabella di corrispondenza pubblicata da ENISA con la sua guida tecnica NIS2 (versione 1.2), che collega i requisiti del Regolamento di esecuzione (UE) 2024/2690 ai controlli della ISO/IEC 27001:2022. ENISA avverte che la tabella non va letta come una misura di equivalenza tra standard: qui serve solo a ritrovare i numeri dei controlli per tema.

Asset, accessi e fornitori

• Inventario e classificazione (A.5.9, A.5.12). Inventario di informazioni e asset con un proprietario per ciascuno, schema di classificazione applicato.
• Controllo degli accessi (A.5.15, A.5.18, A.8.2, A.8.5). Regole di accesso scritte, revisioni periodiche dei diritti con esito registrato, elenco delle utenze privilegiate, autenticazione a più fattori dove il rischio la richiede.
• Fornitori e cloud (A.5.19, A.5.20, A.5.21, A.5.22, A.5.23). Elenco dei fornitori con la valutazione di ciascuno, clausole di sicurezza nei contratti, monitoraggio periodico, regole per i servizi cloud. La Circolare Accredia chiede all'organismo di verificare, dove applicabile, come l'azienda gestisce la sicurezza delle infrastrutture che elaborano i dati, in casa, in cloud, in housing o in hosting. Certificati accreditati in ambito EA/MLA che coprono quei servizi valgono come presunzione di conformità; senza, l'organismo deve sottoporre a audit il sito. Raccogli i certificati dei fornitori prima dell'audit.

Vulnerabilità, log e incidenti

• Vulnerabilità tecniche (A.8.8). Processo di gestione delle vulnerabilità con tempi di rientro. La stessa Circolare, richiamando i requisiti 6.1.2, 8.2 e A.8.8, chiede all'organismo di accertare se l'azienda si sottopone periodicamente a vulnerability assessment o penetration test in funzione del rischio, con quale frequenza, e se conserva registrazioni sulla qualifica di chi li esegue e sulle azioni adottate. Evidenze: rapporti dei test, qualifica del personale o del laboratorio, piano di rientro chiuso o in corso.
• Log e monitoraggio (A.8.15, A.8.16, A.8.17). Log attivi sui sistemi in perimetro, tempi di conservazione decisi, orologi sincronizzati, qualcuno che li guarda con una regola scritta.
• Gestione degli incidenti (A.5.24, A.5.25, A.5.26, A.5.27, A.6.8). Procedura, canale di segnalazione per il personale, criteri di classificazione, registro degli incidenti con le lezioni apprese.

Continuità, persone e crittografia

• Continuità e backup (A.5.29, A.5.30, A.8.13). Piano di continuità ICT, backup pianificati, test di ripristino eseguiti e registrati.
• Persone (A.6.1, A.6.3, A.6.5, A.5.11). Verifiche in fase di assunzione proporzionate al ruolo, formazione periodica, procedura di uscita con revoca degli accessi e restituzione dei beni.
• Crittografia (A.8.24). Regole d'uso della cifratura e gestione delle chiavi.
• Sviluppo, se in perimetro (A.8.25). Regole di sviluppo sicuro applicate e verificabili nel ciclo di rilascio.

Fase 6: far girare il sistema e verificarlo (punti 8, 9 e 10)

• Attività operative (8.1, 8.2, 8.3). Prove che i processi girano: ticket, change, revisioni degli accessi. Valutazione e trattamento del rischio si ripetono nel tempo, quindi il registro deve avere una data recente e non solo quella di avvio del progetto.
• Monitoraggio e misurazione (9.1). Indicatori raccolti, analizzati e portati alla direzione.
• Audit interno (9.2). Programma degli audit, rapporto, rilievi con responsabile. Nella prassi si arriva al primo audit esterno con almeno un ciclo di audit interno che copre tutto il perimetro. Come si organizza è nell'articolo sull'audit interno ISO 27001.
• Riesame di direzione (9.3). Verbale con gli elementi in ingresso (esiti degli audit, incidenti, indicatori, rischi) e le decisioni prese.
• Miglioramento (10.1, 10.2). Registro delle non conformità con causa, azione correttiva, responsabile e verifica di efficacia.

Fase 7: prima di chiamare l'organismo di certificazione

• Organismo accreditato. Controlla che l'organismo sia accreditato per la ISO/IEC 27001 nelle banche dati Accredia.
• Dati per l'offerta corretti. Per la Circolare Accredia il numero di addetti da considerare nel calcolo delle giornate di audit tiene conto anche dei servizi inseriti nel perimetro, perché l'efficacia del sistema riguarda chiunque gestisca informazioni, non solo l'IT. Uno scope descritto in modo riduttivo produce un'offerta che poi va rifatta.
• Altre certificazioni non bastano da sole. La stessa Circolare precisa che riduzioni dei tempi di audit vanno giustificate con evidenze documentate, e che avere già altri sistemi di gestione certificati, per esempio la ISO 9001, non rende da solo il sistema maturo senza evidenze di audit interni efficaci e di un esito positivo dell'ultimo audit di terza parte.
• Scopo pronto. Una descrizione dello scopo coerente con i processi in perimetro e con la revisione della SoA. Nell'esempio della Circolare la formula si chiude con secondo lo Statement of Applicability Rev.0 del gg/mm/aaaa.
• Le due fasi dell'audit iniziale. La certificazione iniziale si svolge in due fasi, secondo la ISO/IEC 17021-1: lo Stage 1 verifica la documentazione e la prontezza del sistema, lo Stage 2 l'attuazione reale dei controlli. Quello che l'auditor non trova nello Stage 1 diventa un rilievo prima ancora dello Stage 2.

Gli errori che fanno slittare l'audit

• SoA scritta prima del registro dei rischi. Le esclusioni non hanno una motivazione che regga, e l'auditor lo vede confrontando le date.
• Scope che non coincide con i processi reali. Sedi, servizi cloud o persone dimenticati emergono nello Stage 2 e allargano il lavoro.
• Documenti senza registrazioni. Una procedura approvata che non lascia log, verbali o ticket non dimostra che il controllo funziona.
• Audit interno fatto da chi ha scritto il sistema. Chi verifica il proprio lavoro perde l'indipendenza, che la ISO 19011:2026 indica tra i principi dell'audit.
• Test di sicurezza assenti o vecchi. Senza vulnerability assessment o penetration test proporzionati al rischio, e senza traccia delle azioni prese, la voce A.8.8 resta scoperta.
• Riesame di direzione come formalità. Un verbale senza decisioni non mostra il coinvolgimento della direzione.

Da dove partire

Se le voci aperte sono poche, la checklist diventa il piano di lavoro fino all'audit interno. Se sono molte, conviene partire da perimetro e registro dei rischi: tutto il resto, SoA compresa, dipende da quelle due voci. Nella pagina dedicata alla certificazione ISO 27001 trovi come affianchiamo le aziende mid-market dalla gap analysis alla preparazione dell'audit.