Persondata og dokumentation

Behandlingsfortegnelse til en app: skab overblik over persondata

En app kan virke fint og stadig mangle et samlet svar på, hvilke personoplysninger den bruger, hvorfor de er nødvendige, hvem der modtager dem, og hvornår de slettes. En behandlingsfortegnelse gør de svar konkrete og forbinder juraen med appens faktiske database, filer, login, logs og leverandører.

Udgivet 21. oktober 2026 · Ca. 11 minutters læsetid

Det korte svar

Beskriv appens behandling som en eller flere forståelige aktiviteter – for eksempel kundesagsbehandling, booking eller medarbejderadministration. Notér for hver aktivitet den ansvarlige virksomhed, formål, berørte persongrupper, datakategorier, modtagere, eventuelle tredjelandsoverførsler, forventede slettefrister og en overordnet beskrivelse af sikkerheden. Hold fortegnelsen skriftlig, tilgængelig og opdateret, når appen ændres.

Fortegnelsen er ikke en eksport af alle databasefelter. Den er et driftsnært overblik over behandlingsaktiviteter. Den skal være konkret nok til, at en anden kan forstå dataflowet og kontrollere, om appen gør det, I beskriver.

Afklar først virksomhedens rolle

Indholdet afhænger af, om virksomheden bestemmer hvorfor og hvordan personoplysninger behandles, eller behandler dem på vegne af en kunde. GDPR artikel 30 har forskellige fortegnelseskrav til dataansvarlige og databehandlere.

Dataansvarlig: Virksomheden bestemmer formål og væsentlige midler. Det kan være en virksomhed, der bruger sin egen app til kunder, bookinger eller medarbejdere.
Databehandler: Virksomheden behandler oplysninger efter en kundes dokumenterede instruks. En SaaS-leverandør kan have denne rolle for kundens data.

Den samme virksomhed kan være dataansvarlig for egne bruger- og faktureringsoplysninger og databehandler for indhold, kunderne lægger i appen. Beskriv rollerne særskilt i stedet for at kalde hele løsningen én ting. Få databeskyttelsesfaglig rådgivning, hvis rollefordelingen er uklar.

Beskriv aktiviteter – ikke hver tabel

En behandlingsaktivitet bør følge et forretningsformål, som en kollega kan genkende. Hvis alt samles i “drift af app”, bliver fortegnelsen for grov. Hvis hver databasekolonne får sin egen række, bliver den umulig at vedligeholde.

Aktivitet	Formål	Typiske systemdele
Brugeradministration	Oprette konto, login og styre adgang	Auth-udbyder, brugerprofil, roller og sessionslog
Kundesagsbehandling	Levere og dokumentere den aftalte ydelse	Database, filer, noter, emails og historik
Support og fejlsøgning	Besvare henvendelser og rette driftsfejl	Supportsystem, logs, skærmbilleder og midlertidig adgang
Fakturering	Opkræve betaling og føre regnskab	Betalingsudbyder, økonomisystem og fakturaarkiv

Opdel aktiviteter, når formål, persongrupper, slettefrist eller modtagere reelt er forskellige. Genbrug ikke automatisk én beskrivelse på tværs af hele virksomheden.

Udfyld de oplysninger artikel 30 kræver

For en dataansvarlig angiver artikel 30 en række oplysninger, som fortegnelsen skal rumme. Brug Datatilsynets aktuelle vejledning til den konkrete vurdering.

1. Kontakt og ansvar: Navn og kontaktoplysninger på den dataansvarlige samt relevante fælles dataansvarlige, repræsentant og databeskyttelsesrådgiver.
2. Formål: Skriv hvorfor aktiviteten behandler personoplysninger. “Fordi systemet gemmer dem” er ikke et formål.
3. Registrerede og oplysninger: Forbind persongrupper som kunder, medarbejdere eller kontaktpersoner med de konkrete kategorier af oplysninger om dem.
4. Modtagere: Beskriv kategorier af interne og eksterne modtagere, herunder relevante leverandører og andre virksomheder.
5. Overførsler: Angiv relevante overførsler til tredjelande eller internationale organisationer og den dokumentation, som reglen kræver.
6. Slettefrister: Angiv, hvor det er muligt, forventede frister for de forskellige datakategorier – ikke blot “slettes efter behov”.
7. Sikkerhed: Beskriv overordnet de relevante tekniske og organisatoriske foranstaltninger, for eksempel adgangsstyring, backup, logning og hændelseshåndtering.

En databehandlers fortegnelse har et andet indhold efter artikel 30, stk. 2, blandt andet kunderne, kategorierne af behandlinger, overførsler og den overordnede sikkerhed. Brug den korrekte del af vejledningen frem for at kopiere kundens fortegnelse.

Antag ikke at en lille virksomhed er undtaget

Den gældende undtagelse i artikel 30, stk. 5 for virksomheder og organisationer med under 250 personer er snæver. Datatilsynets vejledning forklarer, at en aktivitet ikke er undtaget, hvis behandlingen ikke er lejlighedsvis, sandsynligvis indebærer risiko for personers rettigheder og frihedsrettigheder eller omfatter særlige kategorier af oplysninger eller oplysninger om strafbare forhold.

En app i daglig brug behandler ofte oplysninger løbende. Brug derfor ikke virksomhedens størrelse som eneste begrundelse for at springe fortegnelsen over. Dokumentér vurderingen, og kontrollér den mod den aktuelle regel og vejledning. Dette er en praktisk arbejdsramme, ikke juridisk rådgivning.

Find fakta i den virkelige løsning

Et interview er et godt udgangspunkt, men appens kode og platforme viser ofte dataflow, som ingen husker. Sammenhold forklaringerne med de steder, hvor oplysninger faktisk opstår, flyttes og slettes.

Brugerflader og API: Hvilke felter, uploads og fritekster kan brugere sende ind?
Database og filer: Hvilke samlinger, tabeller, objekter, historikfelter og soft-slettede poster findes?
Login og rettigheder: Hvilke identitetsoplysninger, roller, sessionsdata og adgangslogs behandles?
Integrationer: Hvad sendes til email, betaling, analyse, AI-tjenester, CRM og andre API'er?
Drift: Indeholder logs, alarmer, backups, supporttickets eller testmiljøer kopier af personoplysninger?

Gem ikke adgangskoder, API-nøgler eller detaljer, der gør et angreb lettere, i selve fortegnelsen. Beskriv kontroltypen og henvis til den beskyttede driftsdokumentation.

Gør fortegnelsen brugbar i driften

Artikel 30 angiver minimumsoplysninger. Et par tydeligt markerede arbejdsfelter kan gøre dokumentet lettere at holde sandt: intern ejer, seneste kontrol, næste kontrol, systemhenvisning, behandlingsgrundlag og links til den relevante sletteprocedure, databehandleraftale eller risikovurdering. De ekstra felter skal ikke forveksles med selve minimumskravene.

Forbind hver slettefrist med det konkrete job eller den manuelle procedure, der gennemfører den.
Forbind hver modtagerkategori med leverandøroversigten og den relevante aftale.
Forbind sikkerhedsbeskrivelsen med faktiske kontroller, tests og ejere – ikke kun ord som “krypteret” eller “sikkert”.
Brug fortegnelsen, når I svarer på indsigtsanmodninger, vurderer en hændelse eller ændrer privatlivsinformationen.

Opdatér ved ændringer – ikke kun én gang om året

Fortegnelsen skal afspejle den aktuelle behandling og kunne stilles til rådighed for tilsynsmyndigheden efter anmodning. Lad derfor ændringer i dataflowet udløse en lille dokumentationsopgave i samme arbejdsgang som koden og leverandøraftalen.

Ny funktion indsamler en ny type personoplysning eller bruger data til et nyt formål.
Ny integration, AI-tjeneste, analyseplatform eller supportleverandør modtager oplysninger.
Slettefrist, backupmodel, logning, adgang eller dataregion ændres.
Appen åbnes for en ny persongruppe, kunde eller et nyt marked.
En hændelse eller brugerhenvendelse viser, at det beskrevne dataflow ikke passer.

Sæt også en fast kontrol, eksempelvis kvartalsvis eller efter virksomhedens risiko og ændringstempo. En navngiven ejer og en dato er mere værd end “IT holder den opdateret”.

Typiske fejl

Skabelonen bliver sandheden: Dokumentet beskriver en standardapp, men ingen har kontrolleret database, logs, backups og integrationer.
Alt hedder “administration”: Formål, persongrupper, modtagere og slettefrister kan ikke vurderes hver for sig.
Kun hoveddatabasen tælles med: Loginudbyder, filer, support, email, AI-tjenester og overvågning forsvinder fra overblikket.
Slettefristen er et ønske: Ingen har vist, at databasen, filerne, logs og leverandørkopier faktisk følger den.
Fortegnelse og privatlivstekst blandes sammen: Det interne arbejdsdokument og informationen til personer har forskellige målgrupper og indhold.
Dokumentet indeholder secrets: Det bliver enten farligt at dele eller så låst, at ingen vedligeholder det.
Ingen ejer ændringerne: Appen får nye felter og leverandører, mens fortegnelsen bliver stående som et øjebliksbillede.

Tjekliste til en brugbar behandlingsfortegnelse

☐ Rollen som dataansvarlig, databehandler eller begge dele er afklaret pr. aktivitet.
☐ Aktiviteterne følger forståelige formål frem for tabeller eller et samlet “appdrift”.
☐ Persongrupper er tydeligt forbundet med de datakategorier, der behandles om dem.
☐ Modtagere, leverandører og relevante tredjelandsoverførsler er kontrolleret mod det faktiske dataflow.
☐ Slettefrister er konkrete og forbundet med en afprøvet teknisk eller manuel proces.
☐ Sikkerhedsforanstaltninger er beskrevet overordnet og peger på beskyttet dokumentation og tests.
☐ Database, filer, login, logs, backups, support og integrationer er gennemgået.
☐ Vurderingen af en eventuel undtagelse er dokumenteret mod den aktuelle artikel 30 og Datatilsynets vejledning.
☐ Fortegnelsen indeholder ingen secrets eller unødvendige personoplysninger.
☐ Hver aktivitet har en ejer, seneste kontroldato og en udløser for opdatering.

Officielle kilder

Guiden er kontrolleret mod Datatilsynets aktuelle fortegnelsesvejledning, materiale til små virksomheder, skabelonside og den gældende tekst i GDPR artikel 30.

Relaterede guides

Når dokumentet og appen ikke passer sammen

Startklar hjælper med at gennemgå dataflow, leverandører, sletning og sikkerhed i den løsning, I allerede har bygget, så dokumentationen peger på konkrete tekniske handlinger frem for generelle formuleringer.

Se Startklar til AI-byggede apps