Annex A ISO 27001: guida e checklist SoA per professionisti

L’Annex A di ISO 27001 non è una lista da spuntare integralmente: è il catalogo di riferimento da cui selezionare i controlli di sicurezza in funzione dei rischi identificati. La prima azione concreta da fare è condurre o aggiornare il Risk Assessment e avviare la compilazione della Statement of Applicability (SoA). Senza questo collegamento documentato, qualsiasi implementazione rischia di non reggere all’audit.

La SoA è il documento obbligatorio che formalizza le scelte. Per ogni controllo dell’Annex A deve indicare:

• Applicabilità: il controllo è applicabile, non applicabile o parzialmente applicabile?
• Motivazione: perché è stato incluso o escluso (riferimento al rischio, requisito normativo, obbligo contrattuale)?
• Stato di implementazione: pianificato, in corso, implementato?
• Riferimenti alle evidenze: quali documenti, log o procedure dimostrano l’operatività del controllo?

Un consiglio: Iniziate la SoA come foglio di calcolo con una riga per ciascuno dei 93 controlli, anche quelli che escluderete. Questo formato facilita la revisione dell’auditor e dimostra che nessun controllo è stato ignorato per distrazione.

Indice

• Che cos’è l’Annex A e perché conta per il vostro ISMS
• Cosa è cambiato con ISO 27001:2026 nell’Annex A
• Quali sono le categorie e i controlli dell’Annex A?
• Come si compila la Statement of Applicability (SoA): guida passo dopo passo
• Come decidere l’applicabilità collegando rischio e controllo
• Esempi pratici di implementazione e le evidenze che gli auditor richiedono
• Cosa verificano gli auditor sull’Annex A: errori comuni e come evitarli
• Checklist rapida e righe SoA esempio (template copiabile)
• Punti chiave
• Perché il collegamento rischio–controllo–evidenza fa la differenza
• Securityhub affianca le organizzazioni nella certificazione ISO 27001
• Fonti utili e riferimenti normativi

Che cos’è l’Annex A e perché conta per il vostro ISMS

L’Annex A di ISO 27001 è l’appendice normativa che elenca i controlli di sicurezza delle informazioni utilizzabili come misure di trattamento del rischio. La clausola 6.1.3 della norma richiede esplicitamente che l’organizzazione confronti i propri controlli selezionati con quelli dell’Annex A per verificare di non aver tralasciato misure rilevanti. Non si tratta di un obbligo di implementazione totale: un controllo non necessario può essere escluso se la motivazione è documentata nella SoA.

ISO 27002 è la guida di attuazione complementare: fornisce per ciascun controllo dell’Annex A le linee guida operative, gli attributi e gli esempi di implementazione. ISO 27001 definisce i requisiti del sistema di gestione; ISO 27002 spiega come soddisfarli in pratica. Nelle PMI, ISO 27002 è spesso il documento di riferimento durante la fase di implementazione, prima ancora di coinvolgere un ente di certificazione.

La SoA funge da ponte tra tre documenti chiave del vostro ISMS:

• Il Risk Assessment, che identifica i rischi e le vulnerabilità rilevanti per il contesto aziendale.
• Il Risk Treatment Plan (RTP), che stabilisce quali rischi trattare, con quali misure e in quale sequenza temporale.
• L’implementazione operativa, ovvero le procedure, i controlli tecnici e le evidenze che dimostrano che le misure sono attive.

I controlli dell’Annex A sono organizzati in quattro macro-aree: organizzativi, persone, fisici e tecnologici. Questa struttura, introdotta con la revisione del 2022, sostituisce la precedente suddivisione in più domini della versione 2013.

Un consiglio: Quando avviate il Risk Assessment, mappate subito i rischi identificati alle quattro macro-aree dell’Annex A. Questo riduce il tempo di compilazione della SoA e rende immediatamente visibile quali aree richiedono più controlli.

Cosa è cambiato con ISO 27001:2026 nell’Annex A

La versione 2022 ha riorganizzato i controlli in modo sostanziale. L’Annex A aggiornato della versione 2022 contiene 93 controlli organizzati in quattro gruppi tematici. La riduzione numerica rispetto alla versione 2013 non significa meno requisiti: molti controlli precedenti sono stati consolidati, e 11 nuovi controlli sono stati aggiunti per coprire aree come threat intelligence, sicurezza del cloud e continuità operativa ICT.

Le modifiche più rilevanti per chi gestisce un ISMS sono:

• Riorganizzazione in quattro categorie (organizzativi, persone, fisici, tecnologici) al posto dei 14 domini precedenti.
• 11 nuovi controlli, tra cui gestione delle configurazioni, monitoraggio della sicurezza delle informazioni, filtraggio web e data masking.
• Introduzione degli attributi di controllo: ogni controllo è ora classificato per tipo (preventivo, detective, correttivo), proprietà di sicurezza (riservatezza, integrità, disponibilità), concetti di sicurezza, capacità operative e dominio di sicurezza.

Gli attributi di controllo sono uno strumento pratico spesso sottovalutato. Servono a mappare i controlli verso altri standard e normative come NIS2, facilitando la gestione integrata della compliance. Un’organizzazione che deve dimostrare conformità sia a ISO 27001 sia alla Direttiva NIS2 può usare gli attributi per identificare rapidamente quali controlli dell’Annex A coprono anche i requisiti NIS2, evitando duplicazioni documentali.

Attenzione all’errore più diffuso: trattare l’Annex A come una checklist statica è la causa principale delle non conformità rilevate in audit. Gli auditor verificano il nesso diretto tra rischio identificato, controllo selezionato ed evidenza operativa. Un controllo implementato senza un rischio corrispondente nel Risk Assessment è una bandiera rossa.

La transizione da ISO 27001:2013 a ISO 27001:2022 ha richiesto l’aggiornamento della SoA, del Risk Treatment Plan e della mappatura dei controlli. Le organizzazioni già certificate devono verificare che la propria SoA rifletta la struttura a 93 controlli e che gli attributi siano stati integrati nel documento.

Quali sono le categorie e i controlli dell’Annex A?

La tabella seguente fornisce un riferimento rapido per la compilazione della SoA. Durante il Risk Assessment, usatela per verificare che ogni area sia stata considerata prima di dichiarare un controllo non applicabile.

Le macro-aree comprendono controlli relativi a politiche di sicurezza, ruoli, gestione asset, relazioni con fornitori, gestione incidenti, business continuity, conformità, screening, formazione, controllo accessi fisici e sicurezza delle apparecchiature, gestione degli endpoint, crittografia, sicurezza reti, monitoraggio e sicurezza cloud.

Alcuni controlli sono quasi sempre applicabili, indipendentemente dal settore o dalla dimensione aziendale: le politiche di sicurezza delle informazioni (A.5), la gestione degli accessi (A.8–A.8.6) e la formazione sulla consapevolezza (A.6) rientrano tipicamente in questa categoria. Per le PMI dell’Europa centrale, i controlli fisici relativi a sedi secondarie o data center esterni (A.7.5–A.7.8) sono spesso esclusi con motivazione documentata, quando l’infrastruttura è interamente in cloud.

Includere tutte le 93 righe nella SoA, anche per i controlli esclusi, facilita la tracciabilità e la revisione dell’auditor. Un documento con righe mancanti genera domande durante l’audit che rallentano il processo di certificazione.

Come si compila la Statement of Applicability (SoA): guida passo dopo passo

La SoA è il documento obbligatorio che formalizza la scelta dei controlli e deve collegare ogni misura al Risk Treatment Plan. Seguire una sequenza precisa riduce il rischio di lacune documentali.

Passaggi operativi

1. Definire l’ambito ISMS. Documentare quali sistemi, processi, sedi e dati rientrano nel perimetro. L’ambito deve essere approvato dalla direzione e riportato nella SoA come intestazione o sezione introduttiva.

2. Raccogliere i risultati del Risk Assessment. Per ogni rischio identificato, verificare quale trattamento è stato scelto: riduzione, accettazione, trasferimento o eliminazione. Solo i rischi con trattamento «riduzione» generano controlli da selezionare nell’Annex A.

3. Mappare i controlli ai rischi e al RTP. Per ogni controllo applicabile, indicare il riferimento al rischio corrispondente nel Risk Assessment e la voce del Risk Treatment Plan che lo giustifica. Questo collegamento è ciò che gli auditor verificano per primo.

4. Compilare le colonne obbligatorie per ogni controllo. La struttura minima raccomandata per ogni riga è:

   • Numero e nome del controllo (es. A.8 Gestione dei diritti di accesso privilegiato)
   • Applicabilità: Sì / No / Parziale
   • Motivazione (riferimento al rischio o requisito normativo)
   • Stato di implementazione: Pianificato / In corso / Implementato
   • Riferimento all’evidenza (nome del documento, procedura o log)

5. Revisione formale e approvazione dalla direzione. La SoA deve riportare versione, data di approvazione e firma del responsabile. Ogni modifica successiva va tracciata con numero di versione e descrizione della modifica.

Un consiglio: Collegate ogni riga della SoA a un documento specifico già esistente nell’ISMS (es. «Procedura GP-ACC-01» per la gestione degli accessi). Se il documento non esiste ancora, inserite lo stato «Pianificato» e la data prevista di completamento. Questo dimostra all’auditor che il gap è noto e gestito.

La tabella seguente mostra il template minimo per una riga SoA:

Come decidere l’applicabilità collegando rischio e controllo

Il principio base è semplice: la selezione dei controlli deve derivare esclusivamente dal Risk Assessment e dal contesto di business, non da preferenze personali o da ciò che «sembra ragionevole». Interpretare l’Annex A come una checklist statica è un errore: un controllo implementato senza un rischio corrispondente documentato non ha valore probatorio in audit.

I criteri pratici per stabilire l’applicabilità sono:

• Esposizione al rischio: il rischio identificato nel Risk Assessment è rilevante per il perimetro ISMS? Se sì, il controllo è applicabile.
• Impatto potenziale: la mancata implementazione del controllo aumenta la probabilità o la gravità di un incidente? Questo giustifica l’inclusione anche in assenza di un rischio esplicito nel registro.
• Requisito contrattuale o normativo: un cliente, un contratto o una normativa (es. GDPR, NIS2) richiede esplicitamente il controllo? In questo caso è applicabile indipendentemente dal profilo di rischio interno.
• Analisi costi/benefici: il costo di implementazione è sproporzionato rispetto al rischio residuo? Questo può giustificare l’esclusione, ma solo se documentato con motivazione tecnica.

Per le esclusioni, la documentazione deve includere tre elementi: la motivazione tecnica (perché il rischio non è rilevante), il riferimento al rischio nel Risk Assessment (o la sua assenza), e le misure alternative adottate se esistono.

Un consiglio: Per le PMI con risorse limitate, iniziate dalla colonna «Applicabilità» e completate prima tutte le righe con «Sì» o «No». Le righe «Parziale» richiedono più attenzione e possono essere affrontate in una seconda sessione di lavoro.

Esempi pratici di implementazione e le evidenze che gli auditor richiedono

Le PMI dell’Europa centrale che affrontano la certificazione ISO 27001 si trovano spesso a dover dimostrare operatività con risorse documentali limitate. Gli auditor non si aspettano sistemi complessi: si aspettano coerenza tra quanto dichiarato nella SoA e quanto dimostrabile con evidenze concrete.

Per i controlli più frequenti, ecco cosa documentare:

• Gestione degli accessi (A.8–A.8.6): procedura di provisioning/deprovisioning, log di accesso ai sistemi critici, registro delle utenze privilegiate con revisione periodica. Un file Excel aggiornato trimestralmente con le utenze attive è considerato evidenza accettabile in molte PMI.
• Backup e ripristino (A.8): policy di backup documentata, log automatici dei backup, verbale dell’ultimo test di ripristino. Il test di ripristino è l’evidenza più frequentemente mancante nelle PMI.
• Gestione degli incidenti (A.5.24–A.5.28): procedura di incident response, registro degli incidenti con data, descrizione e azioni intraprese. Anche un solo incidente documentato correttamente dimostra che il processo è attivo. Questo controllo supporta anche gli obblighi di notifica previsti dal GDPR, rendendo la documentazione utile su due fronti.
• Formazione e consapevolezza (A.6): piano di formazione annuale, registro delle presenze o attestati di completamento per i corsi online, verbali di briefing sulla sicurezza. Per le PMI, anche una sessione interna documentata con firma dei partecipanti è sufficiente.
• Sicurezza dei fornitori (A.5.19–A.5.22): registro dei fornitori critici, clausole contrattuali sulla sicurezza delle informazioni, valutazione periodica dei fornitori. I contratti con i fornitori cloud devono includere riferimenti espliciti alla gestione dei dati.

Per le misure di sicurezza nelle PMI, la priorità va ai controlli con il maggiore impatto sul profilo di rischio specifico dell’organizzazione. Un’azienda che gestisce dati personali di clienti europei deve dare precedenza ai controlli di accesso e alla gestione degli incidenti, anche prima di completare i controlli fisici.

Un consiglio: Raccogliete le evidenze mentre implementate i controlli, non dopo. Un log, un verbale o una procedura creati retroattivamente sono difficili da difendere in audit e spesso mostrano date incongruenti.

Cosa verificano gli auditor sull’Annex A: errori comuni e come evitarli

Durante un audit di certificazione o sorveglianza ISO 27001, l’Annex A è uno dei punti di verifica più approfonditi. L’auditor non si limita a controllare che la SoA esista: verifica che ogni controllo applicabile abbia un’evidenza operativa e che ogni esclusione sia motivata con riferimento al rischio.

Gli errori più frequenti rilevati in audit sono:

• SoA senza collegamento al Risk Assessment: il documento esiste, ma non è possibile tracciare il percorso rischio→controllo→evidenza. Questa è la non conformità più comune.
• Esclusioni non motivate: controlli marcati «Non applicabile» senza alcuna spiegazione tecnica o riferimento al Risk Assessment.
• Evidenze mancanti o non aggiornate: procedure scritte ma mai applicate, log non conservati, test di ripristino mai eseguiti.
• SoA non approvata dalla direzione: un documento senza firma e data di approvazione non ha valore formale.
• Versione obsoleta: la SoA riflette il profilo di rischio di due anni fa, non quello attuale. La SoA deve essere un documento vivo, aggiornata quando cambia il profilo di rischio.

Per dimostrare operatività, le evidenze più efficaci sono: report automatici di sistema (log di accesso, backup), verbali di riunioni di revisione, registri di formazione con firme, risultati di test di ripristino con data e responsabile, e contratti con fornitori che includono clausole di sicurezza.

Per prepararsi all’audit, verificate questi punti con la checklist di preparazione audit:

• Ogni riga della SoA ha un riferimento al rischio o alla motivazione di esclusione?
• Le evidenze citate nella SoA esistono e sono aggiornate?
• La SoA è stata approvata dalla direzione con data e firma?
• Il numero di versione e la data dell’ultima revisione sono visibili?
• I controlli «Parziale» hanno un piano di completamento con scadenza?

Un consiglio: Eseguite una simulazione di audit interno almeno sei settimane prima della data di certificazione. Chiedete a un collega non coinvolto nella redazione della SoA di seguire il percorso rischio→controllo→evidenza per cinque controlli a campione. Le lacune emergono immediatamente.

Checklist rapida e righe SoA esempio (template copiabile)

Passi minimi per completare una riga SoA

1. Identificare il numero e il nome del controllo dall’Annex A (versione 2022).
2. Verificare se esiste un rischio corrispondente nel Risk Assessment.
3. Decidere l’applicabilità (Sì / No / Parziale) e documentare la motivazione.
4. Indicare lo stato di implementazione attuale.
5. Collegare l’evidenza esistente o pianificare la sua creazione con una scadenza.
6. Assegnare un responsabile per il mantenimento del controllo.

Righe SoA di esempio

Integrazione nel sistema documentale

• Assegnate alla SoA un codice documento univoco (es. ISMS-SOA-001) e gestite le versioni con numerazione progressiva (v1.0, v1.1, v2.0).
• Conservate la SoA nel repository documentale ISMS insieme al Risk Assessment e al Risk Treatment Plan, con accesso controllato.
• Ogni evidenza citata nella SoA deve avere un nome file o un codice documento coerente con il sistema di naming aziendale.

Punti chiave

L’Annex A di ISO 27001 richiede che ogni controllo selezionato sia giustificato da un rischio documentato e supportato da evidenze operative verificabili in audit.

Perché il collegamento rischio–controllo–evidenza fa la differenza

La distinzione tra un ISMS che regge l’audit e uno che genera non conformità sta quasi sempre nella qualità del collegamento tra rischio, controllo ed evidenza, non nella quantità di documenti prodotti. Ho visto organizzazioni con SoA di decine di pagine fallire l’audit perché nessuna riga era collegata a un rischio reale, e PMI con documentazione essenziale superare la certificazione al primo tentativo perché ogni controllo era tracciabile fino alla sua origine nel Risk Assessment.

L’errore più costoso non è escludere un controllo: è implementarlo male perché nessuno ha verificato se fosse necessario. Un controllo applicato senza motivazione assorbe risorse, genera burocrazia e non riduce alcun rischio reale. Una esclusione ben documentata, al contrario, dimostra maturità nella gestione del rischio.

La SoA come documento vivo non è una formalità: è lo strumento con cui la direzione dimostra di avere il controllo del proprio profilo di rischio. Ogni revisione periodica, ogni aggiornamento dopo un incidente, ogni nuova mappatura verso NIS2 o GDPR trasforma la SoA da adempimento a strumento di governance reale. Le organizzazioni che trattano la SoA in questo modo non solo superano gli audit: costruiscono una cultura della sicurezza che produce evidenze in modo naturale, senza sforzi straordinari prima di ogni sorveglianza.

Securityhub affianca le organizzazioni nella certificazione ISO 27001

Redigere una SoA auditabile richiede competenze specifiche: conoscenza della norma, esperienza con gli auditor e capacità di collegare il Risk Assessment ai controlli in modo documentalmente solido. Securityhub offre alle organizzazioni italiane un supporto strutturato che copre l’intero percorso: dall’analisi dei rischi alla predisposizione della SoA, dal Risk Treatment Plan alla raccolta delle evidenze, fino alla preparazione all’audit di certificazione.

Il vantaggio concreto rispetto a un approccio fai-da-te è la riduzione del rischio di non conformità al primo audit: Securityhub conosce le domande che gli auditor pongono e costruisce la documentazione per rispondervi. I deliverable tipici di un engagement includono una SoA completa e approvabile, un Risk Assessment aggiornato alla versione 2022, un Risk Treatment Plan con priorità operative e un set di evidenze pronte per la verifica.

Per avviare una valutazione del vostro ISMS o per pianificare il percorso di certificazione, consultate la pagina passaggi per la certificazione ISO 27001 o contattate direttamente il team Securityhub per un’analisi preliminare senza impegno.

Fonti utili e riferimenti normativi

Le risorse seguenti sono utili sia per approfondire i requisiti normativi sia per costruire una SoA più solida. Citare i riferimenti normativi primari nella SoA aumenta la credibilità del documento durante l’audit.

• ISO 27001:2022 — pagina ufficiale ISO: testo normativo di riferimento per i requisiti del sistema di gestione e l’Annex A.
• Guida alla transizione da ISO 27001:2013 a ISO 27001:2022 (e-cons): spiegazione pratica delle differenze tra le versioni, con indicazioni sui passi di transizione e sugli attributi di controllo.
• Tutti i 93 controlli dell’Annex A spiegati (Matproof): riferimento dettagliato per ogni controllo con note sull’applicabilità e l’integrazione con GDPR.
• Statement of Applicability: struttura e compilazione (Culture Digitali): guida operativa alla redazione della SoA con esempi di struttura documentale.
• Guida pratica alla compilazione della SoA (Culture Digitali): approfondimento sul formato della SoA e sulla gestione delle righe escluse.
• Esempio di SoA reale — Ecocred Consulting: documento SoA pubblico che mostra un formato completo con tutte le colonne obbligatorie; utile come riferimento visivo durante la redazione.
• Protezione dati aziendali per le PMI (Studio Legale Coviello): approfondimento legale su GDPR e protezione dati, utile per documentare la motivazione normativa dei controlli Annex A legati alla privacy.
• Controlli ISO 27001:2022 — riferimento completo (ISMS Directory): tabella di riferimento con tutti i 93 controlli, linee guida di implementazione e strumenti consigliati.

Questo articolo fornisce informazioni di carattere generale sulla normativa ISO 27001 e non costituisce consulenza professionale. Per la valutazione specifica del proprio ISMS e per la preparazione all’audit, si raccomanda di consultare un professionista qualificato o un ente di certificazione accreditato.

Raccomandati

• Step implementazione ISO 27001: guida pratica per aziende – Security Hub
• Checklist preparazione audit ISO 27017: guida pratica efficace – Security Hub
• Controlli Obbligatori ISO 27001: Guida Completa 2024 – Security Hub
• Checklist certificazione ISO 27017: guida pratica completa – Security Hub