SoA ISO 27001: cos'è la Dichiarazione di Applicabilità

La SoA ISO 27001 (Statement of Applicability, in italiano Dichiarazione di Applicabilità) è il documento in cui l'organizzazione elenca i controlli di sicurezza scelti per trattare i propri rischi, li confronta con l'Appendice A della norma e motiva, controllo per controllo, perché lo applica o lo esclude e a che punto è. Nasce dal trattamento del rischio (punto 6.1.3) e viene citata nello scopo del certificato.

Questa guida è per chi deve scriverla la prima volta, o per chi ne ha una ereditata e non sa più se regge. Distinguiamo sempre fra ciò che si legge nelle fonti ufficiali (la norma nelle parti consultabili, la circolare Accredia del 2026) e ciò che è prassi di chi le SoA le costruisce e le porta in audit.

Cos'è la SoA e dove sta nella norma

In Italia la norma è la UNI CEI EN ISO/IEC 27001:2024+A1:2024, cioè il recepimento della ISO/IEC 27001:2022 con l'aggiornamento Amd 1:2024. Dall'indice si ricavano i tre punti che contano per la SoA:

• 6.1.3, Trattamento del rischio relativo alla sicurezza delle informazioni: è la fase di pianificazione in cui si decidono i controlli e in cui la SoA viene prodotta.
• 8.3, con lo stesso titolo, fra le attività operative: è il punto in cui il trattamento passa all'esecuzione.
• Appendice A, normativa, con il prospetto A.1 dei controlli di riferimento per la sicurezza delle informazioni: è il catalogo contro cui si confrontano i controlli scelti.

C'è una differenza da tenere chiara. Il punto 1 della norma stabilisce che chi dichiara la conformità non può escludere nessun requisito dei punti dal 4 al 10. I controlli dell'Appendice A funzionano in un altro modo: si scelgono in base al rischio, e la SoA è il posto in cui quella scelta si mette per iscritto. Il contenuto dei singoli controlli è spiegato nell'articolo sui controlli dell'Allegato A.

La premessa ISO aggiunge un dettaglio pratico: il testo è stato allineato con la UNI CEI EN ISO/IEC 27002:2023, la norma che per ogni controllo dà le linee guida di attuazione. Chi scrive la SoA la tiene aperta accanto.

Perché conta: la SoA finisce nel certificato

La SoA non resta nel cassetto del responsabile della sicurezza. La Circolare tecnica DC n. 22/2026 di Accredia, del 17 giugno 2026, indirizzata agli organismi di certificazione, scrive: "Lo scopo di certificazione rilasciato dall’OdC deve contenere espresso riferimento alla SoA ed al suo stato di aggiornamento, coerentemente ai processi inseriti nel perimetro del sistema di gestione oggetto di certificazione."

Nell'esempio di scopo della circolare, la frase finale è "secondo lo Statement of Applicability Rev.0 del gg/mm/aaaa". Tre conseguenze pratiche:

• la SoA ha un numero di revisione e una data, e quella revisione è quella certificata;
• deve essere coerente con i processi dentro il perimetro: se il perimetro cambia, cambia anche la SoA;
• chi legge il certificato di un fornitore può chiedere la SoA citata nello scopo, per capire quali controlli copre davvero.

La stessa circolare spiega che le linee guida della serie 27000, come la ISO/IEC 27017 e la 27018 per il cloud, non sono certificabili da sole: lo scopo cita la SoA e gli ulteriori standard presi a riferimento per i controlli, mentre il certificato attesta la conformità alla sola ISO/IEC 27001. Nell'esempio della circolare, lo scopo descrive i servizi secondo la SoA integrata dai controlli delle linee guida ISO/IEC 27017 e 27018.

Cosa contiene una SoA

Nella prassi il formato varia: un foglio di calcolo, un documento, una vista di una piattaforma di compliance. Quello che conta è il contenuto. Una SoA che regge in audit riporta per ogni controllo dell'Appendice A:

1. Riferimento e titolo del controllo, con la numerazione dell'Appendice A.
2. Applicabile sì o no.
3. Motivazione dell'inclusione: il rischio del registro a cui risponde, oppure un obbligo di legge, di contratto o una scelta della direzione.
4. Motivazione dell'esclusione, se il controllo non si applica, collegata al contesto e al perimetro.
5. Stato di attuazione: attuato, in corso, pianificato, con la data prevista per quelli non ancora attivi.
6. Riferimento alle evidenze: la politica o la procedura che lo descrive, e dove si trova la prova che funziona.
7. Responsabile del controllo.

In coda si elencano gli eventuali controlli aggiuntivi che l'organizzazione ha scelto fuori dall'Appendice A, per esempio quelli presi dalla 27017 o richiesti da un cliente. In testa: titolo, perimetro, revisione, data, chi l'ha approvata.

Come si costruisce, passo per passo

1. Fissare il perimetro

La SoA vale per il campo di applicazione del sistema di gestione, e Accredia chiede che sia coerente con i processi che ci stanno dentro. Prima di aprire l'Appendice A serve sapere quali sedi, processi, sistemi e servizi sono in perimetro.

2. Valutare i rischi

La valutazione del rischio (punto 6.1.2) viene prima. Asset, minacce, vulnerabilità, probabilità e impatto finiscono in un registro con criteri di accettazione dichiarati. Il metodo è spiegato nell'articolo sulla gestione del rischio con la ISO 27005.

3. Decidere il trattamento e i controlli

Per ogni rischio si sceglie come trattarlo e si individuano i controlli necessari. Solo a questo punto si confronta l'elenco con l'Appendice A, per verificare di non aver tralasciato nulla. L'ordine conta: prima i rischi, poi i controlli.

4. Compilare riga per riga

Si passa tutto il catalogo, senza saltare controlli. Ogni riga deve poter essere ricondotta a un rischio, a un obbligo o a una ragione di esclusione. Le righe con motivazioni copiate e incollate sono le prime che un auditor nota.

5. Approvare, numerare, datare

Nella prassi la SoA viene approvata insieme al piano di trattamento del rischio dai responsabili del rischio. Prende un numero di revisione e una data, che sono quelli che compariranno nello scopo del certificato. Gli altri documenti che l'auditor si aspetta di trovare accanto alla SoA sono elencati in documenti obbligatori ISO 27001.

6. Tenerla viva

Un nuovo fornitore cloud, una sede acquisita, un servizio lanciato, un incidente: ogni cambiamento che tocca i rischi tocca anche la SoA. La SoA è anche uno dei criteri contro cui si conducono gli audit interni ISO 27001, che verificano se i controlli dichiarati attivi lo sono davvero.

Le esclusioni: quando reggono e quando no

Un controllo si esclude quando non c'è il rischio o il contesto a cui risponde. Un'azienda che non sviluppa software in casa può motivare l'esclusione dei controlli sullo sviluppo sicuro, e dovrà però verificare se li richiede ai fornitori che sviluppano per lei.

Le esclusioni che non reggono hanno quasi sempre la stessa forma:

• Non applicabile perché lo fa il fornitore cloud. Se il servizio esterno tratta informazioni in perimetro, il rischio resta dell'organizzazione e di norma il controllo si applica: cambia chi lo esegue, e la SoA lo dice. Accredia, nella stessa circolare, chiede agli organismi di verificare come l'organizzazione gestisce la sicurezza delle infrastrutture, comprese quelle cloud o in data center di terzi, e considera i certificati accreditati in ambito EA/MLA dei fornitori una presunzione di conformità; altrimenti l'organismo deve sottoporre ad audit il sito.
• Non applicabile, siamo piccoli. La dimensione non è una motivazione: lo è il rischio.
• Non applicabile senza altro testo. Un'esclusione senza ragione è una lacuna, non una scelta.

Un esempio: la riga sulle vulnerabilità tecniche

La circolare Accredia cita espressamente il controllo A.8.8, insieme ai punti 6.1.2 e 8.2: l'organismo di certificazione deve accertare se l'organizzazione si sottopone periodicamente a vulnerability assessment o penetration test in base al livello di rischio, valutare la frequenza e verificare le registrazioni sulla qualifica di chi li esegue e sulle azioni prese. Una riga di SoA coerente con questa verifica può essere scritta così:

• Controllo: A.8.8, il controllo sulle vulnerabilità tecniche.
• Applicabile: sì.
• Motivazione: rischi del registro sui sistemi esposti su internet; clausola di sicurezza nei contratti con i clienti.
• Stato: attuato.
• Evidenze: procedura di gestione delle vulnerabilità; report delle scansioni periodiche; rapporto dell'ultimo penetration test con qualifica del fornitore; registro delle azioni correttive.
• Responsabile: IT manager.

I riferimenti alla procedura e ai report sono ipotetici, ma la logica è quella che l'auditor segue: dalla riga della SoA alla procedura, dalla procedura alle registrazioni.

Gli errori che vediamo più spesso

• SoA scritta prima della valutazione del rischio. Si parte dall'Appendice A e si spunta. Il risultato non si riesce a ricondurre al registro dei rischi.
• Tutto applicabile, tutto attuato. Una SoA senza esclusioni e senza controlli in corso è raramente credibile, soprattutto al primo ciclo.
• Stato di attuazione dichiarato senza evidenze. L'auditor chiederà di vedere il controllo funzionare, non la procedura che lo descrive.
• Revisione ferma. Il perimetro è cambiato, la SoA no, e lo scopo del certificato cita una revisione che non descrive più l'azienda.
• Copiata da un modello. Le motivazioni generiche si riconoscono subito, perché non citano nessun rischio dell'azienda.

SoA e NIS2: un ponte, non un'equivalenza

Chi rientra nella NIS2 spesso usa la SoA come base per mappare le misure richieste. ENISA ha pubblicato una tabella di corrispondenza fra i requisiti del Regolamento di esecuzione (UE) 2024/2690 e diversi standard, fra cui la ISO 27001:2022: il quadro di gestione del rischio, per esempio, è mappato anche sul punto 6.1.3. La stessa ENISA avverte che la tabella non va letta come misura di equivalenza fra standard. La SoA aiuta a trovare le sovrapposizioni, non certifica la conformità a un'altra norma.

In sintesi

La SoA ISO 27001 è la traduzione della valutazione del rischio in controlli: per ogni voce dell'Appendice A dice se si applica, perché, a che punto è e dove sta la prova. Si scrive dopo il registro dei rischi, si approva, si numera e si data, perché la sua revisione entra nello scopo del certificato. Se la stai preparando partendo da zero, una gap analysis ISO 27001 ne fornisce la base; il percorso completo è in come ottenere la certificazione ISO 27001 e il quadro della norma nella guida completa alla ISO 27001.

Se vuoi costruire la Dichiarazione di Applicabilità sui rischi reali della tua azienda, o rivedere quella che hai prima dell'audit, puoi vedere come lavoriamo sul percorso ISO 27001.