Governance dei dati per il GDPR: come rendere operativi i requisiti di conformità

Il GDPR indica alle organizzazioni cosa devono fare con i dati personali, ma non prescrive un framework di governance dei dati né un modello operativo. Questa scelta è intenzionale: il GDPR è stato concepito per applicarsi a settori, organizzazioni di diverse dimensioni e ambienti tecnici troppo eterogenei per adottare un unico approccio prestabilito. Il regolamento definisce i risultati richiesti, non i metodi da adottare.

Per ottenere questi risultati, le organizzazioni hanno bisogno di più di una semplice policy. Una governance dei dati efficace per il GDPR consente di identificare i dati personali detenuti da un’organizzazione, tracciarne l’utilizzo, mostrare quali controlli si applicano e produrre prove del loro funzionamento coerente nei sistemi effettivamente in uso.

Il Regolamento Generale sulla Protezione dei Dati (RGPD, più noto con l’acronimo inglese GDPR) è in vigore da maggio 2018. Si applica a qualsiasi organizzazione che tratti dati personali di residenti nell’UE, indipendentemente dal luogo in cui ha sede. Gli obblighi fondamentali del regolamento, conoscere i dati personali detenuti, garantirne l’esattezza e l’utilizzo esclusivo per finalità definite e proteggerli con controlli adeguati, richiedono sistemi operativi specifici. Il principio di responsabilizzazione (articolo 5, paragrafo 2) lo stabilisce esplicitamente: le organizzazioni devono poter dimostrare di rispettare i principi del GDPR, non limitarsi ad affermarlo.

Policy documentate, ruoli definiti, controlli tecnici e registri di audit devono collegare le policy al trattamento effettivo dei dati. Un audit trail (registro di controllo) non è facoltativo ai sensi del GDPR.

Sia i titolari sia i responsabili del trattamento hanno obblighi ai sensi del GDPR, anche se sui titolari ricade la responsabilità più ampia. Quando è richiesta la nomina di un responsabile della protezione dei dati, questa figura deve avere piena visibilità sulle attività di trattamento, sui controlli e sulle decisioni relative ai rischi, non essere soltanto un punto di contatto nominale.

Il modo più chiaro per comprendere cosa richiede il GDPR a un programma di governance consiste nell’associare i singoli articoli alle capacità operative che implicano.

Questa corrispondenza è utile perché il GDPR è formulato come un regolamento, non come una guida all’implementazione. Stabilisce ciò che deve essere garantito: i dati devono essere accurati, i trattamenti devono essere registrati e gli accessi devono essere appropriati, senza specificare i sistemi o i processi necessari per far rispettare tali requisiti. Un programma di governance svolge questa funzione.

L’articolo 25 merita particolare attenzione. La “protezione dei dati fin dalla progettazione” (privacy by design) richiede che la protezione sia integrata nel trattamento sin dall’inizio e che l’accesso ai dati personali sia limitato di default, anziché concesso di default. In termini di governance, ciò significa classificare i dati durante o in prossimità dell’ingestion, associare i controlli agli asset di dati e applicare automaticamente la logica delle policy, senza affidarsi a valutazioni umane caso per caso.

I requisiti di valutazione d’impatto sulla protezione dei dati (DPIA) previsti dall’articolo 35 si applicano specificamente ai trattamenti ad alto rischio: monitoraggio sistematico su larga scala, categorie particolari di dati e processi decisionali automatizzati con effetti significativi. Non tutti i trattamenti richiedono una DPIA, ma un programma di governance deve prevedere un percorso chiaro per determinare quando è necessaria e sottoporla alla verifica appropriata.

Un programma pronto per il GDPR si basa in genere su quattro pilastri fondamentali: inventario, classificazione, applicazione dei controlli di accesso e verificabilità.

I dati personali non possono essere governati se non possono essere individuati. Un inventario identifica quali dati personali esistono, dove risiedono, come si spostano tra i sistemi e quali processi aziendali li utilizzano. Supporta direttamente gli obblighi di registrazione previsti dall’articolo 30 ed è alla base di tutte le altre attività: valutazione del rischio, verifica degli accessi, decisioni sulla conservazione e risposta agli incidenti.

Un catalogo dati e le funzionalità di data lineage rendono operativo l’inventario. Una tabella contenente indirizzi email dei clienti, trascrizioni delle interazioni con l’assistenza o attributi relativi alla salute deve essere visibile non solo come oggetto tecnico, ma anche nel suo contesto: che cosa la alimenta, quali elementi alimenta e a quale finalità aziendale risponde. Le decisioni di governance dipendono dall’utilizzo effettivo dei dati, non soltanto dalla loro ubicazione.

I principi del GDPR sono molto più facili da applicare quando ai dati personali viene assegnato un tagging coerente durante o in prossimità dell’ingestion. La classificazione fornisce il segnale da cui dipendono i controlli a valle. Una volta classificati tramite tag come personali, sensibili o di altro tipo, i dati possono essere automaticamente associati a policy di mascheramento, regole di accesso, piani di conservazione e monitoraggio. Questa è la logica operativa alla base dell’articolo 25. Il requisito consiste nell’integrare la protezione nella progettazione del trattamento sin dall’inizio.

La minimizzazione dei dati deve essere applicata mediante controlli tecnici, non soltanto dichiarata in una policy. Un programma di governance deve adottare un’impostazione che limiti l’accesso di default e lo conceda in modo esplicito in base al ruolo e alla finalità dichiarata.

Il controllo degli accessi basato sui ruoli (RBAC), la sicurezza a livello di colonna e il mascheramento sono i meccanismi utilizzati nella pratica. È preferibile associare la policy ai dati stessi, affinché i controlli valutino il ruolo o la finalità dell’utente ed espongano soltanto ciò che l’attività richiede, senza dover ricreare le condizioni di accesso per ogni campo e ogni interrogazione.

Un programma di governance conforme al GDPR è incompleto senza evidenze. La sola esistenza di una policy non è sufficiente. Devono esistere registri che dimostrino che la policy è stata applicata agli accessi effettivi ai dati e alle attività di trattamento.

La registrazione degli accessi, la cronologia delle query e gli audit che tengono conto del data lineage forniscono tali evidenze. Se a un’organizzazione viene chiesto quali utenti abbiano interrogato una colonna contenente dati personali, se un attributo soggetto a restrizioni sia confluito in una vista a valle o quale attività di trattamento abbia supportato una determinata finalità aziendale, le risposte devono provenire dai registri, non da una ricostruzione manuale eseguita su più sistemi.

La solidità di un programma di governance dipende dai controlli applicati nel data layer. Snowflake fornisce un livello di enforcement che consente alle organizzazioni di applicare classificazione, controlli degli accessi e registri di audit agli asset di dati, anziché mantenerli soltanto nella documentazione.

Il requisito di responsabilizzazione del GDPR impone a un’organizzazione di dimostrare che i controlli vengono applicati in modo coerente ai dati reali. Una piattaforma che applica le policy al data layer in modo automatico e su larga scala rafforza e semplifica la capacità delle organizzazioni di dimostrare la conformità.

Ad esempio, Snowflake Horizon consente la classificazione automatica dei dati sensibili, identifica i dati personali e assegna tag definiti dal sistema e dagli utenti. Il mascheramento basato su tag consente di limitare l’accesso di default, consentendo l’attuazione del requisito della “protezione dei dati fin dalla progettazione” previsto dall’articolo 25.

La sicurezza a livello di colonna e l’RBAC applicano la minimizzazione dei dati a livello di campo, garantendo che gli utenti vedano solo quanto richiesto dal proprio ruolo e dalla finalità dichiarata (articoli 25 e 32). La cronologia degli accessi registra ogni query eseguita sui dati personali, inclusi l’utente, la query e le colonne specifiche lette o scritte, consentendo alle organizzazioni di generare registri di audit in linea con l’articolo 30 e con gli obblighi di responsabilizzazione previsti dall’articolo 5, paragrafo 2. Le funzionalità Snowflake di catalogo dati e data lineage supportano l’inventario dei trattamenti da cui dipende la tenuta dei registri prevista dall’articolo 30.

Esiste anche una dimensione transfrontaliera. Il capo V del GDPR disciplina i trasferimenti di dati personali verso Paesi terzi e organizzazioni internazionali. Gli impegni Snowflake in materia di residenza dei dati prevedono di default che i dati inattivi restino nella regione di deployment del cliente. Ciò consente alle organizzazioni di progettare casi d’uso con requisiti specifici di residenza, ma la conformità dei trasferimenti dipende comunque dal più ampio contesto giuridico e contrattuale, incluse, ove applicabili, le decisioni di adeguatezza, le clausole contrattuali tipo o le norme vincolanti d’impresa.

La conformità al GDPR è spesso considerata soprattutto una questione giuridica. Il principio di responsabilizzazione chiarisce che è anche una questione operativa. Un’organizzazione in grado di identificare i propri dati personali, tracciarne gli spostamenti, applicare controlli degli accessi e produrre registri di audit costruisce la data foundation operativa necessaria per rendere sostenibile la governance dei dati ai fini del GDPR. In Italia, l'autorità di controllo competente è il Garante per la protezione dei dati personali, il cui sito ufficiale (garanteprivacy.it) pubblica linee guida e provvedimenti applicativi del GDPR.