Dansk hosting fra Aalborg
100% CO₂-neutral hosting
24/7/365 dansk support
support@hostious.io
● Hostious viden · artikel

Bureauets GDPR-ansvar: databehandler i kundens kæde

Skrevet af , stifter af Hostious · Udgivet 2. september 2026 · Opdateret 2. september 2026
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 deres instruks. Det udløser tre pligter: en databehandleraftale med hver kunde, styr på dine underdatabehandlere (din hostingudbyder er den vigtigste – kunden skal kende og acceptere den), og dokumenterbar praksis: sikkerhed, sletning (også staging-kopier og lokale backups!) og straks-underretning ved brud. Det lyder tungt – men som bureau er det også en konkurrencefordel: de fleste konkurrenter har det ikke på plads.

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.

Rollerne i kæden

Bureauet som databehandler i GDPR-kæden: dataansvarlig kunde, databehandler-bureau og hostingudbyder som underdatabehandler

Kunden er dataansvarlig: det er deres kunder, deres formål, deres beslutninger. Du er databehandler, når du drifter, fejlretter, migrerer eller på anden vis KAN tilgå persondata på deres site – også selv om du aldrig aktivt kigger i ordrelisten; muligheden er nok. 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 admin-adgang, er du i kæden.

Databehandleraftalen

GDPR kræver en skriftlig databehandleraftale mellem dataansvarlig og databehandler – altså mellem HVER driftskunde og dig. Den skal bl.a. fastlægge: hvilke data og behandlinger der er tale om, at du kun handler efter dokumenteret instruks, dine sikkerhedsforanstaltninger, reglerne for underdatabehandlere, din pligt til at bistå ved henvendelser fra registrerede og ved brud, og hvad der sker med data ved ophør (sletning/tilbagelevering – din offboarding-rutine er den praktiske udmøntning). Brug Datatilsynets standardaftale som skabelon frem for at opfinde din egen: den er gratis, anerkendt og nem at genbruge på tværs af kunder – gør den til en fast del af din driftsaftale-pakke, så den aldrig bliver et selvstændigt projekt.

Underdatabehandlere: din host og dine værktøjer

Alle led, DU trækker ind, som kan røre kundens persondata, er underdatabehandlere i kundens kæde: hostingudbyderen først og fremmest, men også backup-tjenester, mailudbydere på sitets vegne og overvågnings-/supportværktøjer med dataadgang. Du skal have databehandleraftaler NEDAD (med hosten – se hvad aftalen med din host skal indeholde) og gennemsigtighed OPAD: kunden skal kende dine underdatabehandlere og godkende ændringer. Håndtér det pragmatisk med en offentlig liste („vi bruger disse leverandører“) og et varsel ved skift. Vælg i øvrigt underdatabehandlere, der gør listen KORT og europæisk – jo færre led uden for EU, jo færre spørgsmål skal du kunne svare på, jf. vores datasuverænitets-univers.

GDPR i den daglige drift

Fire vaner gør forskellen: Før fortegnelse – én række pr. kunde i et regneark (hvilke data, hvor, hvilke underdatabehandlere) dækker langt. Behærsk kopierne – staging-miljøer, lokale udviklingskopier og „lige et hurtigt database-dump“ ER persondatabehandling: anonymisér staging-data, 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. Sletning som rutine – ved ophør slettes ALT efter aftalens frister, og du bekræfter skriftligt. Det er præcis de fire ting, en kunde (eller deres revisor) spørger om – og med dem på plads er svaret altid „ja, se her“.

Når det går galt

Som databehandler har du ÉN central pligt ved sikkerhedsbrud: underret kunden STRAKS – uden vurderinger, uden forsinkelse, uden først at rydde op i stilhed. Kunden ejer 72-timers fristen over for Datatilsynet; du leverer den tekniske redegørelse og bistanden. Hele håndteringen – roller, første time, kommunikation – står i artiklen om sikkerhedshændelser på kundesites. Din databehandleraftale og din hændelsesrapport er tilsammen dit værn: de viser, at du gjorde det rigtige, i den rigtige rækkefølge, til tiden.

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

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

Er et webbureau altid databehandler?

Næsten altid, når det drifter eller har admin-adgang til sites med persondata – muligheden for adgang er nok. For egne data (CRM, fakturaer) er bureauet selv dataansvarlig.

Skal jeg have databehandleraftale med alle kunder?

Ja – med hver kunde, hvis data du behandler. Brug Datatilsynets standardskabelon, og gør den til fast del af driftsaftalen, så den underskrives sammen med den.

Tæller staging og lokale kopier som databehandling?

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

Læs også