Records of processing activities: guida completa 2026

Indice

• Perché un registro datato diventa un problema in audit
  • Documento, esecuzione e prova non coincidono
• Cosa deve contenere il registro secondo l'articolo 30
  • Un'attività, due voci diverse
  • Campi operativi che rendono verificabile ogni riga
• Quando l'esenzione per le PMI non basta
  • La matrice decisionale trattamento per trattamento
• Chi propone, approva ed esegue ogni voce
  • Le sei fasi del flusso
• Mantenere il registro allineato ai sistemi reali
  • Trigger, riconciliazione e sistemi AI
• Errori comuni che indeboliscono l'audit
  • Approvazioni e chiusure che non reggono al confronto delle date
  • Eccezioni, evidenze sparse ed export senza contesto
• Verifica prima dell'audit con sette domande
• Domande frequenti e avvio della revisione del registro
  • Si può tenere il registro in un foglio di calcolo
  • Chi firma il registro
  • Cosa fare quando un owner lascia l'organizzazione
  • Con quale cadenza riesaminare il registro
  • Da dove iniziare la revisione

Perché un registro datato diventa un problema in audit

Diciamo che, durante un audit interno, l'auditor seleziona la voce sulla gestione del personale e chiede chi l'ha approvata, quando è stata riesaminata e quale fornitore tratta oggi i dati. Il foglio risponde solo alla prima parte della storia. Indica finalità e categorie di dati, ma non mostra l'approvatore, non conserva le versioni precedenti e cita ancora il precedente fornitore delle buste paga. Il controllo si ferma subito, perché l'auditor non può stabilire se la voce descrive il trattamento attuale o uno storico.

Il riferimento normativo è l'articolo 30 del Regolamento (UE) 2016/679, adottato il 27 aprile 2016 e applicabile dal 25 maggio 2018, che richiede a ogni titolare un registro delle attività svolte sotto la propria responsabilità e ai responsabili un registro delle attività eseguite per conto dei titolari. Lo stesso articolo elenca contenuti minimi come titolare, contatti del responsabile della protezione dei dati, finalità, categorie di interessati e di dati personali, destinatari, trasferimenti verso Paesi terzi, termini di cancellazione e, ove possibile, una descrizione generale delle misure di sicurezza. Prevede anche un'eccezione per organizzazioni con meno di 250 dipendenti, che non opera quando il trattamento presenta rischi, non è occasionale o riguarda categorie particolari di dati o dati relativi a condanne penali.

Documento, esecuzione e prova non coincidono

Avere una procedura privacy scritta non dimostra che qualcuno abbia riesaminato una voce in una data precisa. Avere il file del registro non dimostra nemmeno che il contenuto sia stato approvato dal titolare o da un suo delegato. In audit contano tre livelli separati, requisito stabilito, controllo eseguito ed evidenza conservata, e il registro regge solo quando i tre livelli si collegano senza salti.

Un registro auditabile non è il file più recente. È il file di cui potete ricostruire autore, approvatore, data, versione e motivo di ogni modifica rilevante.

La catena da mantenere è semplice da enunciare e meno semplice da far funzionare. Parte dal requisito dell'articolo 30, diventa un controllo operativo di aggiornamento e riconciliazione, assegna un owner a ogni voce, produce un'evidenza datata, conserva una audit trail delle modifiche e trasforma le carenze in finding con remediation tracciata. Quando un anello manca, l'auditor lo tratta come una lacuna di governance, anche se il trattamento sottostante è gestito correttamente.

Per chi sta impostando il sistema partendo dall'organizzazione aziendale può essere utile affiancare al lavoro sul registro una guida per imprenditori alla conformità, utile per collocare responsabilità e adempimenti nel perimetro più ampio dei controlli. Il registro resta però il punto di partenza concreto di ogni verifica sui trattamenti, perché è il primo documento con cui l'auditor confronta contratti, informative, DPIA e sistemi realmente in uso.

Cosa deve contenere il registro secondo l'articolo 30

La tabella seguente riassume i contenuti richiesti per i due ruoli. Titolare e responsabile non compilano lo stesso registro con nomi diversi, perché descrivono responsabilità diverse sullo stesso trattamento.

Per il titolare, il testo del Regolamento (UE) 2016/679 richiede nome e contatti del titolare, degli eventuali contitolari, del rappresentante e del responsabile della protezione dei dati, finalità, categorie di interessati e di dati personali, categorie di destinatari, trasferimenti verso Paesi terzi con indicazione del Paese e, nei casi previsti, documentazione sulle garanzie adeguate, oltre alla descrizione generale delle misure di sicurezza ove possibile. Per il responsabile richiede invece le categorie di trattamenti svolti per conto di ciascun titolare, con titolare, eventuali altri responsabili, categorie di trattamenti e trasferimenti internazionali.

Un'attività, due voci diverse

Diciamo che un'azienda affida l'elaborazione delle buste paga a un consulente esterno. Nel registro dell'azienda, titolare del trattamento, la voce descrive la finalità di amministrazione del personale, gli interessati dipendenti, le categorie di dati retributivi e fiscali, il consulente come destinatario e i termini di cancellazione. Nel registro del consulente, responsabile del trattamento, la voce descrive invece le categorie di operazioni svolte per conto di quel titolare, senza dover ripetere finalità e categorie di interessati come se le avesse decise lui.

La distinzione sembra formale, ma in audit evita due errori frequenti. Il primo è attribuire al responsabile decisioni che spettano al titolare. Il secondo è copiare la voce del cliente nel proprio registro, producendo un documento che non dimostra cosa il responsabile fa effettivamente per ciascuno dei titolari serviti.

Campi operativi che rendono verificabile ogni riga

L'elenco dell'articolo 30 è il minimo normativo, non il minimo per superare una verifica senza ricostruzioni. Per rendere ogni voce difendibile io aggiungerei sempre questi campi di gestione.

• Identificativo stabile e nome del trattamento: il codice non cambia quando cambia il titolo descrittivo, così contratti e DPIA possono richiamarlo nel tempo.
• Owner nominativo e processo collegato: nome, ruolo e funzione responsabile, con il processo o l'asset a cui il trattamento appartiene.
• Finalità verificabile e base documentale: una finalità formulata in modo controllabile, collegata all'informativa e alla documentazione privacy che la supporta.
• Destinatari, fornitori e trasferimenti: soggetti coinvolti, eventuali Paesi terzi e riferimento alle garanzie, senza rinvii generici a documenti non identificati.
• Conservazione e misure: termini di cancellazione, descrizione generale delle misure tecniche e organizzative e riferimento alla DPIA collegata, quando esiste.
• Stato della voce: versione, data dell'ultima revisione, approvatore, motivo della modifica e scadenza del prossimo riesame.

Questo schema trova riscontro anche nella pagina del Garante sul Registro delle attività di trattamento, che inquadra il registro come rappresentazione del modello operativo dei trattamenti e ne consente la tenuta in forma elettronica, con obbligo di esibirlo su richiesta. La forma elettronica aiuta solo se conserva versionamento e approvazioni. Un foglio condiviso senza storico resta un documento, non un'evidenza.

Per capire come le informazioni del registro si riflettono verso l'esterno, è utile confrontare le proprie voci con esempi pubblici di informativa, come il trattamento dei dati sul sito PHABDEV, verificando che finalità, destinatari e tempi dichiarati agli interessati coincidano con quanto risulta dalla voce interna. Se registro e informativa raccontano due versioni diverse dello stesso trattamento, l'auditor chiederà quale delle due descrive il sistema reale, e la risposta dovrà essere documentata, non improvvisata.

Quando l'esenzione per le PMI non basta

La risposta secca è questa. Sotto i 250 dipendenti il registro non diventa facoltativo in blocco. L'esenzione dell'articolo 30, paragrafo 5, non opera quando ricorre anche una sola tra quattro condizioni alternative, e la valutazione va fatta sul singolo trattamento, non sull'organizzazione nel suo insieme.

Le indicazioni del Garante sul registro dei trattamenti e sulle semplificazioni per le PMI chiariscono che l'obbligo permane anche per imprese più piccole quando il trattamento non è occasionale, comporta un rischio per diritti e libertà, oppure riguarda dati particolari o giudiziari, perché le condizioni sono alternative ed è sufficiente che ne ricorra una. Il Garante ammette una semplificazione, circoscrivendo il registro alle attività che fanno scattare l'obbligo, ma richiede una motivazione verificabile, un riesame periodico e un registro costantemente aggiornato, con i cambiamenti inseriti immediatamente.

La matrice decisionale trattamento per trattamento

Per applicare la regola senza discussioni ricorrenti, costruite una matrice con una riga per trattamento e quattro colonne fisse. La prima indica il nome del trattamento e il suo owner. La seconda riporta il criterio di obbligatorietà applicato, citando la condizione dell'articolo 30, paragrafo 5, che ricorre oppure la motivazione per cui nessuna ricorre. La terza definisce il livello di dettaglio scelto nella voce. La quarta conserva l'evidenza della decisione, con autore e data della valutazione.

Diciamo che un'azienda con 80 dipendenti gestisce certificati di malattia e idoneità alla mansione. Quel trattamento riguarda dati sulla salute, quindi entra nel registro con voce completa, owner HR e riferimento alla valutazione del rischio. La stessa azienda potrebbe tenere fuori perimetro una singola iniziativa promozionale occasionale solo se non comporta rischio rilevante, non usa categorie particolari di dati e non è ricorrente, e dovrebbe comunque scrivere perché le quattro condizioni non ricorrono.

La matrice va riesaminata quando cambiano finalità, categorie di dati, interessati o modalità operative. Un trattamento di marketing che diventa profilazione sistematica cambia natura, anche se il nome della voce resta identico. Un sistema di videosorveglianza collegato al controllo accessi può far scattare la condizione del rischio. La gestione degli incidenti e i fornitori ICT con accesso continuativo ai sistemi sono quasi sempre trattamenti non occasionali.

Regola pratica: il perimetro ridotto è difendibile solo se un terzo può leggere, per ogni trattamento escluso, quale criterio è stato applicato, da chi e in quale data.

Chi propone, approva ed esegue ogni voce

Il diagramma seguente mostra la catena di responsabilità che separa proposta, revisione, approvazione ed esecuzione, così che chi alimenta il registro non sia anche l'unico a verificarlo.

Senza separazione dei ruoli, l'auditor non distingue una revisione diligente da un'autocertificazione. Le indicazioni del Garante nelle istruzioni sul registro delle operazioni di trattamento richiedono che il registro sia mantenuto in forma scritta, anche elettronica, e possa essere esibito al Garante su richiesta, descrivendolo come il documento con le principali informazioni sulle operazioni di trattamento dell'impresa, dell'associazione, dell'esercizio commerciale o del professionista. Per un'organizzazione sottoposta ad audit, questo rende rilevante dimostrare chi ha approvato una voce, quando è stata aggiornata e quali modifiche sono intervenute, con un formato che consenta consultazione, aggiornamento e produzione tempestiva.

Le sei fasi del flusso

Prima fase, proposta. La funzione che introduce o modifica un'attività presenta una scheda con finalità, categorie di dati e di interessati, sistemi e fornitori coinvolti. Seconda fase, verifica. Il referente privacy o il DPO controlla coerenza della finalità, profilo di rischio e necessità di una DPIA, lasciando una nota di valutazione. Terza fase, approvazione. Il titolare o un delegato con potere di firma approva la voce con nome, data e versione, perché la responsabilità del registro resta del titolare anche quando la compilazione è delegata.

Quarta fase, inserimento. L'owner registra la voce o l'aggiornamento con motivo della modifica e nuova data di revisione. Quinta fase, riconciliazione. Compliance o internal audit, separati dall'owner, confrontano periodicamente registro, contratti, informative e catalogo dei sistemi e verbalizzano le differenze. Sesta fase, chiusura delle carenze. Ogni scostamento diventa un finding con owner, scadenza e prova di chiusura verificata da un soggetto diverso da chi ha eseguito l'intervento.

Per approfondire la ripartizione tra funzione privacy e responsabili operativi, la nostra analisi su come impostare la governance privacy tra DPO e process owner descrive un modello coerente con questa segregazione. Sul piano operativo, ogni finding collegato al registro dovrebbe conservare identificativo, owner, voce o processo coinvolto, descrizione della carenza, rischio residuo, eventuali controlli compensativi, scadenza, evidenza di chiusura e nome del verificatore.

Il video seguente offre un riferimento visivo utile per discutere con i process owner la differenza tra compilazione della voce e responsabilità della sua approvazione.

Diciamo che cambia il fornitore cloud del gestionale HR. L'owner aggiorna destinatari, trasferimenti e misure nella voce, il DPO verifica la coerenza con il nuovo contratto, il delegato approva la nuova versione e la riconciliazione successiva conferma che il vecchio fornitore non compare più né nel registro né nell'informativa. Quella sequenza, con date e nomi, è l'evidenza che l'auditor si aspetta.

Mantenere il registro allineato ai sistemi reali

Il registro fallisce più spesso per divergenza dai sistemi reali che per assenza del file. Un'organizzazione può avere un ROPA completo alla data della sua redazione e trovarlo superato pochi mesi dopo, quando il procurement attiva un nuovo servizio SaaS o una funzione adotta uno strumento di automazione senza passare dalla privacy. Il rischio principale non è il documento mancante, ma il documento che descrive un'organizzazione che non esiste più.

Le indicazioni del Garante sul registro come strumento di governo dei trattamenti si inseriscono in un contesto in cui, secondo il dato ISTAT richiamato nella stessa fonte, nel 2025 il 16,4% delle imprese italiane con almeno 10 addetti utilizzava almeno una tecnologia di intelligenza artificiale. L'adozione di AI può modificare finalità, categorie di dati, ruoli, trasferimenti, tempi di conservazione e valutazione del rischio, rendendo insufficiente un inventario costruito una sola volta.

Trigger, riconciliazione e sistemi AI

I trigger più efficaci nascono dove i cambiamenti avvengono davvero, cioè procurement, change management IT, onboarding dei fornitori, gestione degli incidenti e avvio di nuove DPIA. Se il trigger vive solo nella procedura privacy, le funzioni operative non lo vedranno mai nel momento in cui serve. Collegate invece l'apertura di un ordine per un nuovo servizio cloud o la chiusura di un change applicativo a una verifica obbligatoria della voce corrispondente, con esito registrato anche quando non serve alcuna modifica.

La riconciliazione periodica confronta quattro fonti che spesso divergono in silenzio. Le voci del registro, i contratti di fornitura attivi, le informative pubblicate e il catalogo applicativo devono raccontare gli stessi trattamenti, con gli stessi fornitori e le stesse finalità. Le differenze emerse non vanno corrette in modo informale, ma registrate come finding con owner e scadenza, perché anche la correzione fa parte dell'evidenza. Su questo punto, la nostra guida su come costruire un sistema privacy capace di assorbire i cambiamenti organizzativi propone un metodo di collegamento tra cambiamenti e aggiornamenti documentali.

Per i sistemi di intelligenza artificiale, l'inventario collegato al registro dovrebbe indicare finalità, owner, stato del ciclo di vita e classe di rischio, in coerenza con la logica di governance dell'EU AI Act. Il sistema automatizzato supporta raccolta e verifica delle informazioni, ma non decide l'inclusione di un trattamento né approva la voce. La decisione resta umana, nominativa e datata, perché è quella che l'auditor dovrà poter interrogare.

Se un cambiamento rilevante non produce né una modifica alla voce né una motivazione scritta entro il ciclo di riesame previsto, trattatelo come un'eccezione autorizzata a termine, con scadenza e responsabile. Un'eccezione tracciata è una scelta di governance. Un aggiornamento dimenticato diventa invece un finding appena l'auditor confronta il registro con il catalogo dei sistemi.

Errori comuni che indeboliscono l'audit

Cinque errori ricorrono con regolarità nei registri che non superano la verifica, e ciascuno indebolisce la prova in un punto preciso della catena.

Approvazioni e chiusure che non reggono al confronto delle date

Le approvazioni retroattive sono il primo segnale che l'auditor cerca. Una voce approvata con data successiva alla richiesta di audit, o approvata in blocco insieme a decine di altre senza log delle singole revisioni, rende indistinguibile una verifica reale da una ricostruzione dell'ultima ora. Il rimedio è strutturale, non cosmetico. Ogni approvazione deve nascere dentro il flusso di aggiornamento, con approvatore, data, versione e motivo registrati al momento della decisione.

Le chiusure non verificate producono lo stesso effetto sul versante dei finding. Quando l'owner dichiara risolta la propria carenza e la chiude senza controllo di un secondo soggetto, l'auditor non ha modo di distinguere la correzione effettiva dalla semplice dichiarazione. La verifica della chiusura spetta a chi non ha eseguito l'intervento, e la prova di chiusura deve mostrare lo stato finale della voce, non una email di conferma.

Eccezioni, evidenze sparse ed export senza contesto

Le eccezioni rinnovate all'infinito trasformano una deroga temporanea in una condizione permanente non governata. Una voce non aggiornata per tre cicli di riesame consecutivi, con la stessa motivazione copiata e nessuna scadenza effettiva, segnala che il controllo non sta funzionando. Ogni eccezione deve avere motivo, rischio residuo accettato, controlli compensativi e una data oltre la quale scade o viene ridiscussa da un responsabile con potere decisionale.

Le evidenze sparse tra email, chat aziendali e cartelle personali rendono la prova non reperibile nel momento in cui serve. Se l'approvazione di una voce sta in un thread di posta senza riferimento all'identificativo del trattamento, in audit equivale a non esistere. Ogni evidenza va collegata alla voce tramite identificativo stabile e conservata in un punto unico, accessibile a chi deve rispondere all'auditor.

Gli screenshot e gli export senza data, fonte e versione chiudono l'elenco. Un'immagine del gestionale non dice quando è stata prodotta, da quale ambiente proviene e a quale configurazione si riferisce. Accompagnate ogni export con data di produzione, sistema sorgente, autore e riferimento alla voce del registro che l'evidenza intende dimostrare.

Tre distinzioni che l'auditor mantiene sempre separate. Una policy scritta non dimostra che il controllo è stato eseguito. Un'eccezione autorizzata e a termine non è una non conformità. Un incidente operativo non coincide automaticamente con un finding di audit.

Verifica prima dell'audit con sette domande

La checklist seguente misura la completezza delle voci prima che lo faccia l'auditor. Applicate le sette domande a un campione di trattamenti e cercate, per ciascuna, una risposta leggibile nel registro stesso.

1. Ogni voce ha identificatore stabile, owner nominativo e data dell'ultima revisione? Cercate il campo compilato con nome e ruolo, non diciture generiche come ufficio privacy o amministrazione.
2. Ogni campo obbligatorio dell'articolo 30 contiene il contenuto richiesto? Un rinvio a documenti non identificati da titolo e versione non è una compilazione, è un rimando che l'auditor non può seguire.
3. Finalità, categorie di dati e fornitori coincidono con contratto e informativa nella stessa versione? Confrontate le date dei tre documenti, perché una coerenza sostanziale con versioni diverse resta una divergenza da spiegare.
4. È possibile ricostruire quale versione del registro era in vigore alla data dell'audit? Se lo storico non conserva le versioni precedenti con le relative approvazioni, la risposta è negativa.
5. Le voci con trasferimenti verso Paesi terzi indicano il Paese e la documentazione sulle garanzie dove prevista? La sola indicazione del fornitore non basta a dimostrare la valutazione del trasferimento.
6. I trattamenti con dati particolari o giudiziari riportano il motivo dell'obbligatorietà e il riferimento alla valutazione del rischio o alla DPIA? Il collegamento deve puntare a un documento identificabile, non a una cartella.
7. Il registro del responsabile elenca ogni titolare servito e i trattamenti svolti per ciascuno, separato dal registro proprio? Due ruoli confusi in un unico elenco rendono entrambe le evidenze incomplete.

Per ogni risposta negativa aprite subito un finding con responsabile assegnato, scadenza e criterio di chiusura verificabile, invece di correggere la voce in silenzio. La correzione silenziosa elimina il sintomo ma distrugge la traccia che dimostra il funzionamento del controllo. Per selezionare le evidenze da allegare alla verifica, la nostra analisi su quali evidenze includere in un assessment privacy aiuta a distinguere documenti utili da materiale che non dimostra nulla.

Domande frequenti e avvio della revisione del registro

Si può tenere il registro in un foglio di calcolo

Sì, se il file consente di identificare le versioni approvate, le modifiche e chi vi ha avuto accesso. Un foglio senza uno storico attendibile rende difficile ricostruire chi ha cambiato una voce e quando. Se mantenete il registro in un foglio, conservate le versioni approvate in sola lettura e annotate le modifiche con autore e approvatore. Quando aumentano le voci e i collegamenti a contratti, DPIA e finding, la manutenzione manuale può rendere più difficile tenere aggiornato l'inventario.

Chi firma il registro

Il titolare del trattamento, o una persona delegata con potere di firma, approva il registro relativo alle attività svolte sotto la sua responsabilità. Il DPO può verificare le voci, supportare il titolare e segnalare incongruenze; il suo ruolo non trasferisce la responsabilità del titolare.

La firma dovrebbe identificare la versione approvata, la data e le voci interessate. Una sottoscrizione generica, senza un riferimento preciso al contenuto, dice poco se il registro è stato modificato in seguito.

Cosa fare quando un owner lascia l'organizzazione

Prima del cambio di ruolo o della chiusura del rapporto, documentate il passaggio: voci assegnate, riesami aperti, finding pendenti e nuovo responsabile. Il nuovo owner dovrebbe verificare le voci ricevute e registrare la presa in carico con la relativa data.

Per ogni controllo, lo snapshot delle responsabilità di AuditReady registra nome, ruolo, livello, data e motivo dello snapshot. Questo permette di ricostruire la responsabilità registrata al momento della rilevazione.

Con quale cadenza riesaminare il registro

Definite una cadenza periodica e affiancatela a un riesame quando cambia un elemento rilevante, come un sistema o un fornitore. La frequenza va calibrata sulla velocità con cui cambia l'organizzazione: un controllo periodico senza aggiornamenti legati agli eventi può lasciare lacune, mentre un ciclo troppo frequente e scollegato da cambiamenti concreti rischia di diventare una conferma formale.

Registrate entrambi i tipi di riesame. Per ciascuno indicate chi lo ha svolto, quali voci ha verificato e quali azioni sono rimaste aperte.

Da dove iniziare la revisione

Partite dai trattamenti che emergono da contratti attivi, catalogo applicativo e informative pubblicate; poi confrontateli con il registro esistente. Per ogni voce incompleta o priva di responsabile, assegnate un owner e definite quale riscontro serve per chiudere la revisione. Concludete il primo ciclo con un riesame tra owner, referente privacy e DPO, documentando approvazioni e azioni da completare.

Il registro è un inventario vivo: la sua attendibilità dipende dalla riconciliazione con contratti, informative e sistemi effettivamente utilizzati. Il file, da solo, non dimostra che le informazioni siano aggiornate. Servono una data di riesame, un'approvazione identificabile e una traccia delle modifiche apportate.

AuditReady collega i registri GDPR di RoPA, DPIA, DSAR e breach a responsabilità, scadenze, attività di trattamento ed evidenze disponibili. Per ciascuna evidenza registra il periodo di conservazione, la scadenza e l'eventuale legal hold. La piattaforma mantiene tracciabili le operazioni, ma non certifica la conformità né sostituisce la consulenza legale. La responsabilità del contenuto resta in capo alle persone che lo verificano e approvano.

Se il registro è ancora in un foglio senza approvazioni e modifiche facilmente ricostruibili, collegate le voci ROPA alle evidenze e alle azioni correttive in un unico record di lavoro. AuditReady organizza responsabilità, scadenze e pacchetti strutturati per il giorno della verifica, con audit trail tracciato.