Audit GDPR checklist: 10 controlli e prove per l'audit

Questa audit GDPR checklist misura quindi la distanza tra testo, sistema reale e prova. Ogni controllo indica perché fallisce, quale evidenza minima conservare, chi risponde dell'esecuzione e quale errore produce di norma un finding. Il focus è operativo, non legale, e non sostituisce la consulenza specialistica. L'obiettivo è costruire una catena ricostruibile nel tempo, dalla policy alla remediation.

Il contesto italiano rende questa prova ricorrente, non eccezionale. Nel 2024 il Garante per la protezione dei dati personali ha ricevuto in Italia 2.204 notifiche di violazione dei dati personali, pari a circa 6 notifiche al giorno. Numeri di questo tipo spostano la verifica dall'esistenza della procedura alla capacità di rilevare, valutare e documentare ogni decisione.

Chi propone, chi approva, chi esegue e chi verifica devono restare distinti. Quando la stessa persona modifica il trattamento, aggiorna il registro e chiude il controllo, l'audit trail perde valore probatorio.

Indice

• 1. Registro dei trattamenti (art. 30 GDPR)
  • Campi ed evidenze minime del registro
• 2. Verifica della base giuridica e delle informative (artt. 5, 6, 13-14 GDPR)
  • Prova da conservare per ogni versione
• 3. Gestione delle richieste degli interessati (artt. 12-22 GDPR)
  • Campi minimi del registro DSAR
• 4. Valutazione d'impatto sulla protezione dei dati (DPIA, art. 35 GDPR)
• 5. Gestione delle violazioni dei dati e notifica (artt. 33-34 GDPR)
  • Record minimo di ogni incidente privacy
• 6. Nomina e monitoraggio dei responsabili del trattamento (art. 28 GDPR)
  • Evidenza minima per ciascun responsabile
• 7. Trasferimenti di dati verso paesi extra-SEE (artt. 44-49 GDPR)
• 8. Conservazione e cancellazione dei dati (art. 5, par. 1, lett. e) GDPR)
  • Come rendere verificabile la retention
• 9. Misure di sicurezza e controllo degli accessi (art. 32 GDPR)
  • Dalla misura dichiarata alla misura verificata
• 10. Privacy by design e approvazione delle modifiche (art. 25 GDPR)
• Controlli GDPR da verificare prima dellaudit
• Dalla checklist al pacchetto di prove per l'audit
  • Errori comuni che indeboliscono l'audit
  • Verifica pre-audit in sette domande

1. Registro dei trattamenti (art. 30 GDPR)

Il registro fallisce raramente perché manca. Fallisce perché descrive l'organizzazione di un anno prima, mentre uffici e fornitori hanno già introdotto nuovi sistemi. Un trattamento avviato senza passaggio dal titolare, un SaaS non censito o una conservazione modificata nel processo rompono subito la coerenza con informative, contratti e DPIA.

Il punto è particolarmente critico per le PMI. L'articolo 30, paragrafo 5, del GDPR esime le organizzazioni con meno di 250 dipendenti, ma l'eccezione non opera quando i trattamenti presentano rischi per i diritti e le libertà degli interessati, non sono occasionali o riguardano categorie particolari di dati. Basta un trattamento continuativo come la gestione del personale perché l'esenzione cessi di applicarsi.

Campi ed evidenze minime del registro

• ID trattamento e processo: collegamento a sistema, applicazione e fornitore effettivi. Il controllo cede quando il record cita un processo generico e il fornitore reale resta fuori.
• Owner e finalità: responsabile di funzione, base giuridica e categorie di dati e interessati. Senza un owner nominativo, nessuno risponde quando il trattamento cambia.
• Destinatari e conservazione: responsabili, trasferimenti, termine e regola operativa di cancellazione. Un termine scritto senza la regola che lo esegue è una prova che non regge.
• Riesame: data, autore della modifica, approvazione e versione precedente conservata. Una riga senza data dice solo che qualcuno ha aggiornato, non quando né perché.

Dico sempre di testare il registro al contrario. Prendete tre sistemi reali, per esempio presenze HR, CRM e helpdesk, e risalite al record corrispondente. Se il software presenze è partito prima dell'aggiornamento del registro, aprite un finding con owner e scadenza. Conservate anche i trattamenti dismessi, con data di cessazione e cancellazione. Una versione datata, con hash o marcatura temporale, dimostra cosa era noto in una data specifica.

2. Verifica della base giuridica e delle informative (artt. 5, 6, 13-14 GDPR)

Un'informativa corretta nel testo può comunque produrre un finding se il sistema raccoglie di più, per finalità diverse o per periodi più lunghi. È il caso tipico del modulo newsletter che alimenta anche una profilazione non dichiarata. Qui il problema non è la formulazione giuridica. È la mancata corrispondenza tra registro, punto di raccolta, configurazione applicativa e versione pubblicata.

La verifica deve incrociare, trattamento per trattamento, base giuridica, informativa collegata, canale di raccolta e comportamento reale del sistema. Per un sito o un modulo digitale, strumenti e servizi descritti nella pagina su iubenda con Amedeo Draghi possono supportare la pubblicazione, ma non sostituiscono il controllo sulla coerenza operativa.

Non verificate solo cosa l'informativa dichiara. Verificate cosa il sistema fa davvero nel momento in cui raccoglie il dato.

Prova da conservare per ogni versione

Conservate storico delle versioni, data di pubblicazione, autore della modifica, revisione del DPO e trattamenti coperti. Uno screenshot senza data vale poco. Acquisite invece screenshot con timestamp, URL o build applicativa e hash del file, così da ricostruire la versione attiva a una data di raccolta.

Se l'audit rileva una finalità assente dall'informativa, assegnate la correzione al responsabile del canale, non genericamente alla funzione privacy. La chiusura richiede la nuova versione in produzione e una verifica sul modulo reale, non soltanto il documento approvato.

3. Gestione delle richieste degli interessati (artt. 12-22 GDPR)

Le DSAR cedono quasi sempre all'intake. Una richiesta arriva via PEC a una casella non presidiata, resta in una chat o viene inoltrata senza registrazione. Quando il team inizia a lavorarla, il termine è già partito da giorni. L'auditor confronta quindi data di ricezione, identificazione dell'interessato, scadenza, risposta e cancellazioni effettuate nei sistemi collegati.

Serve un unico punto di ingresso, con istruzioni chiare per chi riceve richieste su altri canali. La procedura per rendere verificabile il sistema di gestione delle richieste deve trasformare ogni contatto in un record tracciabile, senza lasciare la scadenza nella casella email del singolo operatore.

Campi minimi del registro DSAR

• ID e canale: data e ora di ricezione, canale originario e inoltratore.
• Interessato e diritto: verifica identità quando necessaria, tipo di richiesta e sistemi coinvolti.
• Owner e scadenza: responsabile, termine calcolato, proroghe motivate e stato.
• Chiusura verificabile: risposta inviata, azioni sui fornitori e controllo a campione dell'esecuzione.

Una cancellazione chiusa nel CRM ma non eseguita dal fornitore di email marketing resta una non conformità. Conservate la conferma del fornitore e, in caso di diniego, la motivazione documentata. Raccomando di verificare a campione le chiusure, perché lo stato completato non prova l'avvenuta cancellazione.

4. Valutazione d'impatto sulla protezione dei dati (DPIA, art. 35 GDPR)

La DPIA diventa debole quando viene trattata come documento di lancio e poi dimenticata. Il trattamento cambia fornitore, aggiunge una finalità o integra una nuova fonte dati, ma la valutazione continua a descrivere il sistema originario. Ancora più grave è una misura dichiarata e mai implementata, per esempio una pseudonimizzazione indicata nella DPIA ma assente nella configurazione.

Il controllo parte dallo screening. Ogni progetto rilevante deve lasciare una decisione datata, anche quando la DPIA non è richiesta. Quella motivazione negativa è spesso l'evidenza che manca in audit. Quando la DPIA è dovuta, servono contenuti minimi, consultazione del DPO, valutazione del rischio residuo, approvazione e data di revisione.

Prendiamo un sistema di videosorveglianza introdotto senza screening documentato. Il finding non si chiude producendo un testo retroattivo. Si chiude bloccando o condizionando l'attivazione, valutando il trattamento reale e assegnando ogni misura a un owner con evidenza tecnica.

• Gate di progetto: screening obbligatorio prima dell'approvazione IT.
• Misure tracciate: owner, stato di implementazione e prova di test.
• Revisione attiva: riesame periodico e a ogni modifica sostanziale.

Una DPIA senza collegamenti a registro, fornitori e controlli di sicurezza resta un esercizio descrittivo. L'auditor cerca invece coerenza tra rischio dichiarato, mitigazioni operative e stato effettivo del sistema.

5. Gestione delle violazioni dei dati e notifica (artt. 33-34 GDPR)

La procedura data breach non fallisce quasi mai sulla carta. Fallisce nei timestamp. Nessuno registra quando l'evento è stato scoperto, quando è diventato una violazione accertata e chi ha deciso di notificare o non notificare. Senza questi tre momenti, anche una gestione tecnicamente corretta diventa indifendibile.

I numeri confermano che non è un controllo teorico. Secondo il Garante Privacy, nel 2025 in Italia sono state registrate 2.415 notifiche di data breach, il 10% in più rispetto al 2024, con 130 ispezioni nello stesso anno.

Record minimo di ogni incidente privacy

• Fatti e tempi: scoperta, accertamento, sistemi e categorie di dati coinvolti.
• Valutazione del rischio: criteri applicati, interessati potenzialmente colpiti e impatto.
• Decisione sulla notifica: responsabile, motivazione, scadenza e comunicazioni effettuate.
• Remediation: cause, azioni correttive, owner e verifica di chiusura.

Tenete distinti incidente di sicurezza, violazione di dati personali e finding di audit. Un invio errato a un cliente, per esempio, richiede valutazione privacy separata dal ticket IT di richiamo del messaggio. Collegateli tra loro, ma non confondetene registri e decisioni.

Consiglio esercitazioni periodiche con casi realistici, perché rivelano subito contatti di escalation obsoleti e tempi di valutazione non sostenibili.

6. Nomina e monitoraggio dei responsabili del trattamento (art. 28 GDPR)

La firma dell'accordo ex art. 28 viene spesso scambiata per la fine del controllo. In audit è solo l'inizio. L'auditor chiede come il fornitore è stato valutato prima dell'avvio, quali evidenze sono state riesaminate, chi ha autorizzato i sub-responsabili e cosa è successo quando una garanzia è scaduta o un data center è cambiato.

Il processo di qualifica e monitoraggio continuo dei fornitori deve quindi collegare contratto, registro dei trattamenti, questionario, documenti ricevuti e riesami successivi. Un questionario compilato dal fornitore non equivale a un'evidenza verificata.

Evidenza minima per ciascun responsabile

• Contratto e perimetro: accordo vigente, trattamenti coperti e istruzioni documentate.
• Valutazione iniziale: criteri, documenti esaminati, esito e approvazione.
• Sub-responsabili: notifiche ricevute, autorizzazioni e obiezioni con data.
• Riesame periodico: frequenza basata sulla criticità, evidenze aggiornate e azioni aperte.

Supponiamo che un fornitore helpdesk sposti il supporto fuori dallo SEE. Il controllo efficace intercetta la comunicazione, aggiorna registro e valutazione trasferimenti e conserva la decisione del titolare. Se la comunicazione resta in una email commerciale, il cambiamento emerge solo durante l'audit.

Richiedete le evidenze tramite canali tracciati e a scadenza, registrando invio, ricezione e periodo di validità. La responsabilità della valutazione resta interna, anche quando la raccolta documentale è supportata da una piattaforma.

7. Trasferimenti di dati verso paesi extra-SEE (artt. 44-49 GDPR)

I trasferimenti più rischiosi sono quelli indiretti. Il contratto indica un fornitore europeo, ma il supporto remoto accede da un paese terzo oppure i backup vengono replicati fuori dall'Unione. Se il registro riporta solo la sede legale, la mappa è formalmente completa e operativamente falsa.

La verifica sui trasferimenti di dati verso paesi extra UE deve partire da flussi, log, sub-responsabili e localizzazione effettiva di dati e metadati. Per ogni flusso servono base giuridica del trasferimento, garanzie applicate, valutazione del contesto quando richiesta e conferma aggiornata del destinatario.

Regola pratica: chiedete dove risiedono dati, backup, log e accessi di supporto. La sede legale del fornitore non risponde a nessuna di queste domande.

Prendiamo un servizio di monitoraggio con un nodo di backup extra-UE non dichiarato. Il finding richiede aggiornamento del registro, verifica delle clausole firmate e conferma scritta sulla localizzazione. Non basta aggiungere il paese al registro senza riesaminare la garanzia applicabile.

Conservate versione delle clausole, data di firma, esito delle verifiche sul destinatario e trigger di riesame. Quando cambiano fornitore, sub-responsabile, decisione di adeguatezza o architettura, il controllo va rieseguito. Una valutazione storica senza data di revisione non dimostra che il trasferimento sia ancora coperto.

8. Conservazione e cancellazione dei dati (art. 5, par. 1, lett. e) GDPR)

Il termine di conservazione dichiarato nell'informativa non prova nulla se nessun sistema lo applica. È qui che molti controlli cedono. Le candidature restano archiviate per anni oltre il termine, le mailbox conservano allegati senza regola e i log non hanno scadenza. L'auditor non cerca una policy elegante. Chiede l'ultima cancellazione eseguita e il relativo log.

Ogni categoria di dati deve avere termine, motivazione, sistema interessato e regola operativa. Se la cancellazione è manuale, servono frequenza, operatore, criterio di selezione e verifica. Se è automatica, servono configurazione, esito dei job e gestione degli errori.

Come rendere verificabile la retention

• Regola per sistema: termine collegato a database, file, mailbox, log e fornitori.
• Log di esecuzione: data, perimetro, quantità trattate e anomalie, senza conservare i dati cancellati.
• Backup governati: scadenza, rotazione e comportamento dopo un ripristino.
• Eccezioni motivate: base dell'obbligo, owner e data di riesame.

Un log trimestrale che attesta la cancellazione dal CRM, con conferma del fornitore e controllo sui backup, è un'evidenza difendibile. Una dichiarazione del responsabile, senza esecuzione tracciata, non lo è. Raccomando di campionare record scaduti direttamente nei sistemi, perché gli scostamenti emergono lì, non nelle procedure.

9. Misure di sicurezza e controllo degli accessi (art. 32 GDPR)

Il controllo degli accessi fallisce quasi sempre nello stesso punto: l'utenza esiste ancora, ma la persona che la giustificava no. L'art. 32 non premia l'elenco delle tecnologie adottate. Chiede un livello di sicurezza adeguato al rischio del trattamento specifico, dimostrato con prove datate e non con dichiarazioni di policy.

Il divario è misurabile. Il Cyber Index PMI 2025, su un campione di 1.500 imprese italiane, indica che soltanto circa il 30% delle aziende adotta cifratura dei dati e segmentazione della rete.

Dalla misura dichiarata alla misura verificata

Per ogni trattamento collegate rischio, misura, configurazione e test. Ogni misura ha un punto di cedimento tipico e un'evidenza minima che lo smaschera:

• Cifratura: cede quando copre i dati a riposo ma non backup ed esportazioni. L'evidenza è la configurazione datata di ciascun sistema che ospita copie.
• Revisione degli accessi: cede quando produce un elenco letto e non deciso. Servono data, decisioni di conferma o revoca e ticket di esecuzione.
• Backup: cede quando il ripristino non è mai stato provato. L'evidenza è il log di un restore riuscito, non il report dei job pianificati.

Collegare la revoca all'offboarding HR riduce le utenze residue, ma non sostituisce una verifica indipendente. Se la revisione trimestrale del gestionale HR trova due account di ex dipendenti ancora attivi, registrate revoca, data, responsabile e ripetizione del controllo. Quell'eccezione gestita vale più di una policy impeccabile.

Conservate estratti di configurazione con data e hash, log degli accessi amministrativi e prove di ripristino. Uno screenshot isolato dimostra un'istantanea, non l'efficacia continuativa del controllo.

10. Privacy by design e approvazione delle modifiche (art. 25 GDPR)

La privacy by design diventa verificabile nel processo di change management, non in una dichiarazione di principio. Il fallimento tipico è il rilascio di una funzionalità che introduce nuovi dati, una nuova finalità o un fornitore aggiuntivo senza revisione preventiva. A quel punto registro, informativa e DPIA vengono rincorsi dopo la messa in produzione.

Serve un gate privacy con criteri di attivazione semplici. Nuovi dati personali, nuove categorie di interessati, profilazione, trasferimenti, fornitori o modifiche alla conservazione devono fermare il rilascio finché una valutazione datata non è registrata. Chi sviluppa propone, il responsabile privacy o il DPO esprime la valutazione prevista dal processo, il titolare o un delegato approva, e una funzione distinta verifica il rispetto del gate a campione.

• Criteri di attivazione: soglie chiare integrate nel sistema di gestione modifiche.
• Decisione tracciata: valutatore, data, esito e collegamenti a registro e DPIA.
• Deroghe limitate: eccezioni autorizzate, con scadenza e riesame obbligatorio.
• Verifica ex post: campione di rilasci confrontato con le approvazioni privacy.

Una deroga urgente di trenta giorni, per esempio, è un'eccezione temporanea, non un'approvazione permanente. Se scade senza riesame, diventa un finding. Questa distinzione impedisce che le urgenze operative si trasformino silenziosamente in trattamenti non valutati.

Controlli GDPR da verificare prima dellaudit

Dalla checklist al pacchetto di prove per l'audit

Una checklist diventa utile quando ogni controllo può essere ricostruito mesi dopo, da una persona che non ha partecipato all'attività. Servono owner, data, versione, evidenza, decisione e remediation nello stesso percorso. Se per rispondere all'auditor dovete cercare tra email personali, chat, fogli locali e cartelle condivise senza versioni, il problema è l'assenza di una catena probatoria governata: i documenti esistono, ma nessuno può dimostrare quando sono stati prodotti, da chi e a sostegno di quale decisione.

Conviene partire dai controlli che producono finding con maggiore frequenza operativa: registro dei trattamenti, richieste degli interessati e fornitori. Testateli a campione prima dell'audit formale, partendo dai sistemi reali e non dagli elenchi dichiarati. Un campione piccolo ma completo rivela più di una revisione documentale estesa, perché mostra subito dove mancano le conferme dei fornitori, dove le scadenze DSAR non sono calcolate dalla data di ricezione e dove un trattamento risulta privo di un responsabile effettivo.

Errori comuni che indeboliscono l'audit

• Approvazioni retroattive: documenti firmati dopo l'avvio del trattamento e presentati come valutazioni preventive. La data di firma confrontata con la data di avvio li squalifica come prova.
• Eccezioni senza scadenza: deroghe rinnovate in automatico, che in audit risultano indistinguibili da una non conformità tollerata.
• Evidenze sparse: screenshot senza timestamp, allegati email e versioni locali non collegati al controllo. Dimostrano che qualcosa esiste, non che il controllo è stato eseguito.
• Chiusure non verificate: finding marcati come risolti senza prova tecnica o controllo indipendente, che alla verifica a campione riemergono identici.
• Confusione di categorie: incidente, eccezione autorizzata e finding gestiti nello stesso elenco senza criteri distinti, così ogni decisione diventa irricostruibile.

La correzione richiede disciplina di registro. Ogni finding dovrebbe mantenere ID, controllo di origine, severità, owner, scadenza, azione, evidenza di chiusura e verificatore. Ogni eccezione dovrebbe avere motivazione, rischio residuo, controlli compensativi e data di scadenza. Ogni incidente dovrebbe conservare fatti, valutazione, decisioni e follow-up. Sono oggetti diversi e devono restare collegati, non sovrapposti.

Verifica pre-audit in sette domande

1. Riesco a partire da tre sistemi in produzione e arrivare a registro, informativa, base giuridica e conservazione senza chiedere spiegazioni orali?
2. Per ogni controllo esiste un owner nominato e distinto da chi verifica la chiusura?
3. Le evidenze hanno data, versione, autore e collegamento al trattamento o al finding?
4. Le DSAR mostrano ricezione, scadenza, risposta ed esecuzione nei sistemi e presso i fornitori?
5. DPIA, screening negativi e modifiche rilevanti sono aggiornati allo stato reale dei processi?
6. Incidenti, eccezioni e finding hanno registri e criteri decisionali separati?
7. Le chiusure delle remediation sono state testate a campione nei sistemi?

Se una risposta dipende dalla memoria di una singola persona, il pacchetto non è ancora pronto. AuditReady centralizza audit, evidenze, findings e registri privacy come RoPA, DPIA e DSAR con owner e scadenze, consentendo di collegare una stessa evidenza a più obblighi e di esportare pacchetti strutturati per la revisione. Questa centralizzazione supporta il lavoro operativo: la raccolta e l'ordinamento delle prove possono essere automatizzati, mentre accountability, approvazioni e accettazione del rischio restano umane.

AuditReady aiuta a trasformare questa checklist in controlli assegnati, evidenze versionate e findings tracciati fino alla prova di chiusura, con registri privacy e fornitori collegati nello stesso ambiente operativo. Potete preparare un Audit Day Pack strutturato senza ricostruire manualmente le prove da email e cartelle sparse. Visitate AuditReady per vedere come organizzare il prossimo ciclo di audit GDPR in modo verificabile.