La privacy by design nella progettazione di soluzioni SaaS: il caso TuPassi

Il Garante per la protezione dei dati personali con il provvedimento del 17 dicembre 2020, reso pubblico il 25 gennaio 2021, ha emesso una ordinanza ingiunzione nei confronti di Roma Capitale per un importo complessivo di 500.000 euro per una serie di violazioni della normativa privacy in relazione all’utilizzo dell’applicazione TuPassi.

Il provvedimento, sostanzialmente, costitusce la diretta conseguenza del precedente provvedimento n. 81 del 7 marzo 2019, dove, all’esisto di una complessa attività istruttoria, era stata dichiarata l’illiceità del trattamento dei dati personali degli utenti del sistema TuPassi, messo a disposizione da Roma Capitale per la prenotazione degli appuntamenti presso gli uffici comunali.

In questo articolo, ci sembra interessante sottolineare come la sanzione costituisca in larga misura il risultato sia di una gestione non corretta dei rapporti tra Titolare e Responsabile del trattamento, sia di una progettazione della soluzione software fornita al Comune non conforme ai principi di privacy by design.

Infatti, Roma Capitale - da qualificarsi Titolare del trattamento (definendone finalità e modalità) - aveva acquistato in licenza d’uso la soluzione software alla base del servizio TuPassi da un fornitore esterno. Detto fornitore, inoltre, aveva garantito il servizio di assistenza e manutenzione e tutto ciò aveva comportato un trattamento di dati personali per conto del Titolare.

Questa dinamica è particolarmente frequente nel mondo IT. Molto spesso, infatti, un’impresa che necessita di un determinato servizio informatico (pensiamo ad esempio alla lettura dei badge dei dipendenti, al monitoraggio della temperatura ecc.) lo acquisisce in licenza da un fornitore esterno (con varie modalità) e quest’ultimo, generalmente, offre anche un servizio di assistenza e configurazione.

Logicamente, nel momento in cui il fornitore esegue interventi di manutenzione o assistenza potrebbe effettuare attività di trattamento di dati personali (si pensi ad un intervento di manutenzione su un database). In tutti questi casi, è noto che il fornitore debba essere designato come Responsabile del Trattamento ai sensi dell’art. 28 del Regolamento Europeo e che dovrà ricevere puntuali istruzioni e direttive dal Titolare (anche per quanto attiene alle misure di sicurezza da adottare).

La questione più interessante della vicenda, tuttavia, attiene proprio alla progettazione del sistema. Nel caso TuPassi, il Garante, pur chiarendo che il rispetto dei principi di privacy by design e privacy by default è inteso come obbligo del Titolare, ha, comunque, incoraggiato la società fornitrice dell’applicativo ad adottare specifiche cautele volte a “facilitare” l’adempimento degli obblighi gravanti sui Titolari.

Ciò si traduce, di fatto, nella necessità di tener conto del diritto alla protezione dei dati personali sin dal momento della progettazione del sistema informatico. Nel caso di TuPassi, il Garante ha indicato possibili spunti nella possibilità di:

• impostare, a monte, tempi di conservazione diversificati per ciascuna categoria di dati;
• definire le categorie di dati personali da utilizzare;
• impostare, a valle, tempi di conservazione diversificati in relazione all’esito degli appuntamenti;
• trasformare in forma anonima i dati personali oggetto di trattamento.

Si richiede, quindi, al fornitore della soluzione software di immedesimarsi nel Titolare del trattamento, cercando di rendere possibili, nei parametri di configurazione del servizio, quante più opzioni possibili al fine di consentire a quest’ultimo di effettuare decisioni consapevoli, da un punto di vista di accountability, in merito al trattamento di dati personali.

Ciò, però, richiede una notevole elasticità durante la fase di sviluppo. Ad esempio, nella definizione della struttura dati (es. dei modelli, nel caso si utilizzi un ORM - Object Relational Mapping) occorrerà gestire sin da subito la trasformazione anonima dei dati trattati. Obiettivo che potrebbe essere raggiunto in vari modi:

• con una specifica funzione da invocare, volta per volta, in relazione a singoli utenti (pensiamo ad un pulsante anonimizza);
• con una funzione che verrà eseguita dal sistema in automatico, a certi intervalli prestabiliti, su tutti gli utenti o solo su alcune categorie o al verificarsi di certe condizioni (es. decorsi X giorni dall’appuntamento, trasformazione in forma anonima dei dati personali del richiedente).

Ovviamente, in questo caso dovrebbe essere assicurata l’efficacia dell’algoritmo di anonimizzazione (al riguardo si rinvia, ad esempio, al parere 1/2014 del WP29 sulle tecniche di anonimizzazione), possibilimente sulla base di documentata letteratura scientifica e/o idonea relazione tecnica.

Come si può ben osservare, tutto ciò, da un lato comporta una maggiore complessità in fase di sviluppo, dall’altro, però, potrebbe fornire un importante vantaggio competitivo. Infatti, una soluzione software che effettivamente consenta al Titolare di esplicare in concreto le proprie decisioni in tema di finalità e modalità di trattamento (anche in piena autonomia) ben potrebbe essere preferita, a parità di condizioni, rispetto ad altre in cui si richiedano specifici interventi ex post (onerosi e spesso forieri di malfunzionamenti successivi).

Sul tema, segnaliamo anche le linee guida dell’Autorità Garante Francese per gli sviluppatori di software, pubblicate su GitHub (e, quindi, in continua evoluzione) che contengono una serie di utili suggerimenti su come impostare correttamente lo sviluppo di un’applicazione nel rispetto del Regolamento Europeo sulla privacy.