Bureauets GDPR-ansvar: databehandler i kundens kæde

Kort svar: Drifter du kundesites, er du næsten altid databehandler: du behandler persondata (ordrer, formularer, brugere) på kundens vegne og efter kundens instruks. Det udløser tre pligter: en databehandleraftale med hver kunde, styr på dine underdatabehandlere (hostingudbyderen er typisk den vigtigste, og kunden skal kende og godkende den), og dokumenterbar praksis for sikkerhed, sletning – også af staging-kopier og lokale backups – og underretning af kunden uden unødig forsinkelse ved brud. Det lyder tungt, men har du det på plads, kan du svare „ja, se her“, når kunden spørger.

Fagligt gennemgået: 2. oktober 2026

GDPR-ansvaret er den del af bureaudriften, de færreste har lyst til at tænke på – lige indtil en kunde spørger „har vi en databehandleraftale med jer?“, eller et site lækker data, og alle kigger på hinanden. Her er rollerne, papirerne og den praktiske håndtering – skrevet til bureauer og freelancere, ikke til jurister.

Vigtigt: Artiklen er generel vejledning og ikke juridisk rådgivning. Roller og krav afhænger af den konkrete aftale og behandling. Brug Datatilsynets vejledninger og skabeloner som udgangspunkt, og spørg en rådgiver ved tvivl eller større kontrakter.

Rollerne i kæden

Kunden er dataansvarlig: det er kundens kunder, kundens formål og kundens beslutninger. Du er databehandler, når du drifter, fejlretter, migrerer eller på anden måde behandler persondata på kundens site – også selvom du sjældent aktivt kigger i ordrelisten. Har du administratoradgang og ansvar for driften, behandler du data på kundens vegne. Din hostingudbyder er underdatabehandler i kundens kæde, når hostingen går gennem dig.

To afgrænsninger: for dine egne data (dit CRM, dine fakturaer, dine leads) er du selv dataansvarlig. Og bygger du blot et site uden adgang til driftsdata bagefter, kan databehandlerrollen være begrænset til projektperioden. Men tommelfingerreglen holder: har du løbende adgang til et site med persondata, er du i kæden.

Har kunden selv en aftale direkte med hostingudbyderen, er udbyderen typisk kundens egen databehandler – ikke din underdatabehandler. Det ændrer, hvem der skal have aftale med hvem, så afklar det for hver kunde.

Databehandleraftalen

GDPR artikel 28 kræver en skriftlig databehandleraftale mellem dataansvarlig og databehandler – altså mellem hver driftskunde og dig. Aftalen skal blandt andet fastlægge:

• hvilke data og behandlinger der er tale om, og hvor længe;
• at du kun handler efter dokumenteret instruks fra kunden;
• at dine medarbejdere har tavshedspligt;
• dine sikkerhedsforanstaltninger;
• reglerne for brug af underdatabehandlere;
• din pligt til at bistå kunden ved henvendelser fra de registrerede og ved sikkerhedsbrud;
• hvad der sker med data ved ophør – sletning eller tilbagelevering;
• at kunden kan få de oplysninger, der skal til for at føre tilsyn med dig.

Datatilsynet stiller en skabelon til databehandleraftale til rådighed på dansk og engelsk. Brug den som udgangspunkt frem for at opfinde din egen: den er gratis, kendt og nem at genbruge på tværs af kunder. Gør den til en fast del af driftsaftalen, så den underskrives samtidig og aldrig bliver et selvstændigt projekt. Din offboarding-rutine er den praktiske udmøntning af ophørsbestemmelsen.

Underdatabehandlere: din host og dine værktøjer

Alle led, du selv trækker ind, og som behandler kundens persondata, er underdatabehandlere i kundens kæde: hostingudbyderen først og fremmest, men også backup-tjenester, mailudbydere, der sender på sitets vegne, og overvågnings- eller supportværktøjer med dataadgang.

Efter artikel 28 må du kun bruge underdatabehandlere med kundens forudgående skriftlige godkendelse – enten specifik eller generel. Ved en generel godkendelse skal du give kunden besked om planlagte tilføjelser eller udskiftninger, så kunden har mulighed for at gøre indsigelse. Du skal samtidig have databehandleraftaler nedad med dine egne leverandører – se guiden om databehandleraftalen med dit hostingfirma.

Håndtér det pragmatisk med en liste over dine underdatabehandlere, som kunden kan se, og et fast varsel ved skift. Vælg gerne leverandører, der holder listen kort og overskuelig – jo færre led uden for EU/EØS, jo færre spørgsmål om tredjelandsoverførsler skal du kunne besvare. Guiden om subprocessorer viser, hvordan du læser leverandørernes egne lister, og datasuverænitets-hubben samler resten.

GDPR i den daglige drift

Fire vaner gør forskellen:

• Før fortegnelse. Artikel 30 kræver, at databehandlere fører en fortegnelse over de behandlinger, de udfører for hver dataansvarlig. Der findes en undtagelse for virksomheder under 250 ansatte, men den gælder ikke, hvis behandlingen ikke kun er lejlighedsvis – og løbende drift er sjældent lejlighedsvis. Én række pr. kunde i et regneark (hvilke data, hvor, hvilke underdatabehandlere, hvilke sikkerhedstiltag) dækker langt.
• Behersk kopierne. Staging-miljøer, lokale udviklingskopier og „lige et hurtigt database-dump“ er også behandling af persondata. Anonymisér data på staging, hvor du kan, og slet arbejdskopier efter brug.
• Adgang efter behov. Din adgangsstyring er også GDPR: kun de medarbejdere, der arbejder på kunden, skal kunne se dataene, og alle har personlige logins med totrinslogin.
• Sletning som rutine. Ved ophør slettes alt efter aftalens frister, og du bekræfter det skriftligt.

Det er præcis de fire ting, en kunde (eller kundens revisor) typisk spørger om.

Anonymisering af staging i praksis

En kopi af en webshops database indeholder navne, adresser, e-mails og ordrehistorik. Skal du teste en ny checkout eller et tema, har du sjældent brug for de rigtige kundedata. Overvej derfor at erstatte kundenavne, e-mails og telefonnumre med testdata, før kopien tages i brug, eller at slette ordrer og brugere, som testen ikke kræver.

Med WP-CLI kan du søge-og-erstatte i databasen, og der findes plugins og scripts, der anonymiserer brugere og ordrer. Uanset værktøj: dokumentér, hvordan staging håndteres, og sørg for, at staging ikke sender mails til rigtige kunder. Et staging-miljø, der ved en fejl sender ordrebekræftelser ud, er både pinligt og et potentielt sikkerhedsbrud.

Når det går galt

Som databehandler har du én central pligt ved sikkerhedsbrud: underret kunden uden unødig forsinkelse, når du bliver opmærksom på bruddet (artikel 33, stk. 2). Ikke efter en intern vurdering af, om det „er slemt nok“, og ikke efter først at have ryddet op i stilhed.

Det er kunden som dataansvarlig, der skal anmelde bruddet til Datatilsynet uden unødig forsinkelse og så vidt muligt senest 72 timer efter at være blevet bekendt med det – medmindre bruddet sandsynligvis ikke indebærer en risiko for de registrerede. Din rolle er at levere den tekniske redegørelse og bistanden. Hele håndteringen – roller, første time og kommunikation – står i artiklen om sikkerhedshændelser på kundesites.

Din databehandleraftale og din hændelseslog er tilsammen dit værn: de viser, at du gjorde det rigtige, i den rigtige rækkefølge, til tiden.

Tjekliste: er bureauet klar?

• Der er en underskrevet databehandleraftale med hver driftskunde.
• Listen over underdatabehandlere er opdateret, og kunderne kender den.
• Der er databehandleraftaler med dine egne leverandører (hosting, backup, mail, overvågning).
• Fortegnelsen over behandlinger er ajour.
• Alle medarbejdere har personlige logins med totrinslogin, og adgange fjernes, når de ikke længere er nødvendige.
• Staging og lokale kopier håndteres efter en beskrevet rutine.
• Der er en procedure for underretning af kunden ved brud, med kontaktoplysninger.
• Sletning ved ophør bekræftes skriftligt.

Læs også

• Hub: For bureauer og freelancere
• Databehandleraftale med dit hostingfirma: det skal du tjekke
• Sikkerhedshændelse på et kundesite: hvem gør hvad, hvornår?
• Offboarding: sådan afleverer du et kundesite ordentligt
• Subprocessorer: sådan læser du listen hos dine leverandører
• WordPress hosting hos Hostious – dansk virksomhed med servere i Europa og daglig backup

Ofte stillede spørgsmål om bureauets GDPR-rolle

Er et webbureau altid databehandler?

Næsten altid, når det drifter eller har administratoradgang til sites med persondata. For egne data som CRM og fakturaer er bureauet selv dataansvarlig.

Skal jeg have databehandleraftale med alle kunder?

Ja – med hver kunde, hvis persondata du behandler. Brug Datatilsynets skabelon som udgangspunkt, og gør aftalen til en fast del af driftsaftalen, så de underskrives samtidig.

Tæller staging og lokale kopier som databehandling?

Ja – en kopi af databasen indeholder persondata. Anonymisér staging, hvor det er muligt, slet arbejdskopier efter brug, og lad opbevaring af backup følge aftalens frister.

Hvem anmelder et sikkerhedsbrud til Datatilsynet?

Kunden som dataansvarlig. Bureauet som databehandler skal underrette kunden uden unødig forsinkelse og bistå med den tekniske redegørelse, så kunden kan overholde fristen på 72 timer.