GDPR, il nuovo workflow per lo sviluppo di un sito o un'app.

04 Aprile 2018 | @Roberta Leone

Nella puntata precedente, ci siamo concentrati sul nuovo regolamento europeo e sui nuovi attori interessanti nella revisione della privacy dei prodotti digitali, qui vediamo invece come cambierà il workflow per gli sviluppatori frontend e backend.

In questo articolo parleremo di:

Come deve cambiare il workflow per lo sviluppo?
Privacy Impact Assesstment (PIA) o valutazione d’impatto
Che informazioni deve contenere il PIA?
Formazione, sviluppo personale e nuova cultura aziendale
Misure tecniche di sicurezza
I nuovi standard da seguire nel coding
Requisiti di progettazione, parte integrante di un workflow consapevole
Opt-in, la fine di un’era: come deve essere richiesto il consenso e l’accesso
Testing e Maintenance
Conclusioni

Come deve cambiare il workflow per lo sviluppo?

In qualsiasi linguaggio tu scriva codice, qualsiasi sia il tuo ruolo o il prodotto che stai creando il GDPR richiede che tu sia strutturato e trasparente in ogni passaggio.
L’impatto del General Data Protection Regulation sul flusso di lavoro può essere diviso in due macro aree, come lavorare all’interno dell’azienda e come sviluppare codice.

Come funziona

Il GDPR impatterà sui processi aziendali e sulla pianificazione del progetto. Tutti questi cambiamenti sono interdisciplinari e coinvolgeranno tutti i team da quello di sviluppo ai designer UX, fino ad arrivare al reparto marketing, legal e management.

Privacy by design

Il GDPR richiede obbligatoriamente l’adozione del framework Privacy by Design, un metodo di sviluppo che richiede una protezione ottimale dei dati e un alto standard di protezione, da impostare in maniera predefinita in tutti gli usi e le applicazioni.

Privacy Impact Assesstment (PIA) o valutazione d’impatto

Il Privacy Impact Assesstment (PIA) è un documento che deve essere reso accessibile a tutti i soggetti coinvolti in un progetto, soprattutto quando i dati trattati potrebbero mettere in pericolo i diritti degli interessati.
Possiamo definirlo come il processo in cui vengono discussi, verificati, inventariati e attenuati i rischi per la privacy inerenti ai dati raccolti ed elaborati.

Come tutta la documentazione richiesta per adeguarsi al GDPR, il PIA non è opzionale [in questi casi] e può essere requisito dal Data Protection Regulator nell’eventualità di una violazione della privacy o di un data breach.

La valutazione d’impatto è richiesta in tre casi:

quando il titolare opera una valutazione sistematica e globale di aspetti personali relativi a persone fisiche, basata su un trattamento automatizzato, compresa la profilazione, e sulla quale si fondano decisioni che hanno effetti giuridici o incidono in modo analogo significativamente su persone fisiche
quando il titolare procede al trattamento, su larga scala, di categorie particolari di dati personali o di dati relativi a condanne penali e a reati
quando il titolare opera attività di sorveglianza sistematica su larga scala di una zona accessibile al pubblico.

Che informazioni deve contenere il PIA?

Raccolta e conservazione dei dati

Quali dati personali vengono elaborati?
Come vengono raccolti e conservati i dati?
Dove vengono salvati i dati, in locale, sui nostri server o entrambi?
Per quanto tempo rimarranno salvati i dati? Quando verranno cancellati?
La raccolta e l’elaborazione dei dati sono legittimi, specificati ed esplicitati?
Qual è il processo per la concessione del consenso al trattamento dei dati, il consenso è esplicito e verificabile?
Qual è la base del consenso per l’elaborazione dei dati?
Qual è la base legale per elaborare i dati se non è basata sul consenso?
I dati raccolti sono sono solo quelli esplicitamente richiesti?
I dati sono accurati e aggiornati?
Come vengono informati gli utenti sull’elaborazione dei dati?
Quale controllo hanno gli utenti sulla raccolta e sulla conservazione dei loro dati?

Misure e tecniche di sicurezza

I dati sono criptati?
Sono anonimi o coperti da uno pseudonimo?
Sono sottoposti a backup?
Quali sono le misure tecniche di sicurezza dell’host che li ospita?

Personali

Chi può accedere a questi dati?
Quali informazioni sulla protezione dei dati hanno ricevuto i visitatori?
Quali misure di sicurezza attuano le persone che ricevono questi dati?
Quali sono le procedure di data breach e notifica in caso di violazione?
Quali sono le procedure in atto per ottemperare alle richieste governative?

Diritti d’accesso

In che modo la persona interessata esercita il diritto d’accesso ai suoi dati?
In che modo esercita il suo diritto alla data portability?
Com’è possibile esercitare il diritto all’oblio e la cancellazione dei dati personali?
Come può il soggetto esercitare il diritto di limitare e opporsi?

Legale

Gli obblighi di tutti i responsabili del trattamento dei dati, compresi i subappaltatori, sono coperti da contratto?
Se i dati vengono trasferiti fuori dall’Europa, quali misure di protezione e salvaguardia vengono adottate?

Rischi

Quali rischi corrono gli interessati per l’uso improprio dei dati o in caso di accessi errati e violazioni?
Quali rischi corrono se i dati vengono modificati?
E se i dati vengono persi?
Quali sono le principali fonti di rischio?
Quali misure sono stati adottate per arginare i rischi?

Formazione, sviluppo personale e nuova cultura aziendale

Lo sviluppo in ottica di data protection ovviamente non riguarda solo il codice ma anche chi lo scrive. Il GDPR richiede che anche gli sviluppatori conoscano alcuni aspetti legali e policy attinenti alla loro professione.
Chiunque contribuisca allo sviluppo di un progetto, dipendenti o appaltatori, devono essere conoscere il General Data Protection Regulation e l’ePrivacy Directive oltre ad eventuali leggi nazionali, regionali o locali in materia di privacy.

Dovranno inoltre conoscere le richieste specifiche del loro settore (in special modo quelle industry che trattano una mole considerevole di dati sensibili come la finanza o la sanità) e sviluppare modelli standard di sviluppo all’interno della propria attività.

È necessaria una nuova cultura aziendale, con impiegati preparati, una formazione interna costante comprensiva di corsi di aggiornamento.

Possiamo aspettarci, in un futuro non troppo lontano, professioni verticali sull’applicazione del regolamento in ambito di coding e l’inserimento nei piani di studio del GDPR.

Questa parte non è assolutamente sottovalutabile perchè, in caso di indagine o data breach, sarà preso in esame anche il livello di conoscenza generale della materia: se non vi è alcuna prova documentata che personale o fornitori abbiamo ricevuto una formazione in merito e siano competenti, non aspettiamoci clemenza.

Misure tecniche di sicurezza

Audit periodici e backup sono solo alcune delle misure di sicurezza che vengono implementati o rinforzati con l’entrata in vigore del GDPR.
Un flusso di lavoro attento alla privacy deve prevedere una valutazione attenta dei permessi per accedere ai dati, esaminare possibili usi impropri da parte dei dipendenti, hardware e periferiche non crittografate, server e connessioni non protette.

Monitoraggio e registrazione del sistema sono buone misure di sicurezza: nota bene, i dati che acquisisci esclusivamente a fini di monitoraggio e prevenzione non sono da confondere con i dati personali generati dall’utente, come le informazioni sull’account ad esempio, anche se in teoria tutti i log tecnici e di sicurezza dovrebbero essere trattati esattamente come gli altri, adempiendo alle specifiche del GDPR.

I nuovi standard da seguire nel coding

Creare workflow solidi per la protezione dei dati ed evitare l’acquisizione o la perdita di dati non necessari, richiede che tutti i membri del progetto lavorino con un insieme predefinito di code libraries, tool e framework.
Per iniziare l’adeguamento, crea un elenco di standard e metodologie utilizzate in ogni fase dello sviluppo, dal coding ai testing.

Nel GDPR non sono indicati linguaggi di programmazione da usare, tool di versioning e testing, quello che importa è che misure tecniche di sicurezza in tutti gli sviluppi, garantiscano le norme di sicurezza richieste.
È necessario disabilitare tutti i moduli che non sono sicuri o necessari, in particolare nelle API e nelle librerie di terze parti.
In ottica di privacy by design va effettuata preventivamente un’audit di moduli non sicuri che acquisiscono e conservano dati personali non necessari.

Le revisioni del codice devono includere un’audit per la privacy by design, inclusa una mappa di dove i dati sono archiviati fisicamente e virtualmente, come sono protetti e criptati.

Requisiti di progettazione, parte integrante di un workflow consapevole

Il modello Privacy by Default inizia proprio con lo sviluppo e con un mindset che ti porta a raccogliere la quantità minima di dati personali, sia lato frontend che backend.
Tendi a non aggregare dati, non collegare un set di dati personali con altri e non memorizzarli nello stesso posto.
La ricerca dell’anonimato è una pratica raccomandata anche se non richiesta esplicitamente.
Il GDPR richiede di pianificare la conservazione e la cancellazione dei dati personali con cui vieni a contatto, non di cancellare tutto come regola.
Dovresti, ad esempio, aver bisogno di conservare tutti i record d’acquisto per 10 anni, a fini fiscali o di revisione e questa è una pratica accettabile a patto, ovviamente, che sia tutto documentato.
Il diritto all’oblio dell’utente inoltre, non sta a significare la sparizione completa dal mondo digitale.
Come buona regola i dati vanno cancellati – automaticamente o su richiesta dell’utente – quando non sono più necessari, prestando attenzione a come i set di dati possano rimanere presenti in archivi e backup.

La collaborazione con i servizi in cloud e SASS è necessaria, per garantire che una cancellazioni venga effettuata realmente da ambo le parti.

Un ulteriore aspetto del privacy-conscious system design è quello di proteggere e nascondere i dati da accessi non necessari.
I dati personali non dovrebbero essere visibili nel frontend come nel backend e non tutti gli utenti di un sistema dovrebbero avere un accesso universale; i dati devono inoltre essere crittografati sia in fase di transito che di storaggio.

La design review va sempre effettuata con gli occhi di un malintenzionato (che sia umano o meno) per garantire il massimo delle performance di sicurezza.

Opt-in, la fine di un’era: come deve essere richiesto il consenso e l’accesso

La revisione della normativa europea ha come obiettivo quello di restituire il controllo dei dati personali ai legittimi proprietari, attraverso il consenso al trattamento e ai meccanismi di accesso e modifica.
Nel nostro diritto di utenti, rientra l’essere informati sul data flow che contiene le nostre informazioni.
Lato frontend, tutto si traduce nello sviluppo dei form di consenso e gestione delle informazioni più user-centered possibile.

Siti e applicazioni devono fornire quindi un controllo ottimale sulle impostazioni di consenso attraverso elementi come pannelli di controllo, dashboard, account setting e centri privacy.

I giorni degli out-out, quelli in cui l’utente era costretto ad accettare passivamente quello che un provider facesse o meno delle sue informazioni personali sono ufficialmente finiti.
Dovrai fornire un’interfaccia utente per la gestione dei dati personali dedicata ai singoli soggetti nella quale sia prevista la possibilità di modificare e correggere le informazioni, limitare l’elaborazione dei dati e inserire la possibilità di cancellarli, da non confondere con il diritto all’oblio.

Sul fronte del backend invece devi sviluppare pensando a come rafforzare il potere di consenso e scelta dell’utente; una buona soluzione, per un utente che crea un account, è quella di godere di impostazioni privacy ottimali predefinite, senza essere costretti ad un opt-in.

Mai dare per scontato un consenso, che deve diventare sempre manifesto: la mancanza di azione, come non aver spuntato una casella, non è più un consenso. Bisogna puntare su una reale consapevolezza degli utenti, e sarà un tuo dovere fargli sapere anche per quanto tempo disporrai delle loro informazioni.

Come potrai immaginare se sei arrivato a questo punto della lettura, la parte di sviluppo backend deve prevedere una documentazione puntuale, che esplichi data e ora del consenso, nonché quando e se venga ritirato.

Testing e Maintenance

Abbiamo visto che sviluppare in ottica GDPR significa Privacy by Default e Privacy by Design, ma anche integrare queste soluzione per la protezione della privacy nelle procedure esistenti, come i penetration test.

Impostare un test per verificare la sicurezza della privacy significa pensare in modo creativo: in che modo utenti non autorizzati potrebbero accedere al tuo sistema?
Se stai rivisititando in maniera retroattiva il codice di un progetto già esistente, hai verificato quanto sia facile accedere ai dati ereditati?

Ricorda sempre la regola aurea del GDPR: se non è documentato non è successo.
Anche i risultati dei test devono essere registrati, documentati e usati come dati parlanti.

Conclusioni

Il GDPR cambierà dunque metodi di sviluppo e testing, rendendoli più trasparenti nel modo in cui vengono raccolti i dati degli utenti e come devono essere documentate tutte le fasi della progettazione che diventano, ça va san dir, privacy first o, per dirla come il GDPR, Privacy by Default e Privacy by Design.

Attenersi al nuovo regolamento europeo ha più a che fare con il buon senso, uno strumento potente per poter dire davvero di proteggere i dati dei tuoi utenti.
Adesso però è davvero ora di iniziare.

Coding, Purple, Tech, TrendGDPR, il nuovo workflow per lo sviluppo di un sito o un’app.

Dopo aver introdotto cosa cambia con l'entrata in vigore del nuovo regolamento europeo, vediamo invece gli effetti che avrà sul workflow dello sviluppo digital.