Che cos'è una Dichiarazione di Applicabilità (SoA)?
La Dichiarazione di Applicabilità (SoA) è un documento obbligatorio ISO 27001 che elenca tutti i 93 controlli dell'Annex A e spiega se ogni controllo è incluso nel…
Panoramica
La Dichiarazione di Applicabilità (SoA) è un documento obbligatorio ISO 27001 che elenca tutti i 93 controlli dell'Annex A e spiega se ogni controllo è incluso nel proprio ISMS o escluso. Per i controlli inclusi, descrive come vengono implementati. Per i controlli esclusi, fornisce una giustificazione per l'esclusione.
Cosa significa in pratica
La SoA è il progetto di selezione dei controlli: collega i risultati della valutazione dei rischi ai specifici controlli di sicurezza che si è scelto di implementare. Gli auditor la utilizzano come mappa per verificare che il proprio ISMS affronti i rischi identificati in modo appropriato.
Esempio reale: La valutazione dei rischi identifica il ransomware come una minaccia critica. La SoA mostrerebbe il controllo A.8.7 (Protezione contro il malware) come "Incluso" con dettagli di implementazione come "Software di rilevamento e risposta su endpoint distribuito su tutti i dispositivi con gestione centralizzata", mentre il controllo A.7.4 (Monitoraggio della sicurezza fisica) potrebbe essere "Escluso - organizzazione solo cloud senza data center fisico".
Perché la SoA è importante per ISO 27001
Requisito obbligatorio
La clausola 6.1.3(d) di ISO 27001 richiede esplicitamente di mantenere "una Dichiarazione di Applicabilità contenente i controlli necessari e la giustificazione per inclusioni ed esclusioni". Non è possibile ottenere la certificazione senza una SoA completa e accurata.
Dimostra un approccio basato sul rischio
La SoA dimostra che non si stanno implementando controlli in modo casuale o applicando ciecamente modelli. Mostra come ogni decisione sui controlli sia riconducibile alla valutazione dei rischi.
Mappa per l'audit
Gli auditor utilizzano la SoA per pianificare cosa verificheranno durante gli audit di certificazione. I controlli inclusi necessitano di prove di implementazione ed efficacia. Le esclusioni devono essere giustificate in base alla valutazione dei rischi o al contesto aziendale.
Gestione del cambiamento
Man mano che i rischi evolvono, la SoA dovrebbe essere aggiornata per riflettere nuovi requisiti di controllo o consentire la rimozione di controlli precedentemente esclusi se i rischi diminuiscono.
Rilievo comune in audit: Giustificazioni della SoA che non sono allineate con i risultati della valutazione dei rischi. Ad esempio, escludere i controlli di backup (A.8.13) mentre la valutazione dei rischi identifica la perdita di dati come un rischio elevato porterà a una non conformità.
Cosa deve includere la SoA
Elenco completo dei controlli
Tutti i 93 controlli dell'Annex A di ISO 27001:2022 devono apparire nella SoA, organizzati per tema:
- Controlli organizzativi: da A.5.1 a A.5.37 (37 controlli)
- Controlli sulle persone: da A.6.1 a A.6.8 (8 controlli)
- Controlli fisici: da A.7.1 a A.7.14 (14 controlli)
- Controlli tecnologici: da A.8.1 a A.8.34 (34 controlli)
Stato di inclusione/esclusione
Per ogni controllo, indicare chiaramente se è incluso nel proprio ISMS o escluso. Evitare stati ambigui come "parzialmente applicabile" - i controlli sono o dentro o fuori.
Descrizione dell'implementazione (per i controlli inclusi)
Descrivere brevemente come si implementa ogni controllo incluso. Includere:
- Politiche, procedure o tecnologie specifiche utilizzate
- Chi è responsabile del controllo
- Dove trovare le prove dell'implementazione
- Come il controllo affronta i rischi identificati
Giustificazione dell'esclusione (per i controlli esclusi)
Spiegare perché i controlli esclusi non fanno parte del proprio ISMS. Giustificazioni valide:
- Basata sul rischio: "Nessun rischio nella nostra valutazione richiede questo controllo"
- Basata sul contesto: "Non applicabile - siamo solo cloud senza infrastruttura fisica"
- Legale/regolamentare: "Vietato dalle leggi sulla residenza dei dati nella nostra giurisdizione"
Qualità della giustificazione: Le giustificazioni forti per l'esclusione fanno riferimento a specifici risultati della valutazione dei rischi o al contesto organizzativo. Giustificazioni deboli come "non rilevante" o "non ancora implementato" saranno contestate dagli auditor.
Struttura e formato della SoA
Formato tabellare (più comune)
Una tabella con colonne per:
- Numero del controllo (es. A.5.1)
- Nome del controllo (es. "Politiche per la sicurezza delle informazioni")
- Stato (Incluso / Escluso)
- Descrizione dell'implementazione o giustificazione dell'esclusione
- Riferimento al rischio (collegamento al registro dei rischi)
- Posizione delle prove (opzionale ma utile)
Formato narrativo
Alcune organizzazioni preferiscono un documento narrativo che descrive l'implementazione dei controlli raggruppati per tema. Meno comune ma accettabile se affronta chiaramente tutti i 93 controlli.
Formato basato su strumenti
Le piattaforme GRC e gli strumenti ISMS spesso generano automaticamente le SoA in base alla selezione dei controlli e al collegamento con le valutazioni dei rischi. Questi documenti necessitano comunque di una validazione manuale per garantirne l'accuratezza.
Preferenza degli auditor: La maggior parte degli auditor preferisce le SoA in formato tabellare perché sono facili da scansionare e incrociare. Mantenere le descrizioni dell'implementazione concise (2-3 frasi per controllo) - le procedure dettagliate appartengono a documenti separati, non alla SoA.
Creazione della SoA
Passo 1: Completare la valutazione dei rischi
La SoA è un output diretto della valutazione dei rischi. Identificare tutti i rischi che richiedono un trattamento prima di determinare quali controlli implementare.
Passo 2: Mappare i controlli ai rischi
Per ogni rischio che richiede un trattamento, identificare quali controlli dell'Annex A lo ridurrebbero a livelli accettabili. Un rischio può necessitare di più controlli; un controllo può affrontare più rischi.
Passo 3: Determinare inclusione/esclusione
I controlli che affrontano rischi identificati sono inclusi. I controlli che non affrontano nessuno dei propri rischi possono essere esclusi (con giustificazione).
Passo 4: Descrivere l'implementazione
Per i controlli inclusi, documentare come vengono implementati. Essere sufficientemente specifici affinché gli auditor comprendano il proprio approccio senza duplicare intere procedure.
Passo 5: Giustificare le esclusioni
Per i controlli esclusi, spiegare perché in base alla valutazione dei rischi o al contesto organizzativo. Fare riferimento a risultati specifici del registro dei rischi quando possibile.
Passo 6: Revisione e approvazione
La direzione dovrebbe rivedere e approvare formalmente la SoA, riconoscendo le decisioni di selezione dei controlli e qualsiasi rischio residuo.
Controllo delle versioni: La SoA è un documento dinamico che deve essere aggiornato quando i rischi cambiano, i controlli vengono aggiunti o modificati, o le esclusioni vengono riconsiderate. Mantenere una cronologia delle versioni che mostri quando e perché sono avvenute le modifiche.
Errori comuni nella SoA
Escludere troppi controlli
Le organizzazioni a volte escludono controlli per ridurre lo sforzo di implementazione. Gli auditor esaminano attentamente le esclusioni - se la valutazione dei rischi è approfondita, la maggior parte dei controlli dovrebbe essere inclusa.
Descrizioni generiche dell'implementazione
Copiare le descrizioni dei controlli da ISO 27002 senza descrivere la propria implementazione effettiva. Gli auditor devono capire cosa si fa, non cosa dice lo standard.
Collegamenti mancanti ai rischi
Non riuscire a collegare i controlli a rischi specifici nella valutazione dei rischi. Questo interrompe la tracciabilità e suggerisce che i controlli siano stati selezionati arbitrariamente.
Copertura incompleta
Dimenticare di affrontare tutti i 93 controlli. Anche se un controllo sembra ovviamente non applicabile, deve apparire nella SoA con una giustificazione per l'esclusione.
Nessun ciclo di revisione
Creare la SoA una volta durante l'implementazione iniziale e non aggiornarla mai nonostante i cambiamenti organizzativi o i nuovi rischi.
Suggerimento per l'efficienza: Utilizzare ISMS Copilot per generare un modello di SoA con descrizioni comuni di implementazione per il proprio settore. Personalizzare l'output in base ai risultati specifici della valutazione dei rischi e al contesto.
SoA vs. altri documenti ISO 27001
SoA vs. Piano di Trattamento dei Rischi
Il Piano di Trattamento dei Rischi dettaglia come si implementeranno i controlli selezionati (tempistiche, responsabilità, risorse). La SoA dichiara quali controlli sono implementati e perché. I due documenti sono complementari.
SoA vs. Prove dei Controlli
La SoA descrive quali controlli si implementano. Le prove dimostrano che i controlli sono effettivamente operativi in modo efficace. Durante gli audit, gli auditor campionano i controlli dalla SoA e richiedono le relative prove.
SoA vs. Politiche e Procedure
Le politiche e le procedure forniscono istruzioni dettagliate per l'implementazione dei controlli. La SoA riassume a un livello alto quali controlli esistono e come funzionano.
Come gli auditor utilizzano la SoA
Audit di Fase 1 (revisione della documentazione)
Gli auditor verificano che la SoA sia completa (tutti i 93 controlli affrontati), strutturata logicamente e allineata con la valutazione dei rischi. Controllano che le giustificazioni per le esclusioni abbiano senso.
Audit di Fase 2 (verifica dell'implementazione)
Gli auditor campionano i controlli dalla SoA e richiedono prove che siano implementati come descritto. Testeranno i controlli in tutti e quattro i temi e le aree organizzative nell'ambito di applicazione.
Motivi di non conformità
Ragioni comuni per cui gli auditor emettono non conformità relative alla SoA:
- Controlli marcati come "inclusi" ma non effettivamente implementati
- Esclusioni senza giustificazione valida
- SoA che non riflette i risultati effettivi della valutazione dei rischi
- Controlli mancanti (meno di 93 elencati)
- Descrizioni dell'implementazione troppo vaghe per essere verificate
Preparazione all'audit: Prima dell'audit di certificazione, rivedere ogni controllo "incluso" nella SoA e raccogliere le relative prove. Se non si riesce a trovare prove per un controllo, implementarlo correttamente o aggiornare la SoA per escluderlo con giustificazione.
Mantenimento della SoA nel tempo
Aggiornamenti annuali della valutazione dei rischi
Quando si eseguono le rivalutazioni programmate dei rischi, rivedere la SoA per determinare se le selezioni dei controlli rimangono appropriate. Nuovi rischi possono richiedere controlli precedentemente esclusi.
Cambiamenti organizzativi
Aggiornare la SoA quando:
- Viene distribuita una nuova tecnologia (possono essere necessari nuovi controlli tecnici)
- Il modello di business cambia (es. passaggio al cloud modifica i controlli fisici)
- L'espansione geografica introduce nuovi requisiti normativi
- Fusioni o acquisizioni modificano il profilo di rischio
Revisioni innescate da incidenti
Dopo incidenti di sicurezza significativi, rivedere se i controlli esistenti sono stati efficaci o se dovrebbero essere implementati controlli aggiuntivi (precedentemente esclusi).
Audit di sorveglianza
Gli auditor verificheranno durante gli audit annuali di sorveglianza se la SoA è stata mantenuta aggiornata. Le prove di revisione regolare dimostrano che il proprio ISMS è attivo, non abbandonato dopo la certificazione.
SoA e personalizzazione dei controlli
Lo standard consente la personalizzazione
ISO 27001 permette alle organizzazioni di implementare i controlli in modo diverso in base a dimensioni, complessità e rischio. La SoA dovrebbe riflettere la propria implementazione specifica, non un modello generico.
Controlli aggiuntivi oltre l'Annex A
Se la valutazione dei rischi identifica rischi non adeguatamente affrontati dai 93 controlli standard, è possibile implementare controlli aggiuntivi. Elencarli nella SoA o in un documento supplementare.
La proporzionalità conta
L'implementazione del controllo "A.6.3 Formazione sulla consapevolezza della sicurezza delle informazioni" di una startup di 10 persone sarà diversa da quella di un'azienda con 10.000 dipendenti. Entrambe possono essere conformi se appropriate al contesto ed efficaci nel ridurre il rischio.
Esempio di implementazione proporzionale: Una piccola azienda SaaS solo cloud potrebbe escludere A.7.1-A.7.14 (controlli fisici) giustificando "Nessuna infrastruttura fisica - tutti i sistemi operano in AWS con la sicurezza gestita dai controlli SOC 2 del provider cloud". Questo è accettabile se la valutazione dei rischi riflette l'architettura cloud-first.
Concetti correlati
- Annex A Controls - I 93 controlli di sicurezza che la SoA deve affrontare
- Risk Assessment - Processo che guida la selezione dei controlli nella SoA
- Risk Treatment - Implementazione dei controlli identificati nella SoA
- Control - Le misure di sicurezza selezionate nella SoA
- How to get started with ISO 27001 implementation using AI
Ottenere aiuto
Accelerare la creazione della SoA con ISMS Copilot. Generare descrizioni di implementazione personalizzate, validare le proprie giustificazioni rispetto ai risultati della valutazione dei rischi e assicurarsi che tutti i 93 controlli siano affrontati correttamente.