Persondata og rettigheder

GDPR-anmodninger: find, udlever, ret og slet persondata sikkert

Når en kunde eller medarbejder beder om indsigt, rettelse eller sletning, er en downloadknap eller et slettet bruger-id ikke nok. I skal kunne forbinde personen med data på tværs af app, filer, logs og leverandører, træffe en begrundet beslutning og kontrollere, at resultatet faktisk blev gennemført.

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

Start med anmodningen – ikke med en automatisk sletning

En besked som “send alt om mig” eller “slet min konto” kan udløse forskellige rettigheder og kræver en konkret vurdering. Retten til indsigt, rettelse, sletning, begrænsning og dataportabilitet er ikke det samme. Sletning er heller ikke ubetinget; visse oplysninger kan fortsat være nødvendige på grund af en retlig forpligtelse eller for at fastlægge, gøre gældende eller forsvare et retskrav.

Anmodning	Praktisk opgave	Typisk faldgrube
Indsigt	Find personens oplysninger og den krævede kontekst om behandlingen	At sende et råt databaseudtræk med andre personers data
Rettelse	Ret urigtige oplysninger og vurder afledte kopier og modtagere	At rette profilskærmen, mens gamle værdier lever videre andre steder
Sletning	Vurder grundlag og undtagelser, og udfør godkendt sletning i hele datakæden	At fjerne login, men beholde identificerbare data i tabeller og filer
Begrænsning	Stop den relevante brug af data, mens opbevaring og vurdering fortsætter	At bruge en note i stedet for en håndhævet teknisk tilstand

Denne guide handler om at gøre processen teknisk gennemførlig. Den erstatter ikke en konkret juridisk vurdering af behandlingsgrundlag, undtagelser eller national lovgivning.

Registrér modtagelsen og få en ansvarlig på sagen

Anmodningen kan komme gennem support, email, en medarbejder eller en funktion i appen. Den må ikke forsvinde, fordi den ramte den forkerte indbakke. Registrér modtagelsesdato, kontaktvej, anmodningens omfang, ansvarlig og næste kontrolpunkt i en beskyttet sag.

GDPR kræver svar uden unødig forsinkelse og som udgangspunkt senest en måned efter modtagelsen. Fristen kan om nødvendigt forlænges med yderligere to måneder på grund af kompleksitet eller antal anmodninger, men personen skal have besked om forlængelsen og begrundelsen inden for den første måned. Byg derfor en fristalarm – ikke en antagelse om, at supporten husker sagen.

Lav én sagsstatus. Eksempelvis modtaget, identitet afklares, omfang afklares, data indsamles, vurderes, godkendt, udført og svar sendt. Status skal beskrive arbejdet – ikke bruges som bevis for, at sletning eller udlevering lykkedes.

Kontrollér identiteten uden at indsamle unødige ID-data

En indsigtsanmodning kan blive et databrud, hvis svaret sendes til den forkerte person. En sletteanmodning kan ramme en anden brugers konto. Hvis der er rimelig tvivl om identiteten, må I bede om de ekstra oplysninger, der er nødvendige for at bekræfte den. Vælg den mindst indgribende kontrol, der passer til risikoen.

Indlogget bruger: Lad personen genbekræfte login eller en stærk faktor før følsom eksport eller sletning.
Kendt kontaktvej: Bekræft gennem en kanal, som allerede er knyttet sikkert til personen, når det er tilstrækkeligt.
Ekstra dokumentation: Bed kun om det nødvendige, beskyt materialet, og fastsæt en kort slettefrist for kopien.
Repræsentant: Kontrollér både personens identitet og repræsentantens ret til at handle på vedkommendes vegne.

Find personen gennem stabile forbindelser – ikke kun email

Email, navn og telefonnummer kan ændres, genbruges eller findes på flere personer. Brug en intern person- eller brugerreference som udgangspunkt, og vedligehold et dataflow, der viser, hvor referencen og afledte identifikatorer forekommer.

1. Kerneapp: Profil, sager, bookinger, beskeder, vedhæftninger, kommentarer og historik.
2. Identitet: Loginleverandør, invitationer, sessioner og eventuelle organisationstilknytninger.
3. Drift: Logs, revisionsspor, fejlrapportering, søgeindeks, cache og analyseværktøjer.
4. Integrationer: CRM, email, betaling, support, filarkiv og andre modtagere.
5. Kopier: Eksporter, midlertidige filer, testdata og backup med hver sin håndtering.

Søg bredt, men udlever ikke bredt. Fundlisten er internt arbejdsgrundlag. Det færdige svar skal vurderes for oplysninger om andre personer, fortrolige forhold og det konkrete omfang af retten.

Byg et forståeligt indsigtsmateriale

Retten til indsigt er mere end at sende de felter, personen selv kan se på profilsiden. Den omfatter en kopi af de personoplysninger, der behandles, og oplysninger om blandt andet formål, kategorier, modtagere, opbevaring og datakilde, når det er relevant. Ved en elektronisk anmodning skal materialet som udgangspunkt leveres elektronisk i en almindeligt anvendt form, medmindre personen beder om noget andet.

Brug faste, menneskelige feltnavne og forklar interne koder, statustekster og datoer.
Adskil personens oplysninger fra intern systemstøj, som ikke gør svaret mere forståeligt.
Fjern eller afgræns oplysninger, der krænker andres rettigheder og frihedsrettigheder.
Lever gennem en sikker kanal, og lad downloadlinks være kortlivede og bundet til den rette modtager.
Kontrollér den færdige pakke manuelt med samme omhu som en følsom dataeksport.

Dataportabilitet har egne betingelser og er ikke bare et andet navn for indsigt. Lov derfor ikke automatisk, at ethvert indsigtsudtræk kan importeres direkte i et andet system.

Ret, begræns eller slet gennem hele datakæden

Når vurderingen er godkendt, skal beslutningen omsættes til konkrete handlinger pr. datakilde. Brug en plan, der skelner mellem sletning, rettelse, anonymisering, begrænsning og lovlig fortsat opbevaring. Undgå én bred databasekommando, som også kan ødelægge regnskabsdata, revisionsspor eller andre personers poster.

Primære data: Ret eller fjern de godkendte felter og dokumentér antal berørte poster.
Filer og indeks: Håndtér original, miniature, søgeindeks, cache og midlertidige kopier.
Modtagere: Underret relevante modtagere om rettelse, sletning eller begrænsning, hvor reglerne kræver det.
Backup: Slet enkeltdata, hvor det er teknisk muligt, eller sørg for at slettede data ikke genopstår ved restore.

Hvis data ikke slettes, skal årsag, omfang og fortsat beskyttelse fremgå af beslutningen. En skjult række, en deaktiveret konto eller et felt som deleted: true er ikke i sig selv reel sletning.

Verificér resultatet som en bruger og som systemejer

Kør de samme søgninger efter udførelsen, og kontrollér de systemer, der skulle ændres. Test også at en gendannelse, genindeksering eller synkronisering ikke genopretter de gamle data. Ved rettelse skal I undersøge, om en integration straks skriver den forkerte værdi tilbage.

Teknisk bevis: Resultat pr. datakilde, antal poster, fejl og genkørsel.
Menneskelig kontrol: Gennemgå indsigtsfil eller restdata for andre personer og forståelighed.
Sikkert svar: Fortæl hvad der er gjort, eller hvorfor noget ikke er gjort, uden at afsløre interne sikkerhedsdetaljer.
Minimal sagslog: Bevar kun det nødvendige bevis og giv også denne log en ejer og slettefrist.

Typiske fejl

Kun profilskærmen undersøges: Logs, filer, sager og leverandører bliver glemt.
Alle anmodninger bliver til samme eksport: Indsigt, portabilitet, rettelse og sletning blandes sammen.
Identitet antages ud fra email: Følsomme oplysninger sendes til en kompromitteret eller forkert konto.
Slet alt bruges som genvej: Retlige undtagelser, relationer og andre personers data bliver ikke vurderet.
Backup overses: Slettede data vender tilbage ved en senere gendannelse.
Sagen lukkes ved jobstart: Ingen kontrollerer fejl, restdata eller leverandørens resultat.
Sagsloggen bliver et nyt personregister: ID-kopier, hele eksporten og følsom korrespondance gemmes uden plan.

Tjekliste til en GDPR-anmodning

☐ Modtagelsesdato, kontaktvej, omfang, ansvarlig og svarfrist er registreret.
☐ Det er afklaret, hvilken rettighed eller kombination af rettigheder personen bruger.
☐ Identiteten er bekræftet med en kontrol, der passer til risikoen.
☐ Interne id'er og alle relevante datakilder, filer, logs og integrationer er kortlagt.
☐ Fund om andre personer og fortrolige forhold er vurderet før udlevering.
☐ Sletning, rettelse, begrænsning og fortsat opbevaring er besluttet pr. datakilde.
☐ Relevante modtagere og databehandlere er med i planen.
☐ Backup og risikoen for genopståede data ved restore er håndteret.
☐ Den færdige eksport eller ændring er kontrolleret – ikke kun startet.
☐ Personen har fået et forståeligt og sikkert svar inden fristen.
☐ Sagsloggen indeholder kun nødvendigt bevis og har sin egen slettefrist.
☐ Processen er øvet med testdata, før den bruges under tidspres.

Relaterede guides

GDPR, persondata og ansvar i appen Dataretention og automatiske slettefrister Sikre slette- og massehandlinger Dataeksport og exit-plan ved leverandørskifte Backup og gendannelse Se hele guidebiblioteket

Officielle kilder

Frister, rettigheder og undtagelser skal vurderes efter den konkrete behandling. Kilderne her er Datatilsynets aktuelle vejledning, selve databeskyttelsesforordningen og EDPB's endelige retningslinjer om retten til indsigt.