Data og personoplysninger

Dataretention og automatiske slettefrister i en app

En app kan fungere perfekt og samtidig gemme gamle kunder, kladder, filer, logs og eksporter uden ende. En brugbar slettepolitik kobler derfor hvert datasæt til et formål, en konkret starthændelse, en handling og en teknisk kontrol. Ellers bliver “vi sletter løbende” blot en hensigt, som ingen kan afprøve.

Udgivet 18. september 2026 · Ca. 11 minutters læsetid

En slettefrist er en forretningsregel, ikke ét tal

Databeskyttelsesforordningens princip om opbevaringsbegrænsning siger, at personoplysninger ikke må kunne henføres til personer længere end nødvendigt for formålet. Datatilsynet understreger tilsvarende, at den dataansvarlige selv skal vurdere, hvornår oplysninger ikke længere er nødvendige og derfor som udgangspunkt skal slettes eller anonymiseres. Det giver ikke én fælles frist til alle data.

Beslutningen skal kunne forklares for hvert datasæt. Lovkrav, aftaler, tvister og dokumentationsbehov kan påvirke vurderingen, så få juridisk hjælp, når grundlaget er uklart. Appens udvikler bør ikke opfinde en frist ud fra, hvad der er nemmest at kode.

Datasæt	Fristen kan begynde ved	Beslutning der mangler
Uafsluttet kladde	Seneste reelle brugeraktivitet	Skal den slettes, varsles eller kunne gendannes kortvarigt?
Afsluttet sag	Sagens afslutning eller aftalens ophør	Hvilke dele skal bevares, og hvilke kan fjernes?
Uploadet fil	Tilknyttet sags udløb eller filens eget formål	Findes der kopier, previews eller tidligere versioner?
Teknisk log	Hændelsens tidspunkt	Hvor længe er detaljen nødvendig for drift og sikkerhed?
Brugerkonto	Lukning, fratrædelse eller inaktivitet efter den valgte regel	Hvad skal fjernes, og hvad skal bevares uden aktiv adgang?

Kortlæg alle kopier – ikke kun hovedtabellen

En post kan være væk fra appens skærmbillede og stadig ligge mange steder. Tegn dataflowet fra indsamling til den sidste kopi, og angiv ejer og slettefunktion for hvert sted. Kortlægningen skal passe til den stack, appen faktisk bruger.

Database: Primære rækker eller dokumenter, relationer, historiktabeller, søgeindeks og cache.
Filer: Originaler, thumbnails, previews, konverterede PDF'er, tidligere versioner og papirkurv.
Drift: Applikationslogs, fejlsystemer, analyseværktøjer, køer, midlertidige filer og jobhistorik.
Integrationer: CRM, mailudbyder, AI-tjeneste, regnskab, webhooks og andre modtagere.
Menneskelige kopier: CSV-eksporter, regneark, emailvedhæftninger, supportudtræk og lokale downloads.
Miljøer og backup: Testkopier, snapshots, databasebackup og replikaer med egne opbevaringsperioder.

Vælg den rigtige sluttilstand

“Slet” kan betyde flere forskellige ting i en app. Skriv den forventede sluttilstand ned, så udvikler, ejer og revisor ikke lægger hver sin betydning i ordet.

Permanent sletning: Data kan ikke længere læses gennem appen eller genskabes gennem den normale drift.
Anonymisering: Forbindelsen til personen fjernes reelt og varigt, mens nødvendige, ikke-personhenførbare tal kan bevares.
Begrænset opbevaring: Data bevares af et konkret behov, men almindelig brug stoppes, og adgang og formål indsnævres.
Midlertidig papirkurv: Data skjules og kan gendannes i et kort, besluttet vindue, hvorefter den permanente handling gennemføres.

Et nyt tilfældigt id er ikke nødvendigvis anonymisering. EDPB skelner mellem anonymisering, hvor data ikke længere kan knyttes til en person, og pseudonymisering, hvor forbindelsen stadig kan genetableres. Pseudonymiserede data er fortsat personoplysninger.

Gør fristen synlig i datamodellen

En robust løsning beregner en konkret udløbsdato på serveren, når den relevante forretningshændelse sker. Et felt som retention_due_at ellerexpires_at gør det muligt at søge, teste og overvåge kommende sletninger. Gem også hvilken regel der beregnede datoen, så en senere politikændring kan håndteres bevidst.

Brug en stabil starthændelse: “Sag afsluttet” er tydeligere end “post senest ændret”, som kan skubbes frem af en teknisk opdatering.
Lad serveren beregne datoen: Browseren må ikke kunne forlænge eller forkorte opbevaringen ved at sende et andet timestamp.
Modellér godkendte undtagelser: En pause skal have grund, ejer og revurderingsdato – ikke et permanent boolean-felt uden forklaring.
Indeksér efter behov: Jobbet skal kunne finde forfaldne poster uden at læse hele databasen hver nat.

Kør sletning som et kontrolleret driftsjob

Automatikken skal kunne køres igen efter en fejl uden at slette for meget eller gå i stå på den samme post. Behandl derfor sletning som et overvåget job med afgrænset omfang frem for en stor, skjult databasekommando.

Find kandidater: Vælg kun poster, hvor udløbsdato, status og eventuelle pauser er kontrolleret på serveren.
Behandl i batches: Sæt et loft pr. kørsel, så fejl, låse og belastning kan begrænses og observeres.
Følg relationerne: Fjern eller anonymisér afhængige poster, filer, søgeindeks og leverandørkopier efter en dokumenteret plan.
Tål gentagelse: En ny kørsel efter timeout skal kunne fortsætte uden at skabe inkonsistente data eller fejle på allerede slettede objekter.
Registrér resultatet: Gem politik, antal, tidsrum, job-id og fejl – men ikke en ny kopi af det indhold, der netop skulle væk.
Alarmér på stilstand: Et job, der ikke har kørt eller har efterladt forfaldne data, skal opdages som en driftsfejl.

Soft delete er et sikkerhedsnet, ikke slutningen

Et felt som deleted_at kan give ro ved fejlbetjening, men data ligger stadig i databasen og kan ofte læses af administratorer, jobs eller fejlbehæftet kode. Aftal derfor et afgrænset gendannelsesvindue, begræns adgangen i perioden, og lad et separat job udføre den permanente handling. Kontroller også filer, versionshistorik og cache; de følger ikke automatisk en databaseposts soft delete.

Brug platformens funktioner uden at overlade politikken til platformen

Den tekniske mekanisme afhænger af datalageret. Platformen kan udføre dele af arbejdet, men virksomheden skal stadig definere formål, frist, undtagelser og bevis.

Platform	Mulig mekanisme	Vigtig begrænsning
Cloud Firestore	TTL-felt på en collection group	Sletning er ikke øjeblikkelig eller transaktionel, og underkollektioner slettes ikke sammen med dokumentet.
Azure Blob Storage	Lifecycle policy efter alder, sti eller blob-tag	Aktiv soft delete betyder, at lifecycle-sletningen først lægger blobben i den soft-slettede tilstand.
Supabase/PostgreSQL	Planlagt databasefunktion eller Edge Function via Supabase Cron	Jobbet skal selv håndtere relationer, batches, rettigheder, fejl og overvågning.
Anden stack	Leverandørens TTL, lifecycle eller et planlagt backendjob	Kontrollér den aktuelle dokumentation for timing, omfang, pris, logning og gendannelse.

Firestore oplyser blandt andet, at TTL-sletning typisk sker inden for 24 timer efter udløb, og at den kan aktivere listeners og Cloud Functions-triggers. Brug derfor ikke TTL alene, hvis flere ressourcer skal ændres samlet på et præcist tidspunkt.

Aftal hvad der sker i backup og hos modtagere

Datatilsynets materiale om retten til sletning peger på, at oplysninger også skal fjernes fra backup, hvis det er muligt, og at modtagere skal orienteres, når det er relevant. Den konkrete løsning afhænger af backupteknikken: Nogle systemer tillader ikke sletning af én post i en uforanderlig backup uden at ødelægge kopiens formål.

Dokumentér backupens opbevaringsperiode, adgang og naturlige udløb særskilt fra produktionsdata.
Hvis en ældre backup gendannes, skal aktive slettekrav og udløbsdatoer anvendes igen, før løsningen åbnes normalt.
Før en liste over integrationer og databehandlere, så sletning eller besked ikke stopper ved jeres egen database.
Sørg for, at supporteksporter og lokale kopier har en ejer og en kort, aftalt levetid.

Afprøv politikken uden at satse produktionen

En ny slettepolitik kan ramme mange eksisterende poster med det samme. Firestore advarer eksempelvis om, at en ny TTL-politik gør allerede udløbne dokumenter berettigede til massesletning. Start derfor med en rapport, der kun tæller og viser repræsentative kandidater, og få dataejeren til at godkende logikken.

Kør samme regel på realistiske testdata med relationer, filer, pauser og allerede slettede poster.
Sæt et lavt maksimum pr. kørsel ved den indledende aktivering, og kontrollér resultatet mellem batches.
Test at forkert status, fremtidig dato, aktiv pause og anden virksomhed ikke bliver ramt.
Afbryd jobbet midt i en batch, og bekræft at en genkørsel fortsætter sikkert.
Kontrollér efterfølgende database, filer, indeks, integrationer, jobhistorik og målingen af resterende forfaldne data.

Typiske fejl

Én frist til alt: Kundeprofiler, sikkerhedslogs, fakturagrundlag og kladder har forskellige formål og risici.
Kun skærmbilledet ryddes: Rækken, filen, historikken eller leverandørkopien findes stadig.
Senest ændret styrer alt: En baggrundsopdatering forlænger opbevaringen uden et nyt forretningsbehov.
Soft delete kaldes sletning: Data ligger fortsat læsbart uden et job til endelig fjernelse.
Anonymisering kan rulles tilbage: Identiteten er blot flyttet til en anden tabel eller nøgle.
Jobbet er usynligt: Ingen opdager, at cron, TTL eller lifecycle-reglen er stoppet eller fejler delvist.
Sletningsloggen kopierer indholdet: Revisionssporet genskaber de persondata, der skulle fjernes.

Tjekliste til dataretention i appen

☐ Hvert relevant datasæt har formål, ejer, starthændelse, frist og sluttilstand.
☐ Frister er vurderet ud fra behov og krav – ikke valgt som ét bekvemt standardtal.
☐ Database, filer, logs, indeks, integrationer, eksporter, testmiljøer og backup er kortlagt.
☐ Sletning, anonymisering, begrænset opbevaring og midlertidig papirkurv er adskilt.
☐ Udløbsdato og eventuelle pauser beregnes og kontrolleres på serveren.
☐ Jobbet bruger afgrænsede batches, kan genkøres og følger afhængige data.
☐ Platformens TTL-, lifecycle- eller cron-begrænsninger er verificeret i aktuel dokumentation.
☐ En rapport eller dry run er godkendt, før en ny politik får lov at slette eksisterende data.
☐ Målinger og alarmer viser seneste kørsel, fejl og resterende forfaldne poster.
☐ Backupgendannelse og eksterne modtagere indgår i sletteprocessen.
☐ Revisionssporet dokumenterer udførelsen uden at bevare det slettede indhold.

Relaterede guides

GDPR, dataflow og ansvar for personoplysninger Sikre slette- og massehandlinger for brugere Backup og afprøvet gendannelse Logning, overvågning og alarmer Baggrundsjob, retries og jobstatus

Officielle kilder

Regler og platformfunktioner ændrer sig. Brug kilderne til at kontrollere den konkrete politik og den aktuelle funktion i jeres valgte stack.

Skal slettepolitikken virke i den app, I allerede har?

Startklar gennemgår den eksisterende datamodel, platform og drift og hjælper med at omsætte jeres slettefrister til afgrænsede jobs, kontroller og dokumentation, før medarbejdere eller kunder bliver afhængige af løsningen.

Se Startklar-forløbet