En DPIA fokuserer på de mennesker, hvis data behandles, og ikke på den organisation, der udfører behandlingen. Betydningen af en DPIA overlapper i høj grad med en privacy impact assessment (PIA), som er en ældre og bredere betegnelse for den samme type øvelse, der anvendes i databeskyttelsesregimer uden for EU og, i Storbritannien, i vejledninger, der ligger før selve GDPR. I praksis bruger mange organisationer og endda visse tilsynsmyndigheder de to begreber i flæng, og den bagvedliggende metodik er stort set den samme: kortlægning af datastrømme, vurdering af risici for enkeltpersoner og fastlæggelse af sikkerhedsforanstaltninger. Den juridisk afgørende forskel er mere snæver: Specifikt under GDPR er DPIA den definerede betegnelse, hvor udløsere og indhold er fastlagt i artikel 35, og kravet om forudgående høring i artikel 36. Det er netop dette fokus på mennesker frem for organisationen, der præger alle andre aspekter af, hvordan den fungerer.

Hvorfor er DPIA'er vigtige?

At opdage et databeskyttelsesproblem før lanceringen er langt bedre end at opdage det bagefter. Det er det praktiske argument for en DPIA: Den bringer risici frem i lyset, mens et projekt stadig kan omdesignes ud fra dem, i stedet for efter lanceringen, hvor mulighederne indsnævres til damage control. Det er samtidig en af de tydeligste måder at påvise GDPR-ansvarlighed på – ikke ved at henvise til en politik, men ved at vise de faktiske overvejelser bag en specifik behandlingsbeslutning.

Intet af dette kræver, at man fjerner enhver risiko, en DPIA afdækker. Opgaven er at identificere, hvad der er til stede, afgøre om det er acceptabelt, og etablere de rette sikkerhedsforanstaltninger omkring det. Gøres det tidligt nok, indbygger den samme øvelse databeskyttelse i måden, et projekt designes på, i stedet for at databeskyttelsen blot tilføjes som et gennemgangstrin til sidst.

Hvornår er en DPIA påkrævet i henhold til GDPR?

Artikel 35 fastsætter udgangspunktet: En DPIA er påkrævet, hver gang en behandling sandsynligvis vil medføre en høj risiko for fysiske personers rettigheder og frihedsrettigheder. Om denne tærskel er nået, afhænger af selve behandlingens karakter, afgrænsning, sammenhæng og formål, og ikke af størrelsen på den organisation, der udfører den.

Behandling, der automatisk kræver en DPIA

Tre scenarier krydser altid den grænse i henhold til GDPR artikel 35:

• Systematisk og omfattende profilering eller evaluering, der har retsvirkning eller tilsvarende væsentlig betydning. En kreditvurderingsalgoritme, der afgør berettigelse til lån, er et tydeligt eksempel.

• Behandling i stort omfang af særlige kategorier af oplysninger eller oplysninger om straffedomme, såsom helbredsoplysninger eller biometriske data i stort omfang.

• Systematisk overvågning af offentligt tilgængelige områder i stort omfang, som for eksempel et byomfattende tv-overvågningsnetværk.

Andre indikatorer for behandling med høj risiko

Disse tre scenarier udgør minimummet og er ikke en udtømmende liste. Systematisk overvågning, følsomme oplysninger, behandling i stort omfang, kombination af datasæt fra forskellige kilder, behandling, der involverer sårbare personer, innovative teknologier samt automatisk afgørelser kan alt sammen bringe behandlingen ind i kategorien for høj risiko – også uden for de nævnte scenarier. Nationale tilsynsmyndigheder offentliggør ligeledes deres egne lister, som for eksempel det britiske UK ICO's DPIA guidance , og disse går ofte videre end GDPR's egne eksempler.

Hvilken type risiko vurderer en DPIA?

En DPIA spørger til fysisk, finansiel, social eller anden materiel og ikkemateriel skade på personer. Diskrimination som følge af en automatisk afgørelse, identitetstyveri efter et databrud eller blot det at miste kontrollen over følsomme personoplysninger tæller alt sammen som skade på personen, uanset om organisationen selv nogensinde mærker en konsekvens. Det er et helt andet spørgsmål end det, der stilles i et traditionelt rammeværk for risikostyring, som typisk evaluerer risikoen for selve organisationen frem for for de personer, som behandlingen berører.

DPIA vs. risikovurdering af informationssikkerhed

En risikovurdering af informationssikkerhed fokuserer typisk på trusler mod fortrolighed, integritet og tilgængelighed. Konsekvenser for de berørte personer er det, en DPIA reelt er bygget til at fange. Sikkerhedsforanstaltninger ender ofte med at have en dobbeltfunktion som risikobegrænsende tiltag i en DPIA, men at udføre en informationssikkerhedsvurdering i henhold til ISO 27001 træder ikke i stedet for en DPIA. De besvarer forskellige spørgsmål, selv når de ser på de samme systemer.

Hvad skal en DPIA indeholde?

GDPR artikel 35 fastsætter fire minimumselementer:

Hvem har ansvaret for at gennemføre en DPIA?

Den dataansvarlige har ansvaret for at sikre, at der gennemføres en DPIA, når det er påkrævet. Det er et formelt ansvar, ikke nødvendigvis en opgave for én person alene: Hvor en organisation har en databeskyttelsesrådgiver, hører dennes rådgivning til i processen, og relevante teams, databehandlere og tekniske specialister bidrager ofte med information eller ekspertise undervejs. Ansvar og bidrag er to forskellige ting her, og at sammenblande dem er en udbredt måde, hvorpå ansvaret stille og roligt fordufter.

Hvornår skal en DPIA gennemføres?

GDPR forventer, at en DPIA gennemføres tidligt nok til reelt at præge, hvordan behandlingen udformes, og altid før behandlingen med høj risiko påbegyndes. Når systemet først er bygget, bliver en DPIA blot en formalitet: Arkitekturen er på plads, leverandøren er valgt, og at ændre noget nu medfører reelle omkostninger og forsinkelser. At behandle en DPIA som en del af projektplanlægningen – i stedet for en compliancesikring tilføjet i sidste øjeblik – er det, der reelt forbinder den med GDPR's overordnede princip om databeskyttelse gennem design og som standard.

Skal en DPIA revideres?

Intet ved en færdiggjort DPIA er permanent. En ny leverandør kan overtage en del af behandlingen, et system kan begynde at indsamle et yderligere datafelt, eller en model bygget til ét formål kan blive genanvendt til et andet. Enhver af disse ændringer kan stille og roligt ugyldiggøre den oprindelige vurdering, uden at nogen bevidst har besluttet, at den skulle det. Artikel 35, stk. 11, kræver en fornyet gennemgang, når det er nødvendigt, og i det mindste når risikoen ved behandlingen ændrer sig. I praksis betyder det at gennemgå en DPIA igen, når behandlingens karakter, omfang, sammenhæng eller formål ændrer sig, når ny teknologi træder ind i billedet, når nye risici opstår, eller når de oprindeligt iværksatte garantier ændres væsentligt. Behandl den som en levende proces, ikke et dokument der arkiveres, når det først er godkendt.

Hvad sker der, hvis en DPIA identificerer en høj restrisiko?

Den første reaktion er at søge efter foranstaltninger, der reducerer risikoen. Hvis behandlingen selv efter risikobegrænsende tiltag stadig vil medføre en høj risiko for personer, skal den dataansvarlige rådføre sig med den relevante tilsynsmyndighed, før behandlingen påbegyndes. Det er en anden udløser end den, der sætter en DPIA i gang i første omgang: En indledende høj risiko betyder, at en DPIA er påkrævet, mens en uafbødet høj restrisiko betyder, at tilsynsmyndigheden skal rådføres, før man går videre.

Findes der en standardiseret DPIA-skabelon?

GDPR stiller ikke krav om et enkelt bestemt format. Forordningen definerer, hvad en DPIA skal dække, og lader derefter organisationer frit benytte en skabelon offentliggjort af en tilsynsmyndighed eller tilpasse deres egen metode, så længe de krævede elementer reelt behandles.

Det Europæiske Databeskyttelsesråd vedtog i marts 2026 en harmoniseret DPIA-skabelon (version 1.0), som er tænkt som en fælles reference i hele EU, og offentliggjorde den i april samme år. Den offentlige høring om udkastet blev afsluttet i juni 2026, og da dette skrives, beskriver EDPB's egen side stadig den endelige version som afventende. Den er værd at holde øje med, men det er endnu ikke det eneste krævede format.

Hvordan Formalize understøtter håndtering af DPIA'er

De fleste organisationer opbevarer stadig deres DPIA'er i dokumenter, regneark og e-mailtråde. Det giver intet samlet overblik over, hvilke vurderinger der er udestående, forfaldne eller stille og roligt forældede.

Formalize samler i stedet det arbejde i ét struktureret system:

• DPIA og TIA workflows med navngivne ejere og deadlines, i stedet for et dokument, der venter i nogens indbakke.

• Behandlingsaktiviteter knyttet til risici, systemer og leverandører, så en DPIA afspejler, hvad der reelt sker, og ikke et øjebliksbillede fra dengang den blev skrevet.

• Dokumentation og garantier knyttet direkte til hver enkelt risiko, så en færdig DPIA reelt kan fremvises på anmodning og ikke skal rekonstrueres ud fra hukommelsen.

• GDPR, ISO 27001, NIS2, og andre frameworks i det samme system, i stedet for at være spredt over separate værktøjer, der hver især kræver deres egen opdatering.

Intet af det afgør, om en specifik DPIA er juridisk tilstrækkelig. Den vurdering tilhører stadig de personer, der forstår behandlingen og dens kontekst. Det, Formalize gør, er at gøre den vurdering nemmere at dokumentere, påvise og genbesøge senere.