Privacy by design e by default, la sfida della protezione dei dati personali

Le piattaforme applicative di massa che sono ampiamente diffuse nelle organizzazioni e che costituiscono il supporto fondamentale ai processi (dalle vendite alle fatturazioni, dalla gestione del personale o dei pazienti sanitari alla logistica) hanno bisogno di essere ripensate alla luce di due paradigmi fondamentali introdotti dal GDPR: la protezione dei dati personali by design e by default.

Sono un po’ come le Ford Model T dell’ICT, soltanto che la sfida della loro ottimizzazione è più complessa rispetto a quella di un’automobile. Vediamo perché.

Siamo tutti Model T

Agli inizi del ‘900 la Ford cominciò a produrre la prima vettura “in serie”: la Model T. Non aveva paraurti, né indicatori di direzione luminosi e neanche il tachimetro. Si narra, addirittura, che Henry Ford un giorno ebbe a dire “Ognuno può avere la propria Model T del colore che gli piace, purché sia nero”. Infatti, il prodotto era giovane e nasceva per la seguente finalità: risparmiare tempo durante il percorso usando un veicolo a motore. Il progetto si era concentrato su questo e, soprattutto, sulla riduzione dei costi di produzione per permettere a molti (Ford diceva “a tutti”) l’acquisto di un veicolo di questo genere.

Certamente, nelle riunioni progettuali, non si era tenuto conto dei seguenti rischi:

• danneggiamento per urto frontale o posteriore che, successivamente, avrebbe fatto concepire i paraurti (guardando la Model T ci si può accorgere, addirittura, che le ruote erano sporgenti rispetto alla scocca);
• investimento di pedoni nei cambi di direzione che, nelle auto moderne, avrebbe fatto nascere le frecce luminose;
• difficoltà di frenata in caso di ostacolo imprevisto che, dopo, avrebbe fatto installare il tachimetro per controllare istantaneamente la velocità del mezzo.

In quel momento storico, peraltro, nessuno poteva pensare a rischi di tal genere: le automobili erano talmente rare che, per esempio, i pedoni si scostavano ad ogni rombo di motore che sentivano in lontananza.

Data protection by design e by default: ecco le linee guida EDPB

Model T e la protezione dei dati personali

Un fenomeno analogo succede, oggi, per la protezione dei dati personali sia dal punto di vista organizzativo sia da quello tecnologico.

Le organizzazioni hanno, nel tempo, ricercato

• un assetto efficiente che potesse ridurre i costi e renderle competitive sul mercato (per quelle private) o per assicurare la conformità ai vincoli di bilancio pubblico (per quelle pubbliche);
• un’infrastruttura tecnologica che assicurasse la piena rispondenza ai cicli produttivi (intesi in senso lato sia nel pubblico sia nel privato).

Quindi, come per la Model T, sia gli aspetti organizzativi sia quelli tecnologici scontano un ritardo nella valutazione dei rischi rispetto al trattamento dei dati personali. Solo nell’ultimo decennio, e prevalentemente sul fronte tecnologico, è stato elevato il livello di attenzione sulla sicurezza; ma ciò è avvenuto in maniera perlopiù difensiva del business e, comunque, senza un reale impegno progettuale ed a budget molto limitato.

Il mondo, invece, è cambiato:

• la facilità con la quale le minacce possono sfruttare le vulnerabilità è molto aumentata, soprattutto sul fronte tecnologico;
• la sensibilità verso i diritti e le libertà degli individui e, quindi, verso la protezione dei dati personali, ha indotto molti Stati ad irrigidire il quadro normativo chiedendo maggiori garanzie su questo fronte; infatti, sulla scia dell’Unione Europea con il GDPR, molte altre nazioni hanno varato norme simili anche per assicurarsi la possibilità di agire nel mercato del vecchio continente.

L’impegno dei produttori

E se questo impegno non fosse chiaro dalla lettura sistematica del GDPR, l’European Data Protection Board (EDPB) ha approvato, nella riunione plenaria tenutasi il tra il 12 ed il 13 novembre scorso, le Guidelines on Data Protection by Design & Default (Linee guida sulla protezione dei dati personali fin dalla progettazione e per impostazione predefinita).

Evidentemente, l’EDPB ha tenuto conto delle ragioni del ritardo accumulato, soprattutto in ambito ICT, e, per agevolare il percorso di compliance, ha focalizzato l’attenzione su due aspetti:

• i titolari (ma anche i responsabili) devono introdurre nei processi di trattamento appropriati indicatori chiave di performance che misurino l’efficacia delle misure e delle salvaguardie finalizzate a limitare i rischi per i diritti e le libertà degli individui (vedi punto 16 e seguenti delle Linee guida); questo impegno è necessario sia in fase di progettazione (by design ovvero quando si studia come il processo di trattamento sarà condotto) sia in fase di esercizio (by default ovvero durante tutta conduzione ordinaria del processo di trattamento); insomma, per riprendere il paragone con la Model T, bisogna progettare il tachimetro e fare in modo che questo tachimetro venga osservato durante il percorso;
• i titolari (ma anche i responsabili) devono affidarsi a produttori di software e di piattaforme applicative in generale (i technology provider delle Linee guida) che garantiscano una progettazione ed un funzionamento in linea con le indicazioni del GDPR (vedi punto 86 delle Linee guida).

Tenuto conto di questi aspetti, si può dire che pochissimi fornitori di tecnologia (soprattutto i produttori, grandi e piccoli, di software prêt-à-porter) si sono impegnati a introdurre misure e salvaguardie per ridurre i rischi per il trattamento dei dati personali.

Per esempio, quanti produttori di software per la gestione delle risorse umane hanno introdotto una funzione che consente al datore di lavoro (titolare del trattamento) di corrispondere in maniera corretta ad una richiesta di limitazione del trattamento di un proprio dipendente effettuata conformemente all’articolo 18 del GDPR? Questa sarebbe, nel lessico utilizzato dall’EDPB nelle Linee guida, una salvaguardia per i diritti e le libertà dell’interessato.

E quanti produttori di software di contabilità hanno introdotto un indicatore sul numero di clienti ai quali non si fattura da più di un certo numero di anni e la contestuale possibilità di anonimizzare i dati in modo sistematico ed efficace in tutte le tabelle? E conviene fermarsi solo a questa domanda perché, se si allarga lo sguardo alle molteplici duplicazioni di tabelle fatte per servire più applicativi software in assenza di un ERP (per esempio, quello dell’area marketing e quello della logistica), la situazione potrebbe essere ancora più spinosa.

Questo ragionamento porta a due conclusioni alternative:

• il titolare partecipa alla progettazione della soluzione tecnologica (software o infrastrutturale) e, in pratica, non ricorre più a quella chiavi in mano che, di solito, si presta poco ad essere adattata al singolo cliente; in questo caso, titolare e fornitore tecnologico valutano insieme i rischi connessi al processo di trattamento dei dati personali e progettano la soluzione più idonea; per i soggetti che devono conformarsi al Codice dei contratti pubblici si tratta di basare la scelta del contraente sul dialogo competitivo previsto dall’art. 64 del Dlgs. 50/2016;
• il titolare, nella scelta del partner tecnologico, ha già effettuato una valutazione dei rischi e riesce a delineare nel capitolato tecnico le misure e le salvaguardie che il fornitore deve assicurare; in questo caso, i soggetti pubblici, nelle ordinarie procedure di scelta del contraente previste dal Dlgs. 50/2016, devono motivare accuratamente le parti che contengono i requisiti specifici per evitare contenziosi innescati per la presenza di “clausole immediatamente escludenti”.

Non solo minimizzazione e non solo ICT

Un’ulteriore indicazione rilevante fornita dall’EDPB nelle Linee guida riguarda la protezione dei dati by default: non coincide, come molti credono, con la minimizzazione dei dati personali (vedi punto 40 delle Linee guida). È vero che l’elemento di base di questo paradigma (le Linee guida lo chiama requisito, requirement) può sintetizzarsi nel preconfigurare i sistemi informatici (non solo informatici) per ridurre al minimo i dati personali necessari. Ma ricordiamo che un processo di trattamento di dati personali è l’incrocio di almeno quattro elementi: dati personali, operazioni di trattamento, strumenti di trattamento e soggetti autorizzati alle operazioni di trattamento. È, quindi, una funzione con almeno quattro variabili indipendenti della quale, a sua volta, è necessario calcolare un’ulteriore funzione: quella del rischio. Solo allora possiamo definire misure e salvaguardie che, appunto, mitigano by default il rischio in dipendenza delle quattro variabili iniziali.

Per fare un esempio pratico, l’assistenza di un malato degente presso una residenza sanitaria assistenziale (RSA) da parte dei sanitari ospedalieri che lo curano è un processo di trattamento che prevede:

• dati appartenenti alle particolari categorie che possono variare dal quadro clinico riferito a precedenti ricoveri presso l’ospedale fino alla terapia urgente per uno stato di acuzia sopravvenuta;
• operazioni di trattamento che vanno dalla trasmissione della cartella clinica fino alla consultazione di dati clinici in telemedicina;
• strumenti di trattamento che vanno dal software di gestione della cartella clinica fino al fax per la trasmissione della stessa dall’ospedale alla RSA;
• soggetti autorizzati che sono i medici dell’ospedale, il personale infermieristico, gli operatori socio‑sanitari della RSA.

In questo quadro, è necessario applicare procedure organizzative fin dalla progettazione (by design) del trattamento affinché, di volta in volta e by default, siano individuati i dati giusti, le operazioni corrette, gli strumenti adeguati ed i soggetti autorizzati al fine di ridurre i rischi per i diritti e le libertà dei pazienti.

Conclusioni

Sembra una sfida non facile, anche perché, diversamente da quanto è accaduto per l’evoluzione nel campo delle automobili, i tempi non sono lunghi: ci vogliono soluzioni rapide che consentano di guidare i dati personali con tranquillità. E non basta il tachimetro…