La conformità si scrive nel codice, non nel PDF

In tante aziende la conformità al GDPR è un raccoglitore sullo scaffale. Dentro ci trovi l'informativa, il registro dei trattamenti, le nomine, magari anche una DPIA. Documenti fatti bene, spesso da consulenti in gamba.

Poi apri il gestionale e scopri che qualunque utente vede i dati di qualunque cliente, che i log non esistono, e che i dati di una persona che aveva chiesto la cancellazione tre anni fa sono ancora tutti al loro posto.

Il raccoglitore descrive un'azienda che non esiste. Ed è proprio la situazione che l'articolo 25 del GDPR, quello sulla protezione dei dati fin dalla progettazione e per impostazione predefinita, vorrebbe evitare.

Cosa vuol dire dentro un'applicazione

Tradotta in scelte tecniche, la privacy by design diventa una lista abbastanza noiosa di cose che o ci sono o non ci sono. Niente di filosofico.

• Ogni utente vede solo i dati di sua competenza, e la regola la impone il database, non la schermata che nasconde un pulsante
• I dati sensibili stanno separati da quelli ordinari, e ci si arriva solo quando serve davvero
• Esiste un registro di chi ha letto o modificato cosa, e quando
• La cancellazione cancella per davvero, comprese le copie di servizio e i backup che nessuno guarda mai
• Esportare i dati di una persona è una funzione del programma, non mezza giornata di lavoro manuale
• I dati su cui si fanno le prove non sono la copia del database di produzione

La regola quasi sempre sta nel posto sbagliato

L'errore che incontro più spesso è mettere i permessi nell'interfaccia. La schermata controlla il ruolo dell'utente e nasconde quello che non deve vedere. A prima vista funziona benissimo, e infatti nessuno se ne preoccupa.

Solo che sotto c'è un'API che risponde a chiunque conosca l'indirizzo giusto. Basta un utente un po' curioso con gli strumenti per sviluppatori aperti, e i dati escono lo stesso. Il controllo deve stare nel punto più basso possibile, dove i dati vivono, così vale per qualsiasi strada arrivi a chiederli.

Se la protezione regge solo perché l'utente non sa dove cliccare, non stai proteggendo niente.

Quanto costa aggiungerla dopo

Metterli in piedi mentre si progetta costa poco, perché sono decisioni sulla struttura dei dati prese quando la struttura ancora non c'è. Un pomeriggio di discussione, in genere.

Aggiungerli a un sistema già in produzione, con qualche anno di dati dentro, è tutt'altro lavoro. Bisogna capire chi può vedere cosa in un modello che non era stato pensato per distinguerlo, migrare quello che c'è, e poi verificare di non aver rotto niente per strada. Capita spesso che costi più della funzione nuova che dovevi sviluppare.

Cinque domande da fare a chi ti sviluppa il software

• Se un utente prova a chiamare direttamente il servizio per un dato che non gli compete, cosa succede
• Dove sono fisicamente i dati, e chi dalla vostra parte può leggerli
• Come si cancella una persona, e cosa rimane dopo la cancellazione
• Quanto si conservano i dati, e chi lo ha deciso
• Se domani vi chiedo l'elenco di chi ha aperto una certa scheda, me lo sapete dare

Non sono domande da avvocato, sono domande da committente. E le risposte ti dicono nel giro di cinque minuti se hai davanti un fornitore che il tema lo ha affrontato sul serio, oppure uno che alla fine ti manderà un PDF.