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.
SEO Specialist
La Dichiarazione di Applicabilità, o Statement of Applicability (SoA), è il documento che raccoglie i controlli di sicurezza delle informazioni ritenuti necessari da un’organizzazione, ne spiega la scelta, ne indica lo stato di implementazione e motiva perché eventuali controlli dell’Annex A della ISO/IEC 27001 non siano necessari. In poche pagine può quindi rendere visibile il collegamento tra analisi dei rischi, trattamento, controlli e situazione effettiva del sistema di gestione.
È proprio questa funzione a renderla uno dei documenti più scrutinati durante un audit ISO/IEC 27001. Una SoA coerente permette di comprendere perché un controllo esiste e come viene gestito; una SoA costruita come semplice tabella compilata alla fine del progetto può invece far emergere rapidamente esclusioni immotivate, controlli dichiarati come implementati senza evidenze oppure differenze rispetto al piano di trattamento dei rischi.
Per inquadrare il documento all’interno dell’intero Information Security Management System (ISMS) è utile partire dalla guida su ISO/IEC 27001 e sicurezza delle informazioni, che ricostruisce struttura della norma, Annex A e percorso verso la certificazione.
La SoA nasce dal processo di trattamento dei rischi per la sicurezza delle informazioni. Dopo aver identificato e valutato i rischi, l’organizzazione deve stabilire quali controlli siano necessari per portarli al livello ritenuto accettabile; questi controlli vengono poi confrontati con il set di riferimento dell’Annex A, così da verificare che non siano state trascurate misure pertinenti.
La sequenza è quindi più articolata di una selezione tra 93 caselle:
rischio → trattamento → controlli necessari → confronto con Annex A → Dichiarazione di Applicabilità
Questo passaggio permette anche di comprendere perché non tutti i controlli dell’Annex A devono necessariamente risultare applicabili e, al tempo stesso, perché la SoA può contenere controlli che non provengono dall’Annex A. Un’organizzazione può infatti adottare misure specifiche definite internamente oppure provenienti da altri standard e framework quando sono necessarie al proprio trattamento del rischio.
La SoA diventa così una fotografia del sistema dei controlli effettivamente scelto dall’organizzazione, collegando il riferimento ISO al proprio contesto operativo. Un’impresa che sviluppa software, un’azienda manifatturiera e un provider cloud possono condividere alcuni controlli e differire profondamente su altri, perché asset, processi, minacce, requisiti contrattuali e dipendenze tecnologiche non coincidono.
Il punto 6.1.3 della ISO/IEC 27001:2022 disciplina il trattamento del rischio per la sicurezza delle informazioni. Le diverse lettere del requisito compongono un unico percorso: l’organizzazione seleziona le opzioni di trattamento, determina i controlli necessari, li confronta con l’Annex A e produce infine la SoA.
In particolare, il punto 6.1.3 d) richiede che la Dichiarazione di Applicabilità permetta di ricostruire quattro elementi fondamentali:
La nota dedicata alla SoA dell’ISO/IEC 27001 Auditing Practices Group, documento interpretativo destinato ad auditor e organizzazioni e non sostitutivo del testo normativo, chiarisce anche due aspetti particolarmente utili: la struttura della SoA non è prescritta dalla norma e i controlli necessari che non appartengono all’Annex A devono comunque essere rappresentati nel documento.
Questo evita una lettura troppo meccanica dell’applicabilità. La domanda non è semplicemente “A.5.1 sì o no?”, ma quale rischio o requisito rende necessario quel controllo, come viene trattato e quale evidenza dimostra che la situazione dichiarata corrisponde alla realtà.
La SoA concentra nello stesso documento decisioni che, nel resto dell’ISMS, possono essere distribuite tra risk assessment, piano di trattamento, procedure, registri ed evidenze operative. Per l’auditor rappresenta quindi un punto di ingresso molto efficace: da una singola riga può risalire al rischio che ha giustificato il controllo e, successivamente, verificare se quanto dichiarato sia effettivamente implementato.
Se un controllo viene indicato come necessario e implementato, per esempio, l’auditor può cercarne procedura, configurazione, registro, responsabilità o altra evidenza pertinente. Se viene escluso un controllo dell’Annex A, può verificare se la motivazione sia coerente con il contesto e con i rischi identificati.
Le incongruenze diventano così rapidamente visibili. Una SoA può indicare come implementata una misura che nel sistema non trova riscontro, mentre il risk treatment plan può contenere un controllo assente dal documento; allo stesso modo, un nuovo servizio cloud o un fornitore critico possono aver modificato il profilo di rischio senza che la Dichiarazione sia stata aggiornata.
La SoA è quindi particolarmente utile per controllare la coerenza verticale dell’ISMS:
rischio identificato → decisione di trattamento → controllo necessario → stato dichiarato → evidenza disponibile
Quando uno di questi passaggi non coincide con gli altri, l’audit ha già individuato un punto da approfondire.
Questo spiega anche perché la SoA non dovrebbe essere prodotta poche settimane prima della certificazione ricostruendo a posteriori ciò che l’organizzazione pensa di avere implementato. È molto più robusto mantenerla allineata al processo di gestione dei rischi durante l’intero ciclo di vita dell’ISMS.
ISO/IEC 27001 specifica i contenuti richiesti, ma lascia all’organizzazione libertà sulla forma. La soluzione più frequente è una tabella, perché permette di collegare rapidamente ciascun controllo alle informazioni che lo riguardano.
Una struttura operativa può comprendere:
| Campo | Funzione |
|---|---|
| Riferimento del controllo | Identifica il controllo o la sua mappatura |
| Descrizione | Chiarisce la misura adottata |
| Necessario/applicabile | Esplicita la decisione |
| Motivazione | Spiega perché il controllo è necessario |
| Stato di implementazione | Indica se e quanto il controllo è attuato |
| Motivazione dell’esclusione | Spiega perché un riferimento Annex A non è necessario |
| Evidenza o riferimento documentale | Collega la dichiarazione alla prova operativa |
| Responsabile | Identifica chi presidia il controllo |
Gli ultimi campi non rappresentano necessariamente requisiti testuali prescritti dalla norma, ma possono aumentare notevolmente tracciabilità e utilizzabilità del documento.
L’organizzazione non è inoltre obbligata a copiare titolo e formulazione dei controlli dell’Annex A. Può utilizzare propri controlli, purché riesca a dimostrare il confronto con il reference set previsto dalla norma e a mantenere chiaro il collegamento tra le proprie misure e quelle dell’Annex A.
Questa possibilità è particolarmente rilevante quando l’ISMS utilizza contemporaneamente altri riferimenti, per esempio controlli specifici per cloud, privacy o requisiti contrattuali. Il risultato può essere una SoA più ricca del semplice elenco Annex A, purché il perimetro e le mappature rimangano leggibili.
Uno degli errori più frequenti è considerare i 93 controlli come obbligatori per definizione e compilare la tabella cercando successivamente una giustificazione per ciascuno. La logica corretta parte invece dai controlli necessari determinati attraverso il trattamento del rischio, che vengono successivamente confrontati con l’Annex A.
L’errore opposto consiste nell’escludere controlli con motivazioni troppo generiche. Formule come “non pertinente” o “non necessario” descrivono una decisione senza spiegare perché quella decisione sia coerente con il contesto dell’organizzazione.
Altri problemi ricorrenti sono:
Particolarmente critica è la confusione tra non necessario e non implementato. Un controllo può essere necessario ma ancora in corso di implementazione: in questo caso deve rimanere visibile come tale. Dichiararlo non applicabile per evitare di mostrare una lacuna altera la logica stessa del documento.
Per lo stesso motivo l’aggiornamento della SoA deve seguire l’evoluzione dell’ISMS. Un nuovo trattamento di dati, un servizio cloud, un cambio di fornitore o una variazione normativa possono modificare i controlli necessari, e una Dichiarazione formalmente completa ma riferita a un contesto ormai superato perde gran parte del proprio valore in audit.
Il Percorso E — Statement of Applicability di EvalisDeck organizza il lavoro in modo che la Dichiarazione sia il risultato del processo e non una tabella compilata separatamente alla fine. Il flusso comprende contesto e ambito, valutazione dei controlli, applicabilità e motivazioni, verifiche di coerenza, piano di attuazione e Statement firmato.
La piattaforma gestisce 174 controlli mappati su cinque quadri, mantenendo però distinta questa struttura operativa dai 93 controlli dell’Annex A della ISO/IEC 27001:2022. I controlli aggiuntivi permettono di estendere la valutazione quando il contesto richiede riferimenti complementari, senza presentare il numero 174 come se appartenesse alla norma ISO.
Il punto più delicato rimane l’applicabilità: una voce esclusa deve conservarne la motivazione, mentre un controllo dichiarato necessario ma privo dello stato previsto può essere intercettato dalle verifiche di coerenza prima della pubblicazione. Il piano di attuazione mantiene inoltre visibili i controlli ancora da completare, evitando di trasformare una lacuna operativa in una falsa non applicabilità.
Quando il processo viene chiuso, lo Statement viene pubblicato come versione congelata, conservando la fotografia delle decisioni e dello stato di implementazione in quel momento. Se rischi, infrastruttura o controlli cambiano, la revisione successiva può quindi essere distinta dalla SoA precedentemente utilizzata o sottoposta ad audit.
Chi vuole osservare direttamente questa sequenza può utilizzare la demo guidata di EvalisDeck e aprire il Percorso E dell’azienda dimostrativa, seguendo il passaggio dall’applicabilità dei singoli controlli alla Dichiarazione finale.
La Dichiarazione di Applicabilità, o SoA, documenta i controlli di sicurezza ritenuti necessari dall’organizzazione, le motivazioni della loro inclusione, lo stato di implementazione e le ragioni delle eventuali esclusioni rispetto all’Annex A. Nasce dal processo di trattamento dei rischi previsto dalla ISO/IEC 27001.
Il confronto con tutti i controlli dell’Annex A deve essere dimostrabile, ma non significa che tutti e 93 debbano essere dichiarati necessari e implementati. I controlli ritenuti non necessari devono essere adeguatamente giustificati.
La norma non prescrive un modello grafico unico. Una tabella è spesso la soluzione più pratica perché consente di associare a ogni controllo applicabilità, motivazione, stato di implementazione ed eventuali evidenze, mantenendo visibile anche la mappatura verso Annex A.
No, se è stato determinato come necessario. La SoA deve distinguere la necessità del controllo dal suo stato di implementazione: una misura necessaria ma ancora da completare deve rimanere identificabile come tale.
Sì. I controlli necessari possono provenire anche da altre fonti o essere definiti dall’organizzazione; se fanno parte del trattamento del rischio devono essere ricondotti alla SoA e confrontati con il reference set dell’Annex A.
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
Guide Generali & Audit-Readiness28 Set 2026 · 10 min
La digitalizzazione della consulenza HSE/ESG cambia il modo di gestire clienti, dati, evidenze e documenti, riducendo duplicazioni e migliorando tracciabilità, versioning e riuso delle informazioni.
di Bruno Santini · SEO Specialist
