Redigere una Statement of Applicability che regge all'audit

La clausola 6.1.3(d) della ISO/IEC 27001 richiede una Dichiarazione di applicabilità (Statement of Applicability, SoA): un documento che elenca i controlli necessari, spiega perché li hai inclusi, se sono implementati e perché hai escluso eventuali controlli dei 93 dell'Allegato A. Sembra un adempimento formale. In pratica è il ponte tra la valutazione del rischio e i controlli, e gli auditor di certificazione la leggono con attenzione, perché una SoA debole di solito indica un processo di gestione del rischio debole alle sue spalle.

Cosa deve contenere

Per ogni controllo dell'Allegato A, e per eventuali controlli propri:

1. Applicabile o non applicabile.
2. La giustificazione dell'inclusione: di norma i rischi che il controllo tratta, un requisito legale o contrattuale, oppure una decisione di business.
3. Stato di implementazione: implementato, parzialmente implementato o pianificato.
4. La giustificazione dell'esclusione, se il controllo è escluso.

La maggior parte delle SoA aggiunge una breve descrizione di come ciascun controllo è implementato e un riferimento alla policy o alla procedura. Non è strettamente richiesto, ma rende gli audit molto più rapidi.

Giustificare l'inclusione

Collega ogni controllo a qualcosa di concreto: un rischio nel tuo registro, un obbligo di legge (Art. 32 del GDPR, NIS2, normativa di settore), un contratto o un requisito di un cliente. «Best practice» è una giustificazione debole; «tratta i rischi R-12 e R-17 ed è richiesto dai nostri obblighi NIS2» è una forte. Collegare i controlli ai requisiti di legge aiuta anche quando rispondi a più framework: le nostre pagine dei requisiti mostrano quali altri framework mappa ciascun controllo dell'Allegato A, ad esempio A.8.24 uso della crittografia.

Giustificare l'esclusione

Le esclusioni sono consentite, ma ciascuna richiede una motivazione che l'auditor possa verificare. Motivazioni valide:

• L'attività non avviene nel perimetro. Nessuno sviluppo esternalizzato: A.8.30 escluso.
• Il rischio non esiste nel perimetro. Un'organizzazione completamente remota, senza uffici, può escludere alcuni controlli fisici della A.7, ma non quelli che riguardano apparecchiature e supporti, ovunque si trovino.

Motivazioni deboli: «non pertinente», «se ne occupa l'IT», «lo fa il fornitore cloud». Se un fornitore esegue il controllo, il controllo resta applicabile; lo gestisci tramite i controlli sui fornitori.

Criticità ricorrenti negli audit

• La SoA non corrisponde al piano di trattamento del rischio. I controlli scelti nel trattamento del rischio devono comparire nella SoA, e viceversa.
• Controlli implementati senza evidenze. Indicare un controllo come implementato porta a una richiesta di prova.
• Linguaggio da modello. Descrizioni copiate da un template che non corrispondono a ciò che fai davvero.
• Versioni obsolete. Una SoA che riporta ancora la numerazione dell'Allegato A del 2013, o non aggiornata dopo un cambiamento significativo.

Una struttura pratica

Una riga per controllo: ID e titolo, applicabilità (sì/no), motivazione (rischi, requisiti legali e contrattuali), stato, una descrizione in una riga di come è realizzato, il responsabile e il riferimento alle evidenze. Conservala in un foglio di calcolo o nel tuo strumento GRC sotto controllo documentale, e rivedila a ogni valutazione del rischio.

Mantenere la SoA aggiornata

Una SoA scritta per la prima certificazione e mai più toccata diventa una non conformità al successivo audit. Mantienila aggiornata modificandola ogni volta che:

• la valutazione del rischio modifica i controlli selezionati;
• cambia il perimetro (un nuovo prodotto, ufficio o fornitore cloud);
• cambia lo stato di implementazione di un controllo;
• si applica un nuovo requisito legale o contrattuale (ad esempio NIS2 o il contratto di un cliente).

Registra ogni volta versione, data e approvatore.

Punti chiave

• Ogni controllo dell'Allegato A richiede una decisione e una motivazione, comprese le esclusioni.
• Collega le inclusioni a rischi specifici e a requisiti legali o contrattuali.
• Mantieni la SoA coerente con il piano di trattamento del rischio e aggiornata.

Gestire più framework insieme

Se rispondi anche a SOC 2, NIS2 o PCI DSS, aggiungi una colonna per i requisiti corrispondenti di ciascuno. La SoA diventa allora la base di un set di controlli comune; il nostro articolo su un unico set di controlli per SOC 2 e ISO 27001 illustra l'approccio, e la Gap analysis elenca ogni controllo dell'Allegato A rispetto a qualsiasi altro framework. La guida ISO 27001 copre il resto della certificazione.

Domande

Si possono escludere controlli dell'Allegato A nella ISO 27001?

Sì, se l'esclusione è giustificata, tipicamente perché il rischio non esiste nel tuo perimetro (ad esempio lo sviluppo esternalizzato quando non esternalizzi lo sviluppo). Le esclusioni devono essere giustificate nella Statement of Applicability.

Cosa deve contenere una Statement of Applicability?

La clausola 6.1.3(d) della ISO 27001 richiede i controlli necessari, la giustificazione per la loro inclusione, se sono implementati e la giustificazione per l'esclusione di eventuali controlli dell'Allegato A.

La Statement of Applicability viene condivisa con i clienti?

Di norma non per intero; è un documento interno, esaminato dall'organismo di certificazione. Alcune organizzazioni condividono con i clienti un riassunto, sotto NDA, per mostrare quali controlli si applicano.