Una governance dei dati tracciabile non si misura solo dalla qualità delle policy, ma dalla capacità di ricostruire perché una decisione è stata presa, chi l’ha approvata, quali rischi sono stati accettati e quali controlli compensativi sono stati attivati. Nei contesti GDPR, NIS2, DORA, ISO 27001, Modello 231 e AI Act, molte non conformità nascono proprio nelle zone grigie: eccezioni operative, proroghe, accessi temporanei, trattamenti non standard, fornitori approvati con condizioni e remediation lasciate aperte troppo a lungo.
Questo articolo ha un taglio operativo. Non sostituisce una valutazione legale e non interpreta casi specifici, ma propone un modello per documentare decisioni e deroghe in modo verificabile durante audit interni, audit di seconda parte o verifiche di autorità e stakeholder.
Perché decisioni e deroghe sono il punto debole della governance dei dati
Le organizzazioni tendono a documentare bene i processi standard. Il problema nasce quando il processo non basta: un sistema deve restare attivo oltre la data prevista, un controllo non è ancora implementato, un fornitore non ha consegnato tutta la documentazione, un team chiede accesso urgente a dati personali o un rischio viene accettato temporaneamente.
In questi casi la governance dei dati deve produrre una traccia leggibile, non solo un messaggio in chat o una nota in una riunione. Un auditor non deve ricostruire la storia a posteriori cercando email, ticket e file sparsi. Deve poter seguire una sequenza: richiesta, analisi, decisione, approvazione, controlli compensativi, scadenza, riesame e chiusura.
Il Regolamento (UE) 2016/679 introduce il principio di responsabilizzazione, spesso chiamato accountability, secondo cui il titolare deve essere in grado di dimostrare il rispetto dei principi applicabili al trattamento. Per NIS2 e DORA il linguaggio cambia, ma l’esigenza operativa resta simile: dimostrare che rischi, controlli, incidenti e decisioni sono governati con responsabilità chiare e prove verificabili.
Che cosa tracciare: decisioni, deroghe, eccezioni e accettazioni del rischio
Non tutte le scelte operative hanno lo stesso peso. Una buona governance dei dati distingue le decisioni ordinarie dalle deroghe che modificano temporaneamente un controllo, un processo o una responsabilità.
Una decisione è una scelta documentata tra alternative, per esempio approvare una nuova modalità di raccolta dati, cambiare un owner, aggiornare un registro privacy o accettare una nuova classificazione informativa. Una deroga è invece un’autorizzazione temporanea a non applicare pienamente una regola prevista, di solito per vincoli tecnici, urgenze operative o dipendenze da terze parti.
Le accettazioni del rischio sono un caso ancora più delicato. Non dovrebbero essere trattate come semplici deroghe, perché implicano la consapevole tolleranza di un’esposizione residua entro limiti approvati. Per essere auditabile, l’accettazione deve avere un perimetro, una motivazione, una data di riesame e un responsabile con autorità adeguata.
| Oggetto da tracciare | Esempio operativo | Evidenza minima da conservare |
|---|---|---|
| Decisione | Approvazione di un nuovo flusso dati tra sistemi | Verbale o ticket approvato, analisi impatti, owner, data decisione |
| Deroga | Accesso temporaneo oltre il profilo standard | Richiesta motivata, approvazione, scadenza, controllo compensativo |
| Accettazione rischio | Remediation rinviata per vincolo tecnico documentato | Valutazione rischio, approvatore, piano di rientro, riesame periodico |
| Eccezione fornitore | Documentazione incompleta ma servizio avviato con condizioni | Due diligence parziale, condizioni contrattuali, follow up, data limite |
| Chiusura remediation | Finding risolto dopo implementazione controllo | Test eseguito, evidenza tecnica, validazione owner, audit trail |
Il registro decisionale come base della governance dei dati
Il registro decisionale non deve diventare un archivio burocratico. Deve essere uno strumento vivo, collegato a controlli, processi, rischi, trattamenti, fornitori e remediation. Se resta isolato in un foglio di calcolo non aggiornato, perde valore probatorio e diventa difficile dimostrare la catena delle responsabilità.
Per una governance dei dati realmente verificabile, ogni decisione rilevante dovrebbe avere un identificativo univoco e un legame con il requisito o il controllo interessato. Per esempio, una deroga su un accesso privilegiato dovrebbe collegarsi al controllo sugli accessi, al rischio associato, al sistema coinvolto e alla scadenza di revoca.
Campi minimi consigliati
Un modello operativo può partire da pochi campi, purché siano coerenti e obbligatori. L’obiettivo non è raccogliere testo libero, ma permettere verifiche ripetibili.
| Campo | Domanda a cui risponde | Nota di controllo |
|---|---|---|
| ID decisione o deroga | Di quale evento stiamo parlando? | Deve essere univoco e citabile in audit |
| Ambito | Quali dati, sistemi, processi o fornitori sono coinvolti? | Evita decisioni generiche non verificabili |
| Motivazione | Perché serve la decisione o la deroga? | Deve essere concreta, non solo “urgenza business” |
| Owner operativo | Chi esegue o presidia l’attività? | Non coincide sempre con l’approvatore |
| Approvatore | Chi autorizza e con quale ruolo? | Deve avere autorità coerente con il rischio |
| Rischio residuo | Che esposizione resta dopo la decisione? | Va collegato al registro rischi, se presente |
| Controllo compensativo | Che misura riduce il rischio nel frattempo? | Deve essere testabile o almeno verificabile |
| Scadenza | Quando termina la deroga o avviene il riesame? | Le deroghe senza data diventano eccezioni permanenti |
| Evidenze collegate | Quali prove dimostrano quanto dichiarato? | Ticket, log, verbali, export, screenshot, report |
Per approfondire il tema delle prove verificabili, può essere utile collegare il registro decisionale a una logica di evidenze di audit, evitando che ogni team conservi documenti in cartelle separate senza ownership chiara.
Come gestire le deroghe senza perdere controllo
Una deroga ben gestita non è un fallimento del sistema di controllo. È un meccanismo per mantenere tracciabilità quando la realtà operativa non segue il percorso standard. Diventa un problema quando viene approvata senza scadenza, senza rischio associato o senza un piano di rientro.
Nella governance dei dati, le deroghe dovrebbero seguire un flusso semplice e sempre uguale: richiesta motivata, valutazione del rischio, approvazione, applicazione del controllo compensativo, monitoraggio, riesame e chiusura. Ogni passaggio deve lasciare una prova.
Un flusso operativo in sette passaggi
| Passaggio | Output atteso | Evidenza utile in audit |
|---|---|---|
| Richiesta | Descrizione della deroga e ambito | Ticket, modulo, richiesta firmata digitalmente o approvazione workflow |
| Valutazione | Impatto su dati, sistemi, servizi e obblighi interni | Scheda rischio, DPIA se pertinente, valutazione sicurezza |
| Approvazione | Decisione esplicita con ruolo e data | Audit trail, verbale, approvazione nel sistema di workflow |
| Compensazione | Controllo temporaneo o misura alternativa | Configurazione, report, test, procedura operativa |
| Monitoraggio | Verifica che la deroga resti entro il perimetro | Log, alert, review periodica, evidenze di controllo |
| Riesame | Conferma, modifica o revoca | Decisione aggiornata, motivazione, nuova scadenza se necessaria |
| Chiusura | Rientro nello standard o accettazione formalizzata | Evidenza tecnica, validazione owner, stato finale |
Il punto critico è la chiusura. Molte organizzazioni sanno aprire deroghe, ma non riescono a dimostrare quando sono state chiuse o se il controllo standard è stato ripristinato. Questo crea un accumulo di eccezioni che indebolisce l’intero sistema di controllo.
Evidenze e audit trail: come rendere verificabile la decisione
Una decisione non è auditabile se manca il contesto. Conservare solo l’approvazione finale non basta, perché non mostra quali informazioni erano disponibili al momento della scelta, né quali alternative sono state considerate. Per questo l’audit trail deve registrare eventi, ruoli, timestamp, versioni dei documenti e modifiche di stato.
Per una governance dei dati solida, l’audit trail dovrebbe rispondere a quattro domande: chi ha fatto cosa, quando, su quale oggetto e con quale esito. Se una deroga viene prorogata, l’auditor deve vedere la proroga come nuovo evento, non come modifica silenziosa della data originaria.
La qualità dell’audit trail non dipende solo dai log tecnici. Servono metadati organizzativi: owner, approvatore, controllo collegato, rischio, scadenza, evidenze allegate e stato della remediation. Una guida più ampia su questo aspetto è disponibile nelle best practice per audit trail, con attenzione alla ricostruzione delle responsabilità.
Evidence pack per decisioni e deroghe
Un evidence pack non è una cartella con file accumulati. È un insieme organizzato di prove che consente di verificare una decisione dall’inizio alla fine. Per una deroga su un controllo di accesso, per esempio, il pack dovrebbe includere la richiesta, l’analisi del rischio, l’approvazione, la configurazione temporanea, i log di monitoraggio, il riesame e la revoca finale.
Quando l’organizzazione deve prepararsi a un audit GDPR, è utile collegare queste evidenze al programma complessivo di conformità dimostrabile, così che decisioni, registri, controlli e remediation non siano trattati come elementi separati.
Mappare la governance dei dati a GDPR, NIS2, DORA e AI Act
Il registro decisionale non deve citare norme a caso. Deve collegare ogni decisione ai requisiti interni o normativi realmente pertinenti, senza trasformarsi in un parere legale. Il ruolo operativo del compliance manager, del DPO, del CISO o dell’internal auditor è dimostrare che il processo è governato e che le evidenze sono complete.
Una governance dei dati tracciabile può supportare più framework, ma ogni framework guarda le decisioni da un angolo diverso. Il GDPR si concentra su trattamenti, ruoli, principi e diritti. La Direttiva (UE) 2022/2555, nota come NIS2, richiede attenzione a misure di gestione dei rischi di cybersicurezza e continuità dei servizi essenziali o importanti. Il Regolamento (UE) 2022/2554, noto come DORA, riguarda la resilienza operativa digitale nel settore finanziario. Il Regolamento (UE) 2024/1689, noto come AI Act, introduce obblighi specifici per determinati sistemi di intelligenza artificiale, inclusi aspetti di governance dei dati nei sistemi ad alto rischio.
| Framework | Decisioni da rendere tracciabili | Evidenze operative utili |
|---|---|---|
| GDPR | Nuovi trattamenti, modifiche al registro, accessi, conservazione, misure tecniche e organizzative | ROPA, valutazioni, approvazioni, log accessi, informative versionate, DPIA se applicabile |
| NIS2 | Deroghe su controlli di sicurezza, gestione vulnerabilità, continuità, incidenti | Registro rischi, piani di remediation, report di controllo, evidenze incident response |
| DORA | Eccezioni su resilienza ICT, test, fornitori ICT critici o importanti | Registro ICT risk, test report, piani di rientro, evidenze di monitoraggio fornitori |
| AI Act | Decisioni su dataset, qualità dei dati, supervisione umana e cambiamenti del sistema, se pertinenti | Schede dataset, approvazioni, valutazioni qualità, log modifiche, evidenze di controllo |
Questa mappatura non serve a “dimostrare la norma” in astratto. Serve a rendere verificabile il legame tra un requisito, un controllo, una decisione e la prova che l’organizzazione ha agito in modo coerente con il proprio modello di governance.
Metriche per una governance dei dati controllabile
Le metriche non devono diventare un esercizio cosmetico. Devono aiutare a capire se decisioni e deroghe sono sotto controllo o se stanno creando debito operativo. Alcuni indicatori sono semplici ma molto utili in audit.
Una governance dei dati matura può monitorare il numero di deroghe aperte, la durata media, le deroghe scadute, le proroghe ripetute, le decisioni senza owner, le remediation oltre scadenza e la percentuale di evidenze respinte in fase di review. Non servono soglie universali: ogni organizzazione dovrebbe definire limiti interni coerenti con rischio, settore e complessità.
Controlli di secondo livello
I controlli di secondo livello servono a verificare che il processo sia rispettato, non a rifare il lavoro del primo livello. Un campionamento trimestrale può controllare se ogni deroga ha motivazione, approvatore, rischio, scadenza e prova di chiusura. Se mancano campi ricorrenti, il problema non è solo documentale: potrebbe indicare che il workflow non guida abbastanza gli owner.
Un controllo efficace produce finding, azioni correttive e responsabilità. Se l’audit rileva deroghe scadute senza riesame, la remediation non dovrebbe limitarsi ad aggiornare le date. Dovrebbe correggere la causa: assenza di alert, owner non chiari, approvatori non formati o workflow troppo permissivo.
Errori comuni da evitare
Il primo errore è confondere approvazione e tracciabilità. Un’approvazione isolata dimostra che qualcuno ha detto sì, ma non dimostra che la decisione fosse informata, limitata e monitorata. Il secondo errore è trattare le deroghe come note informali, senza collegarle a rischi, controlli e scadenze.
Il terzo errore è non versionare le decisioni. Se una deroga cambia ambito, durata o controllo compensativo, serve una nuova versione o un nuovo evento nell’audit trail. Sovrascrivere il record originale elimina informazioni utili e rende più difficile ricostruire il percorso.
Il quarto errore è non distinguere tra owner e approvatore. L’owner presidia l’esecuzione e la raccolta delle prove. L’approvatore si assume la responsabilità della decisione secondo il modello interno. Se i ruoli coincidono sempre, il sistema può perdere indipendenza nei casi più rischiosi.
Checklist operativa prima di un audit
Prima di un audit, non limitarti a esportare un elenco di deroghe. Verifica che ogni record racconti una storia completa e coerente. Un revisore deve poter aprire una decisione e capire il contesto senza chiedere spiegazioni orali non documentate.
Usa questa checklist come controllo rapido:
- Ogni decisione o deroga ha un ID univoco e una data di apertura.
- L’ambito indica dati, sistemi, processi, fornitori o controlli coinvolti.
- Sono presenti owner operativo e approvatore con ruolo riconoscibile.
- La motivazione è specifica e collegata a un’esigenza reale.
- Il rischio residuo è documentato o collegato al registro rischi.
- La deroga ha scadenza, riesame e controllo compensativo.
- Le proroghe sono tracciate come eventi separati.
- La chiusura include evidenza tecnica o validazione dell’owner.
- Le evidenze sono versionate e collegate al controllo interessato.
- I finding aperti hanno remediation, responsabile e data target.
Questa checklist non sostituisce una valutazione normativa, ma aiuta a preparare un pacchetto di evidenze leggibile e difendibile.
FAQ
Che differenza c’è tra deroga e accettazione del rischio? Una deroga autorizza temporaneamente uno scostamento da una regola o da un controllo. L’accettazione del rischio formalizza la decisione di tollerare un rischio residuo entro un perimetro approvato. In entrambi i casi servono owner, motivazione, scadenza, evidenze e riesame.
Una decisione presa via email è sufficiente per l’audit? Può essere un’evidenza, ma spesso non basta da sola. È meglio collegarla a un registro strutturato che includa contesto, rischio, approvatore, controllo interessato, scadenza e stato della remediation.
Quanto tempo conservare le evidenze delle deroghe? Dipende da obblighi applicabili, policy interne, tipo di trattamento, contratto e rischio. Operativamente conviene definire una regola di retention approvata e applicarla in modo coerente, evitando cancellazioni non tracciate.
Chi dovrebbe approvare una deroga sui dati? L’approvatore deve avere autorità coerente con impatto e rischio. In base al caso possono essere coinvolti IT, security, compliance, DPO, risk owner, business owner o funzione legale. Questo articolo non fornisce pareri legali su ruoli obbligatori.
Come si dimostra che la governance dei dati è sotto controllo? Si dimostra collegando decisioni, controlli, rischi, owner, audit trail ed evidenze. L’auditor deve poter verificare non solo che esista una policy, ma che le eccezioni siano state gestite, monitorate e chiuse.
Se devi preparare un audit GDPR e vuoi organizzare decisioni, deroghe, evidenze e remediation in un evidence pack strutturato, puoi valutare AuditReady per la conformità GDPR.
audit-ready evidence pack demo / not legal advice