ISO/IEC 27001:2022: i controlli dell'Annex A che le PMI italiane sbagliano

La ISO/IEC 27001:2022 ha mandato in pensione la versione 2013, e il periodo di transizione si è chiuso a fine ottobre 2025. Chi è certificato oggi lo è sulla 2022. Eppure, molti sistemi di gestione ragionano ancora con la testa del vecchio standard: i controlli nuovi ci sono sulla carta, ma non hanno radici operative. È lì che le verifiche si complicano.

Cosa è cambiato nella revisione 2022

La differenza più visibile è strutturale. L'Annex A non ha più 114 controlli su 14 domini, ma 93 controlli su quattro temi:

• A.5 - Controlli organizzativi: 37 controlli
• A.6 - Controlli relativi alle persone: 8 controlli
• A.7 - Controlli fisici: 14 controlli
• A.8 - Controlli tecnologici: 34 controlli

Molti controlli sono stati accorpati, nessuno è stato eliminato nella sostanza. La novità che conta davvero sono gli undici controlli nuovi, che fotografano come sono cambiate le minacce dal 2013:

Controllo	Tema
5.7 Threat intelligence	Organizzativo
5.23 Sicurezza per l'uso di servizi cloud	Organizzativo
5.30 Prontezza ICT per la continuità operativa	Organizzativo
7.4 Monitoraggio della sicurezza fisica	Fisico
8.9 Gestione della configurazione	Tecnologico
8.10 Cancellazione delle informazioni	Tecnologico
8.11 Mascheramento dei dati	Tecnologico
8.12 Prevenzione della fuga di dati	Tecnologico
8.16 Attività di monitoraggio	Tecnologico
8.23 Filtraggio web	Tecnologico
8.28 Sviluppo sicuro del codice	Tecnologico

Ogni controllo, nella 2022, porta anche cinque attributi (tipo di controllo, proprietà di sicurezza, concetti di cybersecurity, capacità operative, domini). Sono uno strumento di organizzazione, non un obbligo: utili per filtrare e rendicontare, ma non è lì che un auditor cerca i problemi.

I controlli gestiti peggio

Nella preparazione alla verifica, l'errore quasi mai è "il controllo non c'è". L'errore è che il controllo esiste come documento ma non come pratica. Ecco i cinque casi che emergono più spesso.

5.7 - Threat intelligence

La richiesta: raccogliere e analizzare informazioni sulle minacce per produrre threat intelligence utile. L'errore tipico: un documento che dichiara "monitoriamo le minacce" e nient'altro. Non esiste una fonte, non esiste una cadenza, non esiste traccia di una sola analisi.

Cosa si aspetta un auditor: fonti identificate (bollettini CERT, avvisi dei fornitori, feed di settore), una frequenza definita, e la prova che l'intelligence raccolta abbia prodotto qualcosa. Anche solo un registro con tre voci ("vulnerabilità X segnalata, sistemi verificati, patch applicata il giorno Y") vale più di una pagina di buone intenzioni.

8.9 - Gestione della configurazione

La richiesta: definire, documentare, applicare, monitorare e riesaminare le configurazioni, inclusi gli aspetti di sicurezza. L'errore tipico: nessuna configurazione di riferimento. Ogni server è stato configurato a mano, in momenti diversi, da persone diverse. Nessuno sa dire quale sia lo stato corretto, quindi nessuno può accorgersi di una deriva.

Cosa serve: una baseline scritta per le tipologie di sistema, un modo per verificare che la realtà vi corrisponda e un registro delle eccezioni approvate. Non serve uno strumento costoso. Serve poter dimostrare che esiste uno stato atteso e che lo si controlla.

8.11 - Mascheramento dei dati e 8.10 - Cancellazione delle informazioni

Sono due controlli nuovi, e quasi sempre i due più scoperti.

Il mascheramento (8.11) chiede di limitare l'esposizione dei dati sensibili oltre lo stretto necessario. Caso tipico: il database di produzione, con dati personali reali, copiato pari pari negli ambienti di test e sviluppo. Un auditor lo nota subito. La risposta corretta è anonimizzare o pseudonimizzare i dati prima che lascino la produzione.

La cancellazione (8.10) chiede che le informazioni non più necessarie siano effettivamente eliminate. Caso tipico: backup conservati senza limite, vecchi account mai chiusi, dischi dismessi senza una procedura. Qui il controllo si lega ai tempi di conservazione: senza una regola che dica per quanto si tiene un dato, non si può dimostrare di averlo cancellato quando andava cancellato.

8.28 - Sviluppo sicuro del codice

La richiesta: applicare principi di sviluppo sicuro al software. L'errore tipico, nelle PMI che sviluppano in proprio: lo sviluppo è "sicuro" perché lo dicono gli sviluppatori. Nessuna regola scritta, nessuna revisione del codice tracciata, nessun controllo automatico nella pipeline.

Cosa rende solido questo controllo: una linea guida di codifica, la revisione del codice come passaggio obbligato prima del rilascio, e controlli di sicurezza integrati nella pipeline. È anche il punto di contatto naturale con la sicurezza dell'AI: se in azienda si sviluppano agenti o integrazioni con modelli, valgono gli stessi principi descritti nell'articolo sulla sicurezza dell'AI in azienda.

Come si presenta un audit su questi punti

La verifica di un controllo segue sempre lo stesso schema. Prima si guarda cosa dice la politica. Poi si chiede l'evidenza che quella politica venga davvero applicata. Infine si verifica che l'evidenza sia coerente nel tempo.

È il terzo passaggio a far emergere i problemi. Una procedura datata il giorno prima dell'audit, un registro con un'unica voce creata per l'occasione, log che iniziano la settimana scorsa: sono tutti segnali che il controllo è teorico. Un auditor esperto non cerca documenti perfetti. Cerca prove ripetibili e datate: un registro che cresce nel tempo, ticket che si chiudono, riesami con cadenza riconoscibile.

La distinzione pratica che conviene avere in mente:

• Una non conformità maggiore è un controllo assente, oppure un fallimento sistemico che mette a rischio il sistema di gestione.
• Una non conformità minore è uno scostamento isolato: il controllo funziona, ma in un caso non è stato seguito.
• Un'osservazione è un rilievo che oggi non è una non conformità, ma lo diventerà se trascurato.

Quasi tutti i rilievi sui controlli nuovi nascono dalla stessa radice: il controllo è stato adottato come testo, non come abitudine operativa. La cura è iniziare a usarlo mesi prima della verifica, così che le evidenze si accumulino da sole.

Checklist di preparazione all'audit

Da affrontare con qualche mese di anticipo, non nelle ultime settimane:

• Statement of Applicability aggiornato ai 93 controlli della 2022, con una giustificazione reale per ogni esclusione.
• Threat intelligence (5.7): fonti definite, una cadenza, un registro con voci concrete.
• Gestione della configurazione (8.9): baseline scritte per le tipologie di sistema e un modo per verificarle.
• Mascheramento (8.11): nessun dato personale reale negli ambienti di test e sviluppo.
• Cancellazione (8.10): tempi di conservazione definiti e prova che la cancellazione avvenga.
• Sviluppo sicuro (8.28): linea guida di codifica, revisione del codice tracciata, controlli in pipeline (se si sviluppa software).
• Monitoraggio (8.16): log centralizzati, regole di allerta, prova che gli alert vengano gestiti.
• Continuità ICT (5.30): test di ripristino documentati, non solo previsti.
• Coerenza temporale: ogni registro deve avere una storia. Se inizia il mese dell'audit, il controllo è giovane e l'auditor lo noterà.

Fonti principali

• ISO - ISO/IEC 27001:2022
• IAF MD 26:2022 - Transition requirements for ISO/IEC 27001:2022

ISO/IEC 27001 non premia la documentazione più voluminosa. Premia il sistema di gestione che funziona anche quando nessuno lo sta guardando, e che lo dimostra. Se la tua azienda è anche soggetta a NIS2, buona parte di questo lavoro è condiviso: le misure tecniche e organizzative della direttiva si appoggiano sugli stessi controlli, come spiego nella checklist di adeguamento NIS2. Un controllo costruito bene risponde a entrambi.