Persondata og leverandører

Databehandlere i appen: få styr på aftaler og hele leverandørkæden

En fungerende app kan sende personoplysninger gennem hosting, database, login, mail, fejlovervågning og AI-tjenester. I skal vide, hvem der behandler hvilke data, hvor det sker, hvad leverandøren må gøre, og hvordan ændringer bliver opdaget. En underskrevet standardaftale er ikke i sig selv et driftsklart overblik.

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

Databehandleraftalen skal passe til det faktiske dataflow

Virksomheden er typisk dataansvarlig, når den bestemmer, hvorfor kunders eller medarbejderes oplysninger behandles og de væsentlige rammer for behandlingen. En leverandør er databehandler, når den behandler oplysninger på virksomhedens vegne og efter dens dokumenterede instruks. Den faktiske rolle afgør kravet – ikke navnet i leverandørens salgsmateriale.

Relation	Praktisk tegn	Det skal afklares
Databehandler	Driver database, hosting, mail eller support efter jeres formål	Instruks, databehandleraftale, sikkerhed, sletning og tilsyn
Underdatabehandler	Hjælper jeres databehandler med den aftalte behandling	Godkendelse, opgave, lokation, garantier og ændringsvarsel
Selvstændig dataansvarlig	Bestemmer selv formål og væsentlige midler	Lovligt grundlag for videregivelse, information og ansvar

Samme leverandør kan have forskellige roller for forskellige funktioner. Hvis rollen er uklar, bør den afklares ud fra den konkrete behandling og ved behov med juridisk rådgivning, før rigtige personoplysninger sendes videre.

Find leverandørerne i appen – ikke kun i bogholderiet

Start med appens virkelige forbindelser. En fakturaoversigt overser ofte gratis tjenester, plugins og API'er, mens kode alene kan overse supportadgang og manuelle eksporter.

1. Tegn dataflowet. Følg et realistisk kundekort, dokument eller login fra indtastning til database, filer, logs, mails, analyse, backup og eventuelle AI-kald.
2. Gennemgå de tekniske spor. Se cloudprojekter, integrationsopsætning, miljøvariablers navne uden at kopiere værdierne, pakker med eksterne tjenester og netværkskald fra backend.
3. Find de manuelle kopier. Medtag supportudtræk, regneark, fejlrapporter, lokale downloads og data, der indsættes i en leverandørs portal.
4. Sammenhold med aftaler og konti. Kontrollér fakturaer, administratorportaler, databehandleraftaler og de leverandørkonti, som faktisk ejer ressourcerne.

Lav ét vedligeholdt leverandørregister

Registrér tjeneste, ejer internt, funktion, datatyper, registrerede personer, rolle, databehandleraftale, underdatabehandlere, behandlingssteder, eventuelle overførselsgrundlag, slettevej, sikkerhedsdokumentation, seneste kontrol og opsigelsesplan. Link til dokumenterne i stedet for at gemme tilfældige kopier flere steder.

Kontrollér aftalen som en teknisk instruks

GDPR artikel 28 kræver en skriftlig og bindende aftale med bestemte oplysninger og forpligtelser. Den skal blandt andet beskrive behandlingens genstand, varighed, karakter og formål, datatyper, kategorier af personer samt den dataansvarliges rettigheder og pligter. Datatilsynet stiller en skabelon til rådighed, men indholdet skal stadig udfyldes, så det passer til jeres løsning.

Instruksen matcher funktionen: Aftalen siger ikke blot “levere IT”, men dækker de konkrete handlinger som lagring, udsendelse, support, backup og sletning.
Sikkerheden kan vurderes: Adgang, kryptering, logning, backup, hændelser og assistance er beskrevet eller understøttet af aktuel dokumentation.
Rettigheder kan gennemføres: Leverandøren kan hjælpe med indsigt, rettelse, sletning og begrænsning inden for jeres proces og frister.
Afslutningen er anvendelig: Det fremgår, hvordan data returneres eller slettes, hvad der sker med backup, og hvornår adgang og integrationer lukkes.
Beviser kan udleveres: I kan få de oplysninger og den mulighed for kontrol, der er nødvendig for at vurdere, om behandlingen følger aftalen.

Underdatabehandlere kræver et aktivt overblik

En databehandler må kun bruge en anden databehandler efter forudgående specifik eller generel skriftlig godkendelse. Ved generel godkendelse skal leverandøren varsle planlagte tilføjelser eller udskiftninger, så I får reel mulighed for at gøre indsigelse. De samme databeskyttelsesforpligtelser skal føres videre i kæden.

Datatilsynets afgørelse fra januar 2026 understreger, at den dataansvarlige skal vide, hvilke underdatabehandlere der bruges. Listen kan ligge i et bilag eller et andet dokument, som aftalen henviser til, men den skal være retvisende, vedvarende tilgængelig og ajourført. Et link til en flydende liste uden løbende inddragelse er derfor ikke et sikkert ændringsflow.

Ved godkendelse

Kend juridisk navn, opgave, datatyper, behandlingssted og dokumenterede garantier. Gem beslutning, dato og ansvarlig.

Ved ændring

Få et aktivt varsel, en rimelig vurderingsperiode, en intern modtager og en besluttet vej for accept, indsigelse eller udfasning.

En EU-region fortæller ikke hele historien

Registrér alle steder, hvor personoplysninger kan behandles – også supportadgang, drift, logs og underdatabehandlere. En valgt database-region i EU beviser ikke alene, at hele leverandørkæden er afgrænset til EU/EØS.

Skeln mellem hvor data lagres, hvorfra nogen kan tilgå dem, og hvor kopier eller backups behandles.
Få tilsigtede overførsler og det relevante overførselsgrundlag tydeligt ind i aftalegrundlaget og registeret.
Vurder nye supportlande, underdatabehandlere og funktioner som ændringer i behandlingen – ikke som en almindelig produktnyhed.
Få konkret databeskyttelsesrådgivning, når kæden omfatter tredjelande eller uklare fjernadgange; en databehandleraftale erstatter ikke kravene til internationale overførsler.

Før tilsyn efter risiko – og gem konklusionen

Den dataansvarlige skal vælge leverandører med tilstrækkelige garantier og føre et passende tilsyn. Datatilsynets model er risikobaseret: større konsekvens og større omfang kræver normalt stærkere og hyppigere kontrol. Det er ikke nødvendigt at udføre samme kontrol af en lille mailtjeneste og en central platform med følsomme oplysninger.

Prioritér. Vurder datatyper, antal personer, kritisk funktion, adgangsmuligheder, behandlingssteder og hvor svært et leverandørskifte vil være.
Indhent relevante beviser. Det kan være leverandørens besvarelse, sikkerhedsbeskrivelse, uafhængig erklæring, certificering, revisionsrapport, hændelseshistorik eller en målrettet audit.
Læs konklusionen og omfanget. Et certifikat eller en rapport hjælper kun, hvis den dækker den tjeneste, periode og kontrol, som jeres behandling afhænger af.
Følg op. Registrér fund, accepteret restrisiko, ansvarlig, frist og næste kontrol. Kritiske mangler kræver en plan, begrænsning eller anden leverandør.

EDPB fremhæver, at I kan støtte jer til oplysninger fra databehandleren, når de faktisk dokumenterer efterlevelse. Hvis oplysningerne er ufuldstændige, uklare eller ikke passer til risikoen, skal I bede om mere eller kontrollere dem nærmere.

Gør leverandørændringer til en driftsproces

Overblikket bliver hurtigt forældet, hvis det kun opdateres ved den årlige GDPR-gennemgang. Knyt derfor kontrollen til de hændelser, der faktisk ændrer appen.

Ny integration eller AI-funktion: Ingen produktionsdata før rolle, datatyper, aftale, lokation og slettevej er registreret.
Varsel fra leverandør: Send ændringen til en navngiven ejer, vurder konsekvensen og gem beslutningen før indsigelsesfristen.
Sikkerhedshændelse: Brug registeret til hurtigt at finde berørte data, kontakter, aftalevilkår, underleverandører og mulige overførsler.
Opsigelse eller erstatning: Eksportér nødvendige data, stop integrationer og tokens, få sletning bekræftet, og opdatér dokumentation og information til brugerne.

Typiske fejl

Kun hostingfirmaet står i registeret: Login, mail, overvågning, AI og manuelle supportværktøjer er usynlige.
Standardaftalen er gemt, men ikke læst: Instruks, datatyper eller sletning passer ikke til den funktion, appen faktisk bruger.
En dynamisk underleverandørliste regnes som godkendelse: Ingen modtager ændringsvarsler eller kan nå at vurdere dem.
“Data ligger i EU” afslutter vurderingen: Support, logs eller underdatabehandlere kan stadig behandle oplysninger andre steder.
Et logo bliver til et sikkerhedsbevis: Certificeringens omfang, udløb, undtagelser og konkrete tjeneste er ikke kontrolleret.
Aftalen har ingen teknisk ejer: Jura, kode, cloudopsætning og den faktiske leverandørkæde glider fra hinanden.

Tjekliste til databehandlere omkring appen

☐ Appens dataflow omfatter database, filer, login, mail, logs, backup, analyse, AI, support og manuelle kopier.
☐ Hver ekstern part har en vurderet rolle for den konkrete behandling.
☐ Leverandørregisteret har intern ejer, datatyper, formål, aftalelink, lokation, slettevej og seneste kontrol.
☐ Databehandleraftalen og instrukserne matcher den funktion og de data, som appen faktisk bruger.
☐ Alle relevante underdatabehandlere, opgaver og behandlingssteder er kendt og dokumenteret.
☐ Ændringsvarsler går til en aktiv postkasse og en navngiven person med tid og vej til at reagere.
☐ Eventuelle tredjelandsoverførsler og deres grundlag er vurderet særskilt.
☐ Tilsynets metode og hyppighed følger risikoen, og beviserne dækker den konkrete tjeneste.
☐ Fund, accepteret restrisiko, opfølgning og næste kontroldato er gemt.
☐ Opsigelse, eksport, adgangslukning og sletning kan gennemføres uden at gætte.

Relaterede guides

GDPR, dataflow og ansvar for personoplysninger Indsigt, rettelse og sletning på tværs af leverandører Dataeksport og exit-plan ved leverandørskifte Driftsberedskab ved nedbrud og sikkerhedshændelser

Officielle kilder

Roller, aftaler, tilsyn og overførsler afhænger af den konkrete behandling. Kilderne her er Datatilsynets vejledninger og afgørelse, selve databeskyttelsesforordningen samt EDPB's udtalelse om databehandlerkæder.