Perché i dati di produzione non vanno nei sistemi di test
I dati personali possono essere trattati solo per lo scopo per cui sono stati raccolti o per uno scopo compatibile con esso (art. 6 cpv. 3 LPD, art. 5 cpv. 1 lett. b GDPR). Testare un software spesso non è senz'altro compatibile con tale scopo.
A ciò si aggiunge la sicurezza: gli ambienti di test sono spesso meno protetti, più persone vi hanno accesso e vi collaborano sviluppatrici e sviluppatori esterni. La protezione dei dati fin dalla progettazione (art. 7 LPD, art. 25 GDPR) richiede di ridurre fin dall'inizio tali rischi con misure adeguate.
Quali metodi esistono?
| Metodo | Risultato | Adatto per |
|---|---|---|
| Mascherare | Le informazioni vengono rese irriconoscibili. | Visualizzazione di documenti, formazione |
| Valori sostitutivi con formato valido | Valori realistici; controlli e interfacce continuano a funzionare. | Sistemi di test, test di integrazione |
| Pseudonimizzare | Riferimento alla persona possibile con la corrispondenza. | Analisi con domande di ritorno, ricerca di errori |
| Dati sintetici | Generati senza riferimento a persone reali. | Prime fasi di sviluppo, test di carico |
Che cosa conta nei dati di test
- Formato valido: identificativi come IBAN o numero AVS superano i controlli dell'applicazione.
- Coerenza: la stessa persona riceve lo stesso valore sostitutivo nei dati correlati.
- Non dimenticare il testo libero: i nomi compaiono spesso nei campi note e nei documenti.
- Controllo successivo: verificare il risultato per individuare eventuali informazioni rimaste non protette.
- Prova: registrare chi ha ricevuto quali dati di test e per quale scopo.
Trasmettere i dati in modo vincolato allo scopo
Ciò che vale per i dati di test vale per ogni trasmissione: a team di analisi, a fornitori di servizi o a un'IA. Il principio è trasmettere solo il riferimento alla persona richiesto dallo scopo – e registrare per ogni destinatario e scopo che cosa è stato trasmesso.