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\u00e0 riveste un ruolo centrale. \u00c8 il primo documento che l’auditor consulta al momento della certificazione e il punto in cui si collega tutto ci\u00f2 che l’organizzazione ha deciso di fare per proteggere le proprie informazioni.<\/p>\n
In questo articolo vedremo cos’\u00e8 la dichiarazione di applicabilit\u00e0, a cosa serve, cosa deve contenere e come redigerla passo dopo passo, con un esempio di tabella per mostrarne il risultato.<\/p>\n
La dichiarazione di applicabilit\u00e0, nota con la sigla inglese SoA (Statement of Applicability<\/em>), \u00e8 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.<\/p>\n 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<\/a>, l’Allegato A riunisce 93 controlli raggruppati in 4 aree. La SoA passa quindi in rassegna questi 93 controlli uno per uno.<\/p>\n \u00c8 bene non confondere la SoA con l’analisi dei rischi. Quest’ultima individua le minacce a cui l’organizzazione \u00e8 esposta, mentre la SoA formalizza la decisione su quali controlli applicare per trattare tali rischi. Sono due documenti distinti che lavorano insieme, e pi\u00f9 avanti vedremo come si collegano.<\/p>\n La SoA svolge diverse funzioni all’interno del SGSI<\/a>. Tre di esse spiegano la sua importanza.<\/p>\n La norma non impone un formato preciso. \u00c8 quindi possibile adottare quello pi\u00f9 adatto, a condizione che raccolga le informazioni necessarie. Per ciascun controllo dell’Allegato A, la SoA deve riportare quattro elementi.<\/p>\n Molte organizzazioni aggiungono colonne extra, come il responsabile del controllo o il rischio che tratta, per rafforzare la tracciabilit\u00e0. Non \u00e8 obbligatorio, ma aiuta a tenere il documento sotto controllo.<\/p>\n Ecco come si presenta di solito una dichiarazione di applicabilit\u00e0 in formato tabella. Si tratta di un esempio semplificato, con pochi controlli, per illustrarne la struttura.<\/p>\n Redigere la SoA non \u00e8 un adempimento isolato. Nasce in modo naturale dal lavoro di gestione dei rischi svolto a monte. Ecco i passaggi abituali per costruirla.<\/p>\n La SoA non \u00e8 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. \u00c8 in quel momento che emerge con chiarezza quali controlli servono per ridurre ogni rischio.<\/p>\n 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\u00e0 tra i rischi individuati e i controlli scelti.<\/p>\n 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\u00f2 restare fuori se non ha senso nel proprio contesto.<\/p>\n Va tenuto presente anche che \u00e8 possibile aggiungere controlli non presenti nell’Allegato A qualora l’analisi dei rischi lo richieda, dato che l’Allegato A \u00e8 un riferimento e non un elenco chiuso.<\/p>\n Per ciascun controllo si annota la sua applicabilit\u00e0 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.<\/p>\n Non va trascurata la giustificazione delle esclusioni, perch\u00e9 \u00e8 proprio ci\u00f2 che l’auditor esamina di pi\u00f9. Escludere un controllo \u00e8 del tutto legittimo, purch\u00e9 si spieghi perch\u00e9 non si applica alla propria organizzazione. Un motivo ben formulato vale pi\u00f9 di un elenco di controlli spuntati senza spiegazione.<\/p>\n Infine, la SoA deve essere riletta e approvata dalla massima autorit\u00e0 di sicurezza dell’organizzazione prima di poter essere considerata valida. \u00c8 questa approvazione formale a trasformare la bozza nel documento di riferimento del SGSI.<\/p>\n Da quel momento \u00e8 pronta per l’audit. Occorre per\u00f2 ricordare che non si tratta di una versione definitiva e immutabile. \u00c8 la prima di una lunga serie, perch\u00e9 la SoA verr\u00e0 aggiornata nel tempo.<\/p>\n La SoA non si redige una volta sola per poi essere archiviata. \u00c8 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.<\/p>\n \u00c8 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.<\/p>\n \u00c8 proprio qui che uno strumento di gestione IT e conformit\u00e0 come Factorial IT<\/a> fa la differenza, perch\u00e9 copre e documenta buona parte dei controlli tecnici dell’Allegato A che compaiono nella SoA.<\/p>\nA cosa serve e perch\u00e9 \u00e8 obbligatoria?<\/h2>\n
\n
Cosa deve contenere la SoA?<\/h2>\n
\n
Esempio di tabella di una SoA<\/h2>\n
\n\n
\n \nControllo<\/th>\n Descrizione<\/th>\n Applicabile?<\/th>\n Giustificazione<\/th>\n Stato<\/th>\n Evidenza<\/th>\n<\/tr>\n<\/thead>\n \n A.5.1<\/td>\n Politiche per la sicurezza delle informazioni<\/td>\n S\u00ec<\/td>\n Rischio individuato nell’analisi dei rischi<\/td>\n In atto<\/td>\n Politica di SI v1.2<\/td>\n<\/tr>\n \n A.5.7<\/td>\n Intelligence sulle minacce<\/td>\n S\u00ec<\/td>\n Necessit\u00e0 di anticipare le minacce esterne<\/td>\n In corso di sviluppo<\/td>\n Procedura di intelligence sulle minacce<\/td>\n<\/tr>\n \n A.6.7<\/td>\n Lavoro da remoto<\/td>\n S\u00ec<\/td>\n Parte del personale lavora fuori dall’ufficio<\/td>\n In atto<\/td>\n Politica sul lavoro da remoto v2.0<\/td>\n<\/tr>\n \n A.7.4<\/td>\n Monitoraggio della sicurezza fisica<\/td>\n No<\/td>\n L’organizzazione non dispone di sedi proprie<\/td>\n Non applicabile<\/td>\n Giustificazione documentata<\/td>\n<\/tr>\n \n A.8.23<\/td>\n Filtraggio web<\/td>\n S\u00ec<\/td>\n Rischio di accesso a siti malevoli<\/td>\n In atto<\/td>\n Configurazione del proxy aziendale<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Come redigere una dichiarazione di applicabilit\u00e0 passo dopo passo?<\/h2>\n
1. Partire dall’analisi e dal trattamento dei rischi<\/h3>\n
2. Selezionare i controlli applicabili dell’Allegato A<\/h3>\n
3. Documentare giustificazione, stato ed evidenze<\/h3>\n
4. Rivedere e approvare il documento<\/h3>\n
Come mantenere e gestire la SoA?<\/h2>\n