In quanto “strumento del trattamento” il software può rappresentare un rischio più o meno elevato per i diritti e le libertà delle persone fisiche. È indispensabile che nello sviluppo del software si abbia la consapevolezza del rischio e si sia in grado di prevederlo e di valutarlo.
Questo è un impegno non trascurabile che dev’essere considerato attentamente per poter determinare, con consapevolezza, i costi e la complessità della realizzazione.
Indice degli argomenti
L’attenzione agli aspetti organizzativi
Sarebbe un errore considerare la protezione dati personali come un problema di sola sicurezza informatica. La protezione dei dati personali non è un mero problema tecnologico. Non si esaurisce con l’adozione di misure destinate alla protezione della soluzione informatica da attacchi e accessi non autorizzati.
Le misure di sicurezza non possono essere decise dai soli tecnici informatici. Serve un approccio integrato tra scelte tecnologiche e aspetti organizzativi. Ove l’attenzione fosse posta ai soli aspetti tecnologici, misure di sicurezza considerate adeguate (ad esempio l’uso della crittografia dei dati sul database e l’utilizzo di un canale cifrato per il trasporto degli stessi), potrebbero essere inficiate da lacune nei processi organizzativi.
Si pensi alla decisione di uno sviluppatore che, non adeguatamente formato alla valutazione del rischio, potrebbe decidere di salvare in un file di log in chiaro i dati di un flusso operativo, in precedenza cifrato, per agevolare le attività di debug applicativo.
Non è difficile indovinare le conseguenze di un eventuale data breach conseguente alla condivisione del file, con altri membri del gruppo di lavoro, su cloud pubblico, durante l’attività di verifica di un baco funzionale di produzione. La situazione si complicherebbe se, in ipotesi, il file contenesse i dati relativi alla salute di un gran numero di persone.
Le decisioni sull’adeguatezza delle misure di sicurezza non possono essere effettuate soltanto dai tecnici. Costoro sono le figure più qualificate a stabilire “come” implementare la soluzione. Ma ogni decisione dev’essere adottata tenendo in considerazione i principi e le regole dettate dal GDPR.
La determinazione dei requisiti e la stessa valutazione in merito alla sostenibilità economica della soluzione vanno effettuate tenendo conto delle esigenze della protezione dei dati personali.
Si tratta quindi di scelte che prescindono dalla mera valutazione tecnologica. Richiedono la capacità di ogni attore di confrontarsi con l’applicazione di questa disciplina e il supporto di processi organizzativi adeguati.
La verifica delle conoscenze
Un indicatore importante della correttezza dell’impostazione del sistema di protezione dei dati personali è dato dalla verifica delle conoscenze richieste alle diverse posizioni organizzative.
Un livello di conoscenza adeguato richiesto a un esperto di sicurezza informatica non desterebbe sorprese. Così come quello appena sufficiente richiesto per l’attività di sviluppatore.
Sarebbe invece difficilmente comprensibile che non si richiedesse a un analista una conoscenza adeguata sul tema. Questi definisce i requisiti funzionali e non funzionali della soluzione. Dovrebbe essere la figura più qualificata a decidere, per esempio, in materia di minimizzazione: non proprio la scelta meno significativa.
E non bisogna dimenticare le figure degli architetti e dei progettisti (applicativi o di base dati). Le loro decisioni possono avere un impatto importante sull’adeguatezza delle misure di sicurezza.
Nella definizione delle competenze delle diverse posizioni organizzative, bisogna tener conto anche delle conoscenze, diverse in funzione del ruolo, in tema di protezione dei dati personali.
Quando si decide “cosa” realizzare, serve tanto la competenza “di dominio”, quanto quella in tema di protezione dei dati personali.
Non è accettabile che chi decide, per esempio, quali dati trattare e per quanto tempo, o i profili di autorizzazione per l’accesso ai dati, non sia esperto nell’applicazione dei principi del trattamento.
Sono spesso gli analisti a decidere in tema di anonimizzazione, aggregazione e condivisione dei dati. Queste decisioni non possono essere adottate senza tener conto delle tecniche di de-indicizzazione e re-indicizzazione, dei principi applicabili al trattamento e della valutazione del rischio di ogni scelta.
Le decisioni in materia di misure di sicurezza, per esempio la crittografia o la pseudonimizzazione, non possono essere adottate senza considerare il trattamento nella sua interezza.
Trattamenti legati all’intero ciclo di vita del software
Un criterio efficace per valutare l’adeguatezza delle misure adottate è quello di considerare i trattamenti come processi legati all’intero ciclo di vita del software.
Fondamentale è la considerazione della complessità dell’organizzazione privacy del titolare. Un indicatore significativo di alta complessità sono le organizzazioni privacy molto articolate: si pensi ai casi, non infrequenti, di “catene di responsabilità” caratterizzati dalla presenza di responsabili e sub-responsabili, impegnati nell’attività di sviluppo del software su commissione del titolare.
L’esperienza dimostra che si tratta di scenari tipici nel contesto di tante pubbliche amministrazioni. Per la mole e la particolarità dei dati trattati, la realizzazione di software non conforme al GDPR, da parte di una pubblica amministrazione, può determinare rischi elevati per i diritti e le libertà delle persone fisiche.
Tirando le somme, se chiedo a un progettista di adottare una misura di sicurezza robusta, questi certamente non sbaglierà decidendo per la crittografia, assumendo, ovviamente, che la considerazione dei costi lo consenta.
La scelta però non può essere slegata dalla considerazione degli aspetti organizzativi.
Solo considerando il trattamento in relazione al suo ciclo di vita, posso rilevare eventuali fattori di rischio capaci di inficiare la bontà della misura selezionata.
Nel caso concreto, la crittografia, misura adeguata in astratto, potrebbe rivelarsi meno efficace della pseudonimizzazione a causa di un problema organizzativo: la mancanza di formazione in materia da parte di uno sviluppatore che vanifichi l’utilizzo della cifratura del dato stampandolo in chiaro e condividendolo.
In questo caso, i dati personali, se fatti oggetto di pseudonimizzazione, sarebbero intellegibili ma gli interessati rimarrebbero non immediatamente identificabili. Livello di sicurezza invece mancante nel caso del dato personale cifrato in origine ma poi reso in chiaro.
Ma anche l’utilizzo della pseudonimizzazione non può essere deciso senza un’attenta valutazione dei costi: auspicabile in sede di nuova implementazione, valutabile in termini di impatto sull’esistente, in sede di evolutiva di una soluzione già esistente.
Questa breve riflessione ci permette di comprendere l’importanza della formazione, della responsabilizzazione delle risorse e dell’adeguatezza dei processi organizzativi.
Il problema della formazione
Non bisogna operare nel settore per comprendere che esperti di business e tecnici informatici, non consapevoli delle esigenze della protezione dei dati, rischiano di adottare decisioni che possono inficiare l’efficacia dei sistemi di protezione dei dati personali. Spesso validi solo in astratto, perché definiti “dall’alto” ma non efficacemente resi “disponibili” a chi poi dovrà applicarli.
Processi organizzativi chiari e piani di formazione adeguati, stabiliscono quale debba essere l’apporto, delle diverse posizioni organizzative, nelle decisioni riguardanti l’adozione delle misure tecniche e organizzative.
La realtà però potrebbe essere profondamente diversa da quanto finora descritto.
Quanto ai processi aziendali, ogni innovazione, soprattutto in realtà rigidamente strutturate, può incontrare ostacoli e richiedere, in ogni caso, tempi lunghi di introduzione e costi non indifferenti.
La stessa formazione delle risorse, per essere adeguata non può certo esaurirsi in una breve presentazione.
A seconda della figura professionale considerata, i tempi della formazione possono essere molto diversi: è diversa infatti la conoscenza, in tema di protezione dei dati personali, richiesta a uno sviluppatore piuttosto che a un sistemista, a un progettista, a un analista, a un capo progetto o a un account.
I soggetti apicali del trattamento, siano essi titolari o responsabili, devono comprendere che a ogni posizione organizzativa viene richiesta una preparazione specifica in tema di protezione dei dati personali.
Non comprendere questo concetto può esporre facilmente al rischio della non conformità e alla violazione dei diritti e delle libertà degli interessati: con le prevedibili conseguenze non solo in termini sanzionatori ma anche, e in questo contesto direi soprattutto, in termini di immagine aziendale.
Un rimedio alle dimenticanze di titolari e responsabili può essere rappresentato dall’esercizio delle funzioni di controllo da parte del DPO, ove presente.
La necessità di un corretto inquadramento dei rapporti con i fornitori
Nella produzione del software, la corretta definizione dei rapporti con i fornitori può diventare un elemento di criticità.
Considerando solo i rapporti con fornitori che intervengono nel ciclo di vita del software, possono essere individuate varie casistiche: si va dalla fornitura di software “a pacchetto”, all’utilizzo delle piattaforme di cloud computing, alla realizzazione di software ad hoc e così via.
Un esempio significativo è quello del prodotto software realizzato su commissione da chi, avendo un forte know how di dominio, si occupi di tutto il ciclo di vita del software, anche della definizione dell’analisi partendo dai requisiti espressi, spesso solo a grandi linee, dal committente.
Si tratta di un caso molto interessante e l’argomento meriterebbe una trattazione autonoma. Ai nostri fini, sono sufficienti alcune considerazioni.
Non sempre gli obblighi del fornitore sono riconducibili al rapporto tra titolare del trattamento e responsabile del trattamento.
In un simile scenario, il fornitore, ancorché non inquadrato come responsabile del trattamento, può adottare le decisioni in materia di applicazione dei principi di data protection by design e data protection by default e quelle riguardanti l’adozione di adeguate misure di sicurezza.
Soluzione conforme all’auspicio espresso nel considerando n. 78 del Regolamento: “in fase di sviluppo, progettazione, selezione e utilizzo di applicazioni, servizi e prodotti basati sul trattamento di dati personali o che trattano dati personali per svolgere le loro funzioni, i produttori dei prodotti, dei servizi e delle applicazioni dovrebbero essere incoraggiati a tenere conto del diritto alla protezione dei dati allorché sviluppano e progettano tali prodotti, servizi e applicazioni […]”.
Il fatto di realizzare un software su commissione non rende necessariamente il fornitore un responsabile del trattamento.
Il responsabile del trattamento infatti è colui che “tratta dati personali per conto del titolare del trattamento” (art. 4, par. 1 del Regolamento).
In mancanza di trattamento, mancano i presupposti per l’applicazione della disciplina riservata al responsabile del trattamento.
Sovente i dati utilizzati nella fase della produzione del software, sono dati fittizi e quindi non viene posto in essere alcun trattamento per conto del titolare.
Se però il fornitore si occupa anche della fase della messa in produzione e dell’assistenza applicativa, trattando dati reali degli interessati, dovrà necessariamente essere inquadrato come responsabile del trattamento e operare sulla base di puntuali istruzioni da parte del titolare del trattamento.
Uguale inquadramento avrà il fornitore qualora nella fase di pre produzione, vengano utilizzati dati di produzione. Si tratta di casi che dovrebbero essere considerati come eccezione alla regola. Un simile utilizzo infatti potrebbe avvenire in violazione dei principi del Regolamento, se non adeguatamente regolamentato e concordato con il titolare del trattamento. Se la scelta fosse frutto della decisione autonoma di un analista o di un progettista, saremmo in presenza di un tipico esempio di non adeguatezza dei processi organizzativi.
Anche a questo proposito, la formazione e la sensibilizzazione delle risorse hanno importanza fondamentale.
Il rapporto tra titolare e responsabile del trattamento
I soggetti apicali del trattamento devono determinare con puntualità le rispettive aree di intervento, in merito all’applicazione della disciplina della protezione dei dati personali.
Qualora nessuna della parti avesse un’adeguata preparazione in materia, lacune e indeterminatezze nella definizione dei rispettivi rapporti giuridici potrebbero risultare problematiche oltre che onerose.
Non sarebbe una buona pratica l’accordo o altro atto giuridico, con il quale il titolare committente, a norma dell’art. 28 del Regolamento, designasse il fornitore responsabile del trattamento, senza precisare in modo puntuale le proprie istruzioni al riguardo.
La questione diventerebbe ancora più delicata nel caso di ricorso da parte del responsabile ad altro responsabile. L’art. 28, par. 4, del Regolamento, stabilisce che al sub-responsabile siano imposti “gli stessi obblighi in materia di protezione dei dati contenuti nel contratto o in altro atto giuridico tra il titolare del trattamento e il responsabile del trattamento”.
È facile comprendere le difficoltà di interpretazione degli obblighi dei responsabili, in mancanza di istruzioni puntuali da parte del titolare del trattamento.
Per il GDPR il titolare del trattamento è il centro di imputazione di tutte le decisioni relative al trattamento e quindi il responsabile finale della conformità e dell’adeguatezza delle scelte effettuate.
Il GDPR però aumenta in modo considerevole il ruolo e la responsabilità del responsabile del trattamento.
Si pensi all’art. 32 del Regolamento che accomuna il titolare al responsabile quanto alla responsabilità in materia di adozione delle misure di sicurezza: “il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”.
La distribuzione delle responsabilità tra titolare committente e responsabile fornitore dev’essere puntualmente definita.
Il contenuto dell’accordo, a norma dell’art. 28, ha un’importanza fondamentale. Esso consente, alle diverse figure professionali impegnate nella realizzazione del software, di comprendere i limiti del rispettivo intervento.
Si consideri la previsione dell’art. 33, par. 2 del Regolamento che, riguardo alla notifica di una violazione dei dati personali all’Autorità di controllo, prevede che il responsabile del trattamento informi il titolare del trattamento “senza ingiustificato ritardo”, dopo essere venuto a conoscenza della violazione.
Certe tipologie di violazione potrebbero essere accertate solo in seguito all’applicazione di una forma qualificata di tracciamento applicativo. Esso potrebbe integrare gli estremi della profilazione e dovrebbe essere deciso solo dal titolare, in presenza di idonea base di legittimità e nel rispetto del principio di trasparenza.
Qualcosa di diverso dal tracciamento dei vari “log di accesso” che pure il responsabile è tenuto ad effettuare a norma dell’art. 32 del Regolamento.
A norma dell’art. 28, par. 3, del Regolamento, il responsabile è vincolato al titolare del trattamento e alle sue istruzioni.
Nel caso di esempio, la decisione del responsabile del trattamento di implementare un sistema di profilazione e tracciamento applicativo (log audit) qualificato, in mancanza di precise istruzioni da parte del titolare, integrerebbe gli estremi del trattamento operato al di fuori della cornice di operatività determinata dal titolare con tutte le conseguenze previste dal GDPR.
Ecco perché il problema della determinazione di tale cornice dev’essere affrontato da figure competenti. Serve la consapevolezza che indeterminatezze a tal riguardo possono determinare assunzioni non corrette sui limiti dell’intervento del responsabile del trattamento.
Si parla di figure competenti e chi più del DPO, se designato, dovrebbe rappresentare il riferimento privilegiato a supporto delle decisioni di titolari e responsabili del trattamento? Purché preparato e all’altezza del ruolo.
Conclusioni
La produzione e la messa a disposizione di software conforme al GDPR è un’attività complessa e costosa.
Titolari del trattamento e responsabili del trattamento devono assicurare un supporto convinto ai gruppi di lavoro basato, principalmente, su efficaci piani di formazione del personale e chiare linee guida di comportamento.
Un corretto adeguamento dei processi organizzativi può rappresentare l’elemento decisivo nella difficile sfida dell’assicurazione della compliance normativa in tema di protezione dei dati personali.
Preziosissimo può essere il supporto del DPO. Ma questo è uno degli aspetti più critici di tutta la disciplina dettata dal GDPR, soprattutto per quanto riguarda le funzioni di controllo. A questo proposito ci sono molti fraintendimenti e purtroppo non sempre il DPO designato ha le caratteristiche multidisciplinari (giuridiche, tecnologiche e organizzative) che gli consentirebbero di intercettare le diverse problematiche che possono caratterizzare il ciclo di vita del software.
@RIPRODUZIONE RISERVATA
