Personopplysninger i testmiljø: kan vi bruke ekte kundedata når vi tester?

Klokka er halv fire en fredag. En utvikler skal finne en feil i fakturamodulen som bare oppstår hos noen få kunder, og den raskeste veien er å kopiere produksjonsdatabasen til testmiljøet. Feilen er funnet før helgen. Kopien med 40 000 kunder, betalingshistorikk og kundeservicenotater blir liggende. Scenariet er oppdiktet, men det er neppe uvanlig.

Spørsmålet er om dette er lov. For private virksomheter er svaret at det kan være det, men bare etter en konkret vurdering som de fleste aldri gjør.

Hva sier GDPR om personopplysninger i testmiljø?

GDPR har ingen egen regel om test og utvikling. Bruk av produksjonsdata i et testmiljø er en ny behandling av personopplysningene, og den må passe inn i de alminnelige reglene i personvernforordningen, som gjelder som norsk lov etter personopplysningsloven § 1.

Tre prinsipper gjør jobben. GDPR art. 5 nr. 1 bokstav b slår fast formålsbegrensningen. Opplysninger samlet inn for å levere en tjeneste og sende faktura, kan ikke viderebehandles på en måte som er uforenlig med det formålet. GDPR art. 5 nr. 1 bokstav c krever dataminimering, altså at det ikke brukes flere opplysninger enn formålet krever. Og GDPR art. 5 nr. 1 bokstav e setter grenser for hvor lenge kopien kan ligge.

Test av et system som allerede behandler de samme opplysningene, ligger nær det opprinnelige formålet. Utvikling av et nytt produkt, eller trening av en KI-modell på kundedata, ligger lenger unna. Flere av de grunnleggende reglene er forklart på pilarsiden om personvern.

Hvordan gjør vi forenlighetsvurderingen?

Når behandlingen ikke bygger på samtykke eller særskilt lovhjemmel, må virksomheten vurdere om testformålet er forenlig med det opprinnelige formålet. GDPR art. 6 nr. 4 lister opp momentene.

• Hvilken forbindelse det er mellom innsamlingsformålet og testformålet.
• I hvilken sammenheng opplysningene ble samlet inn, særlig forholdet mellom kunden og virksomheten.
• Hva slags opplysninger det er, og om det finnes særlige kategorier etter art. 9 eller opplysninger om straffbare forhold etter art. 10.
• Hvilke konsekvenser testingen kan få for de registrerte.
• Om det finnes nødvendige garantier, for eksempel kryptering eller pseudonymisering.

I praksis faller vurderingen ofte ut i favør av test av eksisterende funksjonalitet med et begrenset uttrekk, sikret like godt som produksjonen. Den faller sjeldnere ut i favør av å flytte hele kundebasen til et utviklingsmiljø med bred tilgang, og nesten aldri når helseopplysninger eller opplysninger om barn er med. Er formålet forenlig, kan behandlingen etter fortalepunkt 50 bygge på det opprinnelige behandlingsgrunnlaget. Vi anbefaler likevel å dokumentere vurderingen skriftlig, fordi det er den virksomheten må legge fram når Datatilsynet spør.

Hvorfor foreslår Finanstilsynet en egen lovhjemmel?

Finansdepartementet sendte 13. august 2026 på høring et forslag om endringer i finanstilsynsloven, med frist 6. oktober 2026. Forslaget kommer fra Finanstilsynet, og høringsnotatet er datert 1. juni 2026.

Etter forslaget til ny § 6-6 i finanstilsynsloven kan Finanstilsynet viderebehandle personopplysninger, også særlige kategorier og opplysninger om straffbare forhold, når det er nødvendig for å utvikle og teste IT-systemer og det er «umulig eller uforholdsmessig vanskelig» å oppnå formålet med anonyme eller fiktive opplysninger. Momenter i forholdsmessighetsvurderingen er blant annet arbeidets kompleksitet og omfang, tidsaspektet, kostnader og forventede gevinster.

Høringsnotatet er interessant for private virksomheter av to grunner. Finanstilsynet mener at dagens hjemmel trolig dekker test av eksisterende systemer når det er nær sammenheng med tilsynsoppgavene, men at det er uklart hvor langt den rekker ved utvikling av nye systemer og ved bruk av KI. Og tilsynet skriver rett ut at det er svært krevende å oppfylle GDPRs krav til anonymisering. Notatet viser også at Skatteetaten, Tolletaten og Lånekassen allerede har slike hjemler i sine særlover.

Offentlige organer som behandler opplysninger for å utøve offentlig myndighet, trenger et supplerende rettsgrunnlag i lov etter GDPR art. 6 nr. 3. Private virksomheter har ingen tilsvarende regel å støtte seg på. De må gjøre forenlighetsvurderingen selv, uten et lovvedtak som har avveid hensynene for dem på forhånd.

Når selv et tilsyn mener det trenger lovhjemmel for å teste med ekte data, bør en privat virksomhet ha en skriftlig begrunnelse før den gjør det samme.

Hva sier Datatilsynet om testdata?

Datatilsynets veiledning Programvareutvikling med innebygd personvern sier i kapitlet om test at det skal brukes syntetiske personopplysninger. Tilsynet opplyser selv at veiledningen ikke lenger er tilstrekkelig oppdatert og arbeider med en ny versjon. Utgangspunktet om syntetiske data har likevel støtte i GDPR art. 25, som krever innebygd personvern og personvern som standard.

Datatilsynet har også vist hva som skjer når det går galt. I 2021 fikk Norges idrettsforbund et overtredelsesgebyr på 1 250 000 kroner. Ved testing av en skyløsning lå personopplysninger om 3,2 millioner mennesker, blant dem barn, eksponert på en åpen IP-adresse i 87 dager. Tilsynet la vekt på at forbundet manglet rettslig grunnlag for å bruke ekte opplysninger når fiktive data ville vært nok.

Hvilke alternativer har vi til ekte data?

Valget står mellom fire nivåer, og det er bare det første som tar dataene helt ut av GDPR med sikkerhet.

Pseudonymisering er definert i GDPR art. 4 nr. 5. Opplysningene behandles slik at de ikke kan knyttes til en bestemt person uten tilleggsopplysninger, og nøkkelen oppbevares atskilt og sikret. Pseudonymiserte data er fortsatt personopplysninger for den som har nøkkelen. EDPB har utdypet dette i retningslinjer om pseudonymisering, foreløpig i høringsversjon.

Grensen mot anonymisering er vanskeligere enn mange tror. Syntetiske data som er generert fra ekte kundedata, kan også lekke opplysninger om enkeltpersoner. Vi har skrevet om dette i artikkelen om EDPBs nye retningslinjer om anonymisering.

Hvilke sikringstiltak krever GDPR i testmiljøet?

Et testmiljø med ekte personopplysninger er et produksjonsmiljø i GDPRs forstand. GDPR art. 32 krever et sikkerhetsnivå som passer risikoen, og nevner pseudonymisering og kryptering som eksempler. Testmiljøer er ofte svakere sikret enn produksjonen, med delte kontoer, bredere tilgang og mindre logging.

Konkret bør virksomheten begrense tilgangen til de utviklerne som trenger den, logge oppslag, kryptere lagringen og sette en fast slettedato for hvert uttrekk. Uttrekket bør bare inneholde de feltene testen krever. Et fritekstfelt med kundeservicenotater er sjelden nødvendig for å teste en fakturaberegning. Ved stor risiko, for eksempel særlige kategorier eller mange registrerte, må det vurderes om en vurdering av personvernkonsekvenser er påkrevd.

Hva må stå i databehandleravtalen om testmiljø?

Når en leverandør utvikler eller drifter systemet, skjer testingen ofte hos leverandøren. GDPR art. 28 nr. 3 krever at databehandleren bare behandler opplysningene etter dokumenterte instrukser. Bruk av kundens produksjonsdata i leverandørens testmiljø må derfor være dekket av instruksen.

Les databehandleravtalen med dette for øye. Avtalen bør si om leverandøren kan kopiere produksjonsdata til test, hvilke sikringstiltak som da gjelder, hvor testmiljøet ligger, hvilke underleverandører som har tilgang, og når kopien slettes. Bruker leverandøren kundens data til å forbedre sitt eget produkt for alle kunder, behandler den opplysningene for egne formål og blir selv behandlingsansvarlig for den delen etter GDPR art. 28 nr. 10. Mer om dette står i artikkelen om databehandleravtalen ved kjøp av SaaS.

Hva bør virksomheten gjøre?

1. Kartlegg alle test-, utviklings- og demomiljøer, og finn ut hvilke av dem som inneholder kopier av produksjonsdata.
2. Gjør syntetiske data til standard, og krev skriftlig begrunnelse for unntak.
3. Dokumenter forenlighetsvurderingen etter art. 6 nr. 4 for hvert uttrekk av ekte data.
4. Pseudonymiser eller masker direkte identifikatorer, og fjern fritekstfelt som ikke trengs.
5. Sett samme tilgangsstyring og logging i testmiljøet som i produksjonen.
6. Gi hvert uttrekk en eier og en slettedato, og kontroller at slettingen faktisk skjer.
7. Gå gjennom databehandleravtalene og se om leverandørens testmiljø er regulert.

Begynn med punkt 1. En testkopi som ingen lenger vet hvem som laget, har som regel verken eier, slettedato eller forenlighetsvurdering, og den er det første Datatilsynet vil spørre etter.

Spørsmål og svar

Neste faglige kontroll: 1. mars 2027