SoA Dichiarazione di Applicabilità.

Perché ISO 27001 rende il SoA obbligatorio

La dichiarazione di applicabilità è il ponte tra il vostro lavoro sui rischi e i controlli che un auditor ispezionerà effettivamente. ISO/IEC 27001 lascia deliberatamente aperto il corpo della norma su quali controlli dobbiate attuare, perché la risposta corretta dipende dal vostro contesto e dai vostri rischi. Il SoA è dove colmate quel divario: per ogni controllo di riferimento dell'Allegato A, registrate se si applica, la giustificazione per includerlo o escluderlo, se è già attuato e dove risiedono le evidenze a supporto. È uno dei pochi documenti che la norma indica esplicitamente come output richiesto, motivo per cui nessun audit di certificazione procede senza di esso.

Un modo utile di pensarci è che il SoA trasforma un catalogo di controlli generico in una dichiarazione che riguarda specificamente la vostra organizzazione. Il set di riferimento dell'Allegato A è lo stesso per tutti. Il vostro SoA no. Due aziende certificate di dimensioni simili possono legittimamente escludere controlli diversi, perché le loro valutazioni del rischio e il loro contesto operativo differiscono. Il documento esiste per rendere quelle scelte visibili e difendibili anziché implicite.

Come il SoA si collega alla valutazione del rischio e al trattamento del rischio

Il SoA non sta in piedi da solo. È il prodotto a valle della valutazione del rischio e del piano di trattamento del rischio, e i tre devono concordare. La valutazione del rischio identifica cosa potrebbe andare storto. Il piano di trattamento del rischio decide cosa fare per ciascun rischio, compresi quali controlli applicare. Il SoA dichiara poi, controllo per controllo, cosa significa quella decisione rispetto al set di riferimento dell'Allegato A. Quando un auditor legge il SoA, in realtà sta verificando che la linea che va da un rischio documentato a una decisione di trattamento, poi a un controllo applicato, poi a un'evidenza reale, regga da un capo all'altro.

Le esclusioni meritano particolare attenzione. Contrassegnare un controllo come non applicabile è legittimo, ma solo con una motivazione dichiarata e legata al vostro contesto. «Non sviluppiamo software internamente» è una base difendibile per restringere certi controlli di sviluppo. «Non ci siamo arrivati» non è un'esclusione, è una lacuna. Gli auditor indagano le esclusioni proprio perché è lì che le organizzazioni a volte nascondono lavoro incompiuto.

Ciò che i professionisti mantengono realmente

Trattare il SoA come un registro vivo anziché come un foglio di calcolo una tantum è ciò che separa un audit di sorveglianza scorrevole da una corsa affannosa. In pratica, mantenerlo bene assomiglia a questo:

1. Tenete una riga per ogni controllo dell'Allegato A, con applicabilità, giustificazione, stato di attuazione e un riferimento all'evidenza che un auditor possa seguire senza di voi nella stanza.
2. Rigenerate il SoA ogni volta che cambiano la valutazione del rischio o il piano di trattamento, così che i tre documenti non divergano mai in silenzio.
3. Collegate ogni riferimento all'evidenza a qualcosa di reale e attuale: una politica, una configurazione, un ticket, un log, non una promessa di produrlo in seguito.
4. Riesaminate il documento a una cadenza fissa e in occasione del riesame della direzione, non solo nelle settimane precedenti un audit.
5. Nel passaggio tra versioni della norma, rimappate il SoA rispetto al set di controlli rivisto e confermate che nulla sia sfuggito tra controlli accorpati o di nuova introduzione.

Fatto in questo modo, il SoA smette di essere scartoffie da audit e diventa l'indice dell'intero sistema di gestione della sicurezza delle informazioni. È il primo documento che un auditor esperto richiede, perché gli dice dove risiede tutto il resto.