La Dichiarazione di Applicabilità, detta SoA dall'inglese Statement of Applicability, è il documento in cui la tua organizzazione elenca i controlli di sicurezza scelti, spiega perché ciascuno è stato incluso o escluso e ne dichiara lo stato di attuazione. È un documento obbligatorio del sistema di gestione della sicurezza delle informazioni (SGSI) secondo ISO/IEC 27001:2022: questa guida ti dà una checklist per scriverla, criteri per motivare le esclusioni e regole per mantenerla aggiornata nel tempo.
Che cos'è la SoA e a cosa serve
La norma ISO/IEC 27001:2022 definisce i requisiti di un SGSI: un sistema per gestire i rischi legati alle informazioni che l'organizzazione possiede o tratta. Il percorso parte dall'analisi dei rischi: individuati i rischi, decidi come trattarli e quali misure adottare. La SoA è il punto in cui queste decisioni diventano un documento: nasce nella parte della norma dedicata alla pianificazione (clausola 6), nel passaggio sul trattamento del rischio, dove i controlli scelti vanno confrontati con quelli dell'Allegato A.
L'Allegato A dell'edizione 2022 raccoglie 93 controlli di riferimento, raggruppati in quattro temi: organizzativi (A.5), persone (A.6), fisici (A.7) e tecnologici (A.8). Non sono una lista da spuntare tutta: la SoA serve proprio a dimostrare che li hai esaminati uno per uno e che ogni scelta discende dai tuoi rischi, dai requisiti legali e contrattuali e dal contesto della tua organizzazione. Per i contenuti dei singoli controlli rimandiamo all'articolo sui controlli dell'Annex A 2022; la norma ISO/IEC 27002:2022 ne fornisce la guida attuativa.
Due precisazioni utili prima di partire. Primo: scrivere la SoA è obbligatorio per chi adotta la norma, mentre la certificazione resta una scelta — la stessa ISO ricorda che alcune organizzazioni implementano lo standard solo per le buone pratiche, altre si certificano per rassicurare clienti e partner. Secondo: la SoA non è un modulo prestampato da copiare. Un documento identico a quello di un'altra azienda segnala all'auditor che le scelte non sono state ragionate sui tuoi rischi reali.
Struttura della SoA: la checklist
La SoA ha di solito forma tabellare, con una riga per controllo. Ecco gli elementi che deve contenere e come compilarli perché reggano a un audit.
| Elemento | Cosa scrivere | Segnale di debolezza |
|---|---|---|
| Identificativo e titolo del controllo | Il riferimento dell'Annex A (per esempio A.5.17) e il nome del controllo, così come riportato nella tua copia autorizzata della norma. | Riferimenti all'edizione 2013 non aggiornati alla numerazione 2022. |
| Decisione: incluso o escluso | Una sola delle due opzioni, senza stati ambigui come «in parte» non spiegati. | Righe lasciate in bianco o marcate «da valutare» a ridosso dell'audit. |
| Giustificazione della scelta | Il motivo legato ai rischi, ai requisiti legali o contrattuali, o alla non applicabilità al tuo contesto. | La stessa frase copiata su decine di controlli, o motivazioni generiche come «best practice». |
| Legame con i rischi e il piano di trattamento | Il rinvio ai rischi che il controllo tratta e al piano di trattamento del rischio, documento con cui la SoA deve restare coerente. | Controlli inclusi che non trattano alcun rischio censito: l'auditor chiederà perché li avete scelti. |
| Stato di attuazione | Se il controllo è attuato, in attuazione o pianificato, con riferimenti alle evidenze (procedure, registrazioni, configurazioni). | Controlli dichiarati attuati senza alcuna evidenza consultabile. |
| Responsabile e versione | Chi mantiene la riga aggiornata, data e numero di versione del documento. | Nessun proprietario del documento e nessuno storico delle modifiche. |
Se parti dall'analisi del rischio del tuo SGSI, la compilazione diventa meccanica: ogni rischio rilevante trova almeno un controllo che lo tratta, e ogni controllo incluso risponde a un rischio, a un obbligo o a un impegno contrattuale. Le incongruenze tra rischi, piano di trattamento e SoA sono tra le non conformità più frequenti in audit, quindi vale la pena rileggere i tre documenti insieme prima di considerare il lavoro finito.
Giustificare inclusioni ed esclusioni in modo difendibile
Escludere un controllo dell'Annex A è legittimo: la norma chiede di giustificare le esclusioni, non di includere tutto. Una giustificazione difendibile ha tre caratteristiche:
- È specifica. Spiega perché quel controllo non si applica alla tua organizzazione, non perché «costa troppo» o «non è prioritaria» in astratto.
- È coerente con l'analisi dei rischi. Se escludi un controllo, i rischi che tratterebbe devono risultare accettati, trattati in altro modo o non presenti nel tuo contesto.
- Documenta le misure compensative. Se il rischio esiste ma lo affronti diversamente, la SoA (o un documento collegato) deve dire come.
Esempio illustrativo. Un'azienda di lavorazione alimentare usa per il magazzino frigorifero un gestionale legacy, fuori supporto, che non permette di cifrare il database in cui transitano ricette e lotti. Nell'esaminare il controllo sulla cifratura, il responsabile SGSI valuta la sostituzione immediata troppo onerosa rispetto al rischio. Nella SoA il controllo risulta escluso nella forma prevista, con una giustificazione articolata: il rischio è stato valutato nell'analisi, il server è collocato in un segmento di rete separato raggiungibile solo da due postazioni autorizzate, l'accesso fisico alla sala è registrato e la sostituzione del gestionale è inserita nel piano con una data. La scelta non è «nessuna protezione»: è una combinazione documentata di misure, con un proprietario e una scadenza. In audit, questa riga regge perché racconta un ragionamento verificabile; sarebbe crollata con un generico «non applicabile».
Lo stesso criterio vale per le inclusioni: se includi un controllo, preparati a mostrare come è attuato. Una SoA con novanta controlli «attuati» e poche evidenze a supporto è più fragile di una SoA con alcune esclusioni ben motivate.
Tenerla viva: approvazioni, versioni e momenti di aggiornamento
La SoA non è un documento da scrivere una volta per la certificazione: la norma chiede di mantenere il SGSI, e la SoA ne fa parte. Chi la approva? La responsabilità del sistema di gestione spetta alla direzione, che la norma pone al centro della leadership del SGSI: in pratica le modifiche alla SoA vengono predisposte dal responsabile SGSI o dal consulente e approvate secondo il processo documentale concordato, con il coinvolgimento della direzione per le decisioni che riguardano l'accettazione del rischio. L'auditor di certificazione non approva la tua SoA: ne verifica la coerenza.
Quando aggiornarla? Stabilisci per iscritto i trigger, invece di affidarti alla memoria:
- Cambiamenti del contesto: nuovi servizi, nuove sedi, acquisizioni, nuovi sistemi informativi, variazioni del campo di applicazione.
- Nuovi rischi o nuovi obblighi: esiti dell'analisi del rischio aggiornata, nuovi requisiti legali o contrattuali.
- Esiti del sistema di gestione: incidenti, risultati degli audit e delle verifiche sulle evidenze, azioni correttive, riesame della direzione.
- Revisione periodica: un controllo calendarizzato, per esempio annuale, anche in assenza di eventi.
Per lo storico delle versioni bastano poche regole rispettate: numero di versione e data su ogni emissione, un registro delle modifiche che riassume cosa è cambiato e perché, conservazione delle versioni precedenti e identificazione di chi ha predisposto e approvato ogni versione. Questo storico è esso stesso un'evidenza: dimostra che il documento è vivo e che le decisioni nel tempo sono ricostruibili.
Come OverZeus supporta il lavoro sulla SoA
Scrivere e approvare la SoA resta un compito dell'organizzazione: nessun software decide al posto tuo quali rischi accettare. Dove un supporto fa la differenza è nella tenuta del documento nel tempo e nella raccolta delle evidenze. OverZeus contribuisce su questo piano con due agenti:
- Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti degli interventi: quando un controllo viene applicato, modificato o compensato, la ricostruzione di chi ha deciso cosa e con quale risultato resta disponibile come evidenza. Se una variazione di configurazione compare senza un riferimento autorizzativo, Mnemosyne segnala la lacuna invece di inventare una giustificazione.
- Nestor recupera manuali, runbook e casi precedenti rispettando i permessi, e confronta le versioni dei documenti: se la procedura citata nella SoA e quella usata dai tecnici si contraddicono, evidenzia le differenze e chiede al proprietario quale versione è valida. La revisione e l'aggiornamento spettano al proprietario attraverso il processo concordato; Nestor rende visibili le incongruenze da correggere.
Resta un confine da tenere presente: OverZeus supporta attività ed evidenze utili al percorso ISO/IEC 27001, ma non certifica l'organizzazione e non sostituisce la valutazione dei rischi, le decisioni della direzione né il giudizio dell'auditor.
Errori frequenti da evitare
- Copiare una SoA trovata online o ereditata da un altro progetto senza ragionare sul proprio contesto.
- Escludere controlli con motivazioni generiche, senza collegamento all'analisi dei rischi.
- Dichiarare attuati controlli privi di evidenze consultabili.
- Lasciare la SoA ferma alla prima certificazione mentre sistemi, rischi e obblighi cambiano.
- Perdere lo storico: senza versioni precedenti e registro delle modifiche, ogni aggiornamento diventa irricostruibile.
Scopri come collegare le evidenze operative al tuo sistema di gestione.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.