Ja, i den forstand at art. 32, stk. 1, litra d, taler om regelmæssigt at afprøve, vurdere og evaluere, om de tekniske og organisatoriske foranstaltninger virker. Bestemmelsen står blandt de tiltag, der hører med efter omstændighederne, og den er risikobaseret. Forordningen nævner ikke penetrationstest eller nogen anden bestemt metode, og den sætter ingen frekvens. Det, I skal kunne vise, er en procedure, der passer til risikoen, og at resultatet fører til noget. Afprøvning er også meget mere end en test af tekniske sårbarheder.
Hvad der tæller som afprøvning
Ordlyden omfatter både tekniske og organisatoriske foranstaltninger. En gennemgang af, om medarbejderne følger proceduren, er derfor lige så relevant som en teknisk test. Mange af kontrollerne er enkle, og de første fire står i Datatilsynets katalog:
- Adgange. Periodisk kontrol af, om rettighederne stadig passer til behovet.
- Logs. Stikprøver og en kontrol af, at der logges som forventet, og at loggen kan tolkes.
- Backup. Test af, om data reelt kan genindlæses og bruges.
- Software. Kataloget har en side om softwaretest med fokus på sikkerhed, både før ibrugtagning og i systemer, der allerede kører.
- Procedurer. En øvelse i, hvordan et brud håndteres, viser, om planen virker.
Tilsynet beskriver i vejledningen om behandlingssikkerhed afprøvningen som noget, der sker med jævne mellemrum og afhænger af risikoen. Hvor ofte, må I selv fastsætte og kunne begrunde.
Softwaretest i Datatilsynets katalog
Siden om softwaretest, opdateret 17. oktober 2025, er værd at læse, når I får udviklet noget eller ændrer integrationer. Den skelner mellem test af forventet funktionalitet og sikkerhedstest, der leder efter uønsket funktionalitet. Testene spænder fra undersøgelse af designet og kodegennemgang til integrationstest.
Et par pointer er særlige for persondata. Designet skal undersøges for, om behandlingen kan stoppe, og om data kan slettes, når loven kræver det. En ændring kan få data til at blive liggende længere end nødvendigt, uden at nogen bemærker det. Loggen kan testes som en blindtest, hvor man tolker indholdet uden at vide, hvad der skete, og sammenholder det med de faktiske handlinger. Og loggen bør testes for, om den selv rummer unødige personoplysninger eller adgangskoder.
Tilsynet skriver også, at man sjældent kan regne med, at leverandøren har fokus på sikkerhed af sig selv, så det normalt er nødvendigt at tage stilling til og stille krav om relevant test. Kravet bør stå i aftalen. Bruges rigtige personoplysninger i testdata, er det en behandling, der selv skal vurderes.
Pentest og sårbarhedsscanning
En penetrationstest står ingen steder i GDPR. Den kan være en passende måde at afprøve sikkerheden på, når risikoen er høj, eller systemerne kan nås udefra. Valget afhænger af, hvad I vil have svar på. Her ligger faglig viden om testene på sikkerhedstesten.dk under hvad testen kan svare på og hvad testen ikke erstatter.
Set fra GDPR er der tre ting at tage stilling til, før en test bestilles. Omfatter den systemerne med persondata? Får testeren adgang til personoplysninger, og i så fald hvilken rolle har testeren så? Og hvad gør I med fundene? Rollen hos leverandører er behandlet i dataansvarlig eller databehandler.
Hvordan resultatet bruges
En test uden opfølgning er værdiløs i dokumentationen. Hvert resultat bør give en kort notits med dato, omfang, hvem der testede, hvad der blev fundet, hvad der blev besluttet, og hvornår det var rettet. Fund, der ikke rettes, hører hjemme i risikovurderingen som en risiko, ledelsen har taget stilling til.
Datatilsynet skriver i kataloget, at dokumentation af udførte test kan indgå, når et brud anmeldes, som en del af det, I har gjort for at undgå brud og efterleve art. 32. Efter C-340/21 har den dataansvarlige bevisbyrden for, at foranstaltningerne var passende, så netop den dokumentation er værd at have. Dokumentation af test understøtter også kravet i art. 5, stk. 2, om at kunne påvise, at reglerne overholdes.
En enkel afprøvningsplan
Vores forslag til en mindre virksomhed er en plan på én side med en række pr. foranstaltning. Skriv, hvad der kontrolleres, hvem der gør det, hvor ofte, og hvor resultatet lægges. Frekvensen sættes ud fra risikoen. Tag jeres vigtigste foranstaltninger fra risikovurderingen, og begynd med dem, som I regner mest med. Tag leverandøren med, for en stor del af kontrollen vil ligge hos den.
Så ved ledelsen, hvad der er afprøvet, og hvad der ikke er. Det er også et godt udgangspunkt for DPO’ens rapport.
DPO’ens rolle
Art. 39, stk. 1, litra b, nævner overvågning, herunder revisioner. DPO’en kan pege på, hvad der bør afprøves, læse resultaterne og følge op på, om fundene bliver rettet. DPO’en bør ikke selv stå for de tiltag, der testes, for så kommer den til at evaluere sit eget arbejde. Datatilsynets FAQ nævner netop den interessekonflikt. Virksomheden beslutter, hvad der skal testes, og bestiller testen.
Det skal I lade være med
- At sætte lighedstegn mellem GDPR-kravet og en årlig pentest · bestemmelsen dækker også adgange, logs, backup og procedurer.
- At lade resultatet ligge i en mappe · fundene skal føre til en beslutning.
- At teste med rigtige personoplysninger uden at vurdere det · brug af testdata er også en behandling.
Det skal I kræve af den eksterne
- ☐ Rådgivning om, hvilke foranstaltninger der bør afprøves først.
- ☐ Læsning af testrapporter med øje for persondata.
- ☐ Opfølgning på, om fund er rettet eller besluttet.
- ☐ Afprøvningen samlet i rapporten til ledelsen.
Kilder
- Databeskyttelsesforordningen: art. 5, stk. 2, art. 32, stk. 1, litra d, og art. 39, stk. 1, litra b.
- Datatilsynet: Softwaretest med fokus på sikkerhed, opdateret 17. oktober 2025.
- Datatilsynet: Vejledning om behandlingssikkerhed og databeskyttelse gennem design og standardindstillinger (2018).
- Datatilsynet: Databeskyttelsesrådgivere: interessekonflikt ved evaluering af egne tiltag.
- EU-Domstolen, C-340/21: bevisbyrde.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Politik og virkelighed · Passende sikkerhed efter artikel 32
→ Kontakt · Tlf. 70 13 63 23 · Ekstern DPO hos Nielco IT
