Dai requisiti alle evidenze: come rendere dimostrabile la compliance

Con l'aumento degli obblighi normativi, per le organizzazioni diventa sempre più importante poter dimostrare come la compliance viene attuata nella pratica. Policy e procedure restano necessarie, ma non sempre consentono di capire se un controllo stia funzionando, quale sia il suo effettivo perimetro o come siano state gestite le criticità emerse durante una verifica.

Le evidenze, inoltre, raramente si trovano nello stesso posto. I log sono conservati nei sistemi IT, le informazioni sui fornitori seguono processi propri, le verifiche possono essere affidate a funzioni diverse e le azioni correttive vengono spesso monitorate in strumenti separati. Quando questi elementi devono essere ricondotti a un unico requisito e utilizzati per sostenere una valutazione di compliance, la frammentazione diventa un problema concreto.

Un processo GRC può aiutare a mantenere questi collegamenti e a ricostruire il percorso che porta da un requisito alla relativa verifica. Per essere realmente utile, però, deve permettere di capire che cosa è stato esaminato, con quali evidenze e fino a che punto il risultato ottenuto possa essere considerato attendibile.

Dalla previsione normativa alla verifica

Il GDPR contiene già una chiara dimensione probatoria. L'articolo 5, paragrafo 2, richiede al titolare di essere in grado di dimostrare il rispetto dei principi applicabili al trattamento. L'articolo 24 richiede l'adozione di misure tecniche e organizzative adeguate e il loro riesame quando necessario. Sul piano della sicurezza, l'articolo 32, paragrafo 1, lettera d), prevede espressamente una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure adottate.

La NIS2 segue la stessa direzione in materia di cibersicurezza. L'articolo 21, paragrafo 2, lettera f), include strategie e procedure per valutare l'efficacia delle misure di gestione dei rischi. I poteri di vigilanza previsti dagli articoli 32 e 33 comprendono inoltre la possibilità di richiedere evidenze sull'attuazione delle politiche di cibersicurezza, inclusi i risultati degli audit e la documentazione che li supporta.

Per alcuni soggetti, il Regolamento di esecuzione (UE) 2024/2690 precisa ulteriormente come organizzare queste valutazioni, indicando aspetti quali le misure da monitorare, le modalità utilizzate, le responsabilità e le tempistiche. Anche ENISA, nelle proprie indicazioni tecniche, propone esempi di evidenze che possono essere utilizzate a supporto dei diversi requisiti.

Ne emerge un quadro in cui non è sufficiente che una misura sia formalizzata. Occorre anche poter ricostruire come è stata applicata e su quali elementi si basa la valutazione della sua efficacia.

Il perimetro cambia il significato del risultato

La gestione degli accessi rende questo problema particolarmente evidente.

Nel processo di offboarding, le risorse umane registrano le cessazioni mentre l'IT può utilizzare un workflow per revocare gli accessi. Se alcune cessazioni presenti nei registri HR non compaiono nel workflow IT, un campione estratto soltanto da quest'ultimo non potrà mai intercettarle.

La stessa difficoltà si presenta quando alcune applicazioni vengono gestite al di fuori della piattaforma centrale di identity management. La verifica degli account centrali può essere svolta correttamente, ma il risultato non dice nulla sugli account amministrati localmente in altri sistemi.

Prima di attribuire un giudizio di efficacia al controllo, occorre quindi capire che cosa sia stato effettivamente incluso nella verifica. Un risultato può essere corretto rispetto al campione esaminato e, allo stesso tempo, non coprire l'intero processo.

A questo si aggiunge la distinzione tra progettazione del controllo e sua esecuzione. Se la procedura di offboarding non comprende affatto gli account locali, verificare che le richieste relative agli account centrali siano state completate nei tempi previsti non elimina quella lacuna. Il processo può essere stato eseguito correttamente, pur rimanendo incompleto nel suo disegno.

Questi limiti tendono a perdersi quando il risultato viene sintetizzato in una dashboard o in un report destinato al management. Mantenere visibili il perimetro esaminato, le fonti utilizzate e le eventuali esclusioni evita che una valutazione venga letta in modo più ampio di quanto consenta la verifica svolta.

Le evidenze devono rispondere alla domanda giusta

Una volta definito il perimetro, resta da capire se l'evidenza utilizzata sia davvero adatta al controllo che si vuole valutare.

Il caso dei backup è particolarmente chiaro. L'articolo 32 GDPR richiama la capacità di ripristinare tempestivamente disponibilità e accesso ai dati personali dopo un incidente. La NIS2 include la gestione dei backup e il disaster recovery tra le misure relative alla continuità operativa.

Un log che registra la corretta esecuzione di un backup conferma che il processo programmato è stato completato. Per capire se i dati siano effettivamente recuperabili occorre invece verificare il ripristino. Il test può documentare il sistema interessato, l'esito, i tempi di recupero e gli eventuali problemi riscontrati. Anche le attuali misure di sicurezza di base adottate dall'ACN prevedono, per i soggetti interessati, attività di verifica sul ripristino.

Una logica simile vale per la gestione delle vulnerabilità. Una scansione fotografa gli asset inclusi nell'attività e le vulnerabilità rilevate in quel momento. I ticket di remediation e le verifiche successive mostrano che cosa è accaduto dopo. Se alcuni sistemi non rientravano nella scansione, questo limite deve restare visibile nella valutazione.

Nel rapporto con i fornitori, invece, la documentazione evolve nel tempo. La due diligence iniziale e le clausole contrattuali descrivono la situazione all'onboarding. Con il proseguire del rapporto diventano rilevanti anche le verifiche periodiche, gli audit e la gestione delle criticità emerse durante il servizio.

Il tipo di evidenza cambia quindi insieme al controllo e al momento in cui lo si osserva. Accumulare documentazione non basta se quella documentazione non risponde alla questione che si sta realmente valutando.

Il caso Modena: quale misura era operativa in quel momento?

Il provvedimento del Garante del 17 aprile 2026 relativo all'Azienda USL di Modena aggiunge un ulteriore elemento: il momento a cui si riferisce la valutazione.

Il procedimento è seguito a un attacco ransomware. Durante l'istruttoria, l'azienda sanitaria ha descritto le misure di sicurezza adottate e alcuni interventi di miglioramento già programmati. Il Garante ha esaminato quali protezioni fossero effettivamente operative quando si è verificato l'attacco.

In quel momento, l'accesso remoto tramite VPN non prevedeva ancora l'autenticazione a più fattori. La MFA era stata pianificata, ma è entrata in funzione soltanto dopo l'incidente, quando il servizio VPN è stato riattivato. L'Autorità ha inoltre rilevato carenze nel monitoraggio, tra cui limiti nelle funzionalità del SIEM, assenza di un Security Operation Center e un presidio umano ristretto all'orario d'ufficio.

Il Garante ha accertato violazioni degli articoli 5, paragrafo 1, lettera f), e 32 GDPR e ha irrogato una sanzione di 10.000 euro.

Il caso mostra perché lo stato di una misura deve essere collocato correttamente nel tempo. La pianificazione documenta ciò che l'organizzazione intende fare, mentre l'introduzione della misura dopo un incidente documenta l'intervento correttivo. Per valutare la situazione precedente occorre guardare ai controlli che erano già operativi.

La stessa considerazione vale anche fuori dal contesto di un incidente. Una verifica degli accessi svolta prima di un cambiamento rilevante nel sistema di identity management può rimanere corretta rispetto al periodo esaminato, ma non descrive necessariamente la nuova configurazione. Modifiche a sistemi, fornitori o processi possono quindi rendere necessario riesaminare conclusioni precedenti.

Quando una remediation può dirsi conclusa?

Le evidenze continuano ad avere un ruolo anche dopo l'individuazione di una criticità.

Si consideri una revisione dei tempi di conservazione che individui dati mantenuti oltre il periodo previsto. La cancellazione dei dati risolve i casi emersi. Se però l'origine del problema è un archivio escluso dal meccanismo automatico di cancellazione, occorre correggere anche il processo che ha permesso alla situazione di verificarsi.

Il task di cancellazione può quindi risultare completato mentre la remediation del controllo è ancora aperta. Una volta modificato il processo, può essere necessario verificarne il funzionamento prima di considerare risolta la criticità.

La NIS2 affronta espressamente anche questa fase. L'articolo 21, paragrafo 4, richiede l'adozione senza ingiustificato ritardo delle misure correttive necessarie, appropriate e proporzionate quando viene rilevata una non conformità rispetto alle misure previste dal paragrafo 2.

Anche la reportistica interna dovrebbe mantenere questa distinzione. Un intervento può essere stato eseguito senza che la sua efficacia sia già stata verificata, mentre una criticità può rimanere aperta anche se alcune delle azioni associate risultano completate.

Per il management, al quale la NIS2 attribuisce responsabilità nell'approvazione delle misure di gestione dei rischi di cibersicurezza e nella supervisione della loro attuazione, questa differenza non è soltanto terminologica. Incide sulla rappresentazione effettiva dello stato dei controlli.

Una reportistica che possa essere ricostruita

Con il passare del tempo, la qualità delle evidenze dipende anche dalla possibilità di ricostruire il contesto in cui sono state raccolte.

Non è necessario trasferire ogni log o documento tecnico all'interno di una piattaforma GRC. In molti casi gli originali possono rimanere nei sistemi che li hanno generati, purché esistano riferimenti affidabili e modalità adeguate per recuperarli. Ciò evita anche la creazione di copie non necessarie di dati personali o informazioni sensibili sulla sicurezza.

È invece utile conservare insieme al risultato le informazioni che permettono di interpretarlo: quando è stata svolta la verifica, quali sistemi ha riguardato, quali fonti sono state utilizzate e quali limitazioni sono emerse. In questo modo diventa più semplice capire se una conclusione formulata in passato sia ancora applicabile dopo modifiche organizzative o tecniche.

La profondità delle verifiche deve naturalmente essere proporzionata al rischio. GDPR e NIS2 richiedono di considerare elementi quali la natura del trattamento, la criticità dei sistemi, l'esposizione alle minacce e le possibili conseguenze di un incidente. Un controllo relativo a un sistema critico richiederà quindi normalmente un livello di verifica maggiore rispetto a un processo con impatto limitato.

Tutto questo assume particolare rilievo quando una valutazione deve essere spiegata a distanza di tempo, durante un audit o in sede di vigilanza. GDPR e NIS2 attribuiscono alle autorità poteri correttivi e sanzionatori significativi. Una lacuna documentale, da sola, non determina automaticamente una sanzione, ma l'organizzazione deve poter spiegare quali misure erano in vigore, come sono state valutate e come sono state gestite le eventuali carenze.

Un processo GRC ben costruito facilita questa ricostruzione senza trasformare la compliance in una raccolta indiscriminata di documenti. Le evidenze rimangono legate alla verifica che le ha generate e alle azioni che ne sono seguite, così che il risultato possa essere interpretato correttamente anche quando viene ripreso in un momento successivo.