Primo audit di certificazione ISO 27001: 10 cose da preparare e 10 da non improvvisare

Il primo audit di certificazione ISO/IEC 27001:2022 non si vince nella settimana precedente. Si vince nei mesi in cui il sistema di gestione ha funzionato davvero, ha prodotto tracce e ha lasciato dietro di sé una scia di evidenze che nessuno ha dovuto costruire ad arte. Chi conduce lo Stage 2 non cerca la perfezione: cerca coerenza tra ciò che l’organizzazione dichiara e ciò che fa ogni giorno.

In audit si capisce in fretta se un ISMS respira o se è stato rianimato per l’occasione. Il segnale non è la qualità della grafica delle procedure, ma la naturalezza con cui le persone raccontano il proprio lavoro. Un responsabile IT che sa dove guardare per verificare l’esito di un backup vale più di venti pagine di policy. E, viceversa, un manuale impeccabile che nessuno in azienda ha mai aperto è il primo indizio di un sistema costruito per l’ente di certificazione e non per l’organizzazione.

Ecco una lista pratica: dieci cose da preparare con calma e dieci che, se le improvvisate, l’auditor le vede al primo colpo.

Le 10 cose da fare

1. Raccogliete evidenze reali e tracciabili dal periodo di esercizio dell’ISMS, non snapshot del giorno prima. Servono date coerenti, autori identificabili, versioni progressive: verbali, ticket, registri con una storia credibile alle spalle.
2. Rendete lo Statement of Applicability coerente con la realtà. Ogni controllo Annex A applicabile deve avere uno stato di implementazione e un riferimento a dove vive nella pratica, non solo una crocetta su “Sì”.
3. Portate un risk assessment con metodologia dichiarata (allineatevi a ISO 27005 per criteri, scale e accettazione) e un piano di trattamento con owner, scadenze e stato di avanzamento aggiornato.
4. Fate un audit interno vero, con un auditor competente e indipendente dall’area verificata. Il rapporto deve avere rilievi, non solo complimenti: un audit interno senza nessuna osservazione insospettisce sempre.
5. Conducete il riesame della direzione con gli input della clausola 9.3: risultati audit, stato dei rischi, incidenti, obiettivi, risorse. Verbalizzate decisioni con responsabili e tempi, non buone intenzioni.
6. Preparate le persone chiave a raccontare il loro ruolo nell’ISMS. Il referente sicurezza, l’IT, l’HR e un paio di operativi devono saper spiegare cosa fanno quando qualcosa va storto.
7. Tenete pronto il registro degli incidenti, anche se piccoli. Un ISMS che in un anno non ha mai registrato nulla non è virtuoso, è cieco: mostrate rilevazione, gestione e lezioni apprese.
8. Dimostrate che monitorate gli esiti, non solo che avete gli strumenti. Backup con verifica del ripristino documentata, log con evidenza che qualcuno li legge, alert con destinatario e reazione.
9. Allineate documenti, obiettivi e KPI misurabili. Se la policy dice “riduciamo le vulnerabilità critiche entro 30 giorni”, tirate fuori il dato che lo conferma o la non conformità che lo gestisce.
10. Verificate la gestione dei fornitori e degli accessi: contratti con clausole di sicurezza, elenco utenze con revisione periodica, deprovisioning dei collaboratori usciti. Sono i primi punti dove l’auditor affonda, perché un account attivo di chi ha lasciato l’azienda sei mesi fa vale più di mille parole sulla vostra maturità reale. Preparate anche coerenza tra lo scope dichiarato e le sedi o i servizi che vi rientrano: i controlli devono vivere ovunque il perimetro arrivi, non solo dove è comodo mostrarli.

I 10 errori da evitare

1. Creare procedure la settimana prima e retrodatarle. I metadati dei file, la cronologia delle revisioni e le firme raccontano tutto: una policy “approvata” sei mesi fa ma con proprietà del file di tre giorni fa è una non conformità e un problema di fiducia.
2. Personale che non sa cosa sia l’ISMS. Se alla domanda “cos’è il sistema di gestione della sicurezza” rispondono “l’antivirus”, il problema non è la risposta ma l’assenza di consapevolezza (GDPR art. 32 e formazione a monte).
3. Non aprire mai una non conformità interna. Un ISMS senza NC e senza azioni correttive non è maturo, è finto: il ciclo di miglioramento della clausola 10 deve avere lasciato tracce concrete.
4. Backup e log di cui nessuno controlla l’esito. Avere il job schedulato non basta: se non c’è evidenza che qualcuno verifica successi, fallimenti e ripristini, il controllo esiste solo sulla carta.
5. SoA con controlli marcati “applicabile e implementato” che poi in campo non trovano riscontro. La distanza tra il documento e la stanza server è la prima cosa che si misura.
6. Esclusioni di controlli Annex A senza giustificazione, o giustificate con una frase copiata. “Non applicabile” richiede una motivazione legata al contesto reale dell’organizzazione.
7. Riesame della direzione ridotto a una mail. Senza gli input previsti, senza partecipanti tracciati e senza decisioni, la clausola 9.3 resta scoperta e si porta dietro un rilievo sicuro.
8. Confondere quantità e sostanza documentale. Trecento pagine che nessuno usa valgono meno di dieci procedure vive: l’eccesso di carta spesso nasconde processi mai avvenuti.
9. Presentare un audit interno fatto dal consulente esterno che ha anche scritto il sistema. L’indipendenza salta e il valore dell’evidenza pure.
10. Improvvisare le risposte davanti all’auditor. Meglio un onesto “questo lo verifichiamo così, e qui c’è un punto da migliorare” che una sicurezza teatrale smentita dal primo documento aperto. Un rilievo onesto si chiude con un’azione correttiva; una bugia scoperta contamina la credibilità di tutto il resto del sistema e allunga l’audit a dismisura.

Se arrivate allo Stage 2 con un sistema che ha già lavorato per voi, l’audit diventa una conversazione tra professionisti, non un esame. Se volete una lettura a freddo del vostro livello di preparazione, un occhio esterno prima della verifica di certificazione fa spesso la differenza tra un rilievo minore e una sorpresa.