Sicurezza delle Informazioni (ISO 27001)7 Ott 2026 · 10 min
Guida ai controlli ISO/IEC 27001:2022: struttura dell’Annex A, categorie, applicabilità e rapporto con ISO 27017, 27018 e 27701 per cloud e privacy.
SEO Specialist
I controlli ISO/IEC 27001:2022 contenuti nell’Annex A sono 93 e costituiscono il set di riferimento utilizzato dall’organizzazione per verificare che il trattamento dei rischi per la sicurezza delle informazioni non abbia trascurato misure pertinenti. Sono organizzati in quattro gruppi – organizzativi, relativi alle persone, fisici e tecnologici – e non devono essere interpretati come 93 requisiti da applicare indistintamente a qualsiasi impresa.
La loro selezione dipende infatti dal contesto dell’organizzazione, dai rischi identificati, dagli obblighi applicabili e dalle decisioni di trattamento. Per questo due aziende certificate secondo la stessa ISO/IEC 27001 possono avere Dichiarazioni di Applicabilità differenti: alcuni controlli saranno necessari in entrambe, altri dipenderanno da infrastruttura, attività, fornitori, utilizzo del cloud, trattamento di dati personali e caratteristiche del perimetro.
Quando queste esigenze diventano più specifiche, al nucleo della ISO/IEC 27001 si affiancano altri riferimenti della famiglia 27000 dedicati all’implementazione dei controlli, alla sicurezza dei servizi cloud e alla privacy. Comprendere questa relazione è essenziale anche per leggere correttamente la Dichiarazione di Applicabilità, perché la SoA può comprendere controlli ulteriori rispetto a quelli dell’Annex A quando il trattamento dei rischi lo richiede.
Il passaggio dall’edizione 2013 alla versione 2022 ha modificato sensibilmente la struttura dell’Annex A. I precedenti 114 controlli distribuiti in 14 domini sono stati razionalizzati in 93 controlli organizzati secondo quattro grandi categorie, eliminando sovrapposizioni, accorpando misure affini e introducendo temi che riflettono meglio l’attuale panorama tecnologico.
La struttura vigente è questa:
| Categoria | Controlli |
|---|---|
| Organizzativi | 37 |
| Persone | 8 |
| Fisici | 14 |
| Tecnologici | 34 |
| Totale | 93 |
La riduzione numerica non significa che la norma sia diventata meno articolata. Diversi controlli della precedente edizione sono stati consolidati, mentre sono comparsi riferimenti più espliciti a temi come threat intelligence, sicurezza dei servizi cloud, gestione delle configurazioni, cancellazione delle informazioni, data masking, prevenzione della perdita di dati, monitoraggio delle attività e secure coding.
La stessa architettura è sviluppata in modo più operativo nella ISO/IEC 27002:2022, che descrive i controlli e fornisce indicazioni per la loro implementazione. ISO/IEC 27001 e ISO/IEC 27002 svolgono quindi funzioni differenti ma strettamente collegate: la prima definisce i requisiti del sistema di gestione e utilizza Annex A come set di riferimento; la seconda approfondisce come quei controlli possono essere interpretati e applicati.
Per il quadro completo della norma, dei requisiti dell’ISMS e del percorso verso la certificazione rimane utile l’approfondimento dedicato a ISO/IEC 27001 e sicurezza delle informazioni.
La suddivisione in quattro categorie serve a rendere più leggibile un sistema che coinvolge componenti molto diverse dell’organizzazione.
I 37 controlli organizzativi riguardano aspetti come politiche, ruoli, responsabilità, gestione degli asset, relazioni con i fornitori, incidenti, continuità, requisiti legali e procedure. È l’area nella quale la sicurezza delle informazioni si collega maggiormente alla governance aziendale, perché molti rischi non possono essere affrontati attraverso una configurazione tecnica e richiedono invece responsabilità e processi formalizzati.
Gli 8 controlli relativi alle persone considerano il rapporto tra sicurezza e ciclo di vita del personale: selezione, condizioni di impiego, formazione, consapevolezza, lavoro remoto, responsabilità dopo cambi di ruolo o cessazione del rapporto.
I 14 controlli fisici affrontano la protezione di sedi, aree riservate, apparecchiature, supporti e ambienti nei quali le informazioni possono essere esposte a accessi non autorizzati, danneggiamenti o altre minacce materiali.
I 34 controlli tecnologici riguardano invece sistemi, reti, autenticazione, privilegi, protezione dal malware, vulnerabilità, configurazioni, logging, crittografia, sviluppo e numerosi altri aspetti direttamente legati all’infrastruttura informatica.
Questa classificazione aiuta a orientarsi, ma non determina automaticamente l’applicabilità. Il controllo appartiene a una categoria perché affronta un certo tipo di rischio; diventa necessario per l’organizzazione soltanto quando il processo di trattamento ne giustifica l’impiego.
È questo il motivo per cui la domanda “quanti controlli ISO 27001 devo applicare?” non ha una risposta numerica valida per tutti. I 93 devono essere considerati nel confronto previsto dalla norma, mentre il set effettivamente necessario dipende dal sistema che si sta progettando.
In molte organizzazioni il perimetro della sicurezza delle informazioni non termina con l’Annex A. L’utilizzo di infrastrutture cloud, il trattamento di informazioni personali o la necessità di costruire un sistema strutturato di privacy richiedono livelli di dettaglio ulteriori, per i quali la famiglia ISO/IEC 27000 mette a disposizione riferimenti specifici.
La famiglia ISO/IEC 27000 comprende, accanto alla ISO/IEC 27001, standard con funzioni complementari.
ISO/IEC 27002:2022 sviluppa le indicazioni operative sui controlli di sicurezza delle informazioni e costituisce la base tecnica sulla quale si innestano diversi riferimenti specialistici.
ISO/IEC 27017:2026 approfondisce l’applicazione dei controlli ai servizi cloud, considerando sia il punto di vista del cliente sia quello del provider e dando particolare rilievo alla corretta distribuzione delle responsabilità.
ISO/IEC 27018:2025 riguarda la protezione delle Personally Identifiable Information nei servizi cloud pubblici quando il provider opera come processor, adattando il sistema dei controlli alle esigenze specifiche di questo scenario.
ISO/IEC 27701:2025 disciplina invece il Privacy Information Management System, estendendo la gestione verso un sistema strutturato per le informazioni personali e per le responsabilità di controller e processor.
Il rapporto tra questi standard non va letto come una semplice somma di checklist. Molte misure condividono lo stesso presidio di base e vengono estese, contestualizzate o specializzate in funzione del cloud o della privacy; ciò rende fondamentale una buona mappatura, perché lo stesso controllo operativo non dovrebbe essere gestito come cinque attività indipendenti soltanto perché compare in riferimenti diversi.
Consideriamo un’azienda che utilizzi servizi cloud per ospitare applicazioni e informazioni aziendali critiche. Durante il risk assessment emerge che una parte significativa dei dati viene trattata attraverso fornitori cloud e che una configurazione non corretta, una ripartizione poco chiara delle responsabilità o una gestione inadeguata degli accessi potrebbe compromettere riservatezza, integrità o disponibilità delle informazioni.
Nella SoA il relativo controllo non dovrebbe limitarsi a uno stato del tipo:
Applicabile: sì.
Una motivazione realmente utilizzabile potrebbe invece indicare che:
il controllo è necessario perché servizi e informazioni comprese nell’ambito ISMS sono ospitati presso provider cloud esterni e richiedono responsabilità, requisiti di sicurezza, configurazioni e modalità di controllo formalizzate.
A quel punto lo stato di implementazione dovrebbe essere sostenuto da evidenze coerenti: contratti e accordi con il provider, matrice delle responsabilità, procedure interne, configurazioni, verifiche periodiche o altra documentazione pertinente.
La relazione diventa quindi: rischio individuato → controllo necessario → motivazione → stato → evidenza, ed è proprio questa catena a rendere una SoA leggibile anche durante l’audit.
La stessa precisione è necessaria quando un controllo viene ritenuto non necessario. Immaginiamo un’organizzazione che non sviluppi software, non possieda repository di codice sorgente e utilizzi esclusivamente applicazioni commerciali o SaaS sulle quali non dispone di accesso al codice.
Una motivazione come:
“non applicabile”
non consente di comprendere realmente la decisione. Una formulazione più solida potrebbe precisare invece che:
l’organizzazione non sviluppa né mantiene codice sorgente all’interno del perimetro ISMS e non dispone di repository o accessi a sorgenti software; il controllo relativo all’accesso al codice sorgente non risulta quindi necessario nel contesto attuale.
La motivazione rende immediatamente verificabile la condizione che giustifica l’esclusione. Se in futuro l’organizzazione iniziasse a sviluppare un’applicazione proprietaria, quella premessa verrebbe meno e l’applicabilità dovrebbe essere riesaminata. È proprio per questo che una SoA non può essere considerata una tabella compilata una volta per tutte: cambia quando cambiano rischi, infrastrutture, attività o requisiti.
La gestione diventa più impegnativa quando l’organizzazione utilizza contemporaneamente riferimenti generali, cloud e privacy. Lo stesso presidio può essere pertinente a più quadri, mentre alcune misure acquistano requisiti aggiuntivi quando vengono applicate a un servizio cloud oppure a informazioni personali.
In un foglio di calcolo questa complessità tende a produrre tre problemi: duplicazioni, divergenze tra stati e perdita delle relazioni tra controlli.
Un controllo può risultare implementato nel foglio ISO 27001 e ancora “da valutare” in quello cloud; un’unica evidenza può essere copiata in più righe senza che sia chiaro quale sia la fonte principale; una modifica all’infrastruttura può richiedere aggiornamenti in diverse parti della matrice e lasciare inalterata una delle copie.
La difficoltà non consiste quindi soltanto nel numero delle righe. Consiste nel mantenere coerenti applicabilità, motivazioni, implementazione, mappature ed evidenze quando i riferimenti si sovrappongono.
È qui che assume valore una libreria integrata, purché sia sempre chiara la distinzione tra il set previsto dalla ISO/IEC 27001 e i controlli aggiuntivi utilizzati per estendere il perimetro.
Il Percorso E — Statement of Applicability di EvalisDeck affronta questa complessità attraverso una libreria di 174 controlli mappati su cinque quadri, collegando il nucleo ISO/IEC 27001 ai riferimenti utilizzati per approfondire implementazione, cloud e privacy.
I 174 controlli appartengono quindi alla struttura operativa del Percorso E e non rappresentano il numero di controlli contenuti nell’Annex A della ISO/IEC 27001:2022, che rimane pari a 93.
La differenza è sostanziale: il set ISO fornisce il reference set richiesto dalla norma, mentre la libreria EvalisDeck permette di gestire in uno stesso percorso anche controlli e mappature che diventano pertinenti quando il sistema deve considerare ambiti ulteriori.
Il lavoro viene organizzato attraverso:
Le verifiche automatiche assumono particolare importanza proprio quando aumenta il numero dei controlli. Un controllo dichiarato applicabile ma privo di stato non scompare dal calcolo, mentre un’esclusione deve essere accompagnata dalla relativa motivazione; il sistema può inoltre intercettare contraddizioni prima che la Dichiarazione venga pubblicata.
Questa impostazione mantiene distinto anche ciò che viene spesso confuso: un controllo non applicabile e un controllo necessario ma non ancora implementato sono condizioni differenti. Il secondo deve rimanere visibile nel piano di attuazione, invece di essere trasformato in un’esclusione che migliorerebbe artificialmente lo stato complessivo.
Quando la valutazione viene completata, il Percorso E genera lo Statement come versione congelata, preservando applicabilità, motivazioni e stato dei controlli riferiti a quel momento. Una successiva revisione può quindi aggiornare il sistema senza riscrivere retroattivamente la SoA già consegnata o sottoposta ad audit. Chi vuole verificare direttamente come viene gestita una matrice di questa ampiezza può utilizzare la demo guidata di EvalisDeck e aprire il Percorso E dell’azienda dimostrativa.
L’Annex A della ISO/IEC 27001:2022 contiene 93 controlli di riferimento, suddivisi in 37 organizzativi, 8 relativi alle persone, 14 fisici e 34 tecnologici.
No. L’organizzazione determina i controlli necessari attraverso il trattamento dei rischi e li confronta con l’Annex A. Un controllo dell’Annex A ritenuto non necessario può essere escluso, purché la decisione sia adeguatamente motivata nella Dichiarazione di Applicabilità.
ISO/IEC 27001 stabilisce i requisiti del sistema di gestione della sicurezza delle informazioni, mentre ISO/IEC 27002 fornisce indicazioni più dettagliate sull’implementazione dei controlli. I due riferimenti sono quindi complementari, ma svolgono funzioni differenti.
ISO/IEC 27017 approfondisce la sicurezza dei servizi cloud, ISO/IEC 27018 la protezione delle informazioni personali nei cloud pubblici quando il provider opera come processor, mentre ISO/IEC 27701 riguarda il sistema di gestione della privacy.
Perché 174 è il numero della libreria integrata utilizzata dal Percorso E, che amplia il nucleo ISO/IEC 27001 attraverso controlli e mappature collegati agli ulteriori quadri utilizzati per implementazione, cloud e privacy. Non è quindi il numero dei controlli dell’Annex A.
Sicurezza delle Informazioni (ISO 27001)4 Ott 2026 · 9 min
Guida alla Dichiarazione di Applicabilità ISO 27001: contenuti richiesti dal punto 6.1.3 d), rapporto con Annex A, struttura della SoA ed errori che emergono più facilmente durante l’audit.
di Bruno Santini · SEO Specialist
Sicurezza delle Informazioni (ISO 27001)4 Set 2026 · 10 min
Guida introduttiva alla ISO/IEC 27001:2022: struttura del sistema di gestione, novità della versione corrente, ruolo della Dichiarazione di Applicabilità e percorso organizzativo verso la certificazione.
di Bruno Santini · SEO Specialist
Guide Generali & Audit-Readiness1 Ott 2026 · 12 min
Glossario della rendicontazione di sostenibilità con definizioni essenziali di GHG, Scope 1-2-3, ESRS, VSME, GRI, doppia materialità, ISO, audit e altri termini tecnici.
di Bruno Santini · SEO Specialist
