GDPR artikel 32: regelmæssig afprøvning af sikkerheden

Når en kunde henviser til GDPR artikel 32 i sit spørgeskema, bliver spørgsmålet om test noget mere end et indkøbskrav: kunden vil vide, om sikkerheden i et produkt med personoplysninger bliver afprøvet, og om det sker igen og igen. Et svar med én pentestrapport rammer kun halvdelen. Bestemmelsen taler om en procedure, og det er netop den, kunden spørger efter. Svaret hviler på forordningens ordlyd og på Datatilsynets vejledning om sikkerhedstest af software. Teksten er ikke juridisk rådgivning.

Hvad artikel 32 siger

Artikel 32 i databeskyttelsesforordningen handler om behandlingssikkerhed. Efter stk. 1 skal der gennemføres passende tekniske og organisatoriske foranstaltninger, der sikrer et sikkerhedsniveau, som passer til risiciene for de personer, oplysningerne handler om. Bestemmelsen nævner fire eksempler, alt efter hvad der er relevant: pseudonymisering og kryptering, evne til at sikre fortrolighed, integritet, tilgængelighed og robusthed, evne til at genoprette adgangen til data efter en hændelse og, i litra d, en procedure for regelmæssigt at afprøve, vurdere og evaluere, om foranstaltningerne er effektive.

Stk. 2 siger, at vurderingen af det passende niveau især skal tage hensyn til risikoen for, at oplysninger ødelægges, går tabt, ændres eller kommer uvedkommende i hænde. Hvordan ansvaret efter forordningen fordeles mellem jer og kunden, afhænger af jeres aftaler og af reglerne og er et spørgsmål til jeres egen rådgiver. → Kundedata i testen

En procedure, ikke en enkelt test

Ordet procedure er det vigtigste i litra d. En pentest er en afprøvning på et bestemt tidspunkt. En procedure er det, der sikrer, at afprøvningen gentages, at resultaterne vurderes, og at fundene fører til ændringer. Forordningen fastsætter ikke, hvor ofte det skal ske, eller hvilke former for test der skal bruges.

For et softwarehus betyder det, at det bedste svar til kunden beskriver jeres praksis: hvornår produktet testes, hvad der udløser en ekstra test, hvem der vurderer fundene, og hvordan rettelser efterprøves. Rapporten er dokumentation for, at praksis bliver fulgt, ikke selve svaret. → Et årshjul for sikkerhedstest

Datatilsynets vejledning om sikkerhedstest

Datatilsynet har i sit katalog over sikkerhedsforanstaltninger en vejledning om softwaretest med fokus på sikkerhed. Tilsynet kobler test til forordningens principper og bestemmelser, herunder artikel 32, stk. 1, litra b, om vedvarende fortrolighed, integritet, tilgængelighed og robusthed, og artikel 5, stk. 2, om at kunne påvise, at reglerne overholdes.

Vejledningen beskriver mange former for test gennem hele udviklingen, fra gennemgang af design og kode til test før idriftsættelse, hvor penetreringstest nævnes sammen med sårbarhedsscanning. Tilsynet anbefaler også at overveje, hvilke test der skal gentages efter idriftsættelse, og at alle test og resultater dokumenteres, så rettelser kan følges. Det passer til et softwareprodukt, der ændres løbende: test hører hjemme i udviklingen og ikke kun i en årlig rapport. → Automatiske test i pipelinen og den manuelle pentest

Vejledningen har også et afsnit om testdata. Tilsynet anbefaler at planlægge brugen af personoplysninger i test på forhånd, at styre, hvem der har adgang til testmiljøerne, og at fastlægge, hvordan og hvornår testdata slettes. For et softwarehus, der bestiller en pentest, er det de samme spørgsmål, kunden kan stille: hvilke data testeren så, og hvad der skete med dem bagefter.

Hvad kunden spørger efter

Et spørgsmål med henvisning til artikel 32 kan dække flere ting. Kunden kan ville vide, om produktet overhovedet testes. Kunden kan ville se, at testen tager udgangspunkt i de steder, hvor personoplysningerne ligger. Eller kunden kan ville vide, hvordan I sikrer, at nye funktioner ikke svækker sikkerheden mellem to test.

Svar på alle tre, også hvis kun det første er spurgt direkte. Beskriv, hvilke dele af produktet der behandler personoplysninger, og at testens omfang dækker dem. Beskriv jeres praksis for nye funktioner. Og vedlæg en kundeversion af seneste rapport med dato og status på fund. Skriv beskrivelsen, så den kan genbruges, men gennemgå den, hver gang I sender den. Ændrer I testrytme, omfang eller tester, skal beskrivelsen følge med, ellers giver den kunden et billede af en praksis, I ikke længere har. → Sundhedskunden vil se dokumentation

Certificering som et element

Artikel 32, stk. 3, siger, at overholdelse af en godkendt adfærdskodeks eller en godkendt certificeringsmekanisme efter forordningens artikel 40 og 42 kan bruges som et element til at påvise, at kravene i stk. 1 er opfyldt. Ordet element er vigtigt: det er et bidrag, ikke en afgørelse. Bestemmelsen gælder desuden kun godkendte ordninger efter forordningens regler. Om en bestemt certificering, I har eller overvejer, er godkendt på den måde, skal undersøges for sig, før I henviser til den i et svar om artikel 32.

Har I en certificering, kan I derfor ikke skrive, at den dokumenterer overholdelse af artikel 32. Det samme gælder pentestrapporten. Begge kan indgå i det, I viser kunden, men ingen af dem kan stå alene. → Kunden henviser til en standard

Et tænkt eksempel

Et softwarehus leverer et system til administration af medlemmer i idrætsforeninger. En landsdækkende forening spørger i sit skema: Hvordan opfylder I kravet i GDPR artikel 32 om regelmæssig afprøvning?

Softwarehuset svarer med en kort beskrivelse af sin praksis: en årlig pentest af hele produktet, en ekstra test ved større ændringer i modulet med medlemsdata, automatiske sikkerhedstest ved hver udgivelse og en fast gennemgang af fund i udviklingsteamet. Det vedlægger kundeversionen af seneste rapport og skriver, at test sker med fiktive data. Svaret siger ikke, at kravet er opfyldt; det beskriver, hvad softwarehuset gør. Foreningen spørger til, hvem der vurderer fundene, og får navnet på den funktion i softwarehuset, der ejer opfølgningen.

Det skal I lade være med

Svare med én rapport alene · bestemmelsen taler om en procedure.
Skrive, at produktet opfylder artikel 32 · det er en vurdering, I ikke kan afgøre i et skema.
Opfinde en frist · forordningen fastsætter ikke, hvor ofte der skal testes.
Glemme test mellem to pentest · nye funktioner ændrer risikoen.
Bruge rigtige personoplysninger i testen uden overvejelse · testen må ikke selv blive en risiko.

Hvad kan og ikke kan konkluderes

En beskrevet praksis med regelmæssig test og opfølgning kan vise kunden, at sikkerheden i produktet bliver afprøvet og vurderet over tid, som artikel 32, stk. 1, litra d, nævner. Den kan ikke vise, at sikkerhedsniveauet er passende i forordningens forstand, eller hvordan Datatilsynet vil vurdere en konkret sag. En pentestrapport viser, hvad en test fandt, ikke at forordningen er overholdt.

Tjekliste til svaret om artikel 32

☐ Beskriver svaret en praksis og ikke kun én test?
☐ Fremgår det, hvilke dele af produktet der behandler personoplysninger?
☐ Dækker testens omfang de dele?
☐ Er der en praksis for test af nye funktioner mellem to pentest?
☐ Er brugen af testdata planlagt og beskrevet?
☐ Undgår svaret at love overholdelse?

Kilder

Databeskyttelsesforordningen, forordning (EU) 2016/679: artikel 32, stk. 1, litra a til d, stk. 2 (risici ved behandling) og stk. 3 (godkendt adfærdskodeks eller certificering som et element).
Datatilsynet: Softwaretest med fokus på sikkerhed: test kædet til artikel 5, stk. 1, litra f, og stk. 2, artikel 25 og artikel 32, stk. 1, litra b; penetreringstest før idriftsættelse; overvej gentagne test efter idriftsættelse; dokumentation af test og resultater.

Senest gennemgået: oktober 2026.