La norma ISO 27001 rappresenta il riferimento internazionale per la gestione della sicurezza delle informazioni. All’interno del suo sistema di gestione, la dichiarazione di applicabilità riveste un ruolo centrale. È il primo documento che l’auditor consulta al momento della certificazione e il punto in cui si collega tutto ciò che l’organizzazione ha deciso di fare per proteggere le proprie informazioni.
In questo articolo vedremo cos’è la dichiarazione di applicabilità, a cosa serve, cosa deve contenere e come redigerla passo dopo passo, con un esempio di tabella per mostrarne il risultato.
Cos'è la dichiarazione di applicabilità (SoA) della ISO 27001?
La dichiarazione di applicabilità, nota con la sigla inglese SoA (Statement of Applicability), è il documento che raccoglie tutti i controlli di sicurezza dell’Allegato A della norma ISO 27001. Per ciascuno di essi indica se l’organizzazione lo applica o meno, con la relativa giustificazione e lo stato di implementazione.
In altre parole, offre una fotografia completa dei controlli che l’organizzazione ha scelto di adottare, di quelli che ha escluso e dei motivi di tali scelte. Nella versione vigente della norma, la ISO 27001 del 2022, l’Allegato A riunisce 93 controlli raggruppati in 4 aree. La SoA passa quindi in rassegna questi 93 controlli uno per uno.
È bene non confondere la SoA con l’analisi dei rischi. Quest’ultima individua le minacce a cui l’organizzazione è esposta, mentre la SoA formalizza la decisione su quali controlli applicare per trattare tali rischi. Sono due documenti distinti che lavorano insieme, e più avanti vedremo come si collegano.
A cosa serve e perché è obbligatoria?
La SoA svolge diverse funzioni all’interno del SGSI. Tre di esse spiegano la sua importanza.
- Un documento obbligatorio per la certificazione: la norma lo richiede esplicitamente. Il requisito 6.1.3 d) della ISO 27001 del 2022 impone di redigere una dichiarazione di applicabilità che contenga i controlli necessari, la giustificazione della loro inclusione, il loro stato di implementazione e il motivo dell’esclusione di qualsiasi controllo. Senza SoA non è possibile alcuna certificazione.
- Il collegamento tra l’analisi dei rischi e i controlli: la SoA fa da ponte tra i rischi individuati e le misure messe in atto per trattarli. Rende visibile la tracciabilità tra ciò che la norma richiede e ciò che l’organizzazione realizza concretamente.
- La guida principale dell’auditor: durante l’audit, l’auditor apre la SoA prima di ogni altro documento, perché gli fornisce una mappa completa del SGSI. Da lì verifica che i controlli che si dichiara di applicare siano davvero in atto e che le esclusioni abbiano senso. Una SoA approssimativa, priva di giustificazioni o con esclusioni non motivate, porta rapidamente a una non conformità.
Cosa deve contenere la SoA?
La norma non impone un formato preciso. È quindi possibile adottare quello più adatto, a condizione che raccolga le informazioni necessarie. Per ciascun controllo dell’Allegato A, la SoA deve riportare quattro elementi.
- Il controllo e la sua descrizione: il riferimento e il nome del controllo così come compaiono nell’Allegato A, ad esempio A.5.1 Politiche per la sicurezza delle informazioni.
- La sua applicabilità: la decisione di includere o escludere quel controllo dal proprio SGSI.
- La giustificazione: il motivo di tale decisione, sia che il controllo venga adottato sia che venga scartato. Questo punto è decisivo, perché la giustificazione delle esclusioni è ciò che l’auditor esamina con maggiore attenzione.
- Lo stato di implementazione e le evidenze: indicare se il controllo è in atto, in corso di sviluppo o da avviare, con il rimando alla politica, alla procedura o all’evidenza che lo supporta.
Molte organizzazioni aggiungono colonne extra, come il responsabile del controllo o il rischio che tratta, per rafforzare la tracciabilità. Non è obbligatorio, ma aiuta a tenere il documento sotto controllo.
Esempio di tabella di una SoA
Ecco come si presenta di solito una dichiarazione di applicabilità in formato tabella. Si tratta di un esempio semplificato, con pochi controlli, per illustrarne la struttura.
| Controllo | Descrizione | Applicabile? | Giustificazione | Stato | Evidenza |
|---|---|---|---|---|---|
| A.5.1 | Politiche per la sicurezza delle informazioni | Sì | Rischio individuato nell’analisi dei rischi | In atto | Politica di SI v1.2 |
| A.5.7 | Intelligence sulle minacce | Sì | Necessità di anticipare le minacce esterne | In corso di sviluppo | Procedura di intelligence sulle minacce |
| A.6.7 | Lavoro da remoto | Sì | Parte del personale lavora fuori dall’ufficio | In atto | Politica sul lavoro da remoto v2.0 |
| A.7.4 | Monitoraggio della sicurezza fisica | No | L’organizzazione non dispone di sedi proprie | Non applicabile | Giustificazione documentata |
| A.8.23 | Filtraggio web | Sì | Rischio di accesso a siti malevoli | In atto | Configurazione del proxy aziendale |
Come redigere una dichiarazione di applicabilità passo dopo passo?
Redigere la SoA non è un adempimento isolato. Nasce in modo naturale dal lavoro di gestione dei rischi svolto a monte. Ecco i passaggi abituali per costruirla.
1. Partire dall’analisi e dal trattamento dei rischi
La SoA non è il punto di partenza del percorso. Deriva dal lavoro svolto a monte sui rischi. Prima di metterci mano occorre aver individuato i propri asset informativi, valutato i rischi a cui sono esposti e definito le opzioni di trattamento per ciascuno. È in quel momento che emerge con chiarezza quali controlli servono per ridurre ogni rischio.
Se si prova a compilare la SoA senza questo lavoro preliminare, si finisce per spuntare i controlli alla cieca e l’auditor se ne accorge subito, per l’assenza di tracciabilità tra i rischi individuati e i controlli scelti.
2. Selezionare i controlli applicabili dell’Allegato A
Una volta chiariti i rischi, si scorrono i 93 controlli dell’Allegato A della versione 2022 e si decide quali si applicano alla propria organizzazione. La norma non obbliga ad adottarli tutti. Vanno implementati solo quelli giustificati dal proprio livello di rischio, quindi un controllo può restare fuori se non ha senso nel proprio contesto.
Va tenuto presente anche che è possibile aggiungere controlli non presenti nell’Allegato A qualora l’analisi dei rischi lo richieda, dato che l’Allegato A è un riferimento e non un elenco chiuso.
3. Documentare giustificazione, stato ed evidenze
Per ciascun controllo si annota la sua applicabilità e il motivo della decisione. Per quelli adottati si aggiunge lo stato di implementazione, in atto, in corso di sviluppo o da avviare, insieme al rimando alla politica, alla procedura o all’evidenza che lo supporta.
Non va trascurata la giustificazione delle esclusioni, perché è proprio ciò che l’auditor esamina di più. Escludere un controllo è del tutto legittimo, purché si spieghi perché non si applica alla propria organizzazione. Un motivo ben formulato vale più di un elenco di controlli spuntati senza spiegazione.
4. Rivedere e approvare il documento
Infine, la SoA deve essere riletta e approvata dalla massima autorità di sicurezza dell’organizzazione prima di poter essere considerata valida. È questa approvazione formale a trasformare la bozza nel documento di riferimento del SGSI.
Da quel momento è pronta per l’audit. Occorre però ricordare che non si tratta di una versione definitiva e immutabile. È la prima di una lunga serie, perché la SoA verrà aggiornata nel tempo.
Come mantenere e gestire la SoA?
La SoA non si redige una volta sola per poi essere archiviata. È un documento vivo, da rivedere e aggiornare ogni volta che qualcosa di rilevante cambia nell’organizzazione, ad esempio la comparsa di un nuovo rischio, l’aggiunta di un asset o di una tecnologia, un cambiamento del contesto normativo o la modifica di una decisione di trattamento. Conviene quindi tenere un controllo delle versioni che registri ogni modifica e chi l’ha approvata.
È qui che molte organizzazioni si bloccano. Gestire la SoA in un foglio di calcolo diventa ingestibile non appena si hanno decine di controlli attivi, con i loro responsabili, le loro evidenze e le loro scadenze che cambiano nello stesso momento. Il documento rischia di restare presto obsoleto e di arrivare all’audit con evidenze scadute o controlli privi di responsabile assegnato.
È proprio qui che uno strumento di gestione IT e conformità come Factorial IT fa la differenza, perché copre e documenta buona parte dei controlli tecnici dell’Allegato A che compaiono nella SoA.
- Inventario automatico degli asset IT: sempre aggiornato ed esportabile per l’audit.
- Gestione dei dispositivi (MDM): cifratura, antivirus e patch su Mac, Windows e Linux.
- Gestione degli accessi: assegnazione e revoca dei permessi in base al ruolo di ogni collaboratore.
- Offboarding sicuro: chiusura di tutti gli accessi al momento della registrazione di un’uscita nell’HRIS.
- Evidenze di audit automatiche: pronte da esportare non appena l’auditor le richiede.
Con i controlli in atto e le evidenze raccolte in modo continuo, tenere aggiornata la SoA smette di essere una corsa dell’ultimo minuto prima dell’audit.
