Databehandleravtale i praksis: hva en revisor faktisk sjekker

De fleste virksomheter har en signert databehandleravtale liggende. Langt færre har en som faktisk stemmer med virkeligheten – og det er akkurat den forskjellen en revisor ser etter.

Når jeg går gjennom databehandleravtaler – enten det er som ledd i en ISO 27001-revisjon, en kundes leverandørvurdering, eller en gjennomgang før et mulig tilsyn – er det sjelden et spørsmål om hvorvidt avtalen finnes. Den finnes nesten alltid. Spørsmålet er om den er fullstendig, om den beskriver det som faktisk skjer, og om kravene i den etterleves i praksis. Det er i gapet mellom «signert avtale» og «avtale som stemmer» at avvikene oppstår.

Denne artikkelen tar deg gjennom hva loven krever, hva en revisor konkret ser på, og de vanligste funnene – pluss en sjekkliste du kan bruke selv.

Hva er en databehandleravtale – kort fortalt

Når du lar noen andre behandle personopplysninger på dine vegne – en SaaS-leverandør, en regnskapsfører, et driftsselskap, et e-postsystem – er du behandlingsansvarlig, og den andre er databehandler. GDPR artikkel 28 krever at forholdet reguleres i en skriftlig avtale: databehandleravtalen.

Avtalen finnes ikke for formalitetens skyld. Den fastsetter hva databehandleren har lov til å gjøre med opplysningene, hvilke sikkerhetskrav som gjelder, og hvilke rettigheter du som ansvarlig har til å kontrollere at det skjer riktig. Den er, kort sagt, det juridiske og praktiske bindeleddet i en kjede som ofte er lengre enn folk tror.

Hva loven krever at avtalen inneholder

Artikkel 28 nr. 3 setter et minimum. Avtalen skal beskrive behandlingens gjenstand, varighet, art og formål, hvilke typer personopplysninger som behandles og hvilke kategorier registrerte det gjelder. I tillegg skal den pålegge databehandleren en rekke konkrete plikter:

Krav (art. 28 nr. 3)	Hva det betyr i praksis
Dokumenterte instrukser	Databehandler behandler kun opplysninger etter dine dokumenterte instrukser – ikke til egne formål
Konfidensialitet	De som behandler opplysningene er underlagt taushetsplikt
Sikkerhet (art. 32)	Det er innført egnede tekniske og organisatoriske tiltak
Underdatabehandlere	Bruk av underleverandører krever godkjenning, og samme plikter føres videre nedover i kjeden
Bistand til de registrerte	Databehandler hjelper deg med å oppfylle innsyn, sletting og andre rettigheter
Bistand til sikkerhet og brudd	Databehandler bistår ved hendelseshåndtering, avviksmelding og eventuell DPIA
Sletting eller tilbakelevering	Ved avtaleslutt slettes eller tilbakeleveres opplysningene etter ditt valg
Dokumentasjon og revisjon	Databehandler gjør tilgjengelig all dokumentasjon som trengs for å vise etterlevelse, og muliggjør revisjon

I Norge bygger de fleste avtaler på en standardmal med vedlegg (Bilag A–D): opplysninger om behandlingen, vilkår for bruk av underdatabehandlere, sikkerhetstiltak og eventuelle vilkår for tredjelandsoverføring. Malen er sjelden problemet. Det er vedleggene som avgjør om avtalen er verdt noe – og det er der revisoren går rett inn.

Det revisor faktisk sjekker

Her er forskjellen på en formalitet og en avtale som holder. Dette er punktene jeg går gjennom, og som et tilsyn eller en kundes revisor vil gjøre det samme med:

Stemmer vedleggene med virkeligheten?

Bilag A skal beskrive den faktiske behandlingen: hvilke opplysninger, hvilke registrerte, hvilke formål, hvor lenge. Når dette står tomt, er fylt med generiske formuleringer, eller beskriver noe annet enn det systemet faktisk gjør, er det et avvik. En avtale som ikke beskriver den reelle behandlingen, kan heller ikke regulere den.

Konsekvens: En generisk avtale gir en falsk trygghet. Den ser ferdig ut, men dokumenterer ingenting konkret.

Er underdatabehandlerne under kontroll?

Nesten alle databehandlere bruker egne underleverandører – skyleverandør, hostingtjeneste, e-postutsending, support. Revisoren ser etter tre ting: finnes det en oppdatert liste over underdatabehandlere, finnes det en varslingsmekanisme når listen endres slik at du kan protestere, og er de samme pliktene ført videre i avtalen med underleverandøren? Manglende eller utdatert underleverandørliste er et av de aller vanligste funnene.

Er tredjelandsoverføringer faktisk håndtert?

Hvis opplysninger flyter ut av EØS – som de ofte gjør gjennom amerikanske skyleverandører – må det finnes et gyldig overføringsgrunnlag. For overføring til USA kan dette være EU-US Data Privacy Framework (for DPF-sertifiserte mottakere) eller standard personvernbestemmelser (SCC).

Her er en nyanse en god revisor merker seg: DPF er per mai 2026 gyldig – rammeverket overlevde en rettslig utfordring i EUs underrett høsten 2025 – men en anke ligger til behandling i EU-domstolen, og de to forgjengerne (Safe Harbor og Privacy Shield) ble begge kjent ugyldige. En virksomhet som blindt lener seg på DPF alene, uten å ha vurdert en reserveløsning, har tatt en risiko de fleste ikke er klar over. Det modne grepet er å dokumentere SCC som fallback og gjennomføre en overføringsvurdering (TIA) som vurderer om mekanismen faktisk beskytter opplysningene i mottakerlandet.

Konsekvens: «Vi bruker en stor, kjent skyleverandør» er ikke et overføringsgrunnlag. Revisoren vil se mekanismen og vurderingen bak den.

Er sikkerhetstiltakene konkrete?

Bilaget om tekniske og organisatoriske tiltak skal beskrive faktiske kontroller – tilgangsstyring, kryptering, logging, backup, hendelseshåndtering – ikke floskler som «bransjens beste praksis». Et tomt eller generisk sikkerhetsbilag betyr i praksis at art. 32-kravet ikke er dokumentert.

Skjer sletting og tilbakelevering – og kan det dokumenteres?

Ved avtaleslutt skal opplysningene slettes eller leveres tilbake. Revisoren spør ikke bare om avtalen sier det; hun spør om det finnes en rutine, og om databehandleren kan dokumentere at det faktisk har skjedd ved tidligere avslutninger.

Er revisjonsretten reell?

Artikkel 28 gir deg rett til å revidere databehandleren, og pålegger databehandleren å gjøre tilgjengelig all dokumentasjon som viser etterlevelse. På papiret har de fleste avtaler dette. I praksis er spørsmålet om retten noen gang er brukt, og om databehandleren faktisk kan dokumentere etterlevelse hvis du ber om det. En databehandler som ikke klarer å vise frem noe, er et avvik i seg selv.

De vanligste funnene

Hvis jeg skal koke det ned til de avvikene jeg ser igjen og igjen:

• Vedlegg som står tomme eller er fylt med generisk standardtekst
• Underleverandørliste som mangler, er utdatert, eller aldri er kommunisert til kunden
• Tredjelandsoverføring uten dokumentert grunnlag eller overføringsvurdering
• Sikkerhetsbilag som beskriver intensjoner, ikke faktiske kontroller
• Ingen rutine for – eller dokumentasjon på – sletting ved opphør
• Revisjonsrett som aldri er utøvd, og en databehandler som ikke kan vise frem dokumentasjon
• Motstrid mellom databehandleravtalen og den underliggende tjenesteavtalen
• En avtale som ble signert én gang og aldri oppdatert, selv om behandlingen har endret seg

Fellesnevneren er den samme: avtalen ble behandlet som en signatur, ikke som et levende dokument.

Sjekkliste: er databehandleravtalen din revisjonsklar?

Gå gjennom disse punktene for hver databehandler du bruker:

1. Beskriver vedlegget den faktiske behandlingen – riktige opplysninger, formål og varighet?
2. Finnes en oppdatert liste over underdatabehandlere, med varsling ved endringer?
3. Er det et dokumentert grunnlag for enhver overføring ut av EØS – og en vurdering bak det?
4. Beskriver sikkerhetsbilaget konkrete tiltak, ikke floskler?
5. Finnes en rutine for sletting/tilbakelevering ved opphør, og kan den dokumenteres?
6. Kan databehandleren faktisk fremvise dokumentasjon på etterlevelse hvis du ber om det?
7. Stemmer databehandleravtalen overens med tjenesteavtalen?
8. Er avtalen oppdatert i takt med endringer i behandlingen?

Krysser du av på alle åtte, er du i en helt annen posisjon enn flertallet.

For databehandlere: snu det til et konkurransefortrinn

Hvis du er på leverandørsiden, gjelder den samme logikken som for en DPIA-pakke til kundene dine: den leverandøren som gjør kundens jobb enklere, vinner. En databehandler som stiller med en ryddig, utfylt avtale, en vedlikeholdt underleverandørliste, et konkret sikkerhetsbilag og dokumentasjon som er klar til revisjon, fjerner friksjon fra salgsprosessen og signaliserer modenhet. I anbud merkes forskjellen.

Dette henger også tett sammen med leverandørstyringen i et ISO 27001-styringssystem – se hva en ISO 27001-sertifisering faktisk koster og innebærer – der nettopp kontroll på leverandørkjeden er et eget kontrollområde.

Hvordan SPADE Consulting kan hjelpe

Som ISO 27001 Lead Implementer og ISO 27005 Lead Risk Manager jobber jeg med databehandleravtaler fra begge sider av bordet: jeg skriver og kvalitetssikrer avtaler med tilhørende vedlegg, og jeg gjennomgår eksisterende avtaler for å finne avvikene før en revisor eller et tilsyn gjør det. Som uavhengig konsulent i Bodø, uten overhead fra et stort byrå, kan jeg tilby seniorkompetanse til en fornuftig pris – gjerne med fastpris på en definert gjennomgang.

Usikker på om avtalene deres holder mål?

Book et gratis, uforpliktende møte, så ser vi på porteføljen av databehandleravtaler og hvor de største risikoene ligger.

Kilder og videre lesning

• Personvernforordningen (GDPR): Artikkel 28 (databehandler) og artikkel 32 (sikkerhet ved behandling)
• Datatilsynet: Databehandleravtale – veiledning om krav og innhold
• Europakommisjonen: Standard personvernbestemmelser (SCC) – standardkontrakter for overføring til tredjeland
• EU–US Data Privacy Framework: dataprivacyframework.gov – status og sertifiserte virksomheter

Sist oppdatert: Mai 2026. Artikkelen gir generell informasjon og er ikke juridisk rådgivning. Status for overføringsmekanismer kan endre seg – verifiser gjeldende rettstilstand for konkrete overføringer.