Introduzione al Statement of Applicability (SoA) ISO 27001

Cos’è il Statement of Applicability?

Perché il SoA è fondamentale per la certificazione ISO 27001

Analisi dei Requisiti dello Standard ISO 27001

Struttura di ISO 27001: Annesso A vs. Clauses 4-10

Il ruolo dell’Annex A: 114 controlli di sicurezza

Processo di Determinazione dei Controlli Applicabili

Valutazione dei Rischi (Risk Assessment) e il legame con il SoA

Documentazione delle scelte: Applicabile vs. Non Applicabile

Criteri per l’esclusione dei controlli

Struttura Dettagliata del Documento SoA

Intestazione e Metadati del Documento

Tabella dei Controlli: Layout e Colonne Obbligatorie

Sezione ‘Giustificazione’ e ‘Implementazione’

Compilazione Pratica del SoA: Passo dopo Passo

Passo 1: Mappatura dei controlli dell’Annex A

Passo 2: Classificazione delle condizioni (Implementata/Non Implementata)

Passo 3: Scrittura delle giustificazioni tecniche e normative

Passo 3: Scrittura delle giustificazioni tecniche e normative

Questa fase è il cuore del vostro Statement of Applicability. Ogni decisione presa nella matrice di valutazione del rischio deve trovare qui la sua giustificazione formale, chiara e dimostrabile. La stesura di queste giustificazioni non è un mero adempimento burocratico, ma un esercizio di trasparenza e di alineamento strategico che vi proteggerà in sede di audit.

Per ogni controllo, sia esso applicato o meno, dovete fornire una motivazione concisa ma completa. Seguite sempre la regola del perché, come e rischio residuo. Ad esempio, per un controllo applicato (come l’ISO A.9.4.1 – Gestione degli accessi logici), la giustificazione potrebbe essere: “Il controllo è applicato perché la nostra policy di sicurezza informatica (Doc. P-01) richiede l’autenticazione forte per tutti gli utenti con accesso a dati riservati. La procedura implementata prevede l’uso di password con almeno 12 caratteri e MFA (Multi-Factor Authentication). Il rischio residuo, se non applicato, sarebbe l’accesso non autorizzato a dati riservati, potenzialmente conduttivo a violazioni GDPR e danni reputazionali”.

Se scegliete di non applicare un controllo (es. A.11.1.4 – Telelavoro), la giustificazione è altrettanto cruciale. Evitate frasi vaghe come “non applicabile”. Siate specifici: “Il controllo non è applicato perché l’intera azienda opera su un modello full-remote, utilizzando esclusivamente postazioni gestite e certificate (MDM) su dispositivi aziendali. Il rischio è stato valutato e mitigato attraverso policy di uso accettabile e controlli di endpoint. Il rischio residuo è considerato accettabile dalla Direzione”.

Questa documentazione dimostra che la vostra scelta non è casuale, ma il risultato di un’analisi di rischio matura. È il vostro strumento per dimostrare ai revisori (interni o esterni) la vostra padronanza del sistema di gestione e la vostra capacità di giustificare ogni scelta.

Passo 4: Integrazione con la Statement of Applicability esterna (SOAE)

Passo 4: Integrazione con la Statement of Applicability esterna (SOAE)

Una delle criticità più comuni nella gestione della sicurezza informatica è l’isolamento dei processi. Molti professionisti e aziende creano la propria Statement of Applicability (SoA) come un documento statico e monolitico, senza considerare il contesto operativo più ampio in cui l’organizzazione si muove. Questo approccio genera duplicazioni, incoerenze e una mancanza di allineamento tra i controlli interni e le esigenze di compliance richieste da clienti, fornitori o autorità di regolamentazione. Per superare questa inefficienza e garantire una postura di sicurezza armonizzata, l’integrazione con la Statement of Applicability esterna (SOAE) è un passaggio fondamentale.

La SOAE rappresenta l’insieme delle richieste di controllo che provengono dall’esterno: contratti con clienti (SLA), requisiti normativi specifici del settore (es. NIS2 per i servizi essenziali, GDPR per la privacy, DORA per il settore finanziario), standard di settore e richieste di auditor esterni. Integrare questi elementi nella propria SoA non significa semplicemente accodare liste di controlli, ma operare una fusione strategica.

Il processo prevede tre fasi chiave: raccolta, mappatura e armonizzazione. In fase di raccolta, si analizzano tutti i documenti contrattuali e normativi per estrarre i requisiti di sicurezza specifici. Successivamente, ogni requisito esterno deve essere mappato al controllo di sicurezza corrispondente presente nello standard ISO 27001 Annesso A o nei controlli aggiuntivi definiti internamente. Questa mappatura è essenziale per evitare il rischio di “control gap” o, al contrario, di applicare controlli sovradimensionati.

L’ultimo passo è l’armonizzazione. Qui, si valuta se un controllo richiesto esternamente copre già un requisito interno già implementato. Se il controllo esterno è più stringente, deve essere integrato nella SoA interna, aggiornando la descrizione e il livello di implementazione. Se un requisito esterno non trova corrispondenza nei controlli ISO 27001, è necessario definirlo come un controllo aggiuntivo personalizzato nella SoA, giustificando la sua necessità. Questo approccio integrato non solo semplifica le verifiche di compliance, ma trasforma la SoA da un semplice documento di adesione a uno strumento dinamico di gestione del rischio che riflette fedelmente l’ecosistema operativo dell’azienda, garantendo coerenza e riducendo la complessità gestionale.

Casi Pratici e Scenari Comuni

Casi Pratici e Scenari Comuni di Applicazione della SoA

Per rendere tangibile il processo di compilazione del Statement of Applicability (SoA) ISO 27001, è utile analizzare scenari reali che coinvolgono diverse tipologie di organizzazioni. Ogni scenario mette in luce decisioni specifiche, giustificazioni e rischi, dimostrando come la SoA non sia un semplice modulo, ma un strumento strategico.

Scenario 1: Startup tecnologica SaaS (B2B) con team distribuito

Una startup di 20 persone, con sede in Italia e sviluppatori remoti in Europa, offre una piattaforma di analisi dati per PMI. Non ha infrastruttura fisica propria, ma utilizza AWS, GitHub e Microsoft 365. Non è soggetta a normative specifiche oltre il GDPR.

• Contesto e sfide principali: Rischio di compromissione del codice sorgente e dei dati dei clienti. Gestione dell’accesso remoto e shadow IT. Budget limitato per strumenti di sicurezza enterprise.
• Applicabilità degli Annex A:
  • A.5.7 Threat Intelligence (Applicabile): Obbligatorio per monitorare vulnerabilità su librerie open source e dipendenze. Giustificazione: “L’uso massiccio di codice di terze parti richiede un monitoraggio continuo per prevenire vulnerabilità nella supply chain.”
  • A.5.23 Information Security for use of Cloud Services (Applicabile): Il 100% dei dati è su AWS. Giustificazione: “Necessario definire ruoli e responsabilità con il CSP (Cloud Service Provider) per garantire la sicurezza del cloud.”
  • A.7.1 Physical Security (Non Applicabile): Nessun data center fisico posseduto. Giustificazione: “L’organizzazione opera senza uffici fisici dedicati; i rischi fisici sono mitigati dai controlli del provider cloud.”
  • A.8.22 Segregation of Networks (Applicabile): Fondamentale per isolare lambiente di sviluppo, testing e produzione su VPC (Virtual Private Cloud) AWS. Giustificazione: “Impedisce l’accesso non autorizzato agli ambienti critici.”
• Lessons Learned: La startup ha inizialmente escluso A.5.7 (Threat Intelligence), ma un incidente causato da una libreria vulnerabile (log4j) l’ha costretta a reintrodurla rapidamente. La SoA dinamica è essenziale per startup in rapida evoluzione.

Scenario 2: Studio Professionale (Legale/Contabile) con elevata sensibilità dei dati

Studio di consulenza con 30 dipendenti, utilizza dispositivi mobili (laptop, tablet) per lavorare sui documenti dei clienti. Gestisce dati finanziari e legali altamente confidenziali. Forte enfasi sulla reputazione.

• Contesto e sfide principali: Rischio di perdita di dispositivi (furto o smarrimento) e accesso non autorizzato fisico o remoto. Comunicazione sicura con clienti.
• Applicabilità degli Annex A:
  • A.8.1 User Endpoint Devices (Applicabile): Critico per la crittografia dei dischi dei portatili e la gestione dei dispositivi mobili (MDM). Giustificazione: “I dispositivi mobili contengono dati sensibili dei clienti; la perdita o il furto rappresentano un rischio alto di violazione dei dati.”
  • A.5.16 Identity Management (Applicabile): Necessario implementare l’autenticazione a più fattori (MFA) per tutti gli accessi, inclusi email e sistemi di gestione documentale. Giustificazione: “L’accesso remoto richiede una verifica dell’identità robusta per prevenire il credential stuffing.”
  • A.5.24 Secure Coding (Non Applicabile): Lo studio non sviluppa software interno; utilizza solo software commerciale. Giustificazione: “L’organizzazione non ha processi di sviluppo software interni, quindi i controlli sul secure coding non sono rilevanti.”
  • A.5.31 Legal, Statutory, Regulatory and Contractual Requirements (Applicabile): Imperativo per soddisfare le normative di privacy (GDPR) e i contratti di riservatezza con i clienti. Giustificazione: “Lo studio opera in settori regolamentati e deve garantire il rispetto di obblighi legali stringenti.”
• Lessons Learned: Lo studio ha dovuto integrare controlli specifici per la gestione dei documenti (A.8.20) definendo chiaramente i criteri di classificazione (es. “Confidenziale”, “Uso interno”) per garantire che i documenti client non fossero condivisi in modo inappropriato.

Scenario 3: Manifatturiero con produzione OT (Operational Technology) e IT convergenti

Azienda manifatturiera di medie dimensioni (150 dipendenti) con impianti di produzione automatizzati. Il dipartimento IT gestisce la rete aziendale, mentre il reparto produzione gestisce PLC e SCADA.

• Contesto e sfide principali: Il rischio più alto è l’interruzione della produzione (downtime) a causa di un attacco informatico che propaghi malware dalla rete IT alla rete OT (convergenza IT/OT). Compatibilità dei sistemi legacy.
• Applicabilità degli Annex A:
  • A.5.8 Information Security in Project Management (Applicabile): Necessario per la gestione del progetto di modernizzazione della rete OT. Giustificazione: “Il progetto di integrazione IT/OT comporta rischi specifici che devono essere mitigati durante il ciclo di vita del progetto.”
  • A.5.26 Technical Vulnerability Management (Applicabile): Complesso da applicare sugli apparati OT legacy. La SoA potrebbe specificare una scadenza differita o controlli alternativi (segmentazione). Giustificazione: “Molti sistemi OT non supportano patch standard; si applicano controlli compensativi di rete (firewall, IDS).”
  • A.8.16 Monitoring Activities (Applicabile): Monitoraggio degli eventi di sicurezza sia nella rete IT che in quella OT (SIEM specializzato). Giustificazione: “Rilevamento tempestivo di anomalie che potrebbero indicare un tentativo di attacco agli impianti produttivi.”
  • A.8.24 Use of Cryptography (Applicabile ma limitata): Crittografia per i dati sensibili (IP, progetti), ma non applicabile a tutti i protocolli OT legacy per compatibilità. Giustificazione: “L’uso della crittografia è obbligatorio per la protezione dei dati, ma la sua implementazione sui protocolli OT legacy richiede valutazioni di impatto operativo.”
• Lessons Learned: L’azienda ha realizzato che la separazione netta tra IT e OT richiedeva una SoA specifica per ciascun reparto, pur mantenendo un SoA unico di alto livello. La giustificazione delle esclusioni per sistemi legacy è stato il punto critico per superare l’audit.

Scenari Comuni: Gestione delle Esclusioni (Non Applicabile)

Un errore comune è classificare un controllo come “Non Applicabile” senza una giustificazione solida. Ecco scenari frequenti:

• Software come Servizio (SaaS): Controllo A.8.2 (Privileged Access Rights). Se l’organizzazione utilizza SaaS senza capacità di gestione privilegi interna, potrebbe essere “Non Applicabile” a patto che venga citato il contratto con il fornitore che garantisce gestioni simili.
• Uffici condivisi (Co-working): Controllo A.7.3 (Physical Security perimeters). Se l’organizzazione non ha una sede propria con barriere fisiche, è “Non Applicabile”. La giustificazione deve descrivere come i controlli di sicurezza del co-working soddisfino i requisiti.
• Tecnologie obsolete: Sistemi legacy che non supportano crittografia moderna (A.8.24). L’approccio corretto non è l’esclusione totale, ma la definizione di un piano di migrazione o l’implementazione di controlli compensativi (es. segmentazione di rete), annotati nella SoA.

In tutti i casi, la documentazione nella colonna “Giustificazione” è fondamentale per l’auditor e per il management. Una giustificazione debole (“non è rilevante per noi”) porta a non conformità. Una giustificazione forte (“il controllo è gestito dal provider cloud XYZ tramite il contratto SLA X, come verificato nel report di certificazione SOC 2”) è la chiave per una SoA efficace.

Esempio di giustificazione: Controllo A.12.4.1 (Event Logging)

Per il controllo A.12.4.1 (Registrazione degli eventi), l’organizzazione ha deciso di applicare il controllo. Questa scelta è motivata da due esigenze fondamentali: la conformità normativa e l’efficacia operativa.

Dal punto di vista normativo, la registrazione degli eventi è obbligatoria per soddisfare i requisiti di diversi framework, inclusi il GDPR (per la tracciabilità delle operazioni sui dati personali) e la normativa NIS2, che impone una gestione rigorosa degli incidenti di sicurezza. Inoltre, è essenziale per l’audit trail richiesto da standard come ISO 27001 e PCI DSS.

Sul piano operativo, il logging è cruciale per il monitoraggio degli accessi non autorizzati, l’analisi forense in caso di incidente e il rilevamento tempestivo di anomalie. L’organizzazione ha definito una politica di retention dei log di 12 mesi, con archiviazione cifrata, per bilanciare sicurezza, spazio di archiviazione e requisiti di conformità.

Esempio di esclusione: Controllo A.11.1.1 (Physical security perimeter)

Esempio di esclusione: Controllo A.11.1.1 (Physical security perimeter)

Consideriamo un’azienda che offre servizi di consulenza e sviluppo software con dipendenti in full remote. L’organizzazione non possiede sedi fisiche dedicate: i dipendenti operano da casa propria, da coworking o in mobilità.

In questo scenario, il controllo A.11.1.1, che richiede l’istituzione di una perimeter fisica sicura per l’area dell’organizzazione, non è applicabile. La giustificazione tecnica ed operativa risiede nell’assenza totale di un perimetro fisico controllabile a livello aziendale. Le attività di business sono svolte esclusivamente tramite dispositivi personali e connessioni VPN cifrate, senza la necessità di proteggere un’area fisica condivisa.

L’esclusione è documentata nel SoA come segue:

• Controllo: A.11.1.1 Physical security perimeter.
• Stato: Non applicabile.
• Giustificazione: Nessuna sede fisica aziendale o perimetro di proprietà da proteggere. L’organizzazione opera esclusivamente in modalità remota con dispositivi distribuiti e connessioni sicure. Le rischi associati al controllo fisico del perimetro sono mitigati tramite policy di sicurezza dei dispositivi (BYOD) e controlli di accesso logico.

Gestione delle versioni e aggiornamenti del SoA

Gestione delle versioni e aggiornamenti del SoA

Il Statement of Applicability (SoA) è un documento vivo che richiede un rigoroso controllo delle versioni per mantenere la traccia di audit e dimostrare la conformità ISO 27001. Ogni modifica, inclusa la validazione di un controllo o la giustificazione di una esclusione, deve generare una nuova versione.

Ad ogni aggiornamento, è fondamentale aggiornare la data e descrivere sinteticamente il motivo del cambiamento (es. “incluso controllo 5.16 per gestione delle vulnerabilità”). Una migliore prassi prevede l’uso di un sistema di gestione documentale per tracciare chi ha effettuato la modifica e quando è stata approvata.

Prima di archiviare una nuova versione, verificare l’impatto sulla documentazione correlata, in particolare sul Rischio e sul piano di trattamento. Ricorda: un SoA obsoleto è uno dei motivi più comuni di non conformità durante le valutazioni di certificazione.

Strumenti e Best Practices

La redazione e la gestione di un SoA solido richiedono l’adozione di strumenti e metodologie che garantiscano coerenza, tracciabilità e continuità nel tempo. Per evitare la creazione di documenti statici e destinati a diventare obsoleti rapidamente, è fondamentale integrare il SoA nel flusso operativo quotidiano dell’organizzazione.

Strumenti essenziali per il SoA

Per semplificare la compilazione e la manutenzione, è possibile utilizzare:

• Software GRC (Governance, Risk Management & Compliance): Piattaforme specializzate permettono di mappare i requisiti ISO 27001 agli obblighi normativi, tracciare lo stato di implementazione dei controlli e generare reportistica audit-ready.
• Excel o Google Sheets (per realtà piccole): Un foglio di calcolo ben strutturato può costituire un punto di partenza valido. È cruciale però definire versionamento chiaro e policy di accesso per evitare sovrascritture.
• Gestione documentale (DMS): Utilizzare un sistema di archiviazione centralizzato per allegare evidenze, procedure e policy correlate a ogni controllo menzionato nel SoA.

Best Practices operative

Per compilare un SoA efficace, segui queste linee guida concrete:

1. Redazione dall’analisi di gap: Non partire dalla lista completa dei controlli dell’Allegato A. Inizia dalle non conformità emerse durante l’analisi dei rischi e le valutazioni di compliance. Se un controllo non mitiga un rischio rilevante, spesso può essere escluso.
2. Chiarezza nelle esclusioni: Quando decidi di escludere un controllo (es. A.15.1 – Politiche sulla sicurezza delle relazioni con i fornitori), non limitarti a scrivere “non applicabile”. Fornisci una giustificazione tecnica o di business breve ma precisa. Esempio: “Le relazioni con i fornitori sono gestite tramite accordi specifici che non richiedono una politica formale dedicata, in quanto la due diligence è inclusa nel processo di procurement aziendale”.
3. Verifica incrociata (Traceability): Ogni voce del SoA deve rispecchiare esattamente quanto contenuto nel “Rischio e Trattamento del Rischio”. Se un rischio è stato trattato implementando il controllo A.9.2.1, nel SoA deve comparire la voce corrispondente con indicazione dello stato “Implementato”.
4. Revisione periodica (Non Annuale): Il SoA non è un documento annuale. Rivedilo ogni volta che cambia l’architettura IT, che si introducono nuovi vendor o che emergono nuove minacce (es. nuovi requisiti normativi come NIS2). Definisci trigger specifici nella procedura ISMS per la revisione del SoA.

Checklist operativa per la compilazione

• Uniformità lessicale: Usa termini identici per descrivere lo stato (“Implementato”, “In attesa”, “Non applicabile”) in tutto il documento.
• Aggiornamento in tempo reale: Il SoA deve essere un “living document”. Appena un controllo viene implementato, aggiorna immediatamente lo stato e allega la prova (es. screenshot configurazione, report di test).
• Integrazione con l’organigramma: Indica chiaramente l’owner di ogni controllo (es. “Responsabile Sistemi Informativi” vs “Responsabile Risorse Umane”) per chiarezza durante gli audit.

Utilizzo di GRC (Governance, Risk and Compliance) Software

Checklist di qualità per la revisione del SoA

Per garantire che il Statement of Applicability (SoA) sia non solo conforme ma anche uno strumento operativo utile, è fondamentale una revisione strutturata. Utilizza la seguente checklist prima di finalizzare il documento.

• Completezza dei controlli: Ogni controllo dell’Allegato A della norma ISO/IEC 27001:2022 è stato valutato?
• Chiarezza delle giustificazioni: Le ragioni per l’inclusione o l’esclusione di ciascun controllo sono chiare, specifiche e legate a valutazioni di rischio reali, non generiche?
• Coerenza con il Risk Treatment Plan: I controlli selezionati devono corrispondere esattamente alle misure di trattamento del rischio definite nel piano?
• Dettagli operativi: Per ogni controllo applicabile, sono indicati responsabili, tempistiche e riferimenti a procedure documentali esistenti?
• Versionamento e tracciabilità: Il SoA riporta la data di revisione e le modifiche effettuate? È in linea con la versione corrente del sistema di gestione?
• Formattazione e leggibilità: Il documento è facilmente consultabile da tutto il personale interessato?

Conclusioni e Checklist Finale

Conclusioni e Checklist Finale

Redigere uno Statement of Applicability (SoA) ISO 27001 efficace richiede rigore metodologico e una visione chiara del contesto organizzativo. Non è una mera formalità burocratica, ma la testimonianza tangibile delle decisioni strategiche adottate per proteggere le informazioni critiche.

Il documento diventa così il ponte tra la teoria dello standard e la pratica operativa, dimostrando agli auditor, ai partner e agli stakeholder la reale maturità del sistema di gestione per la sicurezza delle informazioni (SGSI) implementato.

Checklist Finale per la Compilazione del SoA:

• Riferimento Unico: Ogni controllo è identificato tramite il codice ISO ufficiale (es. A.5.1) per evitare ambiguità.
• Decisione Chiara: Per ogni controllo, specificare esplicitamente se è “Applicabile” o “Non Applicabile”.
• Giustificazione Obbligatoria: Non lasciare mai vuoto il campo della motivazione. Spiega perché un controllo è applicabile (riferendoti ai rischi identificati) o perché non lo è (spiegando il motivo della non applicabilità o come l’obiettivo sia raggiunto diversamente).
• Implementazione Pratica: Indica documenti, procedure o responsabili specifici che danno evidenza dell’applicazione del controllo.
• Integrazione con il Rischio: Assicurati che il SoA sia in perfetto allineamento con la Mappa dei Rischi e la Dichiarazione di Applicabilità (SoA) del sistema.

Un SoA curato non solo facilita il superamento dell’audit di certificazione, ma fornisce una base solida per la gestione continua dei rischi e il miglioramento periodico del sistema.

Hai bisogno di una guida esperta per la tua certificazione ISO 27001?

Non lasciare che la complessità dello standard ISO 27001 freni la sicurezza della tua azienda. Il nostro team di specialisti in cybersecurity e governance ICT è pronto ad assisterti nella redazione del tuo Statement of Applicability e nell’implementazione di un sistema di gestione efficace.

Contattaci oggi stesso per una consulenza personalizzata e assicura la tua compliance.

Riepilogo dei punti chiave

Riepilogo dei punti chiave: lo Statement of Applicability (SoA) è un documento obbligatorio nella certificazione ISO 27001 che elenca tutti i controlli di sicurezza applicabili all’organizzazione, giustificando esclusioni e implementazioni. Deve essere redatto basandosi sui risultati dell’analisi dei rischi e tenere conto di requisiti legali, contrattuali e di business. La struttura tipica include: elenco dei controlli (Annesso A dell’ISO 27001:2022), stato di applicazione (Sì/No/Parziale), motivazione della scelta e riferimento alla implementazione. È essenziale che il SoA sia un documento vivo, aggiornato ogni volta che cambiano i rischi o i controlli. Mantenerlo chiaro e tracciabile facilita l’audit di certificazione e dimostra un approccio proattivo alla sicurezza. Per una guida personalizzata sulla compilazione, la nostra consulenza ISO 27001 di Culture Digitali Srl può supportarvi nella stesura e nell’allineamento normativo.

Errori comuni da evitare

• Copie “in bianco”: incorporare SoA generiche non validate al proprio contesto è inutile e pericoloso.
• Controllo manuale: gestire SoA su fogli di calcolo aumenta rischio di errori e falle di audit.
• Giustificazioni vaghe: evitare dichiarazioni generiche (es. “migliora la sicurezza”); spiegare sempre perché è applicabile o meno.
• Documentazione disallineata: SoA deve rispecchiare esattamente il Rischio e i controlli effettivi implementati.
• File statico: non aggiornare SoA dopo cambiamenti tecnici, normativi o organizzativi rende l’impianto obsoleto.
• Omettere l’evidenza: non collegare le dichiarazioni a policy, procedure o schede tecniche rende l’audit laborioso.

Domande Frequenti (FAQ)

Il SoA deve includere tutti i controlli dell’Annex A?

No, non è obbligatorio includere tutti i 114 controlli. Il SoA deve elencare esclusivamente i controlli che l’organizzazione ha deciso di implementare, insieme a una giustificazione per quelli non applicati. Tuttavia, la struttura standard prevede spesso di elencare tutti i controlli per chiarezza, indicando esplicitamente quali sono esclusi e perché.

Qual è la differenza tra Statement of Applicability (SoA) e Statement of Applicability esterno (SOAE)?

Il SoA (interno) è un documento operativo utilizzato dall’organizzazione per gestire l’implementazione dei controlli. La Statement of Applicability esterna (SOAE) è invece il documento ufficiale rilasciato al cliente o ad auditor esterni, spesso in formato RFP (Request for Proposal) o durante le negoziazioni commerciali, che dichiara formalmente quali controlli sono applicabili al servizio offerto.

Quanto tempo è necessario per redigere un SoA compliant?

Il tempo varia in base alla dimensione dell’organizzazione e alla complessità dell’SMS (Sistema di Gestione della Sicurezza). Generalmente, per una PMI, la redazione completa richiede dalle 2 alle 4 settimane, considerando il tempo necessario per il risk assessment preliminare e la validazione da parte dello stakeholder.

Il SoA è un documento obbligatorio per la certificazione ISO 27001?

Sì, è assolutamente obbligatorio. L’ISO 27001 richiede esplicitamente (clausola 6.1.3) che l’organizzazione determini i controlli necessari per mitigare i rischi identificati e documenti questa decisione nel Statement of Applicability. L’assenza del SoA è motivo di non conformità grave durante un audit di certificazione.

Come gestire le giustificazioni per controlli non implementati?

Le giustificazioni devono essere precise e basate su criteri oggettivi. Esempi validi includono: ‘Non applicabile perché non possediamo dati biometrici’, ‘Sostituito da controllo tecnologico X’, o ‘Il rischio residuo è accettato dalla direzione’. Evitare giustificazioni vaghe come ‘non necessario’.

Contattaci

contattaci per saperne di più