La definizione giuridica: articolo 4(1) del GDPR
Il GDPR getta una rete deliberatamente ampia. L'articolo 4(1) definisce i dati personali come:
"Qualsiasi informazione riguardante una persona fisica identificata o identificabile ('interessato'); si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento a un identificativo come il nome, un numero di identificazione, dati relativi all'ubicazione, un identificativo online o a uno o più elementi caratteristici della sua identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale."
Articolo 4(1), Regolamento (UE) 2016/679
Quattro elementi fanno funzionare questa definizione, e ciascuno è importante per il modo in cui classifichi i dati nella tua organizzazione:
- "Qualsiasi informazione", nessun limite di formato. Testo, numeri, foto, registrazioni audio, modelli biometrici, metadati e schemi comportamentali si qualificano tutti.
- "Riguardante", l'informazione deve concernere l'individuo, per contenuto (lo descrive), per finalità (è utilizzata per valutarlo) o per risultato (il suo trattamento ha un impatto su di lui).
- "Identificata o identificabile", la persona non deve essere nominata. Se puoi distinguerla combinando punti dati, è sufficiente.
- "Persona fisica". Il GDPR protegge gli individui viventi, non le aziende. Ma i dati relativi a un libero professionista o a un dipendente nominato sono dati personali.
La conseguenza pratica: se esiste una ragionevole possibilità che chiunque, non solo tu, ma qualsiasi parte con accesso, possa ricollegare i dati a un individuo, si tratta di dati personali ai sensi del GDPR. Ecco perché gli errori di classificazione si propagano a cascata nell'intero programma di conformità.
Esempi reali: cosa rientra e cosa no
Il confine tra dati personali e dati non personali è meno ovvio di quanto la maggior parte delle organizzazioni supponga. Ecco come i tipi di dati più comuni si classificano ai sensi del GDPR, sulla base degli orientamenti normativi e della giurisprudenza della CGUE:
| Tipo di dato | Dato personale? | Perché |
|---|---|---|
| Nome e cognome | Sì | Identifica direttamente un individuo |
| Email: [email protected] | Sì | Identifica una persona fisica per nome |
| Email: [email protected] | No | Indirizzo generico, nessuna persona identificabile |
| Indirizzo IP dinamico | Sì | Sentenza Breyer della CGUE (C-582/14): identificabile con i registri dell'ISP |
| ID cookie / fingerprint del dispositivo | Sì | Identificativo online ai sensi del considerando 30; distingue un utente |
| Numero di matricola del dipendente | Sì | Numero di identificazione collegato a una persona specifica |
| Dati di geolocalizzazione GPS | Sì | Traccia gli spostamenti di un individuo; identificativo di ubicazione |
| Dati salariali collegati al ruolo | Sì | Combinati con reparto/ruolo, identificano l'individuo |
| Risultati di sondaggi anonimizzati | Dipende | Non personali solo se la re-identificazione non è ragionevolmente possibile |
| Record dei clienti pseudonimizzati | Sì | Re-identificazione possibile con la chiave conservata separatamente |
| Filmati di videosorveglianza | Sì | Immagini di individui identificabili |
| Statistiche aggregate (dataset di grandi dimensioni) | No | Solo se gli individui non possono essere distinti dall'aggregato |
| Risultati di test genetici | Sì (categoria particolare) | Categoria particolare dell'articolo 9, dati genetici |
| Appartenenza sindacale | Sì (categoria particolare) | Categoria particolare dell'articolo 9, elencata esplicitamente |
La trappola dell'"effetto mosaico"
Molte organizzazioni classificano i singoli punti dati in modo isolato, un numero di dipendente qui, un codice di reparto là, e concludono che non si tratta di dati personali. Ma il GDPR considera l'identificabilità attraverso la combinazione. Quando il tuo sistema HR, la piattaforma di payroll e i log di controllo degli accessi possono essere incrociati, dati che sembrano anonimi in un sistema diventano dati personali nell'aggregato. È esattamente questa la lacuna che la mappatura dei dati tra entità è progettata per colmare.
Categorie particolari: i dati dell'articolo 9 richiedono una protezione aggiuntiva
Il GDPR tratta determinati tipi di dati personali come intrinsecamente ad alto rischio. L'articolo 9 vieta il trattamento di queste categorie a meno che non si applichi una specifica deroga giuridica, e le sanzioni in caso di errore sono proporzionalmente più elevate.
Le categorie particolari sono:
- Origine razziale o etnica, include i campi relativi alla nazionalità nei sistemi HR se rivelano l'etnia
- Opinioni politiche, donazioni a partiti politici, dati di registrazione elettorale
- Convinzioni religiose o filosofiche, campi relativi alle preferenze alimentari che rivelano la religione (ad es. "halal" o "kosher" nei sistemi di ristorazione)
- Appartenenza sindacale, trattenute in busta paga per le quote sindacali
- Dati genetici. Risultati di test del DNA, informazioni ereditarie
- Dati biometrici (quando utilizzati per l'identificazione), scansioni di impronte digitali, modelli di riconoscimento facciale. Nota: i dati biometrici utilizzati per l'autenticazione (sbloccare un telefono) potrebbero non far scattare l'articolo 9 in tutte le interpretazioni, ma i log di accesso tramite impronta digitale lo fanno certamente
- Dati relativi alla salute, registri di congedo per malattia, accomodamenti per disabilità, valutazioni di medicina del lavoro, richieste di indennizzo assicurativo. Questa è la categoria più comunemente classificata in modo errato negli ambienti aziendali
- Vita sessuale o orientamento sessuale. Campi di monitoraggio della diversità nelle HR, designazioni di beneficiari che rivelano il genere del partner
Dove le organizzazioni multi-entità vengono colte in fallo
L'errore più comune che riscontriamo nelle organizzazioni che gestiscono la privacy su più filiali: l'incoerenza nella classificazione dei dati sanitari. Un registro di congedo per malattia è classificato come "dato HR standard" in una filiale e come "dato sanitario dell'articolo 9" in un'altra. Quando un'autorità di controllo verifica il gruppo, l'incoerenza stessa diventa prova di una governance inadeguata. Ecco perché una tassonomia dei dati unificata in tutte le entità non è facoltativa: è il fondamento di una conformità difendibile.
Basi giuridiche per il trattamento delle categorie particolari
Il trattamento dei dati appartenenti a categorie particolari richiede sia una base giuridica ai sensi dell'articolo 6 sia una deroga separata ai sensi dell'articolo 9(2). Le deroghe più frequentemente invocate includono:
- Consenso esplicito (articolo 9(2)(a)), deve essere libero, specifico, informato e inequivocabile. Il consenso implicito non è mai sufficiente.
- Obblighi di diritto del lavoro (articolo 9(2)(b)), trattamento necessario per assolvere obblighi ai sensi del diritto del lavoro e della sicurezza sociale
- Interessi vitali (articolo 9(2)(c)), situazioni mediche di emergenza in cui l'interessato non può prestare il consenso
- Interesse pubblico rilevante (articolo 9(2)(g)), deve essere proporzionato e prevedere garanzie
Dati pseudonimizzati vs. dati anonimizzati: la distinzione cruciale
È qui che i programmi di conformità sbagliano più che in quasi qualsiasi altro punto. La distinzione determina se il GDPR si applica o meno, e il confine è molto meno chiaro di quanto la maggior parte delle organizzazioni supponga.
Dati pseudonimizzati = comunque dati personali
La pseudonimizzazione sostituisce gli identificativi diretti con identificativi artificiali (token, codici, hash) mantenendo separata la chiave di re-identificazione. Il GDPR definisce esplicitamente la pseudonimizzazione all'articolo 4(5) e tratta i dati pseudonimizzati come dati personali a tutti gli effetti.
Perché? Perché la re-identificazione è possibile. La chiave esiste da qualche parte. Finché una qualsiasi parte, tu, un responsabile del trattamento, un destinatario dei dati o un aggressore con uno sforzo ragionevole, potesse ricollegare lo pseudonimo all'individuo, esso resta un dato personale soggetto a tutti gli obblighi del GDPR.
La pseudonimizzazione è una misura di sicurezza, non una deroga. Può ridurre il rischio (e il GDPR la riconosce come garanzia negli articoli 25 e 32), ma non rimuove i dati dall'ambito di applicazione del GDPR.
Dati anonimizzati = al di fuori dell'ambito del GDPR
I dati veramente anonimizzati, in cui la re-identificazione è irreversibile e non ragionevolmente possibile da parte di alcuno con qualsiasi mezzo ragionevolmente utilizzabile, esulano interamente dal GDPR (considerando 26).
Il criterio è rigoroso: devi considerare tutti i mezzi "ragionevolmente utilizzabili" per la re-identificazione, inclusi gli sviluppi tecnologici futuri, il costo della re-identificazione e la disponibilità di dataset complementari. Il Comitato europeo per la protezione dei dati (EDPB) ha fissato un'asticella elevata e le autorità di controllo hanno costantemente accertato che dataset che le organizzazioni ritenevano anonimi erano in realtà pseudonimi.
Implicazione pratica per il tuo registro dei trattamenti
Se il tuo registro delle attività di trattamento esclude dei dataset partendo dal presupposto che siano "anonimizzati", verifica tale presupposto con una valutazione documentata del rischio di re-identificazione. Se ti sbagli, quei dataset avrebbero dovuto figurare nel tuo registro dei trattamenti fin dall'inizio, e ogni attività di trattamento che li coinvolge è rimasta non documentata. La gestione del registro dei trattamenti di Priverion include flussi di lavoro di classificazione dei dati che segnalano esattamente questo tipo di lacuna in tutte le entità del gruppo.
Dati relativi a condanne penali: articolo 10
I dati relativi alle condanne penali e ai reati hanno una propria regola ai sensi dell'articolo 10. Non costituiscono una categoria particolare ai sensi dell'articolo 9, ma il trattamento è riservato all'autorità pubblica o ai casi autorizzati dal diritto dell'UE o di uno Stato membro con garanzie adeguate.
Per i datori di lavoro: controlli sui precedenti, comunicazioni del casellario giudiziale e persino la semplice annotazione che un dipendente ha la fedina penale pulita rientrano tutti nell'articolo 10. Se le tue filiali in diverse giurisdizioni gestiscono in modo diverso lo screening pre-assunzione, il trattamento incoerente dei dati dell'articolo 10 è un rilievo di audit comune.
Dati dei minori: protezioni rafforzate ai sensi dell'articolo 8
Quando si trattano dati personali di minori sulla base del consenso per i servizi della società dell'informazione, il GDPR richiede il consenso dei genitori per i minori di 16 anni (sebbene gli Stati membri possano abbassare tale soglia a 13). Il titolare del trattamento deve compiere sforzi ragionevoli per verificare che il consenso sia prestato dal titolare della responsabilità genitoriale.
Se la tua organizzazione tratta dati di minori, piattaforme educative, programmi di prestazioni familiari, servizi per i giovani, ciò aggiunge un livello di classificazione che la tua mappatura dei dati deve riflettere.
Mappare i dati personali in un'organizzazione multi-entità
Comprendere la definizione è il punto di partenza. La vera sfida per le organizzazioni con più filiali è applicare quella definizione in modo coerente in ogni entità, ogni sistema e ogni giurisdizione.
Ecco il processo che funziona, e ciò che abbiamo visto fallire:
Ciò che funziona: tassonomia centralizzata, esecuzione distribuita
- Stabilire una tassonomia di classificazione dei dati a livello di gruppo, definire le categorie di dati personali in modo identico in tutte le entità. "Dato sanitario" significa la stessa cosa nella tua filiale svizzera e in quella tedesca.
- Mappare le attività di trattamento a livello di entità, ogni filiale documenta le proprie attività di trattamento utilizzando la tassonomia condivisa. Ciò garantisce accuratezza locale con coerenza a livello di gruppo.
- Identificare i flussi di dati tra entità, laddove i dati personali si spostano tra filiali o verso terzi, mappa tali flussi esplicitamente. I trasferimenti infragruppo richiedono comunque una base giuridica.
- Automatizzare la ricertificazione, quando una classificazione cambia (ad es. viene aggiunto un nuovo tipo di dato ai sistemi HR), tale modifica deve propagarsi al registro dei trattamenti di ogni entità. Le catene di email manuali non sono scalabili.
- Rivedere e verificare regolarmente, la classificazione dei dati non è un esercizio una tantum. Nuovi sistemi, nuovi fornitori e gli orientamenti normativi cambiano tutti ciò che si qualifica come dato personale.
Ciò che fallisce: classificazione decentralizzata senza supervisione
Quando ogni filiale definisce i dati personali in modo indipendente, o quando il RPD di gruppo non ha visibilità sulle classificazioni a livello di filiale, le incoerenze si accumulano silenziosamente. La filiale tedesca classifica le preferenze alimentari come dati sanitari (corretto secondo molte interpretazioni delle autorità di controllo). La filiale britannica classifica lo stesso campo come "dato standard del dipendente". Il registro dei trattamenti appare completo in entrambe le entità, ma la postura di conformità del gruppo presenta una lacuna che qualsiasi audit transfrontaliero individuerà.
Questo è esattamente il problema che ha portato alla nascita di Priverion: un'impresa con 12 filiali che gestiva la conformità al GDPR su 47 fogli di calcolo, senza un modo coerente di garantire che gli stessi dati fossero classificati nello stesso modo ovunque.
