Registro dei trattamenti GDPR: guida operativa

Indice

• Il registro fermo non dimostra il trattamento
  • Dove nasce l'obbligo
• Contenuto del registro dei trattamenti GDPR
  • I sette gruppi minimi del titolare
  • Destinatari, trasferimenti e conservazione
• Chi propone approva esegue e verifica
  • I cinque passaggi
  • Eccezione, non conformità e incidente
• Costruire l'inventario iniziale dei trattamenti
  • Le regole di incrocio
• Campi che rendono ogni scheda ricostruibile
  • Campi di governance per una scheda audit-ready
  • Collegamenti che il registro deve citare
  • Chiusura di una modifica
• Aggiornare il registro quando cambia il sistema
  • Quattro cambi che spostano più campi
• Errori comuni che indeboliscono l'audit
  • Sei difetti e la correzione minima
• Verifica il registro prima del controllo
• Domande frequenti sul registro
  • Il responsabile tiene lo stesso registro del titolare?
  • Una PMI con paghe o videosorveglianza è esentata perché piccola?
  • Basta la bozza preparata dal consulente esterno?
  • Se il trattamento è sospeso la scheda si chiude?

Il registro fermo non dimostra il trattamento

Un sistema biometrico può essere attivo, usato ogni giorno e coperto da un contratto con il fornitore. Se il trattamento non compare nel registro, il documento non rappresenta l'operatività effettiva.

Le autorità di controllo hanno rilevato registri che omettevano trattamenti biometrici. Il punto pratico è chiaro: un registro non aggiornato può diventare un finding, perché non consente di ricostruire quali trattamenti siano svolti e chi ne abbia valutato l'inclusione.

Un inventario elenca. L’accountability documenta chi ha deciso, quando, su quale base e con quali evidenze.

Il registro non è un adempimento binario né un esonero automatico per le organizzazioni con meno di 250 dipendenti. È la prova della decisione di includere o escludere ogni trattamento, da riallineare quando cambiano sistemi, fornitori o strumenti di AI.

Dove nasce l'obbligo

Il Regolamento (UE) 2016/679, applicabile dal 25 maggio 2018, prevede all’articolo 30 che il titolare tenga un registro delle attività svolte sotto la propria responsabilità. Un obbligo parallelo riguarda il responsabile del trattamento, per le categorie di attività svolte per conto dei titolari.

Il paragrafo 5 prevede un'eccezione per le organizzazioni con meno di 250 dipendenti, ma non si applica quando il trattamento può presentare un rischio, non è occasionale oppure include dati degli articoli 9 e 10. La soglia, quindi, non basta per concludere che il registro non sia necessario: occorre valutare la natura e la continuità delle attività e i dati trattati.

Per ogni trattamento, conserva la decisione di includerlo o escluderlo e le relative evidenze. Così, in audit, si possono verificare il criterio applicato e la coerenza del registro con le attività effettive.

Contenuto del registro dei trattamenti GDPR

Un auditor non legge il registro come un elenco di software. Lo legge come una mappa. Per ogni attività deve poter collegare finalità, dati, interessati, destinatari, conservazione, trasferimenti e misure di sicurezza senza chiedere spiegazioni orali.

L'articolo 30 del GDPR definisce almeno 7 gruppi informativi fondamentali per il registro del titolare. Il registro va mantenuto per iscritto, anche in formato elettronico, e messo a disposizione dell'autorità di controllo su richiesta. Termini di cancellazione e misure di sicurezza sono richiesti con l'espressione "ove possibile", che non li rende irrilevanti in controllo.

I sette gruppi minimi del titolare

La finalità deve descrivere uno scopo concreto. "Gestione aziendale" non spiega perché si trattano quei dati, per quanto tempo e verso chi. Una finalità difendibile dice, per esempio, gestione delle paghe, controllo accessi alla sede, assistenza post vendita, selezione del personale.

Per interessati e dati serve precisione nelle categorie. Dipendenti, candidati, clienti, visitatori e fornitori non sono intercambiabili. Se compaiono dati sanitari, biometrici o giudiziari, la scheda deve segnalarlo subito, perché cambia la valutazione di applicabilità e spesso anche le misure attese.

Destinatari, trasferimenti e conservazione

Il nome commerciale di un applicativo non è una categoria di destinatari. L'auditor vuole sapere chi riceve i dati, con quale ruolo e in quale perimetro. Un consulente paghe, un provider cloud e una società di manutenzione possono usare lo stesso sistema, ma non hanno lo stesso accesso né la stessa responsabilità.

Lo stesso vale per i trasferimenti verso Paesi terzi. Se il dato passa da un fornitore che ospita o supporta il servizio fuori dallo Spazio economico europeo, il trasferimento non sparisce perché è mediato. Va indicato, collegato allo strumento utilizzato e verificato contro il contratto vigente.

Sulla conservazione, "ove possibile" non autorizza celle vuote senza spiegazione. Se un termine non è ancora definito, scriva perché, chi deve definirlo e entro quando. Una retention dichiarata ma mai applicata nei sistemi è più debole di una retention in definizione con owner e scadenza tracciati.

Regola pratica: se un campo dell'articolo 30 è vuoto, il registro deve mostrare una decisione motivata, non un'assenza.

Per le misure ex articolo 32 basta una descrizione generale, ma deve rimandare a controlli reali. Controllo accessi, cifratura, backup, registrazione degli eventi e segregazione degli ambienti hanno senso solo se qualcuno può mostrarne l'attuazione. Copiare la stessa frase su ogni scheda segnala che nessuno ha verificato il trattamento specifico.

Per un'organizzazione sotto soglia, il perimetro può essere circoscritto alle attività che fanno scattare l'obbligo. La semplificazione regge solo con una motivazione basata su frequenza, categorie di dati, scala e rischio. Senza quella motivazione, un registro ridotto sembra un registro incompleto.

Il registro del responsabile segue una logica distinta. Descrive le categorie di trattamenti svolti per conto dei clienti, i titolari serviti, le categorie di dati e interessati e, ove possibile, le misure di sicurezza. Non è una copia del registro del cliente e non deve descrivere trattamenti che il responsabile svolge come titolare autonomo.

Chi propone approva esegue e verifica

Il registro si indebolisce quando una sola persona propone la scheda, la approva e poi dichiara che la verifica è andata bene. Non è un problema di fiducia. È un problema di prova, perché manca un controllo indipendente sulla decisione.

Il flusso seguente separa i ruoli senza creare un organigramma teorico. Lo schema aiuta a vedere la sequenza prima dei dettagli operativi.

I cinque passaggi

1. Il process owner propone: apre la scheda o la modifica quando cambiano finalità, sistema, categoria di dati, destinatario o conservazione, e descrive il trattamento come avviene nel processo.
2. IT conferma i fatti tecnici: il referente applicativo verifica sistemi, flussi, integrazioni e fornitori, inclusi quelli rilevanti anche per NIS2 o DORA, senza decidere la base giuridica.
3. Il DPO verifica la coerenza: se nominato, controlla lacune e collegamenti con informativa, nomina del responsabile e DPIA, ma non diventa owner del trattamento.
4. Il titolare approva: il titolare o il responsabile di funzione delegato approva con data, assumendo la decisione sul perimetro e sul contenuto.
5. Un controllo indipendente campiona: internal audit o un controllo di secondo livello verifica in seguito se la scheda corrisponde all'operatività, ai contratti e ai sistemi attivi.

La separazione conta soprattutto nelle modifiche urgenti. Chi ha fretta di attivare un servizio tende a descrivere il trattamento come dovrebbe essere, non come è stato configurato. Un approvatore distinto obbliga a chiudere quel divario prima che la scheda diventi evidenza.

Per tenere distinti ruoli privacy e responsabilità di processo, è utile definire in anticipo come impostare la governance privacy tra DPO e process owner. Il DPO consiglia e verifica. La funzione che tratta i dati resta responsabile di ciò che dichiara.

Eccezione, non conformità e incidente

Il flusso deve gestire tre situazioni diverse. Un'eccezione è autorizzata, motivata e a termine, per esempio un trasferimento temporaneo in attesa del completamento delle clausole contrattuali. Ha un owner, una scadenza e controlli compensativi.

Una non conformità emerge quando la verifica trova una scheda assente, incoerente o non approvata. Si chiude con remediation ed evidenza di chiusura, non con una modifica silenziosa del file. Un incidente o data breach segue invece il processo di gestione e notifica previsto. Riscrivere la scheda dopo i fatti non sana l'evento e può compromettere la ricostruzione.

Il software può tracciare passaggi, versioni e approvazioni. Non decide al posto delle persone. La responsabilità resta di chi propone, di chi approva e di chi verifica, ciascuno per il proprio ruolo.

Per il responsabile del trattamento lo schema non cambia nella sostanza. Cambia la controparte, perché ogni attività va collegata al cliente titolare per conto del quale è svolta. Anche qui, chi eroga il servizio non dovrebbe essere l'unico a certificarne la descrizione.

Costruire l'inventario iniziale dei trattamenti

Parta dai processi, non dal file esistente. Se il punto di partenza è il vecchio foglio, il censimento erediterà le sue omissioni. Un trattamento mai registrato resterà invisibile proprio perché nessuno lo cerca fuori dal documento.

Il primo inventario nasce da tre fonti incrociate. La prima è l'elenco dei processi aziendali con i responsabili di funzione. La seconda è l'inventario applicativo IT, con i sistemi che trattano dati personali. La terza è il registro dei contratti con i fornitori, da cui emergono responsabili, sub-responsabili e possibili trasferimenti.

Le regole di incrocio

• Sistema senza processo: indica spesso un trattamento non censito oppure un applicativo dismesso ma non chiuso formalmente.
• Processo senza sistema: indica spesso un flusso su fogli condivisi, email o archivi locali, che va censito comunque se tratta dati personali.
• Fornitore senza scheda: indica un destinatario o responsabile non collegato a nessuna attività approvata.
• Scheda senza contratto vigente: indica una descrizione ferma a un fornitore precedente o a condizioni non più attuali.

Chieda a ciascun process owner una conferma scritta, non una conversazione in corridoio. Deve indicare finalità, categorie di interessati e di dati, sistemi usati e presenza di dati degli articoli 9 e 10. La conferma datata diventa la base su cui IT e DPO possono verificare coerenza e completezza.

Per ogni attività candidata, la decisione è includere o escludere. Entrambe vanno motivate. Un controllo esamina con particolare attenzione le esclusioni quando il registro è ridotto, perché lì si capisce se il perimetro è stato scelto o semplicemente dimenticato.

Registri data del censimento, referenti intervistati e fonti consultate. Anche il primo inventario è un'evidenza e deve poter essere ricostruito. Se tra sei mesi emerge un trattamento assente, deve poter stabilire se è nato dopo oppure è sfuggito alla rilevazione iniziale.

Il lavoro può procedere per aree. Partirei da HR, paghe, marketing, assistenza clienti e dai sistemi con dati sanitari o biometrici, dove continuità e sensibilità rendono meno difendibile un'esclusione generica. Le aree marginali arrivano dopo, con la stessa regola di motivazione.

Solo a censimento approvato si passa ai campi di governance. Riempire metadati dettagliati su trattamenti non ancora confermati produce schede precise su un perimetro sbagliato. Prima si stabilisce che cosa esiste, poi si rende ogni scheda ricostruibile.

Campi che rendono ogni scheda ricostruibile

L'articolo 30 fissa il contenuto del trattamento. L'audit chiede anche chi ha deciso, quando e su quale evidenza. Senza questi metadati, due versioni diverse della stessa scheda sembrano entrambe vere e nessuna è difendibile.

La tabella seguente non ripete le categorie normative. Raccoglie i campi di governance che permettono di ricostruire la storia della scheda durante un controllo.

Campi di governance per una scheda audit-ready

L'ID stabile evita che una scheda rinominata sembri un trattamento nuovo. Lo stato distingue bozza, approvata, da rivedere e chiusa. Una bozza non ha lo stesso valore probatorio di una scheda approvata e non dovrebbe essere presentata come tale.

Le date di prima istituzione e ultimo aggiornamento devono sopravvivere alle modifiche. Se il file viene sovrascritto, l'auditor vede solo il presente dichiarato. Non può stabilire quando il trattamento è stato censito né se la descrizione precedente era coerente con l'operatività di quel periodo.

Collegamenti che il registro deve citare

Il registro cita documenti distinti, non li sostituisce. Informative ex articoli 13 o 14, contratti ex articolo 28, nomine, valutazioni sui trasferimenti e descrizioni delle misure restano evidenze separate. La scheda deve permettere di aprirli nella versione corretta, non riassumerli in una frase generica.

Per la retention, il collegamento al retention schedule conta più del numero scritto nella cella. Se esiste un legal hold, la scheda deve mostrarlo, perché sospende la cancellazione ordinaria. In AuditReady, per ogni evidenza si registrano periodo di conservazione, scadenza ed eventuale blocco legale. Il principio vale con qualsiasi strumento, il termine deve avere un owner e una fonte verificabile.

Se il collegamento a informativa, nomina o DPIA non si apre, in audit quel collegamento non esiste.

Il campo DPIA collegata ammette due esiti difendibili. O esiste una valutazione identificabile, oppure esiste una motivazione registrata per cui non è stata eseguita. Lasciare il campo vuoto costringe l'auditor a presumere che la domanda non sia mai stata posta.

Per inclusione ed esclusione servono frequenza, categorie di dati, scala, destinatari e impatto potenziale. È la risposta operativa alla domanda più scomoda sotto soglia, come dimostra che questo trattamento è occasionale o non rischioso. La motivazione breve ma specifica vale più di una dichiarazione generale sull'organico.

Chiusura di una modifica

Una modifica si chiude con quattro elementi. Che cosa è cambiato. Chi l'ha approvato e quando. Quale evidenza supporta il nuovo stato. Quale versione precedente resta leggibile.

Finalità, categoria di dati, destinatario, conservazione o fornitore nuovi devono generare una nuova versione, non una sovrascrittura silenziosa. La nota "aggiornato registro" non è evidenza di chiusura. Dice che qualcuno ha toccato il file, non che il trattamento descritto corrisponde al sistema attivo.

Per un import iniziale, non pretenda di compilare tutto in un giorno. Carichi prima ID, owner, stato, date e collegamenti essenziali sulle schede confermate. Poi completi retention, trasferimenti e DPIA per priorità di rischio, con scadenze assegnate. Un completamento pianificato e tracciato è più credibile di un registro improvvisamente perfetto senza storia.

Aggiornare il registro quando cambia il sistema

Un cambiamento tecnologico raramente sposta un solo campo. Cambia un fornitore e si muovono destinatari, trasferimenti, misure e talvolta finalità. Se aggiorna solo il nome del sistema, la scheda resta coerente con un mondo che non esiste più.

L'immagine seguente richiama il lavoro ordinario di riallineamento tra sistemi, contratti e schede.

Quattro cambi che spostano più campi

Con un nuovo SaaS HR cambiano finalità operative, categorie di dipendenti, destinatari, possibile trasferimento extra-SEE, conservazione e misure. Servono evidenza dal fornitore, nomina aggiornata se agisce come responsabile e verifica dei sub-responsabili dichiarati. Owner HR, scadenza prima del go live, chiusura con contratto e configurazione effettiva.

Con uno strumento di AI generativa usato su testi contenenti dati personali, il sistema entra nell'inventario con finalità, owner, categorie ammesse, limiti d'uso e sign-off umano. Non è un decisore autonomo e non approva da solo l'uso dei dati. Il registro privacy, inoltre, non classifica da solo il rischio ai fini dell'AI Act, che richiede una valutazione separata e tracciata.

Per approfondire il metodo di riallineamento tra processi e sistemi, il video seguente offre un supporto visivo al ragionamento operativo.

Con il cambio di un sub-responsabile cloud si rivedono destinatari, paese di trattamento, trasferimenti e misure dichiarate. Se il rischio sale, si verificano anche DPIA e registro fornitori. La data rilevante è quella di effettiva migrazione o accesso, non quella dell'annuncio commerciale.

Il quarto caso è videosorveglianza o biometria già in esercizio ma assente dalle schede. Qui non basta aggiungere una riga. Bisogna registrare data di rilevazione, periodo di scopertura, owner della remediation e verifica indipendente di chiusura.

Le FAQ del Garante sul registro chiedono un contenuto costantemente aggiornato, con modifiche registrate tempestivamente e date di prima istituzione e ultimo aggiornamento. Il punto meno presidiato resta la sincronizzazione tra registro, DPIA, fornitori e incidenti, perché una stessa modifica può alterare tutti e quattro i perimetri.

Per questo conviene trattare ogni change rilevante come un evento di governance, come descritto in un sistema privacy per gestire i cambiamenti organizzativi. Data di rilevazione, owner, scadenza di aggiornamento ed evidenza di chiusura devono viaggiare insieme alla modifica tecnica. Se il ticket IT si chiude ma la scheda resta aperta senza owner, il disallineamento è già ricominciato.

Errori comuni che indeboliscono l'audit

Il difetto più grave non è un campo mancante. È un registro che esiste, sembra ordinato e non corrisponde all'operatività. L'auditor lo scopre incrociando sistemi attivi, contratti e accessi reali, non leggendo solo la prima pagina.

Nel 2024, il Garante italiano ha rilevato che un registro datato 29 dicembre 2021 non censiva il trattamento di dati biometrici. Il documento c'era. Il trattamento in esercizio non era rappresentato, e questa è la differenza tra adempimento formale e prova.

Lo schema seguente riassume i difetti che ricorrono quando la scheda non segue il sistema reale.

Sei difetti e la correzione minima

• Esonero dichiarato solo per l'organico: senza valutazione di occasionalità, rischio e dati particolari o giudiziari, la conclusione non è ricostruibile. Correzione minima, motivazione scritta per attività.
• Schede fotocopia: stessa finalità e stesse misure per paghe, marketing e videosorveglianza indicano che nessuno ha descritto il trattamento specifico. Correzione minima, riscrittura per processo con owner che conferma.
• Aggiornamenti retrodatati: approvazioni raccolte la sera prima del controllo distruggono la credibilità dell'audit trail. Correzione minima, versione reale con data effettiva e finding se il ritardo è rilevante.
• Evidenze sparse: email, chat e screenshot senza data né integrità verificabile non permettono di ricostruire la decisione. Correzione minima, evidenza datata collegata alla scheda e conservata in un archivio unico.
• Eccezioni senza termine: un trasferimento temporaneo rinnovato all'infinito smette di essere un'eccezione e diventa prassi non governata. Correzione minima, scadenza, owner e controlli compensativi.
• Chiusure dichiarate senza evidenza: il fornitore è cambiato ma la scheda cita ancora la vecchia nomina. Correzione minima, verifica indipendente su contratto vigente e accesso reale prima della chiusura.

Questi vizi non vanno confusi con un incidente. Un data breach richiede contenimento, valutazione e, quando previsto, notifica. Aggiornare la scheda può essere una conseguenza, mai la remediation dell'evento.

Un foglio statico con i nomi dei sistemi non sostituisce informativa, contratto con il responsabile, DPIA o documentazione delle misure. Può collegarli e renderli reperibili. Se pretende di sostituirli, in audit lascia scoperte proprio le prove che l'auditor chiede dopo aver letto il registro.

Verifica il registro prima del controllo

Non verifichi tutto l'archivio. Prenda un campione di schede attive, includa almeno un trattamento con fornitore esterno e uno con dati sensibili o trasferimento, poi risponda a sette domande con evidenze alla mano.

1. La finalità descrive un trattamento ancora attivo, con processo e sistema riconoscibili?
2. Sotto i 250 dipendenti esiste una motivazione di inclusione o esclusione basata su rischio, occasionalità e articoli 9 e 10?
3. Owner, approvatore e data sono distinti e ricostruibili senza chiedere conferme orali?
4. Destinatario, fornitore e trasferimento coincidono con il contratto vigente e con gli accessi reali?
5. La conservazione coincide con retention schedule, configurazione del sistema ed eventuale legal hold?
6. La versione precedente è ancora leggibile e mostra che cosa è cambiato?
7. Informativa, nomina e DPIA citate si aprono e corrispondono alla versione in uso?

Se due risposte sono no, non si limita a riformattare il file. Apre una non conformità con owner, scadenza ed evidenza di remediation, distinta da eventuali incidenti aperti. È il passaggio che trasforma un controllo interno in miglioramento dimostrabile.

Il passo successivo è centralizzare schede, scadenze, evidenze e audit trail in un unico archivio, così che RoPA, DPIA, DSAR e breach restino registri collegati alle attività di trattamento, con responsabilità chiare. Per il metodo di preparazione, veda GDPR audit e conformità dimostrabile. Il controllo si prepara sul sistema reale, non inseguendo file sparsi il giorno prima.

Domande frequenti sul registro

Il responsabile tiene lo stesso registro del titolare?

No. Il responsabile tiene un registro distinto per le attività svolte per conto dei titolari. Vi indica le categorie di trattamenti, i titolari, le categorie di dati e di interessati e, ove possibile, le misure di sicurezza.

Una PMI con paghe o videosorveglianza è esentata perché piccola?

La dimensione dell'organico, da sola, non basta a escludere l'obbligo. Paghe, gestione del personale e videosorveglianza sono spesso trattamenti continuativi o potenzialmente rischiosi. La decisione di includere o escludere ciascun trattamento va motivata: il registro documenta questa valutazione, non è un adempimento binario né un'esenzione automatica per le imprese con meno di 250 dipendenti.

Basta la bozza preparata dal consulente esterno?

La bozza documenta un'attività preparatoria, non la decisione del titolare. Il registro approvato deve essere disponibile per il Garante su richiesta e permettere di ricostruire responsabilità e versioni.

Se il trattamento è sospeso la scheda si chiude?

Se i dati sono ancora conservati, la scheda resta attiva: anche la conservazione è un trattamento. Indicare lo stato, la motivazione, il periodo di conservazione applicabile e l'eventuale legal hold; chiudere la scheda quando trattamento, accessi e conservazione sono terminati e l'esito è documentato.

Se il suo registro vive tra fogli, email e cartelle separate, AuditReady può collegare schede RoPA, responsabili, scadenze, evidenze e audit trail in un unico flusso verificabile. Il software organizza le informazioni, ma non prende decisioni legali né valuta automaticamente la conformità. Visiti AuditReady per vedere come preparare un Audit Day Pack e rendere ricostruibili le modifiche nel tempo.