Come motivare correttamente l’esclusione di un controllo nella SoA

Motivare l’esclusione di un controllo ISO 27001 significa spiegare perché quella misura non è necessaria nel contesto concreto dell’organizzazione, collegando la decisione a perimetro dell’ISMS, rischi, attività, tecnologie e requisiti applicabili. Una formula generica come “non pertinente” descrive soltanto la conclusione; una motivazione corretta permette invece a chi legge la Dichiarazione di Applicabilità di ricostruire il ragionamento che ha portato a quella conclusione.

La distinzione è particolarmente importante perché un controllo non necessario non coincide con un controllo necessario ma non ancora implementato. Nel primo caso la valutazione dei rischi e del contesto consente di giustificarne la non applicabilità; nel secondo esiste invece una misura da attuare, che deve rimanere visibile nel piano di trattamento e nello stato della SoA. Utilizzare l’esclusione per nascondere un’implementazione incompleta rende incoerente l’intero percorso tra rischio, trattamento e controllo.

Per la struttura complessiva del documento è utile partire dalla guida su cos’è la Dichiarazione di Applicabilità, mentre l’approfondimento sui controlli ISO/IEC 27001:2022 chiarisce come funziona il reference set dell’Annex A e perché i 93 controlli non devono essere interpretati come altrettanti requisiti automaticamente applicabili.

Perché un’esclusione debole emerge subito durante l’audit

La ISO/IEC 27001:2022 richiede che l’organizzazione determini innanzitutto i controlli necessari attraverso il trattamento del rischio e li confronti successivamente con quelli dell’Annex A, verificando che nessuna misura necessaria sia stata dimenticata. Quando, al termine di questo confronto, un controllo dell’Annex A viene determinato come non necessario, la motivazione deve essere conservata nella SoA.

Da qui deriva la facilità con cui un’esclusione poco argomentata può essere approfondita durante l’audit. Di fronte a una riga che riporta soltanto “N/A”, “non pertinente” o “non applicabile alla società”, il verificatore non dispone di elementi sufficienti per comprendere se la decisione derivi realmente dal contesto oppure sia stata inserita per semplificare la compilazione.

Una motivazione circostanziata offre invece già il percorso da verificare. Se la SoA dichiara che un determinato controllo relativo allo sviluppo software non è necessario perché nel perimetro ISMS non vengono sviluppate applicazioni, non esistono repository di codice e tutti i software utilizzati sono prodotti esterni senza accesso ai sorgenti, l’auditor può controllare la correttezza di queste premesse attraverso architettura, inventario degli asset, contratti o interviste.

La guida dell’ISO/IEC 27001 Auditing Practices Group sulla Statement of Applicability chiarisce precisamente che la giustificazione deve riflettere contesto e gestione dei rischi dell’organizzazione, e non limitarsi al fatto che un controllo compaia o meno nell’Annex A.

Cosa rende accettabile la motivazione di un controllo non applicabile

Una buona motivazione deve rispondere implicitamente a tre domande: quale condizione rende il controllo non necessario, dove vale questa condizione e su quale elemento concreto si basa la valutazione.

La prima componente è il contesto: scrivere che un controllo non serve perché “non pertinente” non identifica alcuna caratteristica dell’organizzazione; specificare invece che il processo, la tecnologia o l’attività a cui il controllo si riferisce non esistono all’interno dell’ambito certificato fornisce già una ragione riesaminabile.

La seconda componente è il perimetro: una misura può risultare non necessaria in un ISMS limitato a determinati servizi e diventare indispensabile se l’ambito viene ampliato. La motivazione dovrebbe quindi evitare affermazioni assolute sull’intera azienda quando la decisione riguarda in realtà soltanto il campo di applicazione dell’ISMS.

La terza componente riguarda rischi e requisiti: anche se un’attività non viene svolta direttamente dall’organizzazione, non è detto che il relativo rischio scompaia: un processo può essere affidato a un fornitore e continuare a essere rilevante per l’ISMS. Allo stesso modo, obblighi legali, contrattuali o richieste delle parti interessate possono rendere necessaria una misura anche quando la valutazione puramente tecnica suggerirebbe il contrario.

Una motivazione robusta segue quindi una struttura semplice:

condizione concreta + relazione con il perimetro + ragione per cui il controllo non è necessario, e, quando opportuno, aggiunge il riferimento all’evidenza che permette di verificare quella condizione.

Motivazioni deboli e motivazioni solide: alcuni esempi

La differenza emerge bene confrontando formulazioni plausibili ma poco informative con motivazioni che esplicitano realmente il ragionamento.

Situazione	Motivazione debole	Motivazione più solida
Accesso al codice sorgente	“Non sviluppiamo software”	“Nel perimetro ISMS non vengono sviluppati né mantenuti software proprietari, non esistono repository di codice sorgente e le applicazioni utilizzate sono prodotti di terzi senza accesso ai sorgenti; il controllo relativo all’accesso al codice non risulta pertanto necessario nel contesto attuale.”
Lavoro remoto	“Non applicabile”	“Le attività comprese nell’ambito ISMS vengono svolte esclusivamente dalle sedi aziendali e la policy vieta l’accesso remoto ai sistemi interessati; non risultano account o infrastrutture abilitate al lavoro da remoto.”
Servizio specifico non presente	“L’azienda non lo usa”	“Nessun sistema compreso nell’ambito ISMS utilizza il servizio o la tecnologia a cui il controllo si riferisce; l’inventario degli asset e l’architettura corrente non riportano componenti di questa tipologia.”
Attività affidata all’esterno	“Gestita dal fornitore”	Motivazione insufficiente di per sé: l’esternalizzazione non elimina automaticamente la necessità del controllo; occorre verificare se il rischio rimanga rilevante e debba essere governato attraverso requisiti, contratti o controllo del fornitore.
Controllo non ancora realizzato	“Non applicabile al momento”	Esclusione impropria: se il controllo è necessario ma non ancora implementato, deve essere mantenuto come applicabile e riportato nello stato o nel piano di attuazione.

Gli ultimi due casi sono particolarmente importanti perché mostrano che una frase formalmente più dettagliata non rende automaticamente corretta l’esclusione. Se il rischio continua a esistere, oppure il trattamento ha già determinato che il controllo è necessario, il problema non è trovare una motivazione migliore: il controllo non dovrebbe essere escluso. La motivazione deve quindi nascere dalla valutazione, non essere scritta a posteriori per giustificarne l’esito.

Come collegare l’esclusione alle evidenze

Una SoA non deve trasformarsi in un archivio nel quale allegare ogni documento dell’ISMS; deve però permettere di ricostruire su quali condizioni concrete si fonda la decisione di applicabilità.

Se l’esclusione deriva dall’assenza di sviluppo software, per esempio, possono essere pertinenti l’inventario applicativo, la descrizione dell’architettura, i contratti dei servizi SaaS o la documentazione dei processi IT. Quando riguarda una determinata modalità di lavoro, diventano utili policy, configurazioni degli accessi o informazioni organizzative; se dipende dal perimetro fisico, potranno essere rilevanti planimetrie, contratti e definizione dell’ambito ISMS.

L’evidenza non serve soltanto in audit: permette soprattutto di riesaminare la decisione quando cambia l’organizzazione. Una motivazione del 2026 può essere perfettamente corretta e diventare falsa l’anno successivo se l’azienda introduce sviluppo interno, abilita il lavoro remoto, migra un servizio sul cloud oppure acquisisce una nuova sede. Se la SoA conserva il collegamento tra esclusione e premessa che la giustificava, il riesame diventa immediato: basta verificare se quella premessa continui a essere vera.

La stessa logica impedisce di conservare esclusioni “storiche” per semplice inerzia. L’applicabilità appartiene al contesto corrente dell’ISMS, e deve cambiare insieme a quel contesto.

Checklist prima di pubblicare la SoA

Prima di chiudere una nuova versione della Dichiarazione conviene controllare l’intera catena logica, non soltanto la presenza di testo nella colonna “motivazione”.

Controllo finale	Cosa verificare
Perimetro aggiornato	La motivazione fa riferimento all’ambito ISMS attualmente valido
Risk assessment coerente	L’esclusione non contraddice rischi o trattamenti già determinati
Confronto Annex A completato	Tutti i controlli di riferimento sono stati effettivamente considerati
Motivazione specifica	Non vengono utilizzate formule generiche come “N/A” senza spiegazione
Necessary controls presenti	Tutti i controlli determinati come necessari compaiono nella SoA, anche se provengono da altre fonti
Stato distinto dall’applicabilità	Un controllo necessario ma incompleto non viene classificato come non applicabile
Evidenze rintracciabili	Le condizioni citate nella motivazione possono essere verificate
Fornitori considerati	L’esternalizzazione non viene utilizzata automaticamente come ragione di esclusione
Coerenza con il piano di trattamento	SoA e risk treatment plan non descrivono due situazioni differenti
Versione identificata	La SoA pubblicata è riconoscibile e separabile dalle revisioni successive

Questo controllo finale è particolarmente utile quando la matrice è stata aggiornata nel corso di molti mesi, perché le incongruenze raramente nascono da una singola decisione macroscopicamente sbagliata; più spesso derivano da rischi aggiornati senza modificare la SoA, controlli completati senza cambiarne lo stato o esclusioni ereditate da una precedente versione del sistema.

Come EvalisDeck gestisce esclusioni e motivazioni nel Percorso E

Nel Percorso E — Statement of Applicability di EvalisDeck, applicabilità e motivazione vengono gestite nello stesso flusso nel quale sono valutati i controlli, proprio per evitare che la giustificazione venga ricostruita soltanto al momento della pubblicazione.

La piattaforma lavora su 174 controlli mappati su cinque quadri, mantenendo distinta questa libreria operativa dai 93 controlli di riferimento dell’Annex A della ISO/IEC 27001:2022. Per ciascuna voce la decisione deve essere accompagnata dalle informazioni necessarie a renderla coerente con il resto della valutazione; un’esclusione senza motivazione scritta non può semplicemente passare come completa.

Il controllo automatico diventa ancora più importante quando applicabilità e stato vengono combinati. Una voce determinata come applicabile ma lasciata senza stato non viene ignorata e non migliora artificialmente il risultato, mentre un controllo necessario ma ancora incompleto rimane nel piano di attuazione anziché essere spostato tra quelli non applicabili. Il sistema confronta inoltre quanto dichiarato nelle diverse fasi e segnala le contraddizioni prima della pubblicazione.

Questa struttura risponde precisamente al problema operativo affrontato nell’articolo: quando la matrice comprende decine o centinaia di controlli, il rischio non è soltanto dimenticare di scrivere una motivazione, ma perdere coerenza tra rischio, applicabilità, stato, evidenza e versione del documento.

Al termine del percorso, lo Statement viene pubblicato come versione numerata e immutabile, così una successiva revisione dell’applicabilità produce una nuova fotografia del sistema senza modificare retroattivamente quella già consegnata o portata in audit. Per vedere direttamente come vengono gestite esclusioni, motivazioni e verifiche di coerenza è possibile entrare nella demo guidata di EvalisDeck e aprire il Percorso E dell’azienda dimostrativa.

---

FAQ sulle esclusioni nella SoA