Persondata og risikovurdering

DPIA og konsekvensanalyse: vurder høj risiko før appen går i drift

En app kan fungere teknisk og stadig udsætte mennesker for en høj risiko. En DPIA undersøger den planlagte behandling af persondata, før I låser designet eller åbner for rigtige brugere. Målet er ikke et dokument til skuffen, men beslutninger om data, funktioner og sikkerhed, som kan forklares og afprøves.

Udgivet 14. oktober 2026 · Ca. 12 minutters læsetid

Det korte svar

Den dataansvarlige skal lave en konsekvensanalyse vedrørende databeskyttelse — en DPIA — når en planlagt behandling sandsynligvis indebærer høj risiko for menneskers rettigheder og frihedsrettigheder. Afklar behovet tidligt, beskriv det faktiske dataflow, vurder om behandlingen er nødvendig og rimelig, identificér konsekvenser for mennesker, og forbind hver væsentlig risiko med en konkret foranstaltning og et bevis.

AI-bygget betyder ikke automatisk høj risiko

Kravet afgøres af behandlingen af persondata — ikke af hvilket værktøj der skrev koden. En enkel lagerapp kan ligge uden for DPIA-kravet, mens profilering, lokationsdata, biometrisk identifikation eller automatiske afgørelser kan ændre vurderingen markant. Dokumentér også, hvorfor en DPIA ikke er nødvendig.

Screen behandlingen — ikke produktnavnet

Start med én afgrænset behandling: eksempelvis automatisk prioritering af kundehenvendelser eller lokationsregistrering af medarbejdere. Beskriv formål, personer, datatyper, kilder, modtagere, systemer, lagring, sletning og beslutninger. Den samme app kan rumme flere behandlinger med forskellig risiko.

Databeskyttelsesforordningen fremhæver blandt andet systematisk og omfattende vurdering af personer med væsentlig virkning, følsomme oplysninger eller oplysninger om strafbare forhold i stort omfang samt systematisk overvågning af offentligt tilgængelige områder i stort omfang. EDPB bruger desuden ni risikokriterier som praktisk screening; i de fleste tilfælde bør to kriterier føre til en DPIA-vurdering, men ét kriterium kan også være nok efter omstændighederne.

Signal	Spørg til appen	Mulig følge
Vurdering eller afgørelse	Rangerer eller afviser appen personer, adgang, service, pris eller mulighed?	Diskrimination, forkert afslag eller manglende mulighed for at gøre indsigelse.
Særlige eller meget private data	Behandles helbred, biometri, genetik, økonomi, lokation eller strafbare forhold?	Fortrolighedstab, identitetsmisbrug, overvågning eller fysisk risiko.
Omfang og sammenkobling	Dækker behandlingen mange personer, lang tid, flere kilder eller hele arbejdsdagen?	Et enkelt fejltrin kan ramme flere og afsløre mere end hvert datasæt alene.
Sårbare personer eller ny teknologi	Er børn, ansatte, patienter eller andre afhængige af beslutningen, eller er løsningen svær at gennemskue?	Svag reel valgfrihed, skæv magtbalance eller ukendte følgevirkninger.

Brug både Datatilsynets danske liste og EDPB's kriterier. Den danske liste er ikke udtømmende, så fravær fra listen er ikke i sig selv et nej til DPIA.

Byg analysen på appens faktiske dataflow

Et arkitekturbillede gør analysen konkret. Tegn hvor data kommer fra, hvilke API'er, databaser, filer, logs, analyseværktøjer og AI-tjenester de passerer, hvem der kan få adgang, og hvornår hver kopi slettes. Medtag testmiljø, backup, eksport og manuelle arbejdsgange — de er også en del af behandlingen.

1. Beskriv formål og forløb. Hvilken opgave løses, hvilke personer berøres, hvilke data bruges, og hvad sker der fra indsamling til sletning?
2. Test nødvendighed og proportionalitet. Kan formålet nås med færre felter, kortere opbevaring, mindre detaljerede data eller uden automatisk afgørelse?
3. Beskriv scenarier for mennesker. Hvad kan gå galt med fortrolighed, integritet, tilgængelighed, gennemsigtighed, rimelighed og muligheden for at bruge sine rettigheder?
4. Vælg og afprøv foranstaltninger. Knyt hver vigtig risiko til en ejer, en ændring i teknik eller proces og et tydeligt acceptkriterium.
5. Registrér beslutningen. Notér restrisiko, godkendelse, åbne handlinger og den ændring, der skal udløse ny vurdering.

Gør foranstaltningerne testbare

“Data er sikre” kan ikke verificeres. Beskriv i stedet hvad kontrollen gør, hvor den håndhæves, hvem der ejer den, og hvilket bevis der viser, at den virker. En teknisk kontrol løser heller ikke automatisk spørgsmål om formål, rimelighed eller gennemsigtighed.

Minimér behandlingen

Fjern unødige felter, reducer detaljer og historik, adskil formål, og test at appen stadig løser den aftalte opgave.

Begræns adgang og handlinger

Håndhæv roller og kundeadskillelse ved dataadgangen, kræv ekstra kontrol ved høj risiko, og test de afslag der skal ske.

Bevar menneskelig kontrol

Vis grundlaget for automatiske forslag, giv en reel korrektionsvej, og mål om mennesker bare accepterer systemets svar uden vurdering.

Opdag og begræns fejl

Brug dataminimerede logs, alarmer, revisionsspor, sikker rollback og gendannelsestest, og forbind fund med en navngiven driftsansvarlig.

Placér ansvar og stop ved høj restrisiko

Den dataansvarlige ejer vurderingen og beslutningen. En databehandler skal hjælpe med relevante oplysninger om løsning og sikkerhed. Har organisationen en databeskyttelsesrådgiver, skal rådgiveren høres. Inddrag relevante brugere eller deres repræsentanter, når deres synspunkter kan kvalificere den planlagte behandling.

Hvis væsentlige risici ikke kan bringes ned med egnede foranstaltninger, er konklusionen ikke “accepter og gå live”. Datatilsynet skal høres forud for behandlingen, når den tilbageværende risiko fortsat sandsynligvis er høj. Få konkret databeskyttelsesfaglig rådgivning ved tvivl; denne guide er en praktisk arbejdsramme, ikke juridisk rådgivning.

Hold DPIA'en i takt med løsningen

Analysen skal passe til den behandling, der faktisk kører. Gennemgå den, når risikoen ændrer sig — eksempelvis ved nye datakilder, nye personer, større omfang, en anden AI-model, automatiske afgørelser, ændret leverandørkæde eller en ny brug af eksisterende data. Knyt derfor analysens version til kode, arkitektur og den godkendte release.

Typiske fejl

DPIA'en starter efter go-live: De dyre designvalg er allerede låst, og højrisikobehandlingen kan være sat i gang uden den krævede vurdering.
Man vurderer systemet samlet: Formål, data og berørte personer blandes sammen, så den konkrete højrisikobehandling bliver skjult.
Risiko betyder kun hackerangreb: Forkerte afgørelser, diskrimination, overvågning og tab af råderum kan ramme mennesker uden et datalæk.
Kontroller er hensigtserklæringer: “Krypteret”, “adgangsbegrænset” eller “menneske i løkken” står uden håndhævelse, test og ejer.
Leverandørens papir overtages: En generel platformsvurdering beskriver ikke jeres formål, konfiguration, dataflow eller brugere.
Analysen opdateres aldrig: Den dokumenterer en prototype, mens produktionen har fået flere data, integrationer og beslutninger.

Tjekliste før behandling med mulig høj risiko

☐ Den dataansvarlige, behandlingen, formålet og de berørte personer er afgrænset.
☐ Datatilsynets liste og EDPB's risikokriterier er gennemgået, og beslutningen om DPIA er dokumenteret.
☐ Dataflowet dækker app, API, database, filer, logs, AI-tjenester, leverandører, test, backup og sletning.
☐ Nødvendighed og proportionalitet er vurderet for hvert vigtigt datasæt og hver væsentlig funktion.
☐ Risikoscenarier beskriver konsekvensen for mennesker, sandsynlighed og eksisterende kontroller.
☐ Hver væsentlig risiko har en foranstaltning, ejer, frist og et testbart bevis.
☐ DPO, databehandlere og relevante brugere eller repræsentanter er inddraget, når det er relevant.
☐ Restrisiko og beslutning er godkendt; fortsat høj risiko er sendt til forudgående høring før behandling.
☐ Ændringer, der kræver genvurdering, er defineret og koblet til appens ændringsproces.

Relaterede guides

Officielle kilder

Krav, screeningskriterier og minimumsindhold er kontrolleret mod aktuelle officielle kilder. Brug Datatilsynets vejledning, danske liste og skabelon til den konkrete behandling, og få faglig rådgivning ved tvivl om høj risiko eller forudgående høring.

Har appen persondata, men mangler I den dokumenterede risikovurdering?

Startklar kan bruges til at kortlægge den konkrete app, finde de vigtigste sikkerheds- og driftsopgaver og gøre foranstaltningerne målbare. Ved juridiske vurderinger kobles relevant databeskyttelsesfaglig rådgivning på.

Se Startklar-forløbet