Se stai cercando come compilare lo Statement of Applicability (SoA) ISO 27001, hai già fatto il primo passo verso la certificazione del tuo Sistema di Gestione della Sicurezza delle Informazioni (SGSI). Lo SoA non è un semplice modulo burocratico: è il documento strategico che dimostra come l’organizzazione applica i controlli di sicurezza, fornendo trasparenza e tracciabilità verso auditor e stakeholder.

Spesso confuso con l’Annex A, lo Statement of Applicability (SoA) ISO 27001 ha un ruolo distinto: dichiara quali controlli sono applicabili, quali sono esclusi e perché. Senza una SoA chiara, anche il miglior Risk Assessment rischia di rimanere teorico. Per questo motivo, la compilazione richiede una strategia precisa, che parte dall’analisi dei rischi e arriva alla documentazione formale.

In questa guida pratica alla compilazione dello Statement of Applicability, analizzeremo passo dopo passo come:

• Interpretare i requisiti dell’Annex A ISO 27001.
• Collegare i controlli ai rischi identificati nel tuo business.
• Giustificare correttamente l’inclusione o l’esclusione dei controlli.
• Creare un template efficace per la SoA (non solo un foglio Excel, ma un documento vivente).

CTA Soft: Se non sai da dove iniziare, scarica il nostro Template Statement of Applicability Excel personalizzabile gratuito per avere subito una struttura pronta all’uso.

Seguimi in questo percorso: la compliance ISO 27001 parte da qui.

Introduzione al Statement of Applicability (SoA): La Bussola della Sicurezza

Immaginate di dover navigare un labirinto complesso senza una mappa. Questo è esattamente ciò che accade a molte organizzazioni quando si affrontano gli standard di sicurezza informatica. Le norme tecniche, come l’ISO 27001, sono piene di controlli, ma non è sempre chiaro quali applicare e come farlo in modo efficace. Qui entra in gioco lo Statement of Applicability (SoA), un documento che agisce come una vera e propria bussola per la vostra sicurezza informatica.

Lo SoA è una dichiarazione fondamentale, spesso un allegato obbligatorio del certificato di compliance, che elenca in modo trasparente quali controlli di sicurezza avete deciso di implementare e perché. Non si tratta di una semplice lista di controllo da spuntare: è la dimostrazione documentale di come la vostra organizzazione ha analizzato i rischi e ha scelto le contromisure più adatte al proprio contesto unico. In questo documento, si fa chiarezza su ogni controllo presente nell’Allegato A della norma ISO 27001, motivando ogni scelta.

Affidarsi allo Statement of Applicability non significa solo rispettare un obbligo normativo. È uno strumento strategico che orienta le risorse, definisce le priorità e fornisce una visione chiara del vostro impianto di sicurezza. Una SoA ben strutturata non solo agevolata l’iter di certificazione, ma diventa un punto di riferimento costante per il management, gli auditor interni ed esterni, facilitando la comunicazione e la comprensione del vostro sistema di gestione della sicurezza delle informazioni (SGSI).

In questa guida pratica, vi accompagneremo passo dopo passo nella compilazione del vostro Statement of Applicability, trasformando un requisito complesso in un processo gestibile e strategico.

Cos’è esattamente il Statement of Applicability secondo l’ISO 27001?

Cos’è esattamente il Statement of Applicability secondo l’ISO 27001?

Il Statement of Applicability (SoA) è il documento strategico centrale che descrive come un’organizzazione implementa la sicurezza delle informazioni. È uno dei requisiti chiave dello standard ISO 27001 e funge da “ponte” tra l’analisi dei rischi e l’applicazione concreta dei controlli di sicurezza.

Il SoA elenca tutti i 93 controlli di sicurezza contenuti nell’Allegato A dello standard (ISO/IEC 27001:2022). Per ciascun controllo, l’organizzazione deve dichiarare esplicitamente se:

• è applicabile (e quindi deve essere implementato);
• non è applicabile (motivando la decisione in modo documentato);
• è parzialmente applicabile (specificando le parti implementate).

Non è un semplice elenco. È la dimostrazione pratica di come l’azienda ha tradotto l’output dell’Analisi dei Rischio (e dei vincoli normativi) in un piano di controllo mirato. La non applicabilità di un controllo non è una scelta liberale, ma una decisione che deve essere supportata da un’adeguata valutazione del rischio, garantendo che i residuali rischi accettati siano formalmente registrati.

Perché il SoA è il documento più critico del tuo Sistema di Gestione della Sicurezza delle Informazioni (SGSI)

Perché il SoA è il documento più critico del tuo Sistema di Gestione della Sicurezza delle Informazioni (SGSI)

Il Statement of Applicability (SoA) non è un semplice elenco. È il documento di governance centrale del tuo Sistema di Gestione della Sicurezza delle Informazioni (SGSI) e la prova tangibile del tuo approccio al rischio. Inserisce il tuo piano di sicurezza in una cornice logica e normativa, dimostrando come le scelte effettuate siano state prese su solide basi di analisi del rischio.

Perché è così critico? Perché è il documento che collega il teorico al pratico. Traccia una linea diretta dalla valutazione del rischio, attraverso la selezione degli obiettivi di controllo, fino all’implementazione operativa dei controlli selezionati (sia tecnici, organizzativi che procedurali). Senza un SoA accurato, la tua dichiarazione di conformità al management e agli auditor è debole e poco credibile.

Requisiti Normativi: Cosa Dice Effettivamente l’ISO 27001

Requisiti Normativi: Cosa Dice Effettivamente l’ISO 27001

L’ISO 27001 non è un semplice elenco di best practice, ma uno standard di gestione formale. Il cuore del sistema è il Sistema di Gestione per la Sicurezza delle Informazioni (SGSI). La norma impone che questo sistema sia integrato nei processi aziendali e gestito in modo da garantire la sicurezza continua delle informazioni. Il fulcro del processo risiede nell’approccio basato sul rischio (clausola 6.1), che richiede di identificare i rischi specifici per l’organizzazione, valutarli e trattarli attraverso controlli mirati. È un requisito fondamentale che vincola l’azienda a non adottare misure di sicurezza generiche, ma a selezionarle in base al contesto operativo.

A livello di documentazione, la norma definisce un set minimo di documenti obbligatori. Tra questi figurano il campo di applicazione del SGSI, la politica per la sicurezza delle informazioni, il processo di valutazione e trattamento del rischio, e l’elenco degli obiettivi di sicurezza. Inoltre, l’organizzazione deve dimostrare l’esistenza di procedure operative, come la gestione degli incidenti di sicurezza e le regole di gestione delle modifiche. Non si tratta di carta per carta, ma di evidenze che il sistema è attivo e funzionante. Un documento spesso frainteso è la Statement of Applicability (SoA): l’ISO 27001 (clausola 6.1.3) richiede esplicitamente di documentare quali controlli dell’Allegato A sono applicabili e perché. La SoA diventa quindi un documento strategico che giustifica le scelte fatte, evidenziando i controlli applicati, esclusi (con motivazione) o parzialmente applicati.

L’approccio per processi è centrale: la norma richiede che il SGSI sia gestito attraverso il ciclo PDCA (Plan-Do-Check-Act). In particolare, la fase di “Check” (clausola 9) impone l’attuazione di misure di monitoraggio, misurazione, analisi e valutazione, incluse le revisioni di management programmate. Il riesame della direzione deve verificare l’adeguatezza, l’efficacia e la congruenza delle misure di sicurezza rispetto agli obiettivi aziendali. La conformità richiede non solo l’implementazione, ma anche la capacità di dimostrare, in sede di audit, che i processi sono pianificati, eseguiti, controllati e migliorati in modo continuativo, garantendo così la resilienza dell’organizzazione verso le minacce informatiche.

Analisi della clausola 6.1.3: Obblighi formali di redazione

Analisi della clausola 6.1.3: Obblighi formali di redazione

La clausola 6.1.3 della norma ISO 27001 impone formalmente la redazione del SoA. Non si tratta di una libera scelta, ma di un obbligo documentale che costituisce il fondamento del sistema di gestione della sicurezza delle informazioni. Il documento deve essere creato e approvato dalla direzione, definendo chiaramente quali controlli di sicurezza (definiti nell’Allegato A) sono applicabili all’organizzazione, quali non lo sono e per quali motivi.

Questo obbligo formale si traduce in un processo strutturato. La redazione del SoA non può essere un semplice elenco di spunta: richiede un’analisi approfondita dei rischi identificati nella fase di valutazione del rischio (clausola 6.1.2) e delle decisioni di trattamento dei rischi. Ogni controllo richiamato deve essere giustificato in modo esplicito, collegando l’implementazione del controllo alla mitigazione di un rischio specifico.

Il SoA deve inoltre indicare lo stato di implementazione di ciascun controllo (es. “implementato”, “in corso di implementazione”) e, se applicabile, evidenziare eventuali esclusioni parziali. Questo livello di dettaglio è cruciale per dimostrare la conformità durante le audit di certificazione. La mancata redazione del SoA o la sua compilazione superficiale costituisce un non-conformità grave, poiché priva il sistema del necessario riferimento centrale per la coerenza delle misure di sicurezza adottate.

La relazione tra SoA, Risk Treatment Plan (RTP) e Catalogo dei Controlli (Annex A)

Il Statement of Applicability (SoA) non è un documento isolato, ma è il fulcro di un sistema integrato di gestione della sicurezza delle informazioni. La sua corretta compilazione presuppone e richiede un allineamento preciso con altri due documenti chiave del processo di certificazione: il Risk Treatment Plan (RTP) e il Catalogo dei Controlli (Allegato A della norma ISO 27001).

Il punto di partenza è il Risk Treatment Plan (RTP). Questo documento, elaborato a seguito della valutazione del rischio, definisce le strategie scelte per trattare i rischi identificati: accettazione, mitigazione, trasferimento o evitamento. È nel RTP che si stabilisce quali controlli implementare, modificare o escludere. Il SoA agisce quindi come “specchio” operativo del RTP: per ogni controllo presente nell’Allegato A che è stato selezionato per il trattamento del rischio, il SoA deve documentare esplicitamente se il controllo è applicabile, in che misura è implementato e la giustificazione della scelta.

L’Allegato A (Catalogo dei Controlli) fornisce l’elenco completo dei 114 controlli di sicurezza. Il SoA non si limita a elencare i controlli applicabili, ma li organizza in modo strategico, collegandoli ai rischi specifici dell’organizzazione. In sintesi: il RTP decide “cosa” fare per mitigare i rischi; il SoA documenta “come” si applicano i controlli scelti in relazione a quei rischi; l’Allegato A fornisce il vocabolario standard dei controlli. Mantenere questa relazione coerente è fondamentale non solo per superare l’audit, ma per garantire che la sicurezza informatica sia una pratica gestita, tracciabile e continua.

Preparazione Preliminare: Gli Step Fondamentali Prima di Scrivere

La compilazione dello Statement of Applicability (SoA) è il cuore del sistema di gestione della sicurezza delle informazioni (SGSI) basato su ISO 27001. Non si tratta di un semplice modulo da compilare, ma di un documento strategico che attesta il perimetro di sicurezza dell’organizzazione.

Tuttavia, molti professionisti commettono l’errore di iniziare la stesura senza una preparazione adeguata, portando a documenti incompleti, incongruenti con la realtà operativa o, peggio, non conformi allo standard.

Questo approfondimento si concentra sugli step preliminari fondamentali che precedono l’effettiva compilazione della tabella SoA.

L’importanza di una preparazione strutturata

Salta questo passaggio e ti ritroverai a redigere il SoA “alla cieca”, ovvero senza un quadro chiaro dei tuoi asset, delle tue minacce e del tuo profilo di rischio.

Il SoA deve rispondere a due domande fondamentali: quali controlli applichiamo e perché?

Per rispondere correttamente, è necessario disporre di dati certi e verificati.

Step 1: Revisione del contesto organizzativo e degli asset

Il punto di partenza assoluto è definire chiaramente l’ambito di applicazione del sistema di gestione.

Azione pratica: Esegui un censimento completo degli asset informativi (hardware, software, persone, dati, locali) che rientrano nell’ambito certificato.

Non devi conoscere ogni singolo file, ma devi avere una mappatura chiara dei processi critici e delle informazioni che trattano.

Checklist operativa:

• Identificazione asset: Elenca i server, le postazioni, le applicazioni cloud, i database e i dispositivi mobili.
• Proprietari degli asset: Assegna un proprietario responsabile per ogni categoria di asset (es. “Responsabile IT” per i server, “Responsabile HR” per i dati dei dipendenti).
• Valore degli asset: Assegna un livello di criticità (es. Alta, Media, Bassa) in base all’impatto che la perdita di riservatezza, integrità o disponibilità avrebbe sull’organizzazione.

Senza questa mappatura, non potrai giustificare l’applicazione (o l’esclusione) dei controlli ISO 27001 in modo pertinente.

Step 2: Analisi dei rischi (Risk Assessment)

ISO 27001 richiede un approccio basato sul rischio. Lo SoA è il risultato diretto di questo processo.

Prima di aprire il template del SoA, devi aver completato l’analisi dei rischi secondo il processo A.5 (come definito in ISO 27001:2022).

Cosa devi aver già fatto:

1. Identificazione delle minacce: Quali eventi negativi potrebbero verificarsi? (es. Ransomware, guasto hardware, accesso non autorizzato).
2. Valutazione del rischio: Calcolare il livello di rischio (Probabilità x Impatto) per ogni minaccia sugli asset identificati.
3. Decisione del trattamento del rischio: Per ogni rischio accettabile, devi decidere se:
   • Ridurre: Applicando un controllo ISO 27001 (questo finirà nel SoA come “Applicato”).
   • Accettare: Rischio accettato formalmente (nessun controllo aggiuntivo necessario).
   • Trasferire: Assicurazione o outsourcing (il controllo potrebbe essere gestito dal fornitore).
   • Evitare: Cessazione dell’attività a rischio.

Consiglio concreto: Utilizza un foglio di calcolo dedicato per tracciare il collegamento tra Asset -> Minaccia -> Rischio -> Trattamento -> Controllo ISO 27001. Questo ti servirà come “evidenza” durante l’audit.

Step 3: Studio approfondito di Annex A (ISO 27001:2022)

L’ultima edizione dello standard ha riorganizzato i controlli in 4 tematiche e 93 controlli. Non è possibile selezionare i controlli a memoria.

Azione pratica: Leggi ogni controllo dell’Annex A e chiediti: “Questo controllo mitiga uno dei rischi che abbiamo identificato nello step 2?”.

Errore da evitare: Applicare i controlli “perché sono obbligatori”. In realtà, ISO 27001 è flessibile. Se un rischio non esiste nel tuo contesto, non sei obbligato a implementare il controllo corrispondente (ma devi giustificarlo nel SoA).

Step 4: Identificazione dei requisiti legali e contrattuali

Alcuni controlli diventano obbligatori non per l’analisi dei rischi interni, ma per legge o per contratto.

Preparazione necessaria:

• Identifica tutte le normative applicabili (GDPR, NIS2, settoriali) e i requisiti contrattuali con clienti o fornitori.
• Verifica se questi requisiti impongono specifici controlli tecnici o organizzativi che devono essere inclusi nel SoA come “Applicati”.

Ad esempio, se tratti dati personali di cittadini UE, il controllo A.5.28 (Privacy e protezione dei dati personali) sarà quasi certamente applicato per obbligo legale.

Step 5: Preparazione degli input documentali

Il SoA non si scrive nel vuoto. Prima di compilare la tabella, assicurati di avere i seguenti documenti pronti e aggiornati:

• Scope del SGSI: Definisce chiaramente cosa è incluso e cosa escluso dalla certificazione.
• Analisi dei rischi (Risk Register): Il registro completo dei rischi identificati.
• Matrix di trattamento dei rischi: Documento che mostra le decisioni prese per ogni rischio.
• Politica di sicurezza: Documento che stabilisce le regole generali.

Avere questi documenti a portata di mano ti permetterà di compilare il SoA in modo coerente e tracciabile.

Checklist di verifica finale (Prima di iniziare)

Prima di aprire il foglio di calcolo del SoA, rispondi a queste domande. Se la risposta è “No” a una di queste, fermati e completa la preparazione:

1. Ho una lista chiara e completa degli asset inclusi nello scope?
2. Ho completato l’analisi dei rischi formale (identificazione e valutazione)?
3. Ho preso decisioni formali su come trattare ogni rischio identificato?
4. Ho studiato tutti i 93 controlli dell’Annex A ISO 27001:2022?
5. Ho identificato tutti i requisiti legali e contrattuali applicabili?

Se hai risposto “Sì” a tutto, sei pronto a procedere con la compilazione effettiva dello Statement of Applicability. Questa preparazione ti farà risparmiare ore di lavoro durante la stesura e ti posizionerà per un audit di certificazione di successo.

Il processo di valutazione del rischio: Il motore del tuo SoA

Il processo di valutazione del rischio: Il motore del tuo SoA

Il Statement of Applicability (SoA) non nasce nel vuoto: la sua validità dipende interamente da un processo di valutazione del rischio solido e documentato. È il motore che alimenta ogni decisione su quali controlli applicare. Senza una valutazione accurata, il SoA diventa un mero elenco di misure generiche, spesso inefficaci o superflue.

L’ISO 27001 richiede di identificare i rischi che minacciano le attività aziendali (come la perdita di dati clienti, il blocco dei servizi o la violazione della riservatezza). Per ogni rischio identificato, si valuta la probabilità di accadimento e l’impatto potenziale. Solo analizzando questo quadro si può decidere se un controllo è necessario, opportuno o non applicabile. Questo approccio basato sul rischio garantisce che gli sforzi di sicurezza siano concentrati lì dove il valore è maggiore, ottimizzando risorse e garantendo una protezione reale.

Proprio per questo motivo, la norma richiede che il processo sia documentato. La tracciabilità tra rischio identificato e controllo applicato nel SoA è essenziale per superare le verifiche di certificazione e per dimostrare una gestione della sicurezza efficace e consapevole.

Identificazione dei requisiti legali e regolamentari (GDPR, NIS2, ecc.)

L’identificazione dei requisiti legali e regolamentari è un pilastro fondamentale per la compilazione della SoA. È il processo attraverso cui l’organizzazione mappa le normative esterne sui controlli di sicurezza, definendo così l’ambito di applicazione del sistema di gestione. Questo esercizio non è solo una formalità, ma un’attività proattiva di due diligence e di mitigazione del rischio.

Le fonti normative da considerare sono molteplici. Il GDPR impone controlli specifici sulla protezione dei dati personali, che devono riflettersi nella SoA (es. crittografia, gestione degli incidenti). Il NIS2 (Direttiva Europea sulla sicurezza delle reti e dei sistemi informativi) definisce requisiti stringenti per le entità critiche, inclusi obblighi di notifica e misure di sicurezza avanzate. Altre normative settoriali come il DORA per il settore finanziario o specifiche leggi nazionali possono aggiungere ulteriori requisiti.

Per una compilazione efficace, consigliamo di seguire un approccio strutturato:

• Mappatura: Crea un registro che elenchi ogni obbligo normativo.
• Analisi del Gap: Confronta i requisiti con i controlli già implementati.
• Attribuzione: Collega ogni requisito legale ai controlli ISO 27001 applicabili nella SoA.
• Revisione: Aggiorna periodicamente il registro al mutare della normativa.

Un approccio integrato garantisce che la SoA non sia solo un documento, ma uno strumento vivo di governance del rischio.

Definizione del contesto organizzativo e dei requisiti di business

Definizione del contesto organizzativo e dei requisiti di business

Prima di compilare il Statement of Applicability (SoA) per l’ISO 27001, è fondamentale delineare il contesto operativo e le pressioni di business che guidano il Sistema di Gestione della Sicurezza delle Informazioni (SGSI). Questo processo inizia con una mappatura approfondita delle parti interessate (internamente: dipendenti, management; esternamente: clienti, fornitori, autorità regolatorie) e con l’analisi delle esigenze e aspettative di ciascuna, specialmente in termini di sicurezza dei dati e continuità operativa. Parallelamente, va definita la mappa dei processi aziendali critici (es. gestione pagamenti, sviluppo software, HR) e dei relativi asset informativi, identificando quelli classificati come critici.

Dovrai anche documentare i driver di business (es. obblighi contrattuali con clienti, riduzione dei costi degli incidenti di sicurezza) e, soprattutto, i requisiti normativi e di compliance. È qui che si intersecano i requisiti ISO 27001 con altri framework (come GDPR o NIS2) e le specifiche richieste dei clienti o di settori regolamentati (es. sanitario, finanziario). Per questa analisi contestuale, una Valutazione del Rischio ISO 27001 completa è indispensabile: ti invito a richiedere un preventivo personalizzato per eseguirla correttamente, così da assicurare che ogni controllo nel tuo SoA sia giustificato dalla tua realtà aziendale.

La Struttura del Statement of Applicability: Template e Campi Obbligatori

La Struttura del Statement of Applicability: Template e Campi Obbligatori

Il Statement of Applicability (SoA) non è un semplice elenco, ma un documento strategico e operativo che deve essere chiaro, verificabile e coerente con il contesto aziendale. Per essere efficace, deve presentare una struttura logica che permetta a auditor, certificatori e stakeholders interni di comprendere immediatamente quali controlli sono stati selezionati, perché e come vengono implementati. Non esiste un template ufficiale imposto da ISO 27001, ma la norma fornisce indicazioni precise sui contenuti minimi indispensabili. Di seguito, analizziamo la struttura tipica e i campi obbligatori per un SoA solido.

Struttura il tuo SoA in modo rapido e conforme

Non partire da zero: utilizza il nostro template Excel per il Statement of Applicability già strutturato secondo i requisiti ISO 27001, con campi precompilati per l’elenco dei controlli Annex A, la justificazione e lo stato di implementazione.

Scarica il Template SoA (Excel)

Componenti fondamentali del documento

Un Statement of Applicability ben strutturato comprende solitamente le seguenti sezioni chiave:

• Intestazione e metadata: versione del documento, data di approvazione, responsabile della redazione, riferimento al contesto dell’organizzazione e agli obiettivi di sicurezza.
• Elenco dei controlli Annex A (da 5.1 a 18.1): l’elenco completo dei 93 controlli (secondo l’ISO/IEC 27001:2022) suddivisi per famiglia.
• Columna “Applicabilità” (Si/No/Parziale): indica se il controllo è applicabile al contesto specifico.
• Justificazione (Motivazione): il cuore del SoA. Spiega perché un controllo è stato selezionato o escluso.
• Collegamento al Risk Treatment Plan (RTP): riferimento al piano di trattamento del rischio associato.
• Stato di implementazione: descrizione del livello di implementazione (es. “Da implementare”, “In corso”, “Completato”).
• Evidenze o referenze documentali: riferimento a procedure, policy o registri che dimostrano l’applicazione del controllo.

Guida pratica ai campi obbligatori del template

Sebbene l’ISO 27001 non imponga un formato specifico, i campi che segue sono considerati essenziali per superare un audit di certificazione e garantire trasparenza. Ecco come compilarli:

1. Codice e Titolo del Controllo

Ad ogni controllo dell’Annex A deve corrispondere una riga nel tuo SoA. È buona norma mantenere la numerazione originale della norma (es. 5.1, 5.2… 18.1) per facilitare il riferimento durante l’audit.

2. Applicabilità (Si/No)

Questa colonna è spesso fonte di errore. Un controllo non è “non applicabile” solo perché l’azienda è piccola. Ad esempio, il controllo 5.1 (Politiche di sicurezza) è sempre applicabile. Un controllo come 8.26 (Applicazione delle patched di sicurezza) potrebbe essere considerato “non applicabile” solo se un’organizzazione non utilizza alcun software o sistema IT, scenario quasi impossibile oggi. La non applicabilità va sempre giustificata.

3. Giustificazione (Motivazione)

Questo è il campo più critico. Deve essere conciso ma esaustivo.

• Se “Si”: Spiega come il controllo è implementato. Ad esempio: “Il controllo 7.3 (Sicurezza delle attrezzature) è applicabile perché tutte le postazioni lavoro sono soggette a politiche di device management e controllo fisico degli accessi, come descritto nella Policy 01/2025.”
• Se “No”: Spiega perché è stato escluso. Ad esempio: “Il controllo 8.12 (Protezione contro il codice malevolo nelle reti) è considerato non applicabile in quanto l’organizzazione non gestisce infrastrutture di rete periferiche o datacenter proprietari, affidandosi interamente a servizi cloud IaaS/PaaS già dotati di protezioni native. Il rischio residuo è trasferito al fornitore cloud.”

Attenzione: La giustificazione non deve essere generica come “non rilevante per il nostro business”. Deve dimostrare un’analisi di rischio contestuale.

4. Stato di Implementazione

Questa colonna monitora l’avanzamento del Risk Treatment Plan. Può essere una semplice checklist o una descrizione testuale. È utile per gestire i progetti di compliance nel tempo.

• Implementato: Il controllo è operativo e sono disponibili evidenze (registri, report, policy firmate).
• Parzialmente Implementato: Alcuni elementi del controllo sono attivi, altri sono in corso di definizione.
• Da Implementare: Il controllo è selezionato ma non ancora attivato (tipicamente legato a progetti futuri nel RTP).

5. Evidenze e Documenti di Riferimento

Il SoA non deve contenere i documenti allegati, ma deve fungere da indice. Indicare il nome del documento o il codice identificativo (es. “Policy di Sicurezza Informatica v.2.0”, “Registro dei Controlli di Accesso Logico”, “Report di Vulnerability Assessment Q1”). Questo campo facilita enormemente il lavoro dell’auditor, che può richiedere l’evidenza in fase di verifica.

Esempio visivo di estratto SoA

Codice (A.5 – A.18)	Titolo Controllo	Applicabilità	Giustificazione	Stato	Evidenza/Ref.
5.1	Politiche di sicurezza	SI	Requisito fondamentale. Policy firmata dal management e comunicata a tutti i dipendenti.	Implementato	Policy 01_2025.pdf
8.1	Strategia di gestione delle reti	NO	L’organizzazione non gestisce reti interne dedicate. Tutte le reti sono fornite da ISP gestiti.	N/A	–
12.1	Documentazione delle procedure di gestione degli incidenti	SI	Procedure definite e documentate nel manuale di sicurezza.	Implementato	Manuale Sicurezza Cap. 5

La relazione con il Risk Treatment Plan (RTP)

Il SoA e il RTP sono documenti gemelli ma distinti. Il RTP elenca i rischi accettati, trasferiti, mitigati o evasi. Il SoA deriva da questo processo, ma si focalizza specificamente sui controlli tecnici e organizzativi. In una struttura integrata, spesso si utilizza un unico foglio di calcolo Excel con due schede principali: una per l’analisi dei rischi (che porta al RTP) e una per il SoA, dove la colonna “Giustificazione” richiama direttamente la decisione presa nel RTP. Questo assicura coerenza logica e facilita la manutenzione periodica.

Common pitfalls (Errori comuni) da evitare

• Copy-paste della giustificazione: Usare la stessa motivazione per controlli diversi è un segnale di mancata analisi contestuale.
• Mancata revisione del SoA: Il SoA è vivo. Va revisionato annualmente o ogni volta che cambia il contesto organizzativo (es. adozione di un nuovo cloud provider, ingresso nel mercato NIS2).
• Omettere i controlli “di gestione”: Spesso le aziende si concentrano sugli aspetti tecnici (A.8) trascurando i controlli organizzativi (A.5) o sulle persone (A.7), che sono ugualmente obbligatori se applicabili.

Hai dubbi su quali controlli applicare nel tuo SoA?

La valutazione di applicabilità dipende fortemente dal tuo settore e dai rischi specifici. Se sei in dubbio su come giustificare l’esclusione di alcuni controlli o se devi preparare il SoA per una certificazione imminente, effettua un mini-assessment gratuito con i nostri esperti.

Richiedi un Assessment Rapido

Checklist di verifica finale

Prima di firmare il documento, verifica che il tuo Statement of Applicability contenga:

• ☑ Tutti i 93 controlli dell’Annex A (ISO/IEC 27001:2022) elencati, anche se solo come riferimento.
• ☑ Una decisione esplicita (Si/No) per ogni controllo.
• ☑ Una giustificazione scritta che regge l’esame di un auditor esterno.
• ☑ Il riferimento al Risk Treatment Plan.
• ☑ La data di revisione e la versione del documento.

Un SoA ben fatto è la dimostrazione tangibile che la tua organizzazione ha internalizzato il processo di sicurezza informatica, trasformando la conformità normativa in un reale strumento di gestione del rischio.

Sei pronto per certificarti o devi aggiornare il tuo SoA?

Il tuo Statement of Applicability deve essere preciso, giustificato e pronto per l’audit. Non rischiare finding negativi o ritardi nella certificazione.

• ✅ Verifica del SoA esistente e identificazione delle criticità.
• ✅ Riesame completo dei controlli Annex A in base alla nuova versione ISO 27001:2022.
• ✅ Redazione o revisione del SoA integrata con il Risk Treatment Plan.

Prenota una Consulenza con un Esperto ISO 27001

Riepilogo

La struttura del Statement of Applicability deve essere chiara, logica e leggibile. Utilizzare un template Excel dedicato è la soluzione migliore per garantire completezza e facilitare la manutenzione nel tempo. I campi obbligatori sono la giustificazione dell’applicabilità e il collegamento con il rischio trattato. Investire tempo nella stesura corretta del SoA paga dividendi non solo in audit, ma nella gestione quotidiana della sicurezza.

Intestazione e metadati: Versione, data, riferimenti normativi

Intestazione e metadati: Versione, data, riferimenti normativi

Per garantire tracciabilità e controllo versionale, ogni Statement of Applicability (SoA) deve includere un’intestazione formale che specifichi:

• Versione del documento: utilizzare un numerazione progressiva (es. 1.0, 1.1) che rifletta aggiornamenti significativi (es. revisione annuale, nuovi requisiti normativi, risultati di audit).
• Data di emissione: indicare la data di creazione o ultima revisione (formato AAAA-MM-DD) per sincronizzare il SoA con il ciclo di vita del Sistema di Gestione della Sicurezza delle Informazioni (SGSI).
• Riferimenti normativi: citare esplicitamente l’ISO/IEC 27001:2022, la versione dell’Annex A e le eventuali normative di settore applicabili (es. NIS2, GDPR, ISO 27002:2022 per l’interpretazione dei controlli).

Questa sezione preliminare, sebbene tecnica, è fondamentale per l’allineamento con gli auditor e per la corretta governance documentale dell’organizzazione.

Tabella dei controlli: Colonne essenziali (ID, Descrizione, Stato Applicabilità)

La struttura della tabella dei controlli nella Statement of Applicability (SoA) è il cuore operativo del documento. Per rendere la SoA uno strumento di lavoro efficace e non solo un mero allegato formale, è fondamentale definire con precisione le colonne.

Di seguito le colonne essenziali e il loro significato pratico:

Tabella dei controlli: Colonne essenziali della SoA

ID Controllo	Descrizione (Sintetica)	Stato Applicabilità
5.4	Responsabilità per le risorse di elaborazione (Controllo organizzativo – Top management)	Applicato Responsabilità delegate al CTO e Head of IT.
A.8.1	Inventario degli asset (Controllo sul gestione degli asset)	Applicato Inventario gestito via CMDB/Gestione Asset.
9.4.2	Riservatezza dei registri di audit (Controllo sul sistema di gestione della sicurezza)	Non Applicabile (N/A) Non eseguiamo audit interni su questo processo.
A.14.2.1	Progettazione sicura delle applicazioni (Sviluppo e manutenzione sicura)	Non Implementato (NI) In fase di implementazione per l’anno fiscale corrente.

Note operative per la compilazione:

• ID Controllo: Si consiglia di mantenere la numerazione originale della norma (es. ISO 27001:2022) per evitare incongruenze durante gli audit.
• Descrizione: Deve essere breve ma chiara. Se necessario, aggiungi una specifica tra parentesi per contestualizzare il controllo alla tua realtà aziendale.
• Stato Applicabilità: È la colonna decisionale. Definisci chiaramente se il controllo è:
  • Applicato (A): Già implementato e operativo.
  • Non Applicabile (N/A): Giustificazione fondata su analisi di rischio o contesto aziendale (es. nessuna energia idroelettrica in sede).
  • Non Implementato (NI): Rischio accettato momentaneamente o piano di implementazione futura.

Una tabella strutturata correttamente permette di tracciare lo stato di conformità e giustificare ogni scelta durante una revisione della direzione o un audit di certificazione.

Sezione ‘Esclusioni’: Come giustificare il Non Applicabile (N/A)

Il Statement of Applicability (SoA) richiede chiarezza assoluta. Le voci marcate come “Non Applicabile” (N/A) sono spesso sottoposte a scrutinio da parte degli auditor.

Per giustificare correttamente un’esclusione, segui questi step operativi:

• Identifica la motivazione tecnica o organizzativa: L’installazione non è fisicamente possibile? Il rischio è stato trasferito contrattualmente? Oppure è stato mitigato tramite un controllo non previsto dalla norma?
• Evita giustificazioni basate sul “costo”: La norma ISO 27001 non richiede l’adozione di controlli eccessivamente costosi, ma impone di documentare il rischio residuo. Non scrivere “troppo costoso”, ma “il controllo non è stato implementato perché il rischio è stato accettato formalmente tramite Risk Treatment Plan” (purché l’analisi dei rischi lo supporti).
• Dettaglia nel SoA: Inserisci una colonna dedicata alle note (“Justification”).

Esempio pratico per la clausola 7.4 (Comunicazioni): Se i tuoi server sono ospitati in un data center di terze parti che gestisce le comunicazioni in entrata e in uscita, potresti dichiarare N/A il punto 7.4.1 (Reti di comunicazione), specificando che il controllo è delegato al fornitore e coperto dal controllo 15.1 (Responsabilità dei fornitori).

Scarica la nostra Checklist “Esclusioni SoA” per verificare se le tue giustificazioni resisteranno all’audit.

Se non sei sicuro che le tue esclusioni siano conformi, fai il nostro mini-assessment online e ottieni un feedback immediato sulla tua bozza di SoA.

Per una revisione professionista del tuo SoA da parte dei nostri esperti certificati, contattaci oggi stesso per una call di 15 minuti.

Colonna ‘Giustificazione’: Il cuore dell’auditabilità

Questa colonna è il fulcro dell’auditabilità. Per ogni controllo, la giustificazione deve esplicitare il ragionamento logico per cui è stato selezionato. Documenta l’analisi del rischio che ha portato a questa scelta, riferendosi al contesto specifico dell’organizzazione. È fondamentale evitare giustificazioni vaghe come “contesto aziendale” o “valutazione del rischio”. L’auditor verificherà proprio in questa colonna la coerenza tra la mappa dei rischi, i controlli implementati e la SoA.

Logica Decisionale: Applicabile, Non Applicabile o Parzialmente Applicabile?

Logica Decisionale: Applicabile, Non Applicabile o Parzialmente Applicabile?

La fase più delicata nella creazione del tuo Statement of Applicability (SoA) è proprio questa: decidere, per ogni controllo di sicurezza dell’Allegato A di ISO 27001, se il controllo è applicabile, non applicabile o parzialmente applicabile alla tua organizzazione. Una scelta sbagliata, infatti, non solo falsa l’intero Sistema di Gestione della Sicurezza delle Informazioni (SGSI), ma espone l’azienda a rischi non mitigati o, all’opposto, spreca risorse preziose su controlli superflui.

Per gestire questa complessità, la soluzione migliore non è affidarsi all’intuizione, ma adottare una struttura decisionale basata su criteri oggettivi e documentati. Ecco una guida pratica per orientarti tra queste tre categorie cruciali.

1. Applicabile: Quando e perché includere il controllo

Un controllo è considerato Applicabile quando è richiesto esplicitamente dalla norma ISO 27001 o quando risulta essenziale per la gestione efficace dei rischi identificati nel tuo Risk Assessment.

Criteri per la classificazione “Applicabile”:

• Requisito Normativo Diretto: La norma ISO 27001 stessa (clausola 6.1.3) richiede di selezionare i controlli dall’Allegato A. Se un controllo è obbligatorio per certificarti, è automaticamente applicabile. Ad esempio, l’A.5.1 Politiche di sicurezza è sempre applicabile perché la norma richiede esplicitamente la documentazione di una politica.
• Rischio Residuo Inaccettabile: Il tuo Risk Assessment ha evidenziato una vulnerabilità specifica (es. perdita di dati) e il controllo specifico è l’unica contromisura tecnica o organizzativa ragionevole per mitigare quel rischio a un livello accettabile.
• Requisiti Contrattuali o Legali: Clienti o leggi specifiche (es. GDPR per i dati personali) richiedono implementazioni specifiche che corrispondono a un controllo ISO.

Esempio Pratico:
Immagina un’azienda che gestisce dati personali dei dipendenti. Il controllo A.8.1 Gestione degli inventari degli asset è applicabile perché senza un inventario non puoi proteggere ciò che possiedi e violeresti il GDPR. Non puoi permetterti di saltarlo.

2. Non Applicabile: Quando escludere un controllo

Un controllo è Non Applicabile quando non esiste alcuna ragione logica, normativa o di rischio per implementarlo. Spesso questa categoria è la più contestata dagli auditor, quindi richiede una giustificazione inattaccabile.

Criteri per la classificazione “Non Applicabile”:

• Assenza totale di rischio correlato: Il rischio che il controllo dovrebbe mitigare non sussiste nell’ambito di applicazione del SGSI. Ad esempio, se la tua azienda non possiede nessun software proprietario o sviluppo interno, il controllo A.14.2 Sviluppo e manutenzione del software potrebbe non essere applicabile.
• Irrelevantza per la natura del business: Un’azienda puramente consulenziale che non produce beni fisici potrebbe giustificare la non applicabilità di controlli specifici sulla logistica o sulla produzione (es. A.8.1 Controllo dei beni mobili).
• Controllo superato dalla tecnologia: Se i tuoi sistemi sono interamente basati su Cloud PaaS/SaaS (es. Microsoft 365, Salesforce) gestiti da terze parti, alcuni controlli infrastrutturali (es. A.11.1 Sicurezza fisica degli edifici) potrebbero non essere applicabili direttamente alla tua organizzazione, ma trasferiti al provider.

Attenzione: L’assenza di applicabilità non può essere usata per giustificare la pigrizia o l’ignoranza di un rischio reale.

Esempio Pratico:
Un’azienda che utilizza esclusivamente dispositivi mobili gestiti (MDM) e non ha uffici fisici (lavoro 100% da remoto) potrebbe dichiarare non applicabile il controllo A.11.1.3 Dispositivi di sicurezza per la protezione degli edifici, giustificando la scelta con l’assenza di infrastrutture proprietarie.

3. Parzialmente Applicabile: Il caso complesso

Questa è spesso la categoria più difficile da gestire ma anche la più realistica. Un controllo è Parzialmente Applicabile quando una parte del controllo è rilevante per l’organizzazione, mentre un’altra parte non lo è.

Criteri per la classificazione “Parzialmente Applicabile”:

• Ambito geografico limitato: L’organizzazione ha sede in Italia e in Germania. La politica di backup potrebbe essere applicabile a entrambe, ma le misure di sicurezza fisica specifiche (es. sistemi antincendio) sono gestite solo dalla sede italiana, rendendo il controllo solo parzialmente applicabile alla totalità dell’organizzazione.
• Jerarchia o tipologia di asset: Il controllo A.9.4.1 Gestione degli accessi logici è applicabile a tutti gli utenti amministratori, ma parzialmente applicabile agli utenti standard (dove, ad esempio, l’autenticazione a più fattori non è richiesta per tutti i livelli di accesso).
• Implementazione graduale: Stai implementando un nuovo controllo di crittografia. Al momento è attivo solo su database critici, ma non su tutto l’archivio dati. È quindi parzialmente applicabile.

Documentazione fondamentale:
Quando scegli questa opzione, devi specificare dove e perché è parziale. Non basta scrivere “Parzialmente Applicabile”; devi aggiungere una nota che spieghi l’ambito di applicazione (es. “Applicabile solo ai server on-premise, non a quelli Cloud” oppure “Applicabile al reparto IT, non al reparto vendite”).

Esempio Pratico:
Il controllo A.12.1 Gestione delle incidenti di sicurezza è sempre applicabile, ma l’organizzazione potrebbe gestire gli incidenti di sicurezza informatica (applicabile) separatamente dagli incidenti di sicurezza fisica (non applicabile nella stessa procedura). Il controllo risulta quindi “Parzialmente Applicabile” se la procedura documentata copre solo gli incidenti informatici.

La Tabella di Decisione: Strumento di Lavoro

Per evitare errori, struttura la tua valutazione in una tabella a colonne. Non fidarti della memoria.

Controllo Allegato A	Scelta (Applicabile/No/Parz.)	Giustificazione	Note / Ambito
A.5.1 Politiche di sicurezza	Applicabile	Requisito diretto della norma ISO 27001. Necessario per governare il SGSI.	–
A.11.1 Sicurezza fisica degli edifici	Non Applicabile	L’organizzazione opera in modalità “Remote First” senza uffici proprietari.	Verificare se esistono server room condivisi.
A.9.4.3 Password system	Parzialmente Applicabile	Applicabile agli utenti interni. Non applicabile ai clienti esterni che accedono al portale self-service.	Vedi procedura “Gestione Accessi Clienti”.

Consigli Finali per la Compilazione

1. Mai lasciare vuoto il campo “Giustificazione”: L’auditor leggerà prima la giustificazione che il controllo stesso. Se la motivazione è debole (“non ne abbiamo bisogno”), preparati a ricevere una non-conformità.

2. Coerenza con il Risk Treatment Plan: La tua scelta nel SoA deve rispecchiare esattamente le decisioni prese nel piano di trattamento del rischio (il documento dove hai deciso cosa fare con ogni rischio).

3. La norma richiede la totalità, non la perfezione: ISO 27001 non richiede che tutti i controlli siano applicabili. Riconoscere onestamente che un controllo non è rilevante per la tua realtà è segno di maturità del sistema, purché la giustificazione sia solida.

Criteri per dichiarare un controllo ‘Applicabile’

Per dichiarare un controllo come Applicabile nella Statement of Applicability, il suo utilizzo deve essere necessario per soddisfare i requisiti di sicurezza delle informazioni del tuo Sistema di Gestione della Sicurezza delle Informazioni (SGSI). Tale necessità deve derivare sia da una valutazione dei rischi eseguita in modo formale, sia dalla volontà di aderire a requisiti normativi o contrattuali specifici.

Il criterio fondamentale è il rischio residuo: se la valutazione dei rischi ha identificato un rischio (minaccia, vulnerabilità, impatto) che il controllo mitiga o elimina, allora il controllo è Applicabile. Non è necessario che il controllo sia implementato in modo completo nella fase di definizione della SoA, ma è essenziale dichiararne l’applicabilità.

Un secondo criterio è la conformità obbligatoria. Se una legge, un regolamento (come il GDPR o la NIS2) o un contratto con un cliente impone specificamente quel controllo, questo va dichiarato Applicabile indipendentemente dal risultato della valutazione del rischio interno. In questo caso, il controllo è applicabile per obbligo esterno.

Infine, è Applicabile un controllo che implementi buone pratiche di settore o che è necessario per garantire la continuità operativa, anche se non derivante da un rischio specifico individuato nella valutazione. È importante fornire, per ogni controllo Applicabile, una breve giustificazione nella colonna “Commenti” della SoA, spiegando perché è stato scelto questo stato.

Quando e come dichiarare un controllo ‘Non Applicabile’ (N/A)

Quando dichiarare un controllo “Non Applicabile” (N/A)

La dicitura “Non Applicabile” (N/A) non è un esonero automatico. Si utilizza solo quando un controllo di Annex A non ha alcuna rilevanza per il perimetro e i rischi dell’Information Security Management System (ISMS) certificato. L’errore più comune è omettere controlli solo perché complessi da implementare, rendendo la SoA facilmente contestabile in audit.

Per dichiarare N/A un controllo, devi fornire una giustificazione documentata che dimostri l’inapplicabilità logica o fisica. Ecco gli scenari tipici:

• Assenza di asset fisici: Il controllo relativo alle installazioni sicure (es. A.11.1) è N/A se l’organizzazione opera esclusivamente con dispositivi mobili e cloud, senza uffici propri.
• Esternalizzazione totale: Controllo A.12.6 (Gestione delle vulnerabilità tecniche) potrebbe essere N/A se tutti i server sono gestiti da un provider cloud e il contratto (SLA) vieta l’accesso diretto al sistema operativo, trasferendo l’onere al fornitore.
• Nessun dato biometrico: Controllo A.9.4.2 (Autenticazione biometrica) è N/A se l’organizzazione non raccoglie né processa dati biometrici.

La dichiarazione deve essere inserita nella colonna “Status” della SoA, seguita da una descrizione nella colonna “Commenti” che spieghi il motivo (es. “N/A – Asset non presenti nel perimetro certificato”).

Gestione dei controlli ‘Parzialmente Applicabili’ e mitigazione

Spesso ci si trova a dover gestire i controlli ISO 27001 che sono stati classificati come “Parzialmente Applicabili”. È importante capire che questa classificazione non è un alibi per ignorare il controllo, ma un invito a valutare attentamente gli aspetti che non si applicano e, soprattutto, a mitigare i rischi residui che ne derivano.

Il primo passo è capire il perché un controllo è solo parzialmente applicabile. Solitamente, questo accade quando l’azienda possiede più business unit, siti geografici o sistemi informativi con profili di rischio differenti. Ad esempio, un controllo potrebbe essere pienamente applicabile per i server on-premise ma non per l’infrastruttura Cloud gestita interamente da un fornitore (in tal caso, si deve verificare la ripartizione delle responsabilità con il Cloud Service Provider). In alternativa, potrebbe essere applicabile solo ad aree ad alto rischio, come l’R&D, ma non all’amministrazione generale.

Per gestire correttamente questi controlli, la dichiarazione di applicabilità (SoA) deve documentare esplicitamente:

• Le parti applicabili: specificare quale business unit, processo o sistema soddisfa il controllo.
• Le parti non applicabili: motivare chiaramente l’esclusione (es. “non rilevante per il processo X”, “gestito da terzi”).
• Misure di mitigazione: se una parte del controllo non è attiva, come si copre il rischio associato?

Quando un controllo è parziale, il processo di trattamento del rischio diventa cruciale. Non basta dire che il controllo è “Parzialmente Applicabile”; bisogna identificare il gap di sicurezza derivante dagli elementi non implementati e valutare se il rischio residuo è accettabile. Se il rischio è accettabile, va documentato nel rapporto di valutazione del rischio (RRA). Se non lo è, bisogna implementare controlli alternativi o complementari per mitigare la minaccia. Ad esempio, se il controllo A.11.1.2 (Sicurezza fisica per gli uffici) non è applicabile perché non si dispone di sede propria, il rischio di accesso non autorizzato potrebbe essere mitigato mediante l’implementazione di un forte controllo degli accessi logici e l’utilizzo di servizi di co-working che garantiscono standard di sicurezza fisica certificati.

Analisi Dettagliata dei Gruppi di Controlli dell’Annex A (ISO 27001:2022)

Controlli Organizzativi (Classe 5): Casi d’uso comuni

Controlli Organizzativi (Classe 5): Casi d’uso comuni

I controlli organizzativi dell’ISO 27001 sono fondamentali per istituire una gestione sistematica della sicurezza delle informazioni (ISMS). Nella compilazione della Statement of Applicability (SoA), questi controlli (Classe 5, numeri 5.1–5.37) definiscono le regole operative, i ruoli e le responsabilità aziendali.

Ecco alcuni casi d’uso comuni:

• Politiche di sicurezza (5.1–5.2): Una PMI inserisce nella SoA i controlli per le politiche di sicurezza informatica e di organizzazione. Esempio: definizione di una Policy di Uso Accettabile (AUP) obbligatoria per tutti i dipendenti e i fornitori che accedono alla rete aziendale, specificando comportamenti consentiti e vietati.
• Organizzazione della sicurezza (5.3–5.4): Un’azienda che opera in più sedi (o che ha forti interconnessioni con partner) deve gestire i controlli relativi alla telelavoro e all’outsourcing. Nella SoA si dichiarerà l’applicazione delle misure per garantire la sicurezza anche in remoto (es. cifratura dei device BYOD) e la gestione del rischio della supply chain.
• Segretezza e non ripudio (5.9–5.10): In contesti legali o di R&S, è comune applicare il controllo di segretezza (5.9) per proteggere informazioni sensibili. Esempio: l’uso di accordi di riservatezza (NDA) firmati digitalmente per garantire il non ripudio (5.10) nelle transazioni critiche con fornitori esterni.
• Revisione e gestione dei rischi (5.15–5.16): Enti pubblici e aziende soggette a normative stringenti (es. GDPR) includono nella SoA la revisione della sicurezza delle informazioni (5.16) in modo pianificato, spesso semestrale, per garantire la conformità normativa continua.

Nella SoA, è cruciale documentare non solo l’applicazione o meno del controllo, ma anche la giustificazione e la descrizione di come è implementato in azienda, evitando l’inclusione automatica di tutti i controlli senza valutazione del contesto.

Controlli sulle Persone (Classe 6): Policy, formazione e background check

Controlli sulle Persone (Classe 6): Policy, formazione e background check

La sicurezza informatica dipende dalle persone. La classe 6 dell’ISO 27001 copre tutti i controlli che riguardano il capitale umano, partendo dalle regole scritte (policy) fino alla verifica dei profili. Nella SoA, deve dichiarare chiaramente quali controlli applica per evitare rischi legati a errori umani o accessi non autorizzati.

1. Policy per il personale (controllo 6.2)
L’organizzazione deve definire e comunicare regole chiare su come utilizzare le risorse IT, la password, l’uso di dispositivi personali (BYOD) e la proprietà intellettuale. Nella SoA, indica se hai una “Policy per il Personale” firmata e condivisa. È il fondamento per una cultura della sicurezza.

2. Formazione e consapevolezza (controllo 6.3)
Non basta una policy: il personale deve essere formato. La SoA deve indicare se prevedi sessioni annuali di formazione obbligatoria su phishing, password management e gestione dei dati sensibili. La verifica dell’efficacia (es. test di sicurezza o quiz) è un punto critico da documentare.

3. Background check (controllo 6.4)
Prima di assumere o assegnare ruoli critici, è necessario verificare l’affidabilità dei candidati. La SoA elenca le verifiche effettuate: controlli dei titoli di studio, referenze lavorative, certificati penali (se previsti dalla legge) e controlli di credito per ruoli finanziari. Ricorda: le verifiche devono essere proporzionate al rischio e rispettare la privacy.

4. Termination e cambio ruolo (controllo 6.5 e 6.6)
Quando un dipendente lascia o cambia mansione, i suoi diritti di accesso devono essere revocati o aggiornati immediatamente. Nella SoA, descrivi il processo di offboarding: ritiro dispositivi, disattivazione account e checklist di passaggio.

Consiglio pratico per la compilazione
Nella colonna “Giustificazione” della SoA, spiega brevemente perché un controllo è applicabile (es. “Ruolo HR presente in azienda”) o perché non lo è (es. “Non abbiamo assunzioni dirette, outsourcing HR”). Usa un linguaggio semplice ma preciso per facilitare l’audit.

Per un’analisi dei rischi personalizzata e una compilazione efficiente della tua SoA ISO 27001, richiedi subito una consulenza con i nostri esperti.

Controlli Fisici (Classe 7): Uffici, data center e dispositivi mobili

La sezione relativa ai controlli fisici (Classe 7) è spesso trascurata nelle Policy di sicurezza, ma rappresenta il primo anello di difesa contro accessi non autorizzati e furti di dati. La dichiarazione di applicabilità deve spiegare chiaramente come l’organizzazione protegge le sue infrastrutture critiche, siano esse localizzate in uffici tradizionali, data center dedicati o dispositivi mobili in mano ai dipendenti.

Uffici e aree sensibili

Per gli uffici, la SoA deve dettagliare le misure di controllo degli accessi fisici. Questo include l’uso di badge o sistemi biometrici per l’ingresso, la presenza di receptionist per il controllo dei visitatori e la delimitazione fisica di aree a rischio (es. sala server, uffici HR). È fondamentale specificare le procedure di autorizzazione per l’accesso ai locali e il protocollo di “tailgating” (porta a seguito). Per le aziende con dipendenti in modalità ibrida, la SoA dovrebbe menzionare le linee guida per la pulizia delle scrivanie (clear desk) e la custodia dei documenti cartacei sensibili in armadi blindati.

Data center e sala server

Se l’organizzazione gestisce internamente un data center o una sala server, la SoA deve richiamare i controlli specifici di questa classe. Oltre agli accessi biometrici a più fattori, sono cruciali i controlli ambientali: sistemi di condizionamento (HVAC) per la temperatura e l’umidità, rilevatori di allagamento e sistemi antincendio a scomparsa di ossigeno o gas (es. Novec 1230). La protezione contro le intrusioni va integrata con sistemi di videosorveglianza CCTV con registrazione conservata per almeno 30 giorni e sistemi di rilevamento intrusione (IDS) fisici. Se il data center è esterno (colocazione), la SoA deve dichiarare la dipendenza dai controlli del provider, richiedendo eventualmente auditorie o attestazioni di conformità (es. SOC 2).

Dispositivi mobili e lavoro da remoto

La Classe 7 include anche i dispositivi mobili (laptop, tablet, smartphone) che, pur essendo “fisici”, operano al di fuori del perimetro aziendale. La SoA deve dichiarare l’applicazione di controlli per la gestione dei dispositivi mobili (MDM/EMM). Questi controlli prevedono la cifratura del disco/FS, l’imposizione di PIN di blocco schermo complessi e la capacità di cancellazione remota in caso di smarrimento o furto (Geofencing e Remote Wipe). Per il lavoro da remoto, la SoA dovrebbe menzionare i requisiti per le reti Wi-Fi domestiche (es. WPA3, cambio password default router) e l’uso di VPN aziendali per accedere alle risorse. È buona norma includere un elenco dei dispositivi autorizzati e le policy di acquisto e smaltimento (asset disposal) per garantire che i dati vengano sovrascritti prima della dismissione.

Controlli Tecnologici (Classe 8): Accesso, crittografia, sicurezza delle reti

Controlli tecnologici (Classe 8): accesso, crittografia e sicurezza delle reti

Nella tabella SoA, la classe 8 è il cuore operativo della sicurezza informatica. Per ogni controllo valutato, registra se è applicabile, chi è il responsabile e come è implementato.

Accesso (8.1 – 8.3):
Definisci i criteri di accesso logico e fisico agli asset. Per ogni controllo, specifichi: multi-factor authentication (MFA) obbligatoria per amministratori e utenti remoti; gestione centralizzata delle identità (IAM) con provisioning/deprovisioning automatico; rotazione periodica delle credenziali; log di autenticazione custoditi per 12 mesi. Se un controllo è escluso, motivane la ragione (es. “non applicabile: nessun accesso remoto” o “sostituito da soluzione SaaS con certificazione SOC 2”).

Crittografia (8.4 – 8.7):
Elenca le politiche di cifratura a riposo e in transito. Esempio: tutti i database aziendali crittografati con AES-256; TLS 1.2+ su tutti i servizi web; gestione chiavi via HSM o KMS cloud; archivio chiavi separato dai dati. Indica la classe di conservazione dei segreti e la cadenza di rotazione (es. ogni 90 giorni). Se alcuni dati non sono crittografati, giustifica con valutazione del rischio accettata dal management.

Sicurezza delle reti (8.8 – 8.10):
Documenta la segmentazione di rete (VLAN, micro-segmentazione), firewall con regole di default-deny, IDS/IPS, VPN dedicata per accesso amministrativo, blacklist IP e whitelisting per servizi critici. Se sono in uso soluzioni SD-WAN o SASE, indicare il provider e i controlli applicati. Per ogni controllo, allegare report di scan e configurazioni (non allegare documenti sensibili, ma descriverne l’output).

Indicazioni operative per la compilazione:
– Colonna “Implementato?”: Usa “Sì” se il controllo è attivo, “Parzialmente” con piano di remediation, “No” con giustificazione formale.
– Colonna “Evidenza”: Inserisci referenza a ticket, screenshot anonimizzati, report di scansione, o link a repository documentale (es. “Confluence: SoA-Controlli-8”)
– Colonna “Responsabile”: Assegna un titolo (es. “CTO”, “SysAdmin”, “DPO”) per non legare la SoA a persone specifiche.
– Colonna “Frequenza”: Specifica la cadenza di revisione (es. “trimestrale”, “ad ogni cambio infrastruttura”).

Checklist operativa:
☐ 1. MFA abilitato per tutti gli accessi privilegiati e remoti.
☐ 2. Criteri di password complessi e gestiti via IAM.
☐ 3. Crittografia end-to-end su dati sensibili e backup.
☐ 4. Segmentazione di rete tra ambienti produttori e test/development.
☐ 5. IDS/IPS configurati e allert configurati verso SIEM.
☐ 6. Registrazione e monitoraggio accessi log centralizzato.
☐ 7. Gestione chiavi crittografiche con rotazione pianificata.
☐ 8. Policy di whitelist per servizi esposti su internet.
☐ 9. Audit trimestrale delle configurazioni di sicurezza di rete.
☐ 10. Piano di remediation per controllo “No”.

Prendi ora un controllo tecnologico applicabile: verifica se è implementato e documenta l’evidenza nella tabella SoA. Questo approccio ti permette di avere una SoA viva, auditabile e pronta per la certificazione.

Esempio pratico: Riscrittura del Controllo A.5.16 (Identity Management)

Per rendere concreto il processo, vediamo come tradurre il controllo A.5.16.8 (Password-based authentication) in un controllo specifico e misurabile per la tua realtà aziendale.

Controllo ISO 27001 (Origine): Le policy per l’autenticazione basata su password devono essere progettate e implementate.

Riscrittura per la Policy Interna (Esempio):

• Obiettivo: Proteggere l’accesso ai sistemi informatici e ai dati sensibili.
• Controlli implementati:
  • Lunghezza e complessità: Tutte le password devono avere almeno 12 caratteri, includendo lettere maiuscole, minuscole, numeri e simboli.
  • Scadenza e rotazione: Le password dei dipendenti devono essere modificate ogni 90 giorni. È vietato il riutilizzo delle ultime 5 password.
  • Autenticazione a più fattori (MFA): L’MFA è obbligatorio per l’accesso remoto (VPN) e per tutti i servizi cloud (Microsoft 365, AWS, ecc.).
  • Gestione password di sistema: Le password predefinite dei dispositivi (router, server) devono essere cambiate al primo accesso e conservate in un gestore di credenziali cifrato accessibile solo agli amministratori.

Verifica e Misurazione (KPI): Monitoraggio trimestrale tramite Active Directory o tool di Identity Governance per verificare la percentuale di account con password scadute o non conformi e la copertura MFA (target 100%).

Redazione della Giustificazione: Evidenza vs. Intenzione

Quando compili la dichiarazione di applicabilità (Statement of Applicability – SoA) ISO 27001, la colonna più critica e spesso più trascurata è quella della giustificazione. È il punto in cui si definisce se un controllo è applicato o meno, ma soprattutto perché. Una giustificazione debole, generica o puramente teorica è una delle cause principali di non conformità nelle audit di certificazione. L’errore più comune è confondere l’evidenza con la intenzione. Capire la differenza tra questi due approcci è fondamentale per costruire una SoA solida, credibile e realmente utile alla gestione della sicurezza.

Il rischio della giustificazione basata solo su intenzioni

Una giustificazione basata esclusivamente su intenzioni si limita a descrivere ciò che l’organizzazione intende di fare, ma non fornisce alcun elemento concreto a supporto. È un’astrazione che non regge all’esame di un auditor.

• Il problema dell’assenza di evidenza: Se per il controllo A.9.2.1 (Registrazione utenti) la giustificazione recita “Registriamo gli utenti perché è una buona pratica”, l’auditor non ha alcuna prova che questo accada effettivamente. Si tratta di un’affermazione di intento, non di un fatto verificabile.
• La mancanza di contesto specifico: Le intenzioni sono spesso generiche e non legate alla realtà operativa, ai rischi specifici dell’organizzazione o alle misure di mitigazione adottate. Non rispondono alla domanda “come lo fai nel tuo contesto?”
• Il fallimento nella verifica: L’auditor non può verificare un’intenzione. Può solo verificare processi, documenti, configurazioni, log e interviste. Una SoA basata su intenzioni non fornisce alcunché da verificare, portando a una quasi certa non conformità.

Costruire giustificazioni solide: il principio dell’evidenza

Un approccio basato sull’evidenza trasforma la giustificazione da una dichiarazione di intento a una dichiarazione di fatto supportata da prove tangibili. Questo approccio risponde in modo preciso alla domanda “perché questo controllo è applicato (o non applicato) in questa specifica organizzazione?” e fornisce all’auditor il percorso per verificare l’affermazione.

Ecco come passare dall’intenzione all’evidenza per la colonna della giustificazione:

1. Legare la giustificazione all’analisi del rischio: La giustificazione principale per applicare o meno un controllo deriva dalla valutazione del rischio specifica. La giustificazione dovrebbe menzionare il rischio identificato, il suo valore e come il controllo (o la sua omissione) contribuisce a mitigarlo o accettarlo.
2. Indicare la fonte dell’evidenza: Invece di dire “Abbiamo una politica”, specificare: “La politica di controllo degli accessi (doc. D-ACC-001) definisce il processo di registrazione utenti e le responsabilità”. Se un controllo non è applicato, la giustificazione potrebbe essere: “Il rischio associato (R-05: Divulgazione di informazioni) è stato trasferito tramite contratto di servizio (doc. CONTR-APP-001), pertanto il controllo A.14.2.8 (Protezione del codice sorgente) non è applicato direttamente, come attestato dall’analisi del rischio (doc. RISK-2024-001)”
3. Descrivere lo stato attuale, non quello futuro: L’auditor verifica lo stato attuale dei controlli. La giustificazione deve riflettere la realtà di oggi. “Stiamo implementando” è un’intenzione. “Il controllo è implementato parzialmente nel sistema X, come documentato nel report di configurazione del 15/05/2024” è un’evidenza.
4. Specificare il perimetro e la responsabilità: La giustificazione deve chiarire se il controllo è applicato a tutta l’organizzazione, a specifici dipartimenti o sistemi. Indicare chi è responsabile della sua attuazione e manutenzione. Per esempio: “Il controllo A.11.1.1 (Policy fisica) è applicato solo alle sedi italiane (milano e roma), come definito nel perimetro della SoA (doc. SOA-2024-001, par. 2.3)”.

Esempi pratici: Da intenzione a Evidenza

Per rendere il concetto più tangibile, vediamo come trasformare giustificazioni debbi in giustificazioni forti.

Controllo ISO 27001	Giustificazione Debole (Intenzione)	Giustificazione Forte (Evidenza)
A.7.2.2 – Formazione specifica	“Formiamo il personale sulla sicurezza perché è importante.”	“Il controllo è applicato. La formazione annuale obbligatoria per tutti i dipendenti è erogata tramite la piattaforma interna ‘SecurityHub’ (doc. S-FORM-001). L’evidenza dell’avvenuta formazione è tracciata nel report di completamento (report Q3-2024), con una compliance del 98%. Il rischio mitigato (R-12: Errori umani) è valutato in ‘Alto’ nel documento di analisi del rischio (doc. RISK-2024-002).”
A.8.2.3 – Gestione password	“Implementeremo policy di password complesse per tutti i sistemi.”	“Il controllo è applicato. La policy di password ‘POL-PWD-001’ richiede 12 caratteri, complessità e rotazione ogni 90 giorni. L’evidenza è la configurazione del dominio Active Directory (config. AD-001, aggiornata il 20/04/2024) e il report di audit mensile che verifica la compliance (report AD-Audit-04-2024). Il rischio residuo è documentato in ‘Basso’ (doc. RISK-2024-003).”
A.12.6.1 – Gestione incidenti	“Abbiamo definito un processo di gestione incidenti.”	“Il controllo è applicato. Il processo formale è descritto nel ‘Manuale di Incident Response’ (doc. IR-001). L’evidenza operativa è fornita dal ticket system (es. Jira) dove sono tracciati tutti gli incidenti dal 01/01/2024 (ticket JIRA-SEC-2024-001 a JIRA-SEC-2024-045). Il report mensile di revisione (doc. IR-REV-04-2024) mostra tempi di risoluzione e miglioramenti. Il rischio mitigato (R-08: Interruzione operativa) è valutato ‘Medio’.”

In sintesi, la colonna della giustificazione nella SoA è il ponte tra l’analisi del rischio e il controllo effettivo. Trasformare le intenzioni vaghe in evidenze concrete non solo supera l’audit, ma crea un valore reale: fornisce chiarezza interna, facilita la gestione continua della sicurezza e costruisce fiducia con auditor e stakeholder. Una SoA basata su evidenze non è un semplice documento di compliance, ma un mappa dinamica del sistema di gestione della sicurezza dell’informazione.

Come scrivere una giustificazione che resista all’audit (Traceability)

Come scrivere una giustificazione che resista all’audit (Traceability)

Una giustificazione robusta nel Statement of Applicability (SoA) non è un semplice commento, ma un record tracciabile che collega l’azienda alla decisione presa. Per resistere all’esame di un auditor di terze parti, ogni voce nel SoA deve essere costruita su tre pilastri: riferimento normativo, analisi del rischio e decisione documentata.

1. Riferimento alla mappa dei rischi (Traceability ID)
La prima riga della giustificazione deve contenere l’identificativo univoco del rischio (es. RISK-IT-015) dalla tua matrice dei rischi. Questo crea un link diretto e inconfutabile. Non limitarti a dire “non applicabile perché non è un rischio rilevante”; scrivi: “Il controllo A.5.7 è escluso perché il rischio associato (ID: RISK-IT-015, mancata crittografia dei dati in transito su rete interna) è stato valutato come ‘Trascurabile’ nel nostro Risk Assessment del [Data], dato che la rete interna è isolata e protetta da firewall dedicati.“

2. Analisi contestuale e proporzionalità
La giustificazione deve riflettere la proporzionalità del controllo rispetto all’ambito di certificazione. Se un controllo ISO 27001 sembra eccessivo per la tua realtà PMI, spiegalo con dati concreti.
Esempio pratico: Per il controllo A.11.1.4 (Sicurezza fisica dei locali), se la tua azienda opera in un co-working, non basta dire “non nostra responsabilità”. Scrivi: “Il controllo è parzialmente applicabile. Le aree critiche (server room) sono soggette a controllo accessi tramite badge. Per le aree comuni del co-working, la responsabilità della sicurezza fisica è contrattualmente trasferita al gestore della struttura, come specificato nel contratto di affitto (Allegato B, clausola 4.2). Monitoriamo comunque l’accesso tramite log.“

3. Decisione formale e firma
La colonna “Decisione” del SoA deve essere binaria: Applicabile, Non Applicabile, o Parzialmente Applicabile. Mai usare termini ambigui come “In valutazione” o “Non rilevante” senza contesto. Se il controllo è escluso, la giustificazione deve concludersi con una dichiarazione di accettazione del rischio residuo da parte della Direzione (es. “Il rischio residuo è accettato dalla Direzione in data [Data]”).

CTA – Micro-offerta
Vuoi un modello Excel pronto all’uso per mappare i rischi e generare automaticamente le tracciate nel SoA? Scarica il Template “SoA & Traceability Matrix” (incluso esempi di giustificazioni pronte per l’audit).

Errori comuni da evitare nella documentazione

Errori comuni da evitare nella documentazione SoA

Il Statement of Applicability (SoA) è un documento critico ma, nella pratica, molte aziende commettono errori ricorrenti che mettono a rischio l’intero processo di certificazione. Identificare questi errori permette di costruire una SoA solida e affidabile.

• Assenza di giustificazione: l’errore più frequente è inserire le voci della norma senza spiegare perché un controllo è applicato o meno. Un SoA valido richiede sempre una motivazione chiara, basata sul rischio o su requisiti specifici del business.
• Genericità dei commenti: utilizzare frasi come “applicato perché necessario” o “non applicato perché irrilevante” non è sufficiente. La documentazione deve dettagliare il contesto operativo, le minacce considerate e l’impatto atteso.
• Incoerenza con la valutazione dei rischi: la SoA deve essere il naturale completamento della valutazione dei rischi (risk assessment). Se un controllo è classificato come “non applicabile” senza un rischio correlato, si crea una contraddizione documentale pericolosa.
• Trascurare i controlli supplementari: molti dimenticano di includere i controlli aggiuntivi derivanti da requisiti legali, contrattuali o specifici del settore (es. GDPR, NIS2, DORA). Una SoA incompleta è una delle cause principali di non conformità in fase di audit.
• Versionamento scorretto: non mantenere una tracciatura delle versioni del SoA rende impossibile dimostrare il miglioramento continuo. Ogni modifica deve essere datata, revisionata e approvata.
• Struttura non chiara: un documento disordinato, senza una mappatura chiara tra i controlli della norma e le scelte aziendali, rallenta l’audit e genera fraintendimenti.

Evitare questi errori non è solo una questione formale: è la base per una gestione della sicurezza informatica che sia effettivamente integrata nei processi aziendali e non solo un adempimento burocratico.

Strumenti e Template per la Compilazione

Nella stesura del Statement of Applicability (SoA), l’uso di strumenti dedicati e template strutturati non è solo un risparmio di tempo, ma un garante di accuratezza e coerenza. Un approccio manuale su fogli di calcolo generici, infatti, si espone a rischi di disallineamento tra la matrice dei controlli, la dichiarazione di non applicabilità e la descrizione della giustificazione.

Il punto di partenza ideale è il template fornito dall’organo di certificazione o da organismi di normazione, che mappa già i controlli dell’Allegato A della norma ISO 27001. Tuttavia, per una gestione dinamica, è preferibile migrare verso soluzioni digitali.

Strumenti consigliati per l’efficienza

• Software GRC (Governance, Risk & Compliance): Piattaforme come RSA Archer, ServiceNow o soluzioni specifiche per la sicurezza informatica offrono moduli preconfigurati per il SoA. Il vantaggio principale è l’automatismo: modificando lo stato di un controllo (es. da “Non Applicabile” a “Applicabile”), il sistema aggiorna automaticamente i report e le evidenze collegate.
• Excel/Google Sheets avanzati: Per PMI o organizzazioni in prima fase di implementazione, un foglio di calcolo ben strutturato può essere sufficiente. È cruciale però che includa formule di controllo per evitare incongruenze (es. se un controllo è “Non Applicabile”, il campo “Giustificazione” deve essere obbligatorio) e una gestione delle versioni rigorosa.
• Tool open source: Soluzioni come ISMS Policy Template o repository GitHub dedicati alla normativa ISO 27001 offrono basi strutturate che possono essere personalizzate secondo le esigenze specifiche dell’organizzazione.

Checklist per la selezione del template

Prima di scaricare o acquistare un template, verifica che sia:

1. Allineato alla versione corrente della norma ISO 27001 (2022): I controlli dell’Allegato A sono cambiati rispetto alle edizioni precedenti (da 114 a 93).
2. Modulare: Permetta di aggiungere o rimuovere controlli in base al contesto organizzativo (es. controlli specifici per cloud computing o lavoro agile).
3. Integrato: Collegato direttamente alla valutazione del rischio e al Statement of Applicability.

Per approfondire l’argomento e ricevere supporto nella scelta degli strumenti più adatti alla tua realtà, contatta i nostri esperti. Offriamo una consulenza mirata per identificare la soluzione tecnologica che si integri perfettamente con i tuoi processi di governance.

Excel vs. Software GRC: pro e contro

Per la stesura dello Statement of Applicability (SoA) ISO 27001, molte aziende iniziano utilizzando Excel per la sua immediatezza e diffusione. Tuttavia, è fondamentale valutare se questo strumento sia adeguato alle esigenze di compliance a lungo termine.

Excel: Pro e Contro

Pro: Gratuito, flessibile e familiare per la maggior parte degli utenti. Permette una gestione rapida iniziale, ideale per PMI con budget limitati o per progetti pilota. Il formato a tabella semplifica l’input manuale dei controlli e lo stato di implementazione.

Contro: L’uso di Excel comporta rischi significativi: errori manuali nella tracciatura versionale, difficoltà nella gestione dei ruoli e delle revisioni, e mancanza di automazione. Scalare il sistema di gestione con fogli di calcolo complessi è quasi impossibile e il tracciamento audit trail è carente, rendendo critica la dimostrazione di conformità in caso di auditor.

Software GRC: Pro e Contro

Pro: Piattaforme dedicate offrono automazione, tracciamento univoco delle versioni, gestione dei ruoli (approvatore, responsabile, revisore) e dashboard in tempo reale. Semplificano la mappatura dei requisiti ISO 27001 contro i controlli Annex A e generano reportistica di compliance istantanea. Riducono drasticamente il tempo dedicato alle revisioni e garantiscono coerenza.

Contro: L’investimento iniziale (licenza e implementazione) è superiore a Excel. Richiede una fase di setup dedicata e formazione specifica dell’operatore. Tuttavia, il ritorno sull’investimento (ROI) è garantito dall’efficienza operativa e dalla riduzione del rischio di non conformità.

Esempio di template Excel per SoA (Descrizione strutturata)

Esempio di template Excel per SoA (Descrizione strutturata)

Un modello efficace per la redazione dello Statement of Applicability su Excel deve essere immediato, tracciabile e conforme alla struttura richiesta dagli standard. L’obiettivo è trascinare l’output del paragrafo 6.1.3 (valutazione dei rischi) in un report chiave per l’audit, senza ricreare manualmente il sistema di gestione.

La struttura ideale prevede una tabella centrale con le seguenti colonne essenziali:

• Codice Controllo (A.5-A.18): Riferimento univoco al controllo ISO 27001.
• Titolo e Descrizione: Testo integrale del controllo o breve spiegazione.
• Applicabilità (SI/NO): Scelta tramite menu a tendina.
• Giustificazione: Campo obbligatorio se la risposta è NO (es. “Non applicabile perché non gestiamo dati di terze parti”).
• Implementazione (SI/NO/Parziale): Stato reale del controllo in azienda.
• Riferimento Documentale: Link al documento di supporto (es. “Procedura di Sicurezza – Accesso Logico v2.1”).
• Responsabile: Ruolo o figura aziendale incaricata.
• Note: Osservazioni aggiuntive o pianificazione di interventi futuri.

Per automatizzare il processo, consigliamo l’utilizzo di tabelle pivot collegate a un foglio di definizione contenente l’elenco completo dei controlli. È buona norma proteggere le celle con le formule e abilitare il controllo degli errori per evitare input incongruenti. Un template strutturato in questo modo garantisce non solo il rispetto della norma, ma anche la scalabilità per revisioni future dell’SoA.

Manutenzione e Aggiornamento del SoA: Un Documento VIVO

Il Statement of Applicability (SoA) non è un documento da archiviare una volta compilato. Deve essere un documento vivo, capace di evolversi insieme all’organizzazione e al panorama delle minacce. Penserai: “Ma non basta aggiornarlo una volta all’anno?”. Sbagliato. Un SoA stagnante è un documento obsoleto che non riflette la realtà operativa e può creare più problemi di quanti ne risolva durante un audit.

Perché la manutenzione è cruciale? I rischi non rimangono statici. Nuove tecnologie vengono introdotte, nuove minacce emergono, e i processi aziendali cambiano. Un aggiornamento tempestivo del SoA garantisce che l’ISMS (Information Security Management System) rimanga allineato con la strategia di business e i requisiti normativi, che siano GDPR, NIS2 o ISO 27001 stessa.

Criteri per l’aggiornamento del SoA

Stabilisci trigger chiari per la revisione del SoA, oltre al ciclo annuale pianificato. Ecco alcuni esempi pratici:

• Cambiamenti organizzativi: Acquisizioni, fusioni, o riorganizzazioni interne richiedono una rivalutazione dei controlli applicabili.
• Introduzione di nuove tecnologie: L’adozione di Cloud, IoT o software specifici (es. AI) introduce nuovi rischi e controlli necessari.
• Incidenti di sicurezza: Un breach o un near-miss deve innescare una review per valutare se i controlli esistenti sono efficaci o se ce ne sono di nuovi da implementare.
• Requisiti legali aggiornati: L’entrata in vigore di nuove normative (es. aggiornamenti DORA o Cyber Resilience Act) impatta direttamente sul SoA.
• Esiti degli audit: Trovate di audit interni o esterni (sia iso che third-party) possono evidenziare la necessità di aggiustamenti.

Processo operativo di manutenzione

Per gestire queste modifiche in modo strutturato, adotta un processo semplice ma robusto. Non serve un software costoso, ma disciplina.

1. Rilevazione: Crea un repository centrale (anche un foglio di calcolo condiviso o un ticket system) per registrare ogni richiesta di modifica al SoA. Ogni modifica deve essere tracciata.
2. Valutazione d’impatto: Per ogni nuova minaccia o cambiamento, valuta il rischio residuo. Se il rischio aumenta, è necessario un controllo aggiuntivo.
3. Approvazione: Le modifiche al SoA devono essere approvate dal management (di solito dal responsabile della sicurezza o dal management review). Questo garantisce ownership e visibilità.
4. Implementazione e Verifica: Una volta approvato, il controllo deve essere implementato e verificato nel tempo. Il SoA aggiornato deve riflettere questo stato.

Checklist per la verifica trimestrale:

• ✓ Il SoA riflette tutte le versioni attuali dei controlli ISO 27001 A.5, A.6, A.7, A.8, A.9?
• ✓ Le giustificazioni per i controlli “Non Applicabili” sono ancora valide?
• ✓ Il documento è accessibile agli auditor esterni?
• ✓ I responsabili dei controlli sono ancora corretti?

Un SoA vivo è la prova tangibile che la sicurezza informativa è un processo continuo, non un progetto con una data di scadenza. Mantenerlo aggiornato riduce lo stress dell’audit e migliora la postura di sicurezza complessiva.

Trigger di modifica: Nuovi rischi, tecnologie o normative

Trigger di modifica: Nuovi rischi, tecnologie o normative

Il Statement of Applicability (SoA) non è un documento statico, ma uno strumento vivo che deve riflettere l’evoluzione dell’organizzazione e del contesto in cui opera. Per mantenere la sua efficacia e validità durante gli audit di certificazione o di sorveglianza, il SoA deve essere aggiornato tempestivamente ogni volta che si verificano specifici trigger di modifica.

Ecco i principali scenari che richiedono una revisione immediata del SoA:

• Identificazione di nuovi rischi: Quando l’analisi dei rischi (o una revisione periodica) evidenzia minacce non precedentemente considerate (es. nuove vulnerabilità software, cambiamenti nei processi operativi o nell’ecosistema dei fornitori), è necessario valutare l’applicabilità dei controlli A.5 e A.8 correlati.
• Introduzione di nuove tecnologie: L’adozione di cloud computing, Intelligenza Artificiale, IoT o nuovi strumenti SaaS richiede di aggiornare il SoA con i controlli specifici per la sicurezza di questi ambienti (es. A.5.23 Gestione della sicurezza nell’uso dei servizi cloud, A.5.25 Valutazione e trattamento dei rischi legati all’IA).
• Modifiche normative e regolamentari: L’entrata in vigore di nuove leggi (es. NIS2, DORA) o aggiornamenti agli standard (es. revisione ISO 27001:2022) possono introdurre obblighi di controllo aggiuntivi o modificare quelli esistenti, rendendo necessario un aggiornamento formale del SoA.
• Reclami, incidenti o audit: Eventi critici possono rivelare lacune nei controlli, spingendo all’introduzione o al rinforzo di specifiche misure di mitigazione documentate nel SoA.

Una gestione proattiva di questi trigger garantisce che il SoA rimanga sempre allineato alla realtà operativa e al rischio residuo accettabile.

Controllo delle versioni e governance del documento

Controllo delle versioni e governance del documento

La Statement of Applicability (SoA) è un documento vivo, sottoposto a continui revisioni. Un rigoroso sistema di controllo delle versioni è quindi essenziale per garantirne l’integrità e la tracciabilità nel tempo.

È buona prassi istituire una Governance formale, designando un unico proprietario del documento (tipicamente l’Information Security Manager o un responsabile della compliance) e coinvolgendo i titolari dei processi per la validazione delle scelte. Il processo di revisione dovrebbe essere pianificato (ad esempio, annualmente o a ogni significativo cambiamento di contesto) e seguire un ciclo strutturato: proposta di modifica, analisi d’impatto, approvazione e pubblicazione.

Ogni versione della SoA deve essere archiviata in un sistema gestionale centrale, accessibile solo agli utenti autorizzati. È fondamentale mantenere un registro delle modifiche (Change Log) che documenti per ogni aggiornamento: data, autore, motivazione del cambiamento e stato di approvazione. Questo approccio non solo soddisfa i requisiti di audit della ISO 27001, ma trasforma la SoA da un semplice elenco a uno strumento strategico per il miglioramento continuo della sicurezza informatica.

Optimizza la governance della tua SoA con l’esperienza di Culture Digitali Srl: contattaci per una consulenza specializzata.

Il SoA durante l’Audit di Certificazione: Cosa si Aspetta l’Auditor

Il SoA durante l’Audit di Certificazione: Cosa si Aspetta l’Auditor

Durante l’audit di certificazione ISO 27001, lo Statement of Applicability (SoA) è il documento centrale su cui si concentra l’auditor. Non è una semplice lista di controllo, ma la prova tangibile che l’organizzazione ha condotto un’analisi dei rischi strutturata e ha selezionato in modo consapevole gli controlli di sicurezza da implementare. L’auditor si aspetta di trovare nel SoA la documentazione del percorso logico che collega gli identificati rischi di sicurezza dell’informazione alle misure di controllo applicate, motivando ogni scelta.

La prima attesa dell’auditor è la completezza e l’allineamento del SoA con il contesto dell’organizzazione. Il documento deve riflettere accuratamente il perimetro del Sistema di Gestione per la Sicurezza delle Informazioni (SGSI), includendo tutti i processi, le informazioni critiche e le divisioni aziendali coperti dalla certificazione. L’auditor verificherà che ogni controllo elencato nella norma ISO/IEC 27001:2022 (Allegato A) sia stato considerato. Per ogni controllo, l’auditor si aspetta di trovare una delle tre decisioni chiare: applicato, non applicato (con motivazione dettagliata), o applicato parzialmente (con spiegazione delle estensioni). La motivazione per le esclusioni è particolarmente scrutinata: deve essere solida, basata su una valutazione del rischio e non su una mera semplificazione operativa.

Successivamente, l’auditor esaminerà la coerenza tra il SoA, il Risk Treatment Plan (RTP) e il Risk Assessment Report. Deve esserci una tracciabilità lineare: i rischi identificati nel report devono essere trattati nel RTP con specifiche azioni, e gli strumenti di controllo implementati per mitigare quei rischi devono corrispondere esattamente a quelli elencati nel SoA. Qualsiasi discrepanza, come un rischio elevato non mitigato da alcun controllo o un controllo applicato senza un rischio associato, rappresenterà una non conformità critica.

Infine, l’auditor valuta l’attualità e la revisione del SoA. Un SoA fermo nel tempo è un segnale di debolezza. L’auditor si aspetta di vedere prove di revisioni periodiche, specialmente in seguito a cambiamenti organizzativi, incidenti di sicurezza o evoluzioni del panorama delle minacce. Il SoA non è un documento statico; è uno strumento vivo che dimostra la maturità e l’efficacia continua del sistema di sicurezza. In sintesi, l’auditor non si limita a controllare la presenza del documento, ma ne analizza la profondità, la coerenza logica e l’allineamento con la realtà operativa dell’azienda. Un SoA ben costruito è la prova più solida che la sicurezza informatica è una priorità strategica, non solo un adempimento formale.

Verifica della coerenza tra SoA, Risk Assessment e RTP

Il Statement of Applicability (SoA) non è un documento isolato: la sua efficacia dipende dalla coerenza con il Risk Assessment e il Risk Treatment Plan (RTP). Per verificarla, segui questi passaggi operativi.

1. Allinea gli obiettivi di controllo

Per ogni rischio identificato nel Risk Assessment, verifica che il controllo (se applicabile) sia elencato nel SoA e che la decisione di inclusione/estrazione sia coerente con la strategia di trattamento indicata nel RTP. Se un rischio è trasferito, mitigato o accettato, il controllo deve riflettere quella scelta.

3. Verifica la tracciabilità

Costruisci una mappa tracciabile: ID rischio → controllo SoA → piano d’azione RTP → evidenza di implementazione. Utilizza un foglio di calcolo con colonne dedicate per evidenziare eventuali discrepanze (es. controllo nel SoA ma non previsto nel RTP, o viceversa).

2. Gestisci le non-applicabilità

Se escludi un controllo dal SoA, motivazione e giustificazione (es. rischio trasferito, controllo sostitutivo) devono essere documentate nel RTP e coerenza con il contesto del Risk Assessment. Assicurati che le esclusioni non creino lacune ingiustificate.

Questa verifica va eseguita prima della certificazione e in ogni revisione: garantisce che il sistema di gestione sia integrato, efficiente e compliant con ISO 27001.

Domande tipiche degli auditor sui controlli esclusi

Domande tipiche degli auditor sui controlli esclusi

Nella fase di audit, la Statement of Applicability (SoA) è spesso sottoposta a scrutinio rigido, specialmente per i controlli marcati come “non applicabili”. L’auditor esterno deve validare che questa esclusione non sia una strategia per eludere il framework di sicurezza. Ecco le domande più frequenti che ti aspetterai:

• Qual è la giustificazione documentata? Non basta affermare che un controllo non serve; devi fornire evidenza oggettiva (es. assenza di dati biometrici, mancanza di reti wireless) supportata dal Risk Treatment Plan (RTP).
• Perché il controllo non è stato selezionato? L’auditor verificherà che la decisione derivi da un’analisi di rischio e non da una semplice scelta arbitraria o di comodità.
• Il contesto aziendale è cambiato? Se l’azienda cresce o cambia tecnologia, quel controllo escluso potrebbe diventare improvvisamente necessario. L’auditor chiederà come monitori questi cambiamenti.
• Come è stata gestita la deroga? In caso di applicazione parziale, verrai chiesto di dimostrare quali alternative hai implementato per coprire il rischio.

Preparati a dimostrare che ogni esclusione è consapevole, giustificata e sicura.

Checklist Finale e Conclusioni

Checklist Finale e Conclusioni

La compilazione dello Statement of Applicability (SoA) non è un semplice adempimento burocratico, ma lo specchio strategico del tuo sistema di gestione della sicurezza delle informazioni. Per garantire che il documento sia non solo corretto ma anche efficace, ecco una mini-checklist pratica da seguire prima della firma definitiva:

• Integrità degli input: Il SoA è stato compilato sulla base di una valutazione dei rischi completa e aggiornata? Ogni controllo citato deve trovare radice in un rischio specifico.
• Copertura normativa: Sono stati considerati tutti i controlli dell’Allegato A della ISO 27001 (2022)? Per ogni controllo, è stata chiaramente documentata l’implementazione (“Sì”) o la giustificazione per l’esclusione (“No”)?
• Giustificazioni solide: Le motivazioni per l’esclusione di un controllo sono tecnicamente valide e non solo legate a vincoli economici temporanei? Rischiano di essere contestate in audit?
• Tracciabilità: È possibile risalire facilmente dalle voci del SoA ai documenti di supporto (procedure, politiche, report di valutazione del rischio)?
• Revisione continua: Il SoA è stato impostato come documento vivo, da rivedere ad ogni ciclo di audit interno, management review o in caso di cambiamenti significativi nell’organizzazione o nel panorama delle minacce?

Domande Frequenti (FAQ)

Il Statement of Applicability è obbligatorio per la certificazione ISO 27001?

Sì, è assolutamente obbligatorio. La clausola 6.1.3 della norma ISO 27001:2022 richiede esplicitamente che l’organizzazione documenti l’esito del processo di valutazione del rischio e produca una dichiarazione di applicabilità. Senza un SoA valido e firmato, non è possibile superare l’audit di certificazione.

Posso dichiarare ‘Non Applicabile’ a tutti i controlli dell’Annex A?

No. Anche se la norma permette di escludere controlli non pertinenti, devi applicare i controlli necessari per mitigare i rischi identificati nella tua valutazione del rischio. Inoltre, la ISO 27001 richiede di implementare almeno una misura di sicurezza per ogni rischio accettato. Dichiarare tutto come ‘Non Applicabile’ è un campanello d’allarme immediato per gli auditor.

Quanto tempo serve per compilare il SoA?

Il tempo varia molto in base alla complessità dell’organizzazione. Per una PMI, la compilazione richiede solitamente dalle 2 alle 4 settimane, integrando il lavoro con la valutazione del rischio. Per grandi aziende o gruppi multinazionali, il processo può estendersi a 2-3 mesi, considerando le revisioni interne e la raccolta delle evidenze.

Il SoA deve essere un documento unico o possono esistere versioni diverse per contesti?

Se l’organizzazione ha più contesti (es. uffici in paesi diversi con normative differenti o linee di business separate), è possibile creare SoA specifici per ogni contesto, purché esista un SoA master che aggrega e giustifica le scelte a livello globale, assicurando la coerenza con la politica della sicurezza aziendale.

Come gestire i controlli introdotti con l’aggiornamento alla ISO 27001:2022?

Bisogna eseguire una gap analysis tra il vecchio SoA (basato sulla ISO 27001:2013) e il nuovo Annex A (2022). I nuovi controlli (come A.5.7 Threat Intelligence o A.5.23 Information security for use of cloud services) devono essere valutati: se applicabili, vanno inclusi con le relative giustificazioni; se non applicabili, vanno esclusi con motivazioni solide.

Contattaci

contattaci per saperne di più