Databehandleraftale skytjeneste: 12-punkts tjekliste til en GDPR-konform DPA
Databehandleraftale skytjeneste: 12 punkter du skal tjekke før underskrift. GDPR artikel 28-krav, gode svar og røde flag for hver.
Indholdsfortegnelse
- Hvorfor en god DPA er den vigtigste leverandørbeslutning
- GDPR artikel 28: hvad loven faktisk kræver
- 12-punkts tjekliste til DPA’en
- Røde flag der bør stoppe underskriften
- Ofte stillede spørgsmål om databehandleraftale skytjeneste
- Læs også
En databehandleraftale skytjeneste er ikke et formaldokument. Det er den kontrakt, der definerer hvad jeres leverandør må og ikke må gøre med jeres data, hvilket ansvar de bærer ved et brud, og hvor I står juridisk hvis Datatilsynet stiller spørgsmål. Alligevel underskriver mange danske virksomheder DPA’er uden at læse dem grundigt, fordi leverandøren præsenterer dem som standard.
Det er en dyr fejl. En mangelfuld DPA flytter risiko fra leverandøren til jer, og den kan udløse påbud fra Datatilsynet alene fordi aftalen ikke opfylder GDPR artikel 28. Denne artikel giver jer en 12-punkts tjekliste, hvor hvert punkt har det konkrete krav fra GDPR, hvad et godt svar lyder som, og hvilke røde flag der bør stoppe underskriften.
Skal I have styr på datasuverænitet og leverandørrisiko? Decree er dansk ejet, dansk hostet, og CLOUD Act-fri. Læs mere om vores sikkerhedstilgang eller se vores subprocessors.
Hvorfor en god DPA er den vigtigste leverandørbeslutning
Når jeres leverandør behandler persondata på jeres vegne, er det jer, der er dataansvarlige. Det betyder, at ansvaret for, at behandlingen er lovlig, ligger hos jer, ikke hos leverandøren. Hvis leverandøren laver en fejl, en sikkerhedsbrist, en ulovlig overførsel eller et brud på opbevaringskravene, kan Datatilsynet rette anklagen mod jer.
DPA’en er det værktøj, der skal sikre to ting: at leverandørens forpligtelser er klare og retskraftige, og at I kan dokumentere over for tilsynet, at I har gjort det, der med rimelighed kan forventes for at sikre lovlig behandling. En god DPA løser begge dele. En dårlig DPA løser ingen af dem.
I dansk praksis er DPA’en også det dokument, en NIS2-revisor først beder om. Hvis aftalen ikke opfylder artikel 28, har I et leverandørstyringsproblem, før revisoren overhovedet er begyndt at se på sikkerhedsforanstaltninger.
GDPR artikel 28: hvad loven faktisk kræver
GDPR artikel 28 er det centrale udgangspunkt. Den fastsætter en række minimumskrav, som enhver databehandleraftale skal indeholde. Stk. 3 lister otte konkrete forpligtelser, som leverandøren skal påtage sig kontraktuelt.
“Behandling foretaget af en databehandler skal være reguleret af en kontrakt eller andet retligt dokument i henhold til EU-retten eller medlemsstaternes nationale ret, der er bindende for databehandleren i forhold til den dataansvarlige…”
Det er ikke et “best practice”-katalog. Det er en lovkrav. Hvis aftalen ikke indeholder de obligatoriske elementer, er den ikke gyldig som DPA, uanset hvad den hedder eller hvor lang den er.
I praksis har vi udvidet listen til 12 punkter, fordi flere af artikel 28’s krav er sammensatte (for eksempel “tekniske og organisatoriske foranstaltninger” dækker både kryptering, adgangskontrol og audit-log).
12-punkts tjekliste til DPA’en
For hvert punkt: lovkravet, hvad et godt svar lyder som, og det røde flag der bør udløse forhandling eller leverandørskift.
1. Behandlingens formål, varighed og typer
Krav: Artikel 28 stk. 3 kræver, at aftalen specifikt beskriver behandlingens genstand, varighed, art og formål samt typen af persondata og kategorier af registrerede.
Godt svar: En klar beskrivelse, ofte i et bilag, der nævner konkret hvilke datatyper (navn, kontaktoplysninger, jobtitel, kommunikationsindhold) og hvilke registrerede (kunder, medarbejdere, leads).
Rødt flag: Generisk formulering som “alle data kunden uploader” uden specifikation.
2. Instruktion fra dataansvarlig
Krav: Leverandøren må kun behandle data efter dokumenterede instrukser fra jer.
Godt svar: Aftalen henviser til en konkret instruks (bilag, ordrebekræftelse) og kræver skriftlig godkendelse for behandling der falder uden for.
Rødt flag: Aftalen tillader leverandøren at “forbedre tjenesten” eller “anvende anonymiserede data til produktudvikling” uden jeres godkendelse.
3. Fortrolighedsforpligtelser for personale
Krav: Personale med adgang til data skal være underlagt fortrolighedsforpligtelser.
Godt svar: Bekræftelse af, at alle medarbejdere har underskrevet NDA, og at adgang er begrænset til “need-to-know”.
Rødt flag: Vag formulering uden konkret henvisning til personalehåndbog eller adgangskontrolproces.
4. Tekniske og organisatoriske foranstaltninger
Krav: Artikel 32 kræver et passende sikkerhedsniveau.
Godt svar: Et bilag med konkrete foranstaltninger: kryptering i hvile og under transport, MFA, audit-log, regelmæssige penetrationstest, certificering (ISO 27001, SOC 2).
Rødt flag: “Branchestandard sikkerhed” uden specifikation, eller manglende vilje til at vise certifikater.
5. Brug af underdatabehandlere
Krav: Underdatabehandlere kræver enten generel eller specifik forhåndsgodkendelse, og leverandøren skal informere om ændringer.
Godt svar: En åben subprocessor-liste online, varsel på 30+ dage før ændringer, ret for jer til at gøre indsigelse.
Rødt flag: Ingen liste tilgængelig, ret til at skifte uden varsel, eller subprocessor-listen indeholder US-ejede leverandører i kritiske roller. Tjek altid hvordan en god subprocessor-liste ser ud.
6. Bistand til de registreredes rettigheder
Krav: Leverandøren skal hjælpe jer med at besvare henvendelser om indsigt, sletning, dataportabilitet osv.
Godt svar: Beskrivelse af konkret proces: SLA på svar (typisk 5-10 arbejdsdage), pris (ofte gratis ved standardanmodninger), tekniske værktøjer (selvbetjenings-portal).
Rødt flag: “Bistand efter aftale” uden SLA, eller timeløn på 1500+ kr per anmodning.
7. Bistand til sikkerhed og brudsanmeldelse
Krav: Leverandøren skal underrette jer “uden unødig forsinkelse” ved sikkerhedsbrud.
Godt svar: Konkret SLA på 24-72 timer, beskrivelse af hvad notifikationen indeholder (omfang, kategorier, foranstaltninger), proces for koordineret underretning til Datatilsynet.
Rødt flag: “Hurtigst muligt” uden tidsangivelse, eller ingen reference til 72-timers fristen i artikel 33.
8. Sletning eller tilbagelevering ved ophør
Krav: Ved aftaleophør skal data slettes eller tilbageleveres efter jeres valg.
Godt svar: Konkret proces: eksportformat (åbent, standardiseret), tidsfrist (typisk 30-90 dage), bekræftelse på sletning, opbevaring kun hvor lov kræver det.
Rødt flag: Lange opbevaringsperioder (“op til 7 år for tekniske formål”), proprietære eksportformater, eller intet konkret offboarding-flow.
9. Audit og inspektion
Krav: Leverandøren skal stille information til rådighed, der dokumenterer overholdelse, og acceptere audits.
Godt svar: Årlig SOC 2- eller ISO-audit-rapport stilles til rådighed, ret for jer til selv at udføre audit (typisk på egen regning, med rimelig varsel).
Rødt flag: Forbud mod kundeaudits, eller krav om titusinder af kroner for audit-rapporter.
10. Tredjelandsoverførsler
Krav: Overførsel uden for EU/EØS kræver gyldigt overførselsgrundlag (DPF, SCC, BCR).
Godt svar: Klar oversigt over hvor data behandles, hvilket grundlag der bruges for hvert tredjeland, og opdateret risikovurdering.
Rødt flag: Uklart eller modstridende info om datalokation, eller henvisning til “udløbet” Privacy Shield. Læs mere om Schrems II-konsekvenser i praksis.
11. Ansvar og forsikring
Krav: Ikke et direkte artikel 28-krav, men centralt for risikofordeling.
Godt svar: Ansvarsbegrænsning står i rimeligt forhold til kontraktværdien (typisk 12 måneders abonnement minimum), cyberforsikring nævnes med beløb.
Rødt flag: Ansvarsbegrænsning på et par tusind kr, eller fuld ansvarsfraskrivelse.
12. Ændringer af aftalen
Krav: Aftalen skal være retskraftig, hvilket forudsætter en klar proces for ændringer.
Godt svar: Skriftlige ændringer med jeres godkendelse for væsentlige forhold. Mindre ændringer (subprocessors, sikkerhedsforanstaltninger) med varsel og indsigelsesret.
Rødt flag: “Vi kan ændre aftalen ensidigt med 14 dages varsel” uden begrænsning af, hvad der kan ændres.
For en åben reference, se Decrees DPA, som vi gør tilgængelig før kontraktindgåelse.
Røde flag der bør stoppe underskriften
Hvis I møder ét eller flere af følgende, bør I forhandle eller skifte leverandør, ikke underskrive:
- Aftalen er kun tilgængelig efter underskrift af NDA, og I må ikke vise den til ekstern rådgiver.
- Subprocessor-listen er ikke offentlig, eller leverandøren nægter at oplyse, hvor data fysisk behandles.
- Leverandøren henviser til “Privacy Shield” som overførselsgrundlag (afgørelsen er ugyldig siden 2020).
- DPA’en udelader artikel 28’s obligatoriske elementer (instruktion, fortrolighed, sikkerhed, sletning, audit).
- Leverandøren modsætter sig konkrete SLA’er på brudsanmeldelse eller sletning.
- Aftalen indeholder klausuler, der reelt fritager leverandøren for ansvar ved sikkerhedsbrud.
I praksis er en mangelfuld DPA et signal om en mangelfuld leverandørstyring hos leverandøren selv. Det er sjældent kun aftalen, der er problemet.
Ofte stillede spørgsmål om databehandleraftale skytjeneste
Skal vi have en DPA med alle leverandører?
I skal have en DPA med enhver leverandør, der behandler persondata på jeres vegne. Det inkluderer SaaS, hosting, e-mail, CRM, support-leverandører og konsulenter med adgang til data. For leverandører, der kun behandler aggregerede eller anonymiserede data, kan kravet bortfalde.
Hvem skal underskrive DPA’en hos os?
Den dataansvarliges juridiske repræsentant. I praksis er det direktion eller juridisk afdeling, ofte med DPO som intern review. Det er ikke en IT-beslutning alene.
Kan vi bruge leverandørens standard-DPA?
Ja, hvis den opfylder artikel 28. Mange standard-DPA’er fra modne leverandører er fuldt dækkende. Hvis ikke, skal I forhandle ændringer eller leverandørens vilje til at acceptere jeres egen DPA. Det er ofte forhandlingsbart for kontraktværdier over 100.000 kr årligt.
Hvor ofte skal DPA’en revideres?
Mindst årligt eller ved væsentlige ændringer i behandlingen. Subprocessor-ændringer udløser typisk en revurdering. Datatilsynet forventer dokumenteret review.
Hvad gør vi hvis leverandøren nægter at ændre DPA’en?
Dokumenter risikoen, eskaler beslutningen til ledelsen, og overvej om kontraktværdien retfærdiggør at acceptere mangelfuld DPA. For kritiske behandlinger er svaret ofte at finde en anden leverandør.
Læs også
- CLOUD Act danske virksomheder: komplet guide og handleplan
- Decrees databehandleraftale: åben skabelon
- Datasikkerhed hos Decree: dansk hosting, ingen CLOUD Act-eksponering
- Email-løsning: dansk mail-hosting til erhverv
Vil du samle din virksomheds digitale rygrad hos én dansk leverandør? Decree bygger og driver hele stakken (mail, signering, telefoni, CRM, dokumenter, eLearning) plus skræddersyede SaaS-platforme og mobilapps. Alt hostet i EU, CLOUD Act-fri, samlet i én DPA. Se platformen eller kontakt os for en samtale.
- databehandleraftale
- gdpr
- artikel 28
- leverandørstyring
- compliance












