ISO 27001 Allegato A: rendere operativi i 93 controlli

L'Allegato A (Annex A) offre ai team di sicurezza un utile insieme di riferimento. Il suo valore operativo deriva dalla capacità di mostrare perché un controllo si applica, come è attuato e quali evidenze lo supportano nel vostro ambiente. Un registro con 93 indicatori di stato verdi non basta se nessuno sa spiegare quali sistemi coprono.

Per un CTO, la sfida pratica è tradurre l'intento dei controlli in lavoro tecnico e operativo senza trasformare il sistema di gestione per la sicurezza delle informazioni in una burocrazia parallela. Le revisioni degli accessi dovrebbero utilizzare dati reali sulle autorizzazioni. I piani di ripristino dovrebbero riflettere le dipendenze dei servizi. Le valutazioni dei fornitori dovrebbero riguardare i servizi che l'azienda utilizza effettivamente.

Questa guida spiega come selezionare i controlli, distribuire le responsabilità, definire le attuazioni e verificare le affermazioni che ne derivano. Le frequenze di revisione e gli esempi di attuazione che seguono sono raccomandazioni pratiche, non intervalli universali prescritti dalla norma.

Capire che cosa fa l'Allegato A e che cosa non fa

La ISO/IEC 27001:2022 contiene 93 controlli dell'Allegato A suddivisi in quattro temi. I punti da 4 a 10 contengono i requisiti del sistema di gestione: contesto dell'organizzazione, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento. L'Allegato A supporta la selezione dei controlli; non sostituisce tali requisiti né la vostra valutazione dei rischi.

La distinzione è importante durante l'attuazione. Una configurazione di backup può supportare un controllo selezionato, ma non dimostra che abbiate definito il campo di applicazione del SGSI, valutato i rischi, svolto un audit interno o completato il riesame della direzione. Si tratta di attività distinte con evidenze distinte.

La selezione dei controlli si basa sul rischio. Determinate i controlli necessari per trattare i vostri rischi, poi confrontateli con l'Allegato A per verificare che nessun controllo necessario sia stato omesso. Possono essere necessari controlli aggiuntivi non presenti nell'Allegato A. Viceversa, un'esclusione motivata è possibile; non esiste una regola secondo cui ogni organizzazione debba escludere qualcosa o attuare esattamente la stessa selezione.

La ISO/IEC 27002:2022 fornisce una guida all'attuazione dei controlli. I suoi attributi aiutano a organizzarli per tipo di controllo, proprietà di sicurezza delle informazioni, concetto di cybersecurity, capacità operativa e dominio di sicurezza. Sono utili strumenti di filtro, non checklist di certificazione aggiuntive. Per la formulazione autorevole consultate le norme in licenza.

Usare i quattro temi per trovare i responsabili giusti

I temi forniscono una struttura di navigazione, non quattro filoni di lavoro indipendenti. Un processo di uscita del personale, per esempio, collega responsabilità legate al rapporto di lavoro, amministrazione delle identità, restituzione delle attrezzature e accesso alle applicazioni.

Controlli organizzativi: collegare la governance alle decisioni operative

Questi controlli riguardano politiche, responsabilità, separazione dei compiti, asset, classificazione e gestione delle informazioni, governance degli accessi, fornitori, incidenti, continuità, obblighi di legge e attività di riesame.

Iniziate individuando dove vengono prese le decisioni. Chi approva un nuovo servizio cloud? Chi assegna una classificazione delle informazioni? Chi decide se un evento segnalato è un incidente? Una politica dovrebbe rendere tali decisioni ripetibili e attribuire i relativi poteri, invece di limitarsi a esprimere sostegno alla sicurezza.

La sicurezza dei fornitori richiede una catena di evidenze specifica per il servizio: la finalità di business del servizio, le informazioni che tratta, i rischi valutati, le responsabilità contrattuali e il riesame continuo. Il report di assurance di un fornitore può supportare questa valutazione, ma il suo ambito, il periodo di riferimento e le responsabilità a carico del cliente devono corrispondere al vostro utilizzo.

Analogamente, la gestione degli incidenti richiede più di un elenco di contatti di emergenza. Definite canali di segnalazione, criteri di valutazione, poteri di risposta, gestione delle evidenze e attività di apprendimento. Registrate esercitazioni o risposte effettive, comprese le azioni successive e i relativi responsabili.

Controlli sulle persone: rendere gli eventi del rapporto di lavoro inneschi affidabili

Gli otto controlli sulle persone riguardano screening, termini e condizioni di impiego, consapevolezza e formazione, processo disciplinare, responsabilità dopo la cessazione o la variazione del rapporto di lavoro, riservatezza, lavoro da remoto e segnalazione degli eventi.

Integrateli nei processi esistenti relativi al personale. Chi entra in azienda ha bisogno di obblighi, accessi e istruzioni adeguati. Chi cambia ruolo ha bisogno di una rivalutazione delle autorizzazioni, non di semplici aggiunte. Chi lascia l'azienda ha bisogno della rimozione degli accessi, della restituzione degli asset e di chiarezza sulle responsabilità di riservatezza che permangono.

La responsabilità coinvolge spesso più team. Le risorse umane possono avviare un'uscita, gli amministratori delle identità disattivano l'account centrale, i responsabili delle applicazioni rimuovono gli accessi gestiti localmente e un manager conferma il completamento. Assegnare l'intero processo alla sicurezza nasconde queste dipendenze.

Tra le evidenze utili figurano registrazioni approvate dei flussi di lavoro, completamento della formazione e solleciti per le attività scadute, condizioni accettate e campioni di variazioni del rapporto di lavoro. Limitate l'accesso alle evidenze sensibili delle risorse umane: chi revisiona un controllo non ha automaticamente bisogno dei fascicoli completi del personale.

Controlli fisici: documentare il proprio perimetro e quello del fornitore

I controlli fisici riguardano sedi, accessi, monitoraggio, minacce ambientali, aree sicure, scrivanie e schermi, apparecchiature, supporti di memorizzazione, utenze, cablaggi, manutenzione e smaltimento.

Anche un'organizzazione cloud-first deve considerare la sicurezza fisica. Una parte dell'attuazione può essere fornita da un fornitore cloud, mentre gli accessi agli uffici e i dispositivi dei dipendenti restano di sua responsabilità. Registrate questa ripartizione invece di escludere automaticamente l'intero tema.

Per le vostre sedi, individuate chi può entrare, come cambiano gli accessi, dove si trovano le apparecchiature sensibili e come vengono gestiti i visitatori. Per i dispositivi remoti, definite modalità di custodia, trasporto, riparazione e smaltimento adeguate ai rispettivi rischi.

Le evidenze possono comprendere registrazioni delle autorizzazioni di accesso, procedure per i visitatori, inventari delle apparecchiature e registrazioni degli smaltimenti. Le evidenze dei fornitori dovrebbero indicare le strutture e i servizi coperti; non vanno considerate prova dei controlli sui vostri uffici o portatili.

Controlli tecnologici: definire la copertura prima di scegliere gli strumenti

Il tema tecnologico riguarda endpoint, accessi privilegiati, autenticazione, accesso al codice sorgente, capacità, malware, vulnerabilità, configurazioni, gestione dei dati, backup, resilienza, logging, monitoraggio, reti, crittografia, sviluppo e gestione delle modifiche.

Partite dalla copertura dei sistemi. Una politica sulle identità è incompleta se gli accessi alla produzione, gli account di servizio o un'applicazione gestita separatamente restano fuori dalla sua attuazione. Una piattaforma di logging è incompleta se gli eventi critici non la raggiungono mai o se nessuno risponde agli alert.

Per lo sviluppo software, collegate requisiti e decisioni di progettazione a code review, test di sicurezza, separazione degli ambienti, gestione dei dati di test e approvazione dei rilasci. Il threat modeling può aiutare a individuare i requisiti di sicurezza prima dell'implementazione. La profondità dei test dovrebbe seguire rischi e obblighi; la ISO 27001 non impone un calendario universale per i penetration test.

Per la crittografia, distinguete i dati a riposo da quelli in transito e documentate titolarità, accesso, recupero, rotazione e revoca delle chiavi. «Cifratura attivata» lascia senza risposta importanti questioni di attuazione.

Che cosa è cambiato nel 2022 e dove cercare le lacune

L'edizione 2013 contava 114 controlli in 14 domini. L'edizione 2022 li ha riorganizzati in 93 controlli suddivisi in quattro temi, inclusi 11 controlli nuovi. Un numero inferiore non significa meno lavoro di sicurezza: l'accorpamento può riunire diverse responsabilità operative sotto un unico riferimento.

Quando aggiornate un registro precedente, preservate le attuazioni e le evidenze sottostanti invece di limitarvi a sostituire gli identificativi. Verificate se il nuovo raggruppamento modifica la copertura, le responsabilità o i test necessari a supportare il vostro stato.

Il termine di transizione per le certificazioni accreditate ISO/IEC 27001:2013 era il 31 ottobre 2025. Quei certificati non sono più validi; aggiornare soltanto il registro dei controlli non costituisce una certificazione rispetto all'edizione 2022.

Quelli che seguono sono punti di partenza pratici per gli 11 nuovi controlli, non riproduzioni del loro testo ufficiale.

Evitate di considerarli undici acquisti automatici di prodotti. Per esempio, la threat intelligence richiede analisi e azione, non soltanto l'abbonamento a un feed. La cancellazione dei dati richiede la comprensione di copie, backup e obblighi di conservazione, non soltanto un pulsante di eliminazione. Il monitoraggio richiede un percorso di risposta operativo.

Registrare separatamente applicabilità e attuazione

La vostra Dichiarazione di applicabilità (Statement of Applicability, SoA) dovrebbe indicare i controlli necessari, spiegarne l'inclusione, registrare se sono attuati e motivare le esclusioni dei controlli dell'Allegato A. Questi requisiti rientrano nelle disposizioni sul trattamento del rischio della ISO/IEC 27001.

Utilizzare tutti i 93 riferimenti come indice di revisione è un modo pratico per rendere il confronto verificabile. Includete anche gli eventuali controlli aggiuntivi necessari. La SoA non è il registro dei rischi, il piano di trattamento né l'archivio delle evidenze, anche se dovrebbe collegarsi a ciascuno di essi dove pertinente.

Per ogni controllo applicabile, registrate:

• I rischi o gli obblighi che ne motivano l'inclusione.
• I sistemi, le sedi, le informazioni e i processi pertinenti.
• L'attuazione effettiva e il responsabile.
• Le evidenze a supporto e il relativo periodo di riesame.
• Dipendenze, eccezioni e lavori non completati.
• La data del prossimo riesame o l'evento che lo attiva.

Mantenete l'applicabilità indipendente dallo stato di attuazione. «Applicabile, parzialmente attuato» è una registrazione onesta e utile. «Non applicabile perché non abbiamo acquistato uno strumento» non è una motivazione di applicabilità.

Un'esclusione dovrebbe descrivere i fatti relativi al campo di applicazione che rendono il controllo non necessario e restare coerente con la valutazione dei rischi. «Non sviluppiamo software» va verificato se un fornitore esterno sviluppa il vostro portale clienti. L'esternalizzazione modifica il percorso di attuazione e delle evidenze; non elimina automaticamente il rischio.

Per le attuazioni distribuite, registrate la ripartizione. Un controllo di protezione fisica può dipendere da strutture di hosting gestite dal fornitore, dagli accessi agli uffici gestiti dall'azienda e dal modo in cui i dipendenti gestiscono i dispositivi. Un unico responsabile può rispondere dell'affermazione complessiva, mentre team diversi svolgono le attività.

Una descrizione dell'attuazione utile è abbastanza specifica da poter essere verificata: «Gli amministratori della produzione ricevono accessi nominativi e approvati tramite il servizio di identità; gli accessi di emergenza sono registrati e riesaminati separatamente». «Gli accessi sono gestiti in modo sicuro» non può guidare né un ingegnere né un revisore.

Verificare l'affermazione dietro lo stato

Una politica descrive il comportamento previsto. Può dimostrare progettazione e approvazione, ma da sola non può dimostrare il funzionamento. Costruite una catena di evidenze che vada dal requisito al meccanismo attuato e poi a un risultato osservato.

Per la gestione degli accessi, confrontate le regole approvate con le autorizzazioni effettive degli utenti e con le registrazioni delle uscite. Includete, dove pertinente, le identità privilegiate, gli account non personali e le applicazioni esterne alla gestione centralizzata delle identità. Registrate la popolazione, il campione e le eccezioni, invece di presentare un unico screenshot di comodo.

Per i backup, esaminate la configurazione e un risultato di ripristino. Un job di backup riuscito dimostra meno di un recupero riuscito di informazioni utilizzabili. Verificate autorizzazioni, dipendenze e obiettivi di ripristino; un database ripristinato senza le sue chiavi di cifratura può non ripristinare il servizio.

Per la sicurezza dei fornitori, collegate la valutazione al servizio specifico e alle responsabilità contrattuali. Verificate se le evidenze coprono il servizio che utilizzate e se le responsabilità individuate a carico del cliente sono attuate.

Una registrazione pratica di un test dovrebbe contenere il risultato atteso, il metodo, l'ambito, la data dell'evidenza, il revisore, il risultato e la decisione successiva. Distinguete:

• Progettazione: il meccanismo proposto affronta il rischio individuato.
• Attuazione: il meccanismo esiste nell'intero ambito dichiarato.
• Funzionamento: le registrazioni mostrano che ha funzionato nel periodo di riferimento.
• Efficacia: i test indicano che raggiunge il risultato previsto.

Le evidenze possono comprendere configurazioni, esportazioni, ticket, contratti, interviste e osservazioni fisiche. Selezionate evidenze che supportino l'affermazione effettiva. Un'esportazione della configurazione può mostrare le impostazioni attuali; i ticket storici possono mostrare se le eccezioni sono state gestite nel tempo.

Preservatene la provenienza: sistema di origine, data di raccolta, periodo coperto ed eventuali filtri. Proteggete le evidenze che contengono segreti o informazioni personali con restrizioni di accesso e oscuramenti adeguati. La raccolta delle evidenze non dovrebbe creare un nuovo archivio incontrollato di dati sensibili.

Esempio pratico: rendere verificabile il processo di uscita

Consideriamo, a titolo illustrativo, un'azienda SaaS con 45 dipendenti, un ufficio, hosting nel cloud, gestione centralizzata delle identità e due applicazioni con account locali. Sono ipotesi esemplificative, non risultati di clienti Secani.

Il rischio è il mantenimento dell'accesso a informazioni dei clienti o dell'azienda dopo l'uscita. I controlli pertinenti comprendono le responsabilità legate alla variazione del rapporto di lavoro, la gestione delle identità, i diritti di accesso e la restituzione degli asset. Anche l'autenticazione tecnica e le restrizioni di accesso supportano l'attuazione.

L'azienda registra il controllo come applicabile. Le risorse umane sono responsabili dell'avvio della procedura di uscita; l'IT delle azioni su identità e dispositivi; ciascun responsabile di applicazione della rimozione degli account locali. Il manager del dipendente conferma la tempistica richiesta per l'uscita. Il responsabile della sicurezza riesamina il processo e le eccezioni non risolte.

L'attuazione comprende un ticket di uscita autorizzato, la disattivazione programmata dell'account centrale, la revoca delle sessioni ove supportata, la rimozione degli account locali, la restituzione degli asset e la verifica delle credenziali gestite dalla persona. I segreti condivisi vengono cambiati ove necessario; gli account personali non vengono riassegnati con leggerezza a un successore.

Il pacchetto di evidenze collega la procedura approvata, il ticket di uscita, le registrazioni delle azioni sugli account, le conferme relative alle applicazioni locali e la registrazione delle apparecchiature. Ogni elemento supporta una parte definita dell'affermazione.

Durante una revisione illustrativa, il team esamina quattro uscite. Gli account centrali sono stati disattivati come previsto, ma un'applicazione locale ha mantenuto l'accesso per due giorni. Il controllo non viene dichiarato pienamente efficace sulla sola base delle evidenze relative alle identità centrali.

Il responsabile dell'applicazione rimuove l'account, valuta se vi siano stati accessi e registra l'esito. Il team aggiunge l'applicazione alla checklist di uscita e assegna una fase di riconciliazione. L'azione di trattamento riceve un responsabile e una scadenza; un test successivo verifica che il flusso rivisto funzioni.

Questo esempio mostra perché le evidenze devono seguire le dipendenze. Quattro sistemi che indicano «completato» non dimostrano il completamento se un quinto sistema non è mai stato incluso.

Mantenere operativi i controlli tra un riesame e l'altro

I controlli cambiano quando cambiano sistemi, fornitori, persone ed esigenze di business. Oltre ai riesami programmati, definite eventi che attivano un riesame, come rilasci significativi, nuovi servizi, cambiamenti delle sedi, incidenti e obblighi modificati.

Utilizzate una cadenza adeguata alla variabilità e al rischio. Le eccezioni sugli accessi privilegiati possono richiedere un riesame tempestivo, mentre una politica stabile può seguire un ciclo più lungo integrato da eventi di modifica. Sono scelte della direzione, non frequenze universali dell'Allegato A.

Monitorate un numero ridotto di indicatori utili: correzioni scadute, sistemi non coperti, eccezioni sulle evidenze non risolte e test dei controlli falliti. Teneteli separati dal conteggio dei documenti. Un ampio archivio di evidenze può comunque lasciare non testato un ambiente di produzione critico.

L'audit interno fornisce una valutazione separata del SGSI; i riesami ordinari da parte dei responsabili dei controlli non lo sostituiscono. Analogamente, il riesame della direzione richiede decisioni della leadership su prestazioni, cambiamenti, risorse e miglioramento, non soltanto un foglio di calcolo dei controlli compilato. La certificazione è svolta da un organismo di certificazione indipendente, non dall'ISO né da un fornitore di software.

Tra gli errori comuni figurano assegnare tutto alla sicurezza, copiare le esclusioni di un'altra organizzazione, affidarsi ai certificati dei fornitori senza verificarne l'ambito e chiudere i rilievi quando cambia una politica invece che quando il processo rivisto è stato verificato.

Partire da un servizio e da una catena di evidenze completa

Scegliete un servizio rappresentativo e ricostruitene sistemi, fornitori, informazioni e responsabili operativi. Selezionate un piccolo insieme di controlli correlati, come accessi, gestione delle modifiche, logging e ripristino, e rendete verificabile ciascuna attuazione prima di ampliare il registro.

Secani supporta questo flusso di lavoro modellando sistemi e dipendenze, collegando le evidenze a requisiti, controlli e decisioni e tracciando le lacune come attività. Assegnate un responsabile e un revisore, allegate le registrazioni esistenti e conservate commenti e approvazioni della revisione. Considerate le mappature o le sintesi assistite dall'IA come bozze: validate le fonti e mantenete esplicita l'approvazione umana. Preparazione strutturata all'audit illustra il modello di evidenze sottostante.

Il primo risultato dovrebbe essere una catena coerente che va dal rischio al controllo, all'attuazione, all'evidenza, al risultato del test e alla decisione successiva. Questa catena può poi essere ripetuta nel resto del campo di applicazione senza inventare un nuovo processo per ogni riferimento dell'Allegato A.

Domande pratiche

Una sola registrazione può supportare più controlli?

Sì. Un ticket di uscita può supportare diversi controlli correlati. Spiegate quale affermazione supporta per ciascuno; condividere un'evidenza non rende identici i controlli.

Ogni controllo deve avere una propria politica?

No. Organizzate politiche e procedure attorno a processi operativi comprensibili. Un solo documento può riguardare più controlli, purché responsabilità e attuazione restino chiare.

Da dove dovrebbe provenire l'elenco autorevole dei controlli?

Utilizzate la norma ISO/IEC 27001 in licenza per la formulazione dell'Allegato A e la ISO/IEC 27002 per la guida all'attuazione. Le sintesi operative sono utili strumenti di orientamento, non sostituti delle norme.