GDPR e hosting nell'UE: a cosa i team dovrebbero fare attenzione con gli strumenti di sviluppo

Quando un'azienda vuole introdurre un nuovo strumento di analytics, la procedura è ormai rodata: il responsabile della protezione dei dati chiede il contratto di trattamento, qualcuno verifica la sede dei server, l'informativa sulla privacy viene integrata. Con la cassetta degli attrezzi del reparto sviluppo va spesso diversamente: un membro del team trova uno strumento utile, crea un account e tre mesi dopo quello è parte silenziosa della routine lavorativa. Questa disparità di trattamento non ha alcuna ragione oggettiva — anche gli strumenti per sviluppatori trattano dati, e alcuni più di quanto i loro utenti siano consapevoli.

I servizi di test sono, per questo, un buon oggetto di osservazione. Un servizio di screenshot, per esempio, fotografa pagine web — e la foto di una pagina web contiene tutto ciò che quella pagina mostra. Con una pagina di marketing pubblica la cosa è innocua. Interessante diventa ai margini: ambienti di staging riempiti con copie di dati reali di produzione. Pagine che mostrano commenti degli utenti, recensioni o immagini del profilo. Indirizzi nei cui parametri URL si annidano attributi di sessione o identificativi. Chi consegna pagine del genere a un servizio esterno trasmette, a seconda dei casi, dati personali — anche se nella testa avviene soltanto «stiamo testando il layout».

Il GDPR ordina con chiarezza una costellazione del genere: l'azienda che usa il servizio resta titolare del trattamento dei dati; il servizio opera di norma come responsabile del trattamento. Questa distribuzione dei ruoli non è una formalità, ma ha una conseguenza pratica: serve un contratto di trattamento ai sensi dell'articolo 28 — di solito come documento standard del fornitore —, e la responsabilità che il trattamento nel suo complesso sia lecito non migra con i dati verso il fornitore. Resta all'azienda.

La seconda domanda standard riguarda il luogo del trattamento. All'interno dell'UE il GDPR si applica direttamente; con i fornitori che trattano dati in paesi terzi comincia invece un capitolo di verifica a sé: decisioni di adeguatezza, clausole contrattuali standard, valutazioni d'impatto sul trasferimento. Per i trasferimenti verso gli USA esiste sì una decisione di adeguatezza, ma i suoi predecessori sono già stati abbattuti due volte in tribunale, e anche il quadro attuale resta giuridicamente controverso. Niente di tutto questo rende inutilizzabili i servizi statunitensi — ma ognuna di queste costruzioni è lavoro di verifica che con una sede UE semplicemente viene meno. L'hosting UE è, in questo senso, meno un sigillo di qualità che una scorciatoia: rende la valutazione più breve, non superflua.

ScanU, un servizio per test di regressione visiva e screenshot nei browser, si presta qui come esempio concreto, perché il fornitore rende esplicita la sede dei dati: i dati vengono ospitati, secondo le indicazioni del fornitore, a Francoforte, e il servizio si posiziona espressamente con riguardo al GDPR — come si legge sulla pagina introduttiva di ScanU in italiano. Per un'azienda tedesca questo significa: la questione dei paesi terzi, per il servizio principale, in prima battuta non si pone, e la verifica può concentrarsi sui punti consueti — contratto, tempi di conservazione, cancellazione, sub-responsabili.

E proprio qui va collocata una frase onesta, valida per ogni fornitore, incluso quello qui considerato: le affermazioni su un sito di prodotto sono il punto di partenza della verifica, non il suo risultato. «Ospitato a Francoforte» e «orientato al GDPR» sono autodichiarazioni del fornitore — chi vuole usare il servizio a fini aziendali legge il contratto di trattamento, verifica la lista dei sub-responsabili e chiarisce che cosa accade ai dati alla disdetta. Un fornitore che consegna volentieri documenti del genere fa per la fiducia più di qualsiasi formula di marketing; uno presso cui non si trovano ha già risposto alla domanda più importante.

Chi legge per la prima volta un contratto di trattamento può orientarsi su quattro punti. Primo, l'oggetto: il contratto descrive concretamente quali dati vengono trattati per quale scopo, o resta genericamente intercambiabile? Secondo, le misure tecniche e organizzative, di solito in allegato: vi stanno indicazioni comprensibili su cifratura, controllo degli accessi e sede — o luoghi comuni? Terzo, la regolazione dei sub-responsabili: il cliente viene informato dei cambi, e può opporsi? Quarto, restituzione e cancellazione dei dati a fine contratto. Nessuna di queste domande presuppone una laurea in giurisprudenza — sono domande di comprensione a cui ogni persona tecnicamente preparata può rispondere. E dove il contratto tace, la domanda mirata al fornitore è il test più onesto della sua disponibilità a informare.

Un punto di verifica spesso trascurato sono i tempi di conservazione — eppure sono, per il diritto della protezione dei dati, un tema centrale, parola chiave minimizzazione: i dati non vanno tenuti più a lungo di quanto lo scopo richieda. Nei servizi di screenshot la conservazione della cronologia di verifica determina per quanto tempo riproduzioni delle proprie pagine giacciano presso il fornitore. ScanU scala questa cronologia per livello di prezzo — dai tre giorni della tariffa gratuita, passando per 15 e 30 giorni, fino ai 90 giorni del livello più grande, come indicano i livelli di prezzo di ScanU. Notevole in questo: dal punto di vista della protezione dei dati, il livello più piccolo è il più parsimonioso. Chi ha bisogno di cronologie lunghe, per esempio per circoscrivere regressioni su mesi, sceglie consapevolmente la durata maggiore — ma dovrebbe essere una scelta consapevole, non un'impostazione predefinita su cui nessuno ha mai riflettuto.

Almeno altrettanto importante della verifica del fornitore è il proprio comportamento d'uso — perché la misura di protezione dei dati più efficace è non mettere affatto dati sensibili nel servizio. Per i servizi di test questo significa concretamente: riempire gli ambienti di verifica con dati di esempio sintetici invece che con copie del database di produzione. Testare pagine e layout pubblici invece di viste con login e dati reali dei clienti. Fare attenzione che negli URL testati non si annidino token di sessione o identificativi personali. Queste regole costano poco, valgono per ogni strumento basato su URL — e disinnescano la questione della protezione dei dati più efficacemente di qualsiasi clausola contrattuale.

Come possano apparire simili regole d'uso sta in tre frasi per il wiki del team. Prima: nel servizio entrano solo indirizzi di pagine pubbliche o di ambienti di staging con dati sintetici — mai viste che mostrano dati reali dei clienti. Seconda: prima di creare un nuovo progetto di verifica, l'URL viene esaminato una volta consapevolmente nei suoi parametri; token di sessione e identificativi personali non hanno nulla da cercarvi. Terza: i report condivisi vengono trattati come documenti interni — inoltro solo alle persone coinvolte, niente link nei canali pubblici. Regole del genere si formulano in dieci minuti e si trasmettono in fretta nell'onboarding di nuove colleghe e colleghi. Il loro valore sta meno nella formulazione che nel fatto che il tema sia stato pronunciato una volta: gli incidenti di protezione dei dati nell'uso degli strumenti nascono raramente da intenzione — per lo più da routine in cui nessuno ha mai posto la domanda.

Anche i report condivisi meritano un pensiero. I report di verifica condivisibili sono decisamente pratici per la collaborazione — proprio per questo dovrebbe essere chiarito chi possa aprire un report condiviso e per quanto tempo resti disponibile. Non è una particolarità dei servizi di test: per i report vale lo stesso che per i documenti condivisi in ogni strumento cloud. Un report che contiene screenshot di una pagina di prodotto non ancora pubblicata è materiale riservato e come tale va trattato.

Quanto in profondità deve andare la verifica? Il GDPR stesso detta la risposta: in base al rischio. Un servizio di screenshot che fotografa pagine di marketing pubbliche è di un altro calibro rispetto a un software per le buste paga con dati sugli stipendi. Sarebbe sproporzionato investire entrambi con lo stesso catalogo di domande — ma altrettanto sbagliato non guardare affatto il caso più piccolo. Una via di mezzo pragmatica per gli strumenti di sviluppo: chiarire il ruolo (responsabile del trattamento?), raccogliere il contratto, annotare sede dei dati e sub-responsabili, fissare tempi di conservazione e cancellazione, formulare regole d'uso per il team. Il tutto si sbriga in tempi contenuti e copre gli obblighi essenziali.

Giocato fino in fondo sull'esempio di un servizio di screenshot, questo catalogo appare così. Ruolo: il servizio tratta i contenuti delle pagine trasmessi su incarico dell'azienda — responsabile del trattamento, dunque, e di conseguenza contratto ai sensi dell'articolo 28 da raccogliere e archiviare. Sede dei dati: leggerla presso il fornitore e annotarla; per ScanU è indicata Francoforte, con cui la verifica sui paesi terzi per il servizio principale viene meno. Sub-responsabili: ricavare la lista dai documenti contrattuali o richiederla — anche un fornitore UE può impiegare sub-fornitori, e solo questa lista rende completa la catena. Tempi di conservazione: il livello di prezzo scelto determina per quanto tempo cronologia di verifica e quindi screenshot vengano tenuti; confrontare la durata con il fabbisogno effettivo e motivare la decisione in una frase. Cancellazione: chiarire che cosa accada a report e cronologie alla disdetta. Chi documenta questi cinque punti su una pagina ha fatto, per uno strumento di questa classe di rischio, l'essenziale — e ha al tempo stesso un modello riutilizzabile per il prossimo strumento. Le risposte alle domande tipiche sul servizio stesso le raccoglie il fornitore nelle domande frequenti su ScanU.

Ne fa parte anche una voce nel registro delle attività di trattamento — quella documentazione obbligatoria in cui un'azienda fissa quali servizi trattino quali dati per quale scopo. Suona più burocratico di quanto sia: per uno strumento di sviluppo sono poche righe. Il valore vero sta altrove: chi scrive la voce deve aver risposto alle domande. La documentazione impone la verifica che altrimenti si perde nella quotidianità.

Un'obiezione dalla pratica merita, in tutto ciò, una risposta onesta: se la verifica diventa troppo macchinosa, non avviene in modo più accurato, ma non avviene affatto. Se tra «strumento trovato» e «strumento approvato» stanno sei settimane e tre competenze diverse, prima o poi sviluppatrici e sviluppatori creano l'account in privato — e da un servizio verificabile nasce shadow IT di cui nessuno sa più nulla. La conseguenza non è rinunciare alla verifica, ma adattarla al rischio: un controllo rapido e documentato per gli strumenti con basso contatto con i dati, la verifica completa per tutto ciò che si avvicina a dati di produzione o sistemi dei clienti. Un team che sa che il controllo rapido dura pochi giorni e finisce per lo più con un sì non ha alcun motivo di aggirarlo. L'organizzazione della protezione dei dati più solida è, alla fine, quella la cui via ufficiale è più veloce della scorciatoia.

Resta l'inquadramento complessivo. La scelta di strumenti parsimoniosi con i dati e ospitati in modo trasparente non è un sofisma giuridico, ma parte della diligenza artigianale che i team altrove trovano da tempo ovvia — nessuno gestirebbe un database senza un piano di backup. Hosting UE, tempi di conservazione chiari e un contratto di trattamento pulito sono tre buoni criteri tra più d'uno, non un sostituto della propria verifica: anche un servizio ospitato a Francoforte può essere configurato male, usato male o riempito con i dati sbagliati. La responsabilità non la porta il fornitore, ma l'azienda che lo impiega.

La buona notizia in chiusura: lo sforzo è una tantum e contenuto. Un'ora di verifica strutturata per strumento, una breve voce nella documentazione, due regole d'uso per il team — di più, per la maggior parte degli strumenti di sviluppo, non serve. Paragonato allo sforzo di dover spiegare a posteriori una trasmissione di dati sconsiderata, è un ottimo scambio.