GDPR-guiden 2026: Webbureauets rolle forklaret

GDPR:
Hvad er webbureauets ansvar?

Bureauer rører persondata hver dag — kontaktformularer, analytics, nyhedsbreve, backups af klientsites. Alligevel er der uenighed om, hvem der bærer ansvaret: bureauet eller klienten? Svaret afhænger af rollen. Her er rollernes forskel, 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) kender to hovedroller, og forskningen i dem afgør hvem der svarer over for Datatilsynet:

UPTIME

DeskUptime: Gratis Desktop Uptime- & SSL-overvågning

Dataansvarlig

Den der bestemmer hvorfor og i store træk hvordan data behandles. Din klient er typisk dataansvarlig for sit websites data: den bestemmer formål (marketing, salg) og midler (CMS, nyhedsbrevsværktøj).

Databehandler

Den der behandler data på den ansvarliges instruks. Et bureau der vedligeholder et klientsite og har adgang til brugerdata via admin-login, backups eller staging-miljøer er typisk databehandler.

Begge dele

Mange bureauer er begge: databehandler for klientens websitedata — men selvstændig dataansvarlig for egne data (medarbejdere, egne leads, jeres egen analytics på jeres domæne).

Hvorfor det betyder noget: som databehandler kan du ikke bare "følge klientens instruks" hvis instruksen bryder GDPR — så hæfter I sammen. Og uden en skriftlig databehandleraftale er behandlingen ulovlig fra dag ét (art. 28).

De fem klassiske fejl hos bureauer

1. Ingen databehandleraftale. Art. 28 kræver en skriftlig aftale FØR behandlingen starter — ikke "den kommer nok senere". Det gælder også jeres subleverandører (hosting, e-mail).

2. Cookies før samtykke. Ikke-nødvendige cookies (analytics, marketing, sociale plugins) må først sættes efter et aktivt, informeret samtykke — og ligeså let at trække tilbage som at give. Et banner med "Acceptér alle" og gemt afvis-knap holder ikke.

3. Analytics uden hjemmel. Standard Google Analytics-setup overfører data til USA. Datatilsynene har slået fast, at det kræver ekstra forholdsregler (fx IP-truncering, DPA, evt. proxy-løsning) — ellers er trafikdata reelt persondata uden lovligt grundlag.

4. Formulardata i mailkæder. Kontaktformularer der videresendes som e-mail samler persondata i postkasser uden opbevaringsfrist eller adgangsstyring. Bedre: formular direkte til CMS/database med logget adgang.

5. Glemte staging- og backupmiljøer. Kopier af produktionssites med ægte brugerdata ligger ofte ubeskyttet på staging-domæner. Enten anonymiser data, eller lås miljøerne bag login — og sæt frist for sletning.

72-timers-reglen — også for bureauet

Ved en persondata-brud skal den dataansvarlige melde til Datatilsynet inden for 72 timer, hvis risikoen er reel (art. 33). Som databehandler er pligten strammere: I skal mellem til klienten uden unødig forsinkelse efter at blive bekendt med bruddet (art. 33 §2).

I praksis betyder det: hvis I opdager, at et klientsite er blevet kompromitteret, starter klientens 72-timers-ur snarest — og jeres meldepligt gør jeres reaktionstid til en kontraktlig størrelse. Hav en skriftlig incident-proces klar: hvem opdager, hvem vurderer, hvem melder, inden for hvor mange timer.

Hvad skal en DBA indeholde?

Art. 28 §3 lister minimumet: genstand og varighed, art og formål, datakategorier, klientens rettigheder og instrukspligt, fortrolighed, sikkerhedsforanstaltninger, subleverandører, hjælp ved indberetninger, sletning/tilbagelevering og revisionsrettigheder. Vores e-bog har en klar-til-brug skabelon.

Hosting og tredjeland

Klienter spørger i stigende grad, hvor deres site hostes. EU/EOES-hosting fjerner et kapitel af transfer-spørgsmålene. Har I subleverandører i tredjelande, skal de stå på en liste i DBA'en og være dækket af standardkontraktclauses.

5-trins tjekliste for bureauet

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

1. Kortlæg jeres dataprocesser. Hvilke klientsites har I adgang til? Hvor lander formulardata? Hvilke værktøjer sætter I selv op (analytics, nyhedsbrev)? Én oversigt rækker langt.
2. Få DBA'er på alle kundeforhold. En standardskabelon + kort proces: send ved kontraktopstart, arkivér underskrevet version.
3. Ryd op i cookies og tracking. Samtykkebanner med lige vilkår for ja/nej, nødvendige cookies alene før samtykke, dokumenteret cookiepolitik.
4. Skriv incident-processen. Én side: opdagelse → vurdering → melding til klient (timer, ikke dage) → hjælp til Datatilsynet-melding.
5. Gennemgå det årligt. Nye klienter, nye værktøjer, nye subleverandører? Opdater listen og aftalerne. Dokumenteret gennemgang tæller ved tilsyn.

Ofte stillede spørgsmål

Er bureauet dataansvarlig for klientsitets cookies?

Som udgangspunkt nej — klienten bestemmer formålet med tracking. MEN: sætter I cookien op, vælger I teknisk løsning og leverer konfigurationen. Vær derfor sikker på, at klienten aktivt har godkendt setup'et, og at samtykke-løsningen virker. Delvist ansvar kan deles (art. 26, fælles ansvar).

Skal der DBA med hostingleverandøren også?

Ja — hosting af et website med persondata er behandling på vegne af den ansvarlige. Enten står klienten selv som part (typisk når klienten ejer hostingabonnementet), eller også er I mellemled og skal selv have aftale med hosten og videreføre kravene.

Hvor store er bøderne?

Op til 20 mio. euro eller 4 % af global omsætning for de tunge principovertrædelser; 10 mio. euro / 2 % for fx manglende DBA eller utilstrækkelig sikkerhed. For små virksomheder er den reelle risiko dog oftest påbud, tilsynssag og tabt tillid.

Gælder GDPR overhovedet for små sites?

Ja. GDPR har ingen størrelsesgrænse — kun undtagelser for ren privat/husholdningsbrug. Et firmas contactside med navn og e-mail er persondata, uanset om virksomheden har tre ansatte.

Hvordan hænger det sammen med NIS2 og EAA?

Tre spor: GDPR beskytter persondata, NIS2 kræver operationel cybersikkerhed, EAA stiller krav om tilgængelighed. En hændelse kan ramme flere spor samtidig. Se vores NIS2-guide og EAA-guides for de andre ben.