Norske virksomheter: de åtte kravene i databehandleravtalen og vedlegg

En databehandleravtale må minst inneholde de åtte kravene i GDPR artikkel 28(3): dokumentert instruks, taushetsplikt, sikkerhetstiltak, regler for underdatabehandlere, bistand ved registrertes rettigheter, bistand ved avvik og DPIA, sletting eller retur av data ved avtaleslutt, og tilgang for revisjon. Avtalen er lovpålagt så snart en ekstern part behandler personopplysninger på vegne av virksomheten din, uansett bransje eller størrelse. Ferdige maler finnes hos Datatilsynet og i SSA-malverket, men selve innholdet må alltid fylles ut konkret for din behandling.

Kort oppsummert:

• En gyldig databehandleravtale må inneholde alle de åtte kravene i GDPR artikkel 28(3), som instrukser, taushetsplikt og sikkerhetstiltak, uten unntak.
• Vedleggene til avtalen skal spesifisere konkret hvordan behandling, sikkerhetstiltak og underdatabehandlere håndteres, og må fylles ut før signering for å være etterprøvbare.
• Kontroll av avtalen krever at du sjekker at alle vedlegg er fylt ut, at underdatabehandlere er oppdatert, og at rutiner for varsling ved brudd er tydelige.
• Effektiv oppfølging innebærer å ha en fast rutine for å oppdatere og revidere vedleggene minst én gang årlig, og ikke bare signere en mal uten videre oppfølging.
• Spesialtilpassede løsninger, som Fleetvakt, bør ha tydelig beskrevet tekniske rutiner i Vedlegg 2, for å sikre etterlevelse av kravene til lagring, tilgang og varsling ved databrudd.

Innholdsfortegnelse

• De åtte obligatoriske punktene i artikkel 28(3)
• Vedlegg 1–3: slik fyller du ut det som faktisk gjør avtalen etterprøvbar
• Regler for underdatabehandlere og overføring til tredjeland
• Varslingsfrister, sletting og revisjon i praksis
• Sjekkliste og maler før du signerer
• Vanlige feil og hva du bør stille krav om i forhandlingene
• Slik bør en flåte-SaaS regulere bilder, GPS og skiftdata
• Hva jeg mener virksomheter overser mest
• Fleetvakt og databehandleravtalens praktiske krav
• Kilder

De åtte obligatoriske punktene i artikkel 28(3)

Artikkel 28 nummer 3 er selve ryggraden i enhver databehandleravtale. Punktene er ikke forslag til gode formuleringer. De er minstekrav, og en avtale som mangler ett av dem er ikke gyldig etter regelverket, uansett hva partene har signert.

De åtte kravene fordeler seg slik:

• Dokumentert instruks (bokstav a). Databehandleren skal bare behandle personopplysninger etter dokumenterte instrukser fra deg som behandlingsansvarlig, inkludert ved overføring til tredjeland. I praksis betyr dette at avtalen selv, eller vedleggene til den, må beskrive nøyaktig hva databehandleren har lov til å gjøre med dataene, ikke bare at de «skal følge instruksjoner».
• Taushetsplikt (bokstav b). Alle som har tilgang til opplysningene hos databehandleren skal være underlagt konfidensialitet, enten gjennom lovbestemt taushetsplikt eller kontraktsforpliktelse. Dette omfatter også ansatte hos eventuelle underdatabehandlere.
• Sikkerhetstiltak (bokstav c). Databehandleren skal gjennomføre tiltak som kreves etter artikkel 32, altså tekniske og organisatoriske tiltak tilpasset risikoen. Dette punktet henger sammen med sikkerhetsvedlegget (Vedlegg 2), som må beskrive konkrete tiltak, ikke generelle formuleringer om at «sikkerhet tas på alvor».
• Underdatabehandlere (bokstav d). Avtalen skal regulere om databehandleren kan bruke underdatabehandlere, og på hvilke vilkår. Dette er et av punktene som oftest forhandles om, fordi det avgjør hvor mye kontroll du som kunde har over hvem som til slutt får tilgang til dataene dine.
• Bistand ved registrertes rettigheter (bokstav e). Databehandleren skal, så langt det er mulig, bistå deg med å svare på forespørsler fra registrerte, som innsyn, retting eller sletting. Dette punktet konkretiseres ofte med en frist, for eksempel at databehandleren skal svare innen ti virkedager.
• Bistand ved avvik og DPIA (bokstav f). Databehandleren skal bistå deg med å oppfylle plikter etter artikkel 32 til 36, inkludert varsling av avvik og vurdering av personvernkonsekvenser. Dette er punktet som binder sammen avtalen med de operasjonelle rutinene for bruddshåndtering.
• Sletting eller retur ved avtaleslutt (bokstav g). Etter avtalens opphør skal databehandleren, etter ditt valg, slette eller returnere alle personopplysninger, med mindre lagring er pålagt av annen lovgivning. Dette punktet forhandles ofte fordi leverandører gjerne vil ha backup-kopier lenger enn kunden er komfortabel med.
• Tilgjengeliggjøring for revisjon (bokstav h). Databehandleren skal gjøre tilgjengelig all informasjon som er nødvendig for å vise etterlevelse, og tillate og bidra til revisjoner, inkludert inspeksjoner. Dette er punktet der sertifiseringer som ISO 27001 ofte kommer inn som et praktisk alternativ til fysisk revisjon.

Det britiske datatilsynet ICO understreker at disse åtte punktene er obligatoriske uansett bransje. Norsk praksis følger samme linje, men Datatilsynets veiledning legger i tillegg vekt på at avtalen skal beskrive selve behandlingen konkret, ikke bare gjengi lovtekstens punkter ordrett.

Vedlegg 1–3: slik fyller du ut det som faktisk gjør avtalen etterprøvbar

Selve avtaleteksten sier lite om din virksomhet spesifikt. Det er vedleggene som gjør avtalen konkret, og det er ofte her ferdige maler svikter, fordi de leveres tomme og aldri blir fylt ut før signering.

Helsedirektoratets standardavtale bygger på nettopp denne strukturen: en generell avtaletekst pluss fyllbare vedlegg, og veilederen anbefaler at Vedlegg 1 og 2 alltid fylles ut, uansett bransje.

1. Vedlegg 1: beskrivelse av behandlingen. Her skal du liste formålet med behandlingen, varigheten, arten av behandlingen (for eksempel lagring, analyse eller sletting), kategoriene av personopplysninger (kontaktinfo, bilder, lokasjonsdata) og kategoriene av registrerte (ansatte, kunder, sjåfører). Uten dette vedlegget blir «formålet» med avtalen udefinert, og det gjør det vanskelig å vurdere om databehandleren faktisk holder seg innenfor mandatet sitt. Erfaring fra offentlige anskaffelser viser at Vedlegg 1 bør fylles ut før forhandlingene starter, ikke som en etterpåklokskap når avtalen skal signeres.
2. Vedlegg 2: tekniske og organisatoriske sikkerhetstiltak. Dette vedlegget skal beskrive konkrete tiltak: kryptering av data i ro og under overføring, tilgangsstyring basert på roller, logging av tilganger, rutiner for sikkerhetskopiering, og hvor dataene fysisk lagres. En generisk formulering som «vi følger bransjestandard» holder ikke. Vedlegget skal kunne leses av en tredjepart og gi et konkret bilde av hva som faktisk gjøres.
3. Vedlegg 3/4: administrative punkter. Her føres kontaktpersoner for personvernspørsmål hos begge parter, rutiner for revisjon (hvordan og hvor ofte revisjon kan gjennomføres), og en oppdatert liste over underdatabehandlere med navn, land og hva de behandler. Denne listen er noe av det som endrer seg oftest, og bør derfor ha en egen oppdateringsrutine knyttet til seg, ikke bare stå som et statisk bilag fra signeringsdatoen.

Profftips: Sett en kalenderpåminnelse for å gå gjennom Vedlegg 1–3 minst én gang i året. De fleste avvik oppstår ikke fordi avtalen var dårlig skrevet, men fordi virksomheten endret systemer eller leverandører uten å oppdatere vedleggene.

Regler for underdatabehandlere og overføring til tredjeland

Bruk av underdatabehandlere er ett av de områdene der avtaletekstens presisjon avgjør hvor mye kontroll du faktisk har. Artikkel 28(3) bokstav d krever at databehandleren enten får spesifikk eller generell forhåndsgodkjenning fra deg før nye underdatabehandlere tas i bruk.

Ved spesifikk godkjenning må databehandleren be om ditt samtykke for hver enkelt underdatabehandler, navngitt og beskrevet. Dette gir deg full oversikt, men er tungt å administrere for leverandører med mange underleverandører.

Ved generell godkjenning aksepterer du på forhånd at databehandleren kan bruke underdatabehandlere fritt, mot at du informeres om endringer og får en reell mulighet til å protestere. Dette er den vanligste modellen for SaaS-leverandører, men avtalen må da inneholde:

• En konkret frist for varsling før en ny underdatabehandler tas i bruk, typisk 14 til 30 dager.
• En reell innsigelsesrett, ikke bare en formalitet, der du kan si nei eller kreve avtalen avviklet dersom du ikke godtar endringen.
• En rutine for hvordan den oppdaterte listen over underdatabehandlere gjøres tilgjengelig, for eksempel via en offentlig side eller varsling per e-post.

Overføring til tredjeland, altså land utenfor EØS, krever et eget overføringsgrunnlag. Dette kan være en adekvansbeslutning fra EU-kommisjonen, standard personvernbestemmelser (SCC), eller andre godkjente mekanismer. Avtalen må vise til hvilket grunnlag som brukes, og for enkelte overføringer må virksomheten også dokumentere en tilleggsvurdering av om mottakerlandets lovgivning faktisk gir tilstrekkelig beskyttelse i praksis, ikke bare på papiret.

Dette er ikke noe du kan overlate til leverandørens standardvilkår uten å lese dem. Mange skytjenester krever at kunden aktivt godtar databehandleravtalen i et administrasjonspanel for at den skal gjelde for din organisasjon, og det samme gjelder ofte overføringsgrunnlaget: det ligger i et eget vilkårsdokument du må finne og verifisere selv, ikke noe som automatisk følger med kontoen din.

Varslingsfrister, sletting og revisjon i praksis

Loven sier at databehandleren skal bistå ved brudd, men sier ikke eksakt hvor raskt varsling skal skje. Dette er derfor et av punktene avtalen din bør konkretisere selv, fordi det avgjør om du i det hele tatt har tid til å reagere.

Datatilsynets veiledning peker på at en kontraktsfestet frist på 24 til 48 timer fra databehandleren er en fornuftig praksis. Grunnen er enkel: du som behandlingsansvarlig har selv en frist på 72 timer til å melde avvik til Datatilsynet. Hvis databehandleren bruker to av de tre døgnene før du får vite om bruddet, sitter du igjen med svært lite tid til å vurdere, dokumentere og sende inn meldingen.

Sletting og retur ved avtaleslutt er et annet punkt som ofte blir for vagt i praksis. En god avtale spesifiserer:

• Hvilken frist databehandleren har for sletting eller retur etter at avtalen er avsluttet, for eksempel 30 dager.
• Om sletting skal bekreftes skriftlig, og hvem som er ansvarlig for å sende denne bekreftelsen.
• Hva som gjelder for backup-kopier, siden disse ofte lagres lenger enn primærdataene av tekniske årsaker.

Når det gjelder revisjon, er ikke fysisk inspeksjon alltid praktisk eller nødvendig. For store skyleverandører er det vanlig å akseptere sertifiseringer som ISO 27001 eller tredjeparts revisjonsrapporter som dokumentasjon i stedet for at kunden selv reiser ut og inspekterer serverrom. Dette er en fornuftig løsning for mindre kunder som ikke har ressurser til egen revisjon, men avtalen bør da spesifisere hvilken sertifisering som gjelder, og at rapporten skal deles på forespørsel, ikke bare nevnes som en mulighet.

Sjekkliste og maler før du signerer

Før du signerer noe, er det noen kontrollpunkter som avgjør om avtalen faktisk holder vann, uavhengig av hvor godt den er formulert språklig.

For virksomheter som ikke har egen juridisk kompetanse, er det ofte tryggest å starte med en anerkjent mal i stedet for å skrive fra bunnen. SSA-malen som brukes ved offentlige anskaffelser passer godt for de fleste kommersielle SaaS-forhold, mens Helsedirektoratets standardavtale er spesielt tilpasset behandling av helseopplysninger og bør brukes der behandlingen omfatter denne typen sensitive data.

Uansett hvilken mal du starter med, bør du sette en fast rutine for oppfølging. En årlig gjennomgang av vedleggene, kombinert med en kontroll hver gang du tar i bruk en ny underleverandør, fanger opp de fleste avvik før de blir et problem. Dokumenter alltid når vedleggene ble sist oppdatert og hvem som godkjente endringen.

Vanlige feil og hva du bør stille krav om i forhandlingene

De fleste problemene med databehandleravtaler oppstår ikke fordi avtalen mangler juridisk språk, men fordi vedleggene aldri ble fylt ut riktig. Datafolkas gjennomgang av vanlige avvik peker på noen mønstre som går igjen hos små og mellomstore virksomheter.

De vanligste feilene er:

• Tomme eller generiske vedlegg. Databehandleren leverer en standardmal der Vedlegg 2 bare sier «vi følger god sikkerhetspraksis» uten å nevne kryptering, tilgangsstyring eller loggføring konkret.
• Manglende liste over underdatabehandlere. Avtalen nevner at underdatabehandlere kan brukes, men det finnes ingen oppdatert liste å kontrollere mot.
• Uklare revisjonsrettigheter. Avtalen sier at revisjon er mulig, uten å si noe om hvordan, hvor ofte, eller hva som skjer hvis leverandøren nekter tilgang.
• Ingen konkret slettemekanisme. Avtalen sier data skal slettes ved avtaleslutt, men gir ingen frist og ingen bekreftelsesrutine.

Når du forhandler en avtale, bør du prioritere fire punkter spesielt. Be om en navngitt og oppdatert liste over underdatabehandlere, ikke bare en generell klausul. Krev en konkret varslingsfrist ved brudd, ikke formuleringer som «uten ugrunnet opphold». Insister på at Vedlegg 2 beskriver faktiske tiltak, ikke honnørord. Og sørg for at ansvarsfordelingen ved brudd er tydelig: hvem betaler hva, og hvem har bevisbyrden dersom noe går galt.

Dette er forhandlingspunkter, ikke fasitformuleringer. Den konkrete kontraktsteksten bør uansett vurderes av juridisk kompetanse tilpasset din virksomhet, særlig når avtalen gjelder sensitive persondata eller store datamengder.

Slik bør en flåte-SaaS regulere bilder, GPS og skiftdata

En løsning for skiftkontroll og skadedokumentasjon av kjøretøy behandler flere typer personopplysninger samtidig: bilder av bilen og eventuelt sjåføren i bakgrunnen, GPS-posisjon, og informasjon knyttet til den enkelte sjåførens skift. Alt dette må inn i Vedlegg 1, spesifisert som egne kategorier, ikke samlet under en vag merkelapp som «kjøretøydata».

Vedlegg 2 må for en slik løsning beskrive konkret hvordan bildene lagres, hvor lenge de beholdes, og hvem som har tilgang. En rutine for automatisk sletting av bilder som ikke lenger er aktuelle, altså bilder uten registrert skade eller tvist, er nettopp den typen tiltak som hører hjemme i sikkerhetsvedlegget, ikke bare i en generell personvernpolicy.

En databehandleravtale for denne typen tjeneste er ikke fullført før vedleggene viser de faktiske tekniske rutinene: rollebasert tilgang mellom admin og sjåfør, hvor lenge bilder lagres før automatisk sletting, og at hostingen skjer i Norge. Uten disse detaljene er avtalen bare en mal som aldri ble ferdigstilt.

Norsk hosting bør nevnes eksplisitt i vedlegget, fordi det er relevant for vurderingen av om data forlater EØS-området i det hele tatt. Hvis løsningen ikke bruker underdatabehandlere utenfor EØS, er dette enkelt å dokumentere. Hvis den gjør det, for eksempel via en skyleverandør med servere i tredjeland, må overføringsgrunnlaget beskrives konkret i tillegg.

Til slutt må avtalen si noe om hvordan brudd håndteres i praksis for denne typen data. Hvis GPS-loggen eller bildedatabasen skulle bli utsatt for uautorisert tilgang, må rutinen for varsling og bistand ved DPIA være beskrevet på forhånd, ikke improviseres når noe faktisk skjer. Se også hvordan bilder og GPS-data om ansatte bør håndteres i praksis for flåteadministrasjon.

Hva jeg mener virksomheter overser mest

Den vanligste misforståelsen jeg ser, er troen på at en signert standardmal automatisk betyr etterlevelse. Det gjør den ikke. En mal fra Datatilsynet eller en SSA-basert avtale er et godt skjelett, men skjelettet uten utfylte vedlegg er verdiløst i en revisjon eller ved et faktisk avvik.

Det andre jeg mener blir underprioritert, er oppfølgingsrutinen. Virksomheter bruker ofte flere uker på å forhandle selve avtaleteksten, men null tid på å planlegge hvordan Vedlegg 1 til 3 skal oppdateres når leverandørforholdet endrer seg. En liste over underdatabehandlere fra 2023 er ikke bare utdatert, den er potensielt feilaktig dokumentasjon dersom noen ber om å se den i dag.

Start heller med kartleggingen: se på egen behandlingsprotokoll før du i det hele tatt setter deg ned med avtaleteksten. Fyll ut vedleggene konkret, gjerne før forhandlingen starter, ikke etter. Og sett en fast årlig frist for å kontrollere at underdatabehandlerlisten og sikkerhetstiltakene fortsatt er riktige. Disse tre stegene løser flertallet av problemene jeg ser i praksis, uavhengig av hvor godt selve kontraktsteksten er skrevet.

— Sejad

Fleetvakt og databehandleravtalens praktiske krav

En løsning for skiftkontroll og skadedokumentasjon kan dekke de tekniske punktene en databehandleravtale krever dokumentasjon på, ikke bare avtaletekst i teorien. En slik tjeneste dokumenterer kjøretøyskader gjennom bilder tatt ved hvert skift, verifisert av AI mot skiltgjenkjenning, med norsk hosting og rutiner for automatisk sletting av bilder som ikke lenger er aktuelle.

Det betyr at Vedlegg 2 i din databehandleravtale kan beskrive konkrete, etterprøvbare tiltak: rollebasert tilgang mellom admin og sjåfør, dokumentert lagringstid for bilder, og en tydelig norsk lagringslokasjon i stedet for uklare skyløsninger spredt over flere land. For virksomheter med flere kjøretøy erstatter dette upresise løsninger som bildeutveksling i chattegrupper, der ingen egentlig vet hvor lenge bildene ligger eller hvem som har sett dem. Se funksjonene til Fleetvakt eller sjekk prisene for å finne ut om løsningen passer din flåte.

Kilder

Før du signerer en databehandleravtale, er det verdt å ha disse kildene ved hånden, gjerne lagret som PDF-kopier med dato for når du sist kontrollerte dem:

• Datatilsynet: Hva må en databehandleravtale inneholde?
• Helsedirektoratet: Veileder - Standard databehandleravtale

Lagre kopier lokalt og noter når vedleggene sist ble godkjent internt. Det gir deg dokumentasjon å vise til dersom noen, en kunde, en revisor eller Datatilsynet, ber om å se hvordan avtalen faktisk ble håndtert.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Anbefalinger

• Bilder og GPS av ansatte: hva du må ha på plass
• Hvem skadet firmabilen? Slik dokumenterer du det