Artikel 32 i GDPR kræver, at den dataansvarlige og databehandleren gennemfører passende tekniske og organisatoriske foranstaltninger til at sikre et sikkerhedsniveau, der passer til risiciene. Bestemmelsen har ingen fast liste, og Datatilsynet skriver, at den ikke fastsætter præcist, hvilke foranstaltninger der skal træffes. Det, der er passende hos en virksomhed, afhænger af det tekniske niveau, omkostningerne, behandlingens karakter og risikoen for personerne. Kravet flytter arbejdet over på jer. I skal kunne vise, at I har vurderet risikoen, valgt foranstaltninger ud fra den og kontrolleret, at de virker.
Hvad bestemmelsen siger
Art. 32, stk. 1, nævner fire ting, der efter omstændighederne hører med:
- Litra a: pseudonymisering og kryptering af personoplysninger.
- Litra b: evnen til at sikre vedvarende fortrolighed, integritet, tilgængelighed og robusthed i systemerne.
- Litra c: evnen til rettidigt at genoprette tilgængeligheden og adgangen efter en fysisk eller teknisk hændelse.
- Litra d: en procedure for regelmæssig afprøvning, vurdering og evaluering af, om foranstaltningerne virker.
Stk. 2 siger, at vurderingen navnlig tager hensyn til risikoen ved hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til oplysningerne. Stk. 4 siger, at personer under den dataansvarliges myndighed kun behandler oplysninger efter instruks.
Kravet gælder også databehandlere. En leverandør, der følger art. 32, fjerner ikke jeres eget ansvar for at vurdere opsætning, adgange og brug.
Hvad det betyder i IT
Oversat til hverdagen bliver de fire punkter til spørgsmål, som IT eller leverandøren skal kunne svare på.
Fortrolighed. Hvem kan se hvad, og hvorfor? Adgange efter arbejdsbetinget behov, MFA, kryptering af bærbare og mail med fortrolige oplysninger. For logins fra internettet til systemer med beskyttelsesværdige data forlanger Datatilsynets katalog MFA eller en løsning med samme virkning.
Integritet. Kan oplysninger ændres, uden at det opdages? Logning og ændringsstyring hører med her, og fejl i integrationer kan være lige så skadelige som angreb.
Tilgængelighed. Virker backuppen, når den skal bruges? Kataloget nævner test af, at data reelt kan genindlæses. Der er stor forskel på en backup, der kører, og en genetablering, der er prøvet.
Afprøvning. Hvornår blev det sidst kontrolleret? Punktet er gennemgået i test af sikkerheden efter GDPR.
Oversættelsen er vores. Den samlede gennemgang af foranstaltningerne står i Datatilsynets katalog oversat til IT-opgaver.
Risiko for personer som målestok
Niveauet fastlægges ud fra risikoen for dem, oplysningerne handler om. Det er den store forskel til NIS2, hvor sikkerheden ses fra net- og informationssystemerne og fra driften af virksomhedens tjenester. De to regelsæt kan pege på de samme foranstaltninger, men et system kan være uvigtigt for driften og stadig kræve stram adgangsstyring, fordi det rummer helbredsoplysninger. Hvordan de to spor deles, står i GDPR og NIS2 i samme risikovurdering. Vurderingen for personerne er beskrevet i risikovurdering for de registrerede.
Stærkere risiko giver stærkere krav. Følsomme oplysninger, mange personer og bred adgang flytter niveauet op. En lille virksomhed med få oplysninger må gerne stå et andet sted end en klinik, men begge skal kunne forklare hvorfor.
Bevisbyrden efter et brud
Hvad sker der, når noget alligevel går galt? Af C-340/21 fremgår det, at bruddet alene ikke afgør, om sikkerheden var for svag, mens bevisbyrden ligger hos jer som dataansvarlig. C-687/21 peger samme vej. For ledelsen betyder det, at der skal kunne fremlægges en forklaring på, hvad der blev gjort, og hvorfor det var passende.
Det, der skal kunne lægges frem, er typisk risikovurderingen, valget af foranstaltninger med begrundelse, dokumentation for kontrol, herunder logs og testresultater, og leverandørens erklæringer. Hvad der ellers hører til, står i GDPR-dokumentation.
Hvor det typisk knækker
I praksis er det afstanden mellem politik og virkelighed, der skaber problemerne. Adgange hober sig op, når folk skifter job. Konti efter fratrædelser står åbne. Logning er slået til, uden at nogen læser loggen, og backup er aldrig prøvet. Se politik og virkelighed. Et andet svagt punkt er grænsen til leverandøren. Hvem har ansvaret for opsætningen, og hvem læser leverandørens meldinger? Står det ikke nogen steder, gør ingen det.
DPO’ens rolle
DPO’en driver ingen systemer. Den rådgiver om, hvad art. 32 kræver hos jer, og kontrollerer efter art. 39, stk. 1, litra b, at det er gjort. En DPO, som kan læse en opsætning, kan gå fra politikken ned i adgange og logs og give ledelsen et billede af, om teksten holder. Beslutninger og gennemførelse ligger hos virksomheden, IT og leverandøren. Hvem der efterprøver, og hvad det skal ende i, står under Det får I.
Det skal I lade være med
- At lede efter den rigtige liste · der er ingen, så vurdér ud fra jeres egen risiko.
- At overlade hele vurderingen til leverandøren · dens art. 32-arbejde dækker ikke jeres opsætning.
- At regne en certificering som svar · den siger noget om leverandøren, og I skal stadig vurdere jeres egen behandling.
Det skal I kræve af den eksterne
- ☐ En vurdering af, om foranstaltningerne hænger sammen med risikoen.
- ☐ Kontrol i systemerne frem for alene læsning af dokumenter.
- ☐ Rapportering til ledelsen om afvigelser.
- ☐ Klar adskillelse af rådgivning og drift, så egne tiltag ikke skal evalueres.
Kilder
- Databeskyttelsesforordningen: art. 32 og art. 39, stk. 1, litra b.
- Datatilsynet: De 10 brud: bestemmelsen fastsætter ingen præcise foranstaltninger.
- Datatilsynet: Vejledning om behandlingssikkerhed og databeskyttelse gennem design og standardindstillinger (2018).
- Datatilsynet: Katalog over foranstaltninger: MFA og backup.
- EU-Domstolen, C-340/21 og C-687/21.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Når DPO’en går ned i systemerne · Kryptering og GDPR
→ Kontakt · Tlf. 70 13 63 23 · Ekstern DPO hos Nielco IT
