Normative europee

Ciclo di vita del software e GDPR: gli elementi a maggior impatto sul processo di sviluppo

Ecco alcuni aspetti della nuova disciplina che, per la loro portata innovativa, richiedono una particolare attenzione nello svolgimento delle attività tipiche del processo di sviluppo del software

18 Giu 2020

Saverio Marando

dottore in giurisprudenza esperto di protezione dei dati personali e consulente software

Il Regolamento generale sulla protezione dei dati (GDPR) ha un impatto significativo sul ciclo di vita di prodotti e servizi informatici. Il software, infatti, è “strumento” privilegiato del trattamento dei dati personali e deve essere realizzato nel rispetto dei principi e delle regole dettate dal GDPR.

Le novità più significative della nuova disciplina richiedono una verifica continua dell’adeguatezza delle misure tecniche e dei processi organizzativi utilizzati nelle fasi del processo di sviluppo del software.

L’applicazione del GDPR, però, può rivelarsi un’impresa ardua per alcune figure professionali non abituate a confrontarsi con i principi della protezione dei dati personali.

Il nuovo approccio alla protezione dei dati personali

I titolari del trattamento decidono autonomamente le caratteristiche del trattamento, con un approccio basato sulla valutazione del rischio.

La protezione dei dati personali diventa un processo fondamentale finalizzato a disciplinare in modo organico e strutturato tutte le decisioni relative al trattamento. Il Regolamento richiede l’assunzione di responsabilità del vertice gerarchico dell’organizzazione, attraverso una serie di impegni che devono concretizzarsi in attività adeguate e dimostrabili.

Approccio basato sul rischio, accountability, data protection by design e data protection by default, valutazione d’impatto sulla protezione dei dati (DPIA), disciplina del data breach: sono solo alcuni aspetti della nuova disciplina, certamente tra quelli più significativi, sufficienti a far comprendere la complessità della compliance.

Nella realizzazione di soluzioni informatiche, le conseguenze della non conformità possono essere molto serie. Nei casi più gravi di violazione dei dati personali, un tipico esempio è il trattamento su larga scala di categorie di dati particolari, può essere pregiudicato l’esercizio dei diritti, la sicurezza delle persone fisiche e, addirittura, il corretto funzionamento del sistema democratico.

Titolari e responsabili del trattamento devono acquisire piena consapevolezza degli obblighi derivanti dal Regolamento. Devono essere assistiti da figure preparate a “facilitare” l’adozione di sistemi di gestione della protezione dei dati personali adeguati e conformi.

Significativo che laddove l’esigenza di tutela sia maggiormente sentita, per la caratterizzazione soggettiva dei soggetti attivi del trattamento o per la peculiarità dei trattamenti posti in essere, il legislatore comunitario abbia previsto la necessità di affiancare, a titolari e responsabili del trattamento, la figura del Data Protection Officer (DPO).

Il DPO opera come una sorta di “garante interno” all’organizzazione di riferimento, chiamato a svolgere, da una parte, il ruolo fondamentale di “facilitatore” dell’applicazione della nuova disciplina, dall’altra, all’esercizio di un efficace controllo del rispetto della stessa, operando, anche, come punto di contatto privilegiato per gli interessati e per l’Autorità di controllo.

La sfida della conformità

Il Regolamento richiede un cambio di passo nella tutela del diritto fondamentale alla protezione dei dati personali: un ripensamento globale delle politiche di gestione della conformità e della sicurezza dei trattamenti.

I soggetti apicali del trattamento devono prendere coscienza che serve un cambiamento culturale nella valutazione della compliance al GDPR che da problema deve diventare opportunità.

Una sfida, cioè, a vedere il vantaggio competitivo che può derivare dal considerare la protezione dei dati personali, come un tratto distintivo connaturato al proprio modo di operare.

Un elemento di differenziazione che, nel rafforzare la sicurezza delle persone fisiche, tende ad alimentare un clima di fiducia che, per il Regolamento, è indispensabile allo sviluppo dell’economia digitale nel mercato dell’Unione.

Se ancora in molti avvertono un senso di fastidio verso la tutela di un bene ritenuto anacronistico nel mondo della condivisione globale dei dati, non sono pochi gli esempi di soggetti che, nel proporre prodotti e soluzioni, pongono l’accento, in primo luogo, sulla tutela della privacy e della sicurezza degli utenti.

Questa tutela diventa il tratto distintivo da pubblicizzare addirittura prima delle stesse funzioni applicative. Vengono in mente le numerose soluzioni basate sull’impiego della crittografia end-to-end.

GDPR e processo di sviluppo del software

La produzione di software conforme al GDPR richiede che ogni fase del processo di sviluppo venga rivista in profondità. Questo pone, evidentemente, il problema del coinvolgimento del vertice gerarchico dell’organizzazione. Anche perché, è bene non trascurarlo, la conformità determina un aumento non trascurabile della complessità e dei costi di realizzazione.

Non esiste sistema di gestione dei dati personali adeguato che non si basi sul supporto convinto e decisivo dei ruoli apicali del trattamento: in termini di dotazione di risorse, di adeguamento dei processi organizzativi, di formazione del personale e di corretta definizione dei rapporti con i fornitori.

Il processo di sviluppo del software può avere diverse caratterizzazioni. Si passa dai processi più strutturati a quelli più agili. Indipendentemente dall’approccio seguito però, possono essere individuate, tipicamente, due macro fasi concettuali: determinazione di cosa realizzare e determinazione di come farlo. In alcuni contesti può essere prevista una fase destinata alla verifica della fattibilità della soluzione.

Ognuna di queste fasi dev’essere rivista alla radice per essere conforme con il GDPR.

WHITEPAPER
Covid-19: come rispettare le regole senza fermare lo sviluppo del mercato?
Sanità
Risk Management

Valga un esempio su tutte: la necessità che gli attori coinvolti, magari prima che inizi lo sviluppo del software, si rendano conto della ricorrenza dei presupposti per effettuare una valutazione d’impatto sulla protezione dei dati. Si tratta di un elemento fondamentale di decisione, riguardo alle caratteristiche o, addirittura, alla stessa fattibilità della soluzione informatica.

La protezione dei dati come requisito fondamentale del software

La protezione dei dati personali diventa il requisito fondamentale con il quale riscontrare ogni altro requisito funzionale e non funzionale durante tutto il ciclo di vita del software.

Si tratta di un elemento di grande novità e criticità: non tutti gli attori, infatti, sono abituati a confrontarsi con questo requisito.

Il primo fondamentale passo, per comprendere il senso della nuova disciplina, consiste nello sgomberare il campo da un frequente fraintendimento: il Regolamento generale sulla protezione dei dati non parla mai di privacy ma di protezione dei dati personali. L’unico accenno al termine si trova in una nota al considerando n. 173, nella versione in lingua inglese del testo.

Il Regolamento si applica anche quando il bene principale da tutelare non sia la riservatezza. Riguarda i dati personali degli interessati che devono essere tutelati, indipendentemente da quale sia la base di legittimità del trattamento.

Il tema della protezione dei dati personali non è nuovo al mondo della realizzazione del software. Le novità contenute nel GDPR, però, soprattutto l’attenzione alla protezione dei dati personali by design e by default, richiedono spesso uno stravolgimento di processi e metodologie.

La protezione dei dati personali dev’essere considerata come una parte integrante del processo di realizzazione del software: un requisito imprescindibile, in quanto all’applicazione di principi e norme del trattamento (con essa si misura l’accountability), ma modulabile riguardo all’adozione delle misure tecniche e organizzative, che possono essere adattate alle peculiarità del trattamento e del livello di rischio che rappresenta.

L’art. 25, par. 1, del Regolamento, nel richiedere l’adozione di misure tecniche e organizzative adeguate, consente di tener conto “dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche”.

Le misure tecniche e organizzative adeguate richieste al titolare devono essere volte ad attuare in modo efficace i principi della protezione dei dati e il Regolamento richiama espressamente, a questo proposito, il principio di minimizzazione. Lo stesso articolo, al par. 2, richiede che le misure adottate dal titolare siano “adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento”.

Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita incidono sulla professionalità richiesta alle diverse posizioni organizzative.

Ogni risorsa impegnata nel processo di sviluppo del software deve essere capace di comprendere come la protezione dei dati personali possa influire sulle competenze del proprio ruolo.

Nel GDPR gli obblighi e le responsabilità legate all’effettuazione del trattamento, sono attribuite, principalmente, al titolare del trattamento.

Bisogna però considerare che, nella pratica della realizzazione del software, spesso l’effettiva applicazione del GDPR viene affidata alle decisioni di dipendenti o collaboratori (ad esempio analisti di business, progettisti), chiamati a misurarsi con l’applicazione di regole e principi che, non necessariamente, fanno parte del proprio bagaglio di conoscenze.

Si pensi alla valutazione del rischio come processo iterativo applicato a tutto il ciclo di vita del software. È una novità significativa che richiede preparazione.

In questo nuovo scenario, la formazione delle risorse diventa fondamentale.

Lo sviluppo del software come processo basato sul rischio

Il Regolamento generale sulla protezione dei dati cerca di contemperare l’interesse all’utilizzo dei dati personali con quello all’impiego corretto degli stessi, con un approccio risk based.

La valutazione del rischio nel GDPR opera come regola generale ma assume forme particolari nei casi di rischio elevato e di rischio elevato residuo inaccettabile, con la previsione del ricorso, rispettivamente, alla valutazione d’impatto sulla protezione dei dati e alla consultazione preventiva.

L’art. 24 del Regolamento stabilisce che il titolare, nell’adozione delle misure tecniche e organizzative adeguate a garantire la conformità del trattamento al Regolamento, deve tener conto di due criteri fondamentali:

  • le peculiarità del trattamento (si tratta della formula “tenuto conto della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento”);
  • i “rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche”.

Un esempio significativo è il rischio di discriminazione conseguente all’impiego della profilazione su larga scala dei comportamenti o di processi decisionali automatizzati, in mancanza di idonee garanzie a tutela degli interessati.

La valutazione del rischio del trattamento rappresenta una regola generale. Il trattamento dei dati personali dev’essere sempre preceduto dall’analisi preventiva dei rischi che possono derivarne.

Il titolare, prima di iniziare un trattamento e durante tutto il ciclo di vita dello stesso, deve effettuare la valutazione continua dell’impatto del trattamento sui diritti e sulle libertà delle persone fisiche.

Quando poi non risulti sufficiente una valutazione generica del rischio, a causa del verificarsi di un “rischio elevato” per i diritti e per le libertà delle persone fisiche, il Regolamento disciplina il ricorso alla valutazione d’impatto sulla protezione dei dati.

L’art. 35, par. 3, prevede delle presunzioni sulla ricorrenza del rischio elevato per talune tipologie di trattamenti (ad esempio il trattamento su “larga scala” di categorie particolari di dati personali). I paragrafi 4 e 5, prevedono la pubblicazione da parte dell’Autorità di controllo di elenchi di tipologie di trattamenti, soggetti, rispettivamente all’applicazione o all’esclusione della DPIA.

L’art. 36, par. 1, del Regolamento prevede, infine, che il titolare coinvolga, l’Autorità di controllo (consultazione preventiva), prima di procedere al trattamento, qualora la valutazione d’impatto sulla protezione dei dati indichi la presenza di quello che possiamo chiamare: “rischio residuo elevato inaccettabile”.

Questa caratteristica del rischio esclude che il titolare debba ricorrere all’Autorità ogni qualvolta ravvisi un rischio elevato. Al contrario si richiede che il rischio persista a un livello, appunto, inaccettabile nonostante la previsione dell’adozione di misure di mitigazione, opportune in termini di tecnologia disponibile e costi di attuazione (cfr. considerando n. 84 del Regolamento).

L’impatto della valutazione del rischio sul ciclo di vita del software

La previsione nel Regolamento di una valutazione del rischio così articolata, costituisce un requisito che non può essere ignorato dalle figure impegnate, a qualsiasi titolo, nel ciclo di vita del software.

La decisione di realizzare un software, soprattutto quando tratti categorie di dati particolari su larga scala, richiede l’effettuazione di un corretto bilanciamento degli interessi in gioco, secondo il criterio della proporzionalità.

Significativa la previsione dell’art. 35, par. 7, lett. b) del Regolamento, in tema di valutazione d’impatto sulla protezione dei dati. Essa deve contenere “una valutazione della necessità e proporzionalità dei trattamenti in relazione alle finalità”.

Questa valutazione dev’essere correlata con quella dei rischi per i diritti e le libertà delle persone fisiche e va fatta prima della realizzazione del software.

Si evita così tanto la correzione in corso d’opera, qualora vengano riscontrate non conformità alla disciplina dettata dal GDPR, quanto gli effetti di un eventuale data breach.

La necessità di una continua valutazione del rischio modifica, in alcuni casi in modo sostanziale, il modo di operare degli attori coinvolti nella produzione del software. Bisogna che siano evitate sviste che potrebbero determinare gravi conseguenze.

In definitiva, con il GDPR, la valutazione del rischio ha un impatto considerevole sulle attività di dimensionamento, analisi, progettazione, sviluppo, test, accettazione, messa in esercizio, assistenza operativa, gestione di progetto.

Non è un’affermazione di poco conto. Comprendere questo concetto e adottare comportamenti conseguenti non è così semplice.

Una riconferma dell’importanza della formazione e della sensibilizzazione delle risorse.

Conclusioni

La protezione dei dati personali, nel contesto della produzione del software, non può essere progettata e decisa in modo astratto.

Con il Regolamento generale sulla protezione dei dati, ai tradizionali requisiti legati alla produzione del software, si aggiungono due requisiti fondamentali: la protezione dei dati personali e la valutazione continua del rischio.

Non sono requisiti di facile implementazione. È richiesto il coinvolgimento convinto del vertice gerarchico dell’organizzazione, chiamato al “cambio di passo” che, anche nel contesto della produzione del software, “strumento del trattamento”, costituisce l’elemento indispensabile per l’assicurazione della conformità normativa in tema di protezione dei dati personali.

WHITEPAPER
Sicurezza: perchè puntare su un approccio zero trust?
Sicurezza
Sicurezza dei dati

@RIPRODUZIONE RISERVATA
M
Saverio Marando
dottore in giurisprudenza esperto di protezione dei dati personali e consulente software
Argomenti trattati

Approfondimenti

D
data protection
G
GDPR

Articolo 1 di 5