Anonymiserat produktionsdata - Myt eller ren fiktion: del 1
Del 1: GDPR
Testdata: möjligen det torraste och tråkigaste ämne man kan föreställa sig, det är antagligen därför det också är ett område som inte får speciellt mycket fokus. Lite av ett nödvändigt ont. Nu råkar jag vara nördig nog att faktiskt tycka om testdata och av erfarenhet kan jag säga att det finns mycket effektivisering att hämta genom att skapa bra testdata.
Som konsult möter jag i princip dagligen kunder som har problem med testdata och kunder som vill få i gång testautomatisering, men som inte lyckas. I de flesta fallen handlar det om att kunden vill använda produktionsdata som testdata, ibland med anonymisering för att säkerställa att man följer GDPR.
Med den här artikeln vill jag slå hål på myter kring att produktionsdata är lämpligt testdata och att personuppgifter blir lagligt testdata om man bara anonymiserar. Artikeln är indelad i 5 avsnitt enligt bilden och det här är så klart den första delen som handlar om testdata i förhållande till GDPR.
Den observanta har redan lagt märke till att testautomatisering egentligen inte är i linje med målet med artikeln, men eftersom testautomatisering är så hett eftertraktat idag, samtidigt som man ofta inte förmår att ro konceptet i hamn, har jag valt att bryta ut det i ett eget avsnitt. Nu när jag ändå är inne på andra saker än produktionsdata och anonymisering är det lika bra att löpa linan ut, jag passar på att ta ton om externa integrationer och testmiljöisolering.
GDPR
Att använda produktionsdata (med personuppgifter i) som testdata utan att först maskera genom att anonymisera[2] eller pseudonymisera[3], är oftast förbjudet enligt GDPR eftersom det är svårt att definiera en laglig grund baserat på test. Även om man anonymiserar kan det vara olagligt, om anonymiseringen inte är tillräckligt väl gjort.
Skälet är att data tillhör personen och inte något bolag. Bolagets behov av testdata är därför i princip irrelevant. För att överhuvudtaget få använda personuppgifterna för test måsta man kunna hävda en laglig grund, vi kommer tillbaka till det senare.
Föreställ dig att vi har en produktionsdatabas, med 100 000 personer i, som vi vill använda för test. Den första frågan vi måste ställa och är om vi verkligen behöver alla personerna? Om vi exempelvis kan klara oss med 99 999, så har vi bevisat att vi inte behöver alla och då måste vi ta bort en.
I nästa steg måste vi då fråga oss vilken av de 100 000 personerna vi inte behöver och därmed ta bort just den.
Det kan låta överdrivet att titta på individnivå när vi talar om så stora kvantiteter, men det är exakt det som är GDPR. Varje individs rättighet!
Det finns gråzoner som inte är prövade av Integritetsskyddsmyndigheten (IMY) ännu. Om vi exempelvis har en uppdatering med större ändringar i databasstruktur, som innebär en transformation av data i samband med uppdateringen, då kan vi testa hur mycket som helst med syntetiskt testdata utan att kunna fastställa att transformationen gått väl om vi inte kan testa transformationen med just produktionsdata. Problemet häri ligger i att produktionsdatat kan innehålla oväntade fel som gamla systemet felaktigt accepterat, men som nya systemet inte kommer att acceptera. Här kan det vara (utan garantier) lagligt att använda produktionsdata för att validera existerande data mot nya databasstrukturen, men då inte odiskriminerat. Exakt vilka kriterier som ska användas som begränsning måste beslutat från fall till fall, men följande är en grund att utgå ifrån:
- Data används under kortaste möjliga tid
- Säkerhet garanteras på samma sätt som i produktion
- Access begränsas på samma sätt som i produktion
- Inga externa integrationer existerar som kan påverka individen
Observera att detta också betyder att endast de personer som har access till data i produktion, kan verifierar funktionaliteten.
Oavsett ovan, så gäller fortfarande att man måste ha en laglig grund.
Laglig grund
För att få behandla personuppgifter måste man ha en laglig grund, detta definieras i GDPR artikel 6.1 a-f: Samtycke, Avtal, Rättslig förpliktelse, Skydda individens intresse, Uppgift av allmänt intresse, samt Berättigat intresse.
I teorin fungerar ”Samtycke” bäst, men i praktiken är det svårt eftersom någon kan dra tillbaka samtycket och därmed påverka testningen. ”Avtal” verkar intuitivt rimligt, men ett avtal är i de flesta fall inte avhängt ny funktionalitet och kan därför inte användas till utveckling av ny funktionalitet. ”Berättigat intresse” väger individens intresse mot bolagets och med tanke på att GDPR syftar till att skydda individens intresse så bör detta användas med försiktighet och bara då man mycket klart kan visa att bolagetsintresse väger tyngre. I praktiken kan vi, i min åsikt, för test bara hänvisa till ”Skydda individens intresse”, men att göra detta odiskriminerat är mycket tveksamt.
Däremot kan det vara lagligt (än en gång, inga garantier) om vi tydligt visar att majoriteten av testning sker med testdata utan personuppgifter (alternativt med anonymiserade personuppgifter), att behovet av den testning som sker med personuppgifter är väl definierat och att testningen sker inom ramen av en tydlig strategi som sätter individens rättigheter i centrum.
Om man väljer att använda personuppgifter för test måste man följa GDPR även i den berörda testmiljön. Den berörda personen ska första ha blivit informerad, personuppgifterna ska vara dokumenterade i företagets personuppgiftsregister. Om externa parter ska behandla personuppgifterna för test krävs dessutom att detta är definierat i ett personuppgiftsbiträdeskontrakt. Och så det roligaste av allt: Om personuppgifter oavsiktligt raderas eller ändras i testmiljön, innebär detta en personuppgiftsincident och att man måste utvärdera om detta måste rapporteras till IMY.
I bilden bredvid finns några exempel på personuppgiftsincidenter, taget från IMYs websida.
Sammanfattning
Det finns, i min åsikt, utrymme i GDPR att använda produktionsdata som testdata, men det är ett ganska trångt utrymme, det är juridiskt oprövat och innebär därför risk. Hur stor risken är står i direkt relation till hur det utförs. Att minimera testomfånget, att begränsa sig till verifikation, att likställa säkerhet och access med produktion kan mitigera risken, men inte eliminera den. Oavsett detta så måste man även för test fortfarande följa GDPR med registerförteckning, incidenthantering, information till individen, med mera.
Terminologi
[1] GDPR
General Data Protection Regulation. På svenska: Dataskyddsförordningen (DSF)
[2] Anonymisering
Att ändra på information så att den inte går att härleda till en enskild individ. En envägsprocess, det vill säga att det inte går att vända processen för att identifiera individen
[3] Pseudonymisering
Att ändra på information så att den oinvigde inte kan härleda till en enskild individ. Den som besitter rätt information kan vända processen och identifiera individen. Syftet är att informationen ska vara anonym för det flertal som bearbetar informationen men inte behöver veta vem det berör, men att utvalda individer ska kunna identifiera individen vid behov
[4] Syntetisering
Att skapa data som inte har någon koppling till verkligt data och därmed inte kan härledas till någon individ eller organisation
[5] Luhn-algoritm
En matematisk algoritm som används för att validera rimlighet av exempelvis personnummer eller kontonummer. I exempelvis personnummer är den sista siffran beräknad med Luhn-algoritm och benämns kontrollsiffra. Algoritmen är inte till för att bekräfta att personnumret är korrekt, det syftar bara till att upptäcka de mest uppenbara felskrivningarna
[6] Verifikation
I testsammanhang definieras test som att leta efter fel eller potentiella fel. Verifikation däremot förutsätter att test redan utförts och syftar till att verifiera att funktionaliteten som tidigare testats inte har försämrats. Ett typexempel är att testa funktionaliteten, men efter att ett nytt uppgraderingsförfarande använts, verifierar man att funktionaliteten fortfarande är intakt för att säkerställa att processen fungerat.
[7] Mitigera
Att mildra eller lindra skärpan eller intensiteten av något. Se Svenska akademins ordbok (www.saob.se)
Inläggsförfattare
