GDPR-guide 2026: Webbureauets rolle forklaret

GDPR:
Hvem har ansvaret — bureauet eller kunden?

Webbureauer rører persondata hver dag — kontaktformularer, analytics, nyhedsbreve, backups af kundesider. Alligevel er der vedvarende forvirring om, hvem der bærer ansvaret. Svaret afhænger af din rolle. Her er rollerne forklaret, de fem klassiske fejl og en 5-trins tjekliste.

Opdateret august 2026 · Læsetid: 7 minutter

To roller: dataansvarlig og databehandler

GDPR (forordning 2016/679) definerer to hovedroller, og det er dem, der afgør, hvem der skal svare over for tilsynet:

🎯 Dataansvarlig

Den part, der bestemmer, hvorfor og i store træk hvordan data behandles. Din kunde er typisk dataansvarlig for sin sides data: kunden bestemmer formålene (markedsføring, salg) og midlerne (CMS, nyhedsbrevsværktøj).

🔧 Databehandler

Den part, der behandler data på den ansvarliges instruks. Et bureau, der vedligeholder en kundeside med adgang til brugerdata via admin-logins, backups eller staging-miljøer, er typisk databehandler.

⚖️ Begge dele på samme tid

Mange bureauer er begge: databehandler for kundernes sidedata — men selvstændig dataansvarlig for egne data (medarbejdere, egne leads, analytics på eget domæne).

Hvorfor det betyder noget: som databehandler kan du ikke bare "følge kundens instruks", hvis den bryder GDPR — I er begge udsat. Og uden en skriftlig databehandleraftale (DBA) er behandlingen ulovlig fra dag én (art. 28).

De fem klassiske bureau-fejl

1. Ingen databehandleraftale. Art. 28 kræver en skriftlig DBA FØR behandlingen starter — ikke "det når vi senere". Det gælder også jeres underbehandlere (hosting, e-mail).

2. Cookies før samtykke. Ikke-nødvendige cookies (analytics, markedsføring, sociale plugins) må kun sættes efter aktivt, informeret samtykke — og det skal være lige let at sige nej som ja. Et banner med "Acceptér alle" og en gemt afvis-knap lever ikke op til kravene.

3. Analytics uden retsgrundlag. En standard Google Analytics-opsætning sender data til USA. Europæiske datatilsyn har afgjort, at det kræver ekstra sikkerheder (IP-afrunding, DBA, evt. proxy-løsninger) — ellers er trafikdata i praksis persondata uden lovligt grundlag.

4. Formularer videresendt som e-mail. Kontaktformularer sendt som mail spreder persondata ud i postkasser uden opbevaringsgrænse eller adgangsstyring. Bedre: lad indsendelser lande direkte i CMS/databasen med logget adgang.

5. Glemte staging- og backupmiljøer. Kopier af produktionssider med ægte brugerdata ligger ofte ubeskyttet på staging-domæner. Enten anonymiser dataene, eller lås miljøerne bag login — og sæt en sletningsfrist.

72-timers-reglen — den gælder også bureauet

Ved brud på persondatasikkerheden skal den dataansvarlige underrette tilsynet inden for 72 timer, hvor risikoen er reel (art. 33). Som databehandler er din pligt skarpere: du skal underrette kunden uden unødig forsinkelse, efter du er blevet opmærksom påbruddet (art. 33, stk. 2).

I praksis: opdager du, at en kundeside er kompromitteret, startede kundens 72-timersur med det samme — og din underrettelsespligt gør jeres reaktionstid til et kontraktspørgsmål. Hav en skriftlig incidentproces klar: hvem opdager, hvem vurderer, hvem underretter, inden for hvor mange timer.

📝 Hvad skal en DBA indeholde?

Art. 28, stk. 3, lister minimumet: genstand og varighed, art og formål, datakategorier, den ansvarliges rettigheder og pligter, fortrolighed, sikkerhedsforanstaltninger, underbehandlere, hjælp til underrettelse, sletning/tilbagelevering og revisionsret. Vor e-bog indeholder en klar-til-brug skabelon.

🌍 Hosting og tredjelande

Kunder spørger i stigende grad, hvor deres side hostes. EU/EØS-hosting fjerner et helt kapitel om tredjelandsoverførsler. Bruger du underbehandlere i tredjelande, skal de stå i DBA\u2019en og være dækket af standardkontraktklausuler.

En 5-trins tjekliste for dit bureau

Sådan får I det basale på plads — uden at det bliver et månederlangt projekt:

1. Kortlægg jeres dataprocesser. Hvilke kundesider har I adgang til? Hvor lander formulardata? Hvilke værktøjer sætter I selv op (analytics, nyhedsbreve)? Én oversigt rækker langt.
2. Få DBA på alle kundeforhold.Én standardskabelon + en kort proces: send ved kontraktstart, arkivér den underskrevne version.
3. Ryd op i cookies og tracking. Samtykkebanner med lige vilkår for ja/nej, kun nødvendige cookies før samtykke, dokumenteret cookiepolitik.
4. Skriv incidentprocessen. Én side: opdagelse → vurdering → kundeunderrettelse (timer, ikke dage) → hjælp til tilsynsrapporten.
5. Gennemgå årligt. Nye kunder, nye værktøjer, nye underbehandlere? Opdatér listen og aftalerne. En dokumenteret gennemgang tæller ved revision.

Ofte stillede spørgsmål

Er bureauet ansvarligt for kundens cookies?

Som udgangspunkt nej — kunden bestemmer formålet med tracking. MEN: sætter I cookien op, valgte I teknisk løsning og leverede konfigurationen. Sørg for, at kunden aktivt godkendte opsætningen, og at samtycceløsningen faktisk virker. Ansvaret kan være delt (art. 26, fælles ansvar).

Skal vi også have en DBA med hostingleverandøren?

Ja — hosting af en hjemmeside med persondata er behandling på den ansvarliges vegne. Enten er kunden den direkte part (typisk når kunden ejer hostingkontoen), eller også er I mellemled og skal have egen aftale med hosten, der viderefør de samme krav.

Hvor store er bøderne?

Op til 20 mio. euro eller 4 % af global omsætning for alvorlige principbrud; 10 mio. euro / 2 % for fx manglende DBA\u2019er eller utilstrækkelig sikkerhed. For små virksomheder er den realistiske risiko dog oftest påbud, tilsynssager og mistet tillid.

Gælder GDPR overhovedet små sider?

Ja. GDPR har ingen størrelsesgrænse — kun undtagelser for rent privat brug. En firmakontaktside med navne og e-mails er persondata, uanset om virksomheden har tre eller tre hundrede ansatte.

Hvordan forholder det sig til NIS2 og EAA?

Tre spor: GDPR beskytter persondata, NIS2 kræver operationel cybersikkerhed, EAA forlanger tilgængelighed. Én enkelt hændelse kan ramme flere spor på samme tid. Se vores NIS2- og EAA-guides for de andre søjler.