Er IKT-selskapet vårt databehandler eller felles behandlingsansvarlig?

Vi har lett etter en norsk veiledning som besvarer det direkte for interkommunale IKT-selskaper. Den finnes ikke. Datatilsynets veiledning om felles behandlingsansvar gir generiske eksempler — en skytjeneste er databehandler, en nettjeneste som bruker opplysningene til egen statistikk er trolig felles behandlingsansvarlig — og nevner verken kommuner eller interkommunale selskaper.

Det betyr at svaret må utledes fra prinsippene. Her er utledningen, og de fire stedene den går galt i praksis.

Hva forordningen faktisk skiller på

Artikkel 26 nr. 1 definerer felles behandlingsansvar:

«Dersom to eller flere behandlingsansvarlige i fellesskap fastsetter formålene med og midlene for behandlingen, skal de være felles behandlingsansvarlige.»

Artikkel 28 regulerer databehandleren: en som behandler personopplysninger på vegne av den behandlingsansvarlige, etter instruks, og som ikke selv fastsetter formålet.

Skillet er ikke hvem som har tilgang til opplysningene. Det er hvem som bestemmer hvorfor de behandles.

Datatilsynets formulering er presis: en felles behandlingsansvarlig har «lovlig adgang til å behandle opplysningene» og kan bruke dem til egne formål. En databehandler «har ikke lovlig adgang til å bestemme formålet eller behandle de konkrete opplysningene til egne formål».

Og så artikkel 28 nr. 10, som er den bestemmelsen som gjør spørsmålet farlig i praksis: dersom en databehandler selv fastsetter formål og midler i strid med avtalen, skal databehandleren anses for å være behandlingsansvarlig for den behandlingen. Du kan altså ikke avtale deg bort fra rollen. Rollen følger av hva som faktisk skjer.

Testen, i fire spørsmål

Still disse fire om det interkommunale IKT-selskapet. Svarene avgjør rollen for hver enkelt behandling — ikke for selskapet som helhet.

1. Hvem bestemmer hvilke opplysninger som skal inn i systemet?

Bestemmer kommunen det, og IKT-selskapet bare drifter, peker det mot databehandler. Bestemmer IKT-selskapet det, fordi de har valgt løsningen og satt datamodellen, blir bildet mer sammensatt.

2. Kan IKT-selskapet bruke opplysningene til noe eierkommunene ikke har bedt om?

Driftsstatistikk på tvers av eierkommunene. Kapasitetsplanlegging. Ytelsesmåling av egne tjenester. Rapportering til representantskapet. Hvis svaret er ja på noen av disse, og formålet er selskapets eget og ikke kommunens, er selskapet behandlingsansvarlig for den behandlingen — uansett hva avtalen sier.

3. Hvem har valgt løsningen?

Har IKT-selskapet valgt fagsystemet på vegne av femten kommuner, uten at hver enkelt kommune gjorde en selvstendig vurdering, har selskapet i realiteten fastsatt et vesentlig middel for behandlingen. Det trekker mot felles behandlingsansvar.

4. Hvem svarer innbyggeren når hun ber om innsyn?

Dette er lakmustesten. En databehandler skal bistå den behandlingsansvarlige med å oppfylle innsynsretten. En felles behandlingsansvarlig kan bli krevd direkte — artikkel 26 fastslår at den registrerte kan utøve sine rettigheter «med hensyn til og overfor hver av de behandlingsansvarlige», uavhengig av hva de har avtalt seg imellom.

Klarer selskapet ikke å svare, blir svaret gitt av ordningen dere har i praksis, ikke av den dere har på papiret.

Selskapsformen avgjør mindre enn de fleste tror

Norsk kommunal sektor har tre regulerte samarbeidsformer som er relevante her, i tillegg til aksjeselskapet.

Interkommunalt selskap (IKS) etter lov om interkommunale selskaper er et eget rettssubjekt med representantskap og styre. Det kan være databehandler for eierkommunene, og det er den vanlige konstruksjonen. Men et eget rettssubjekt med eget styre, eget budsjett og egen strategi har lettere for å utvikle egne formål enn en avdeling har.

Kommunalt oppgavefellesskap etter kommuneloven kapittel 19 kan være eget rettssubjekt eller ikke, avhengig av hva samarbeidsavtalen sier. Er det ikke eget rettssubjekt, blir rollefordelingen en annen — da er det representantkommunen som er behandlingsansvarlig.

Vertskommunesamarbeid etter kommuneloven kapittel 20 innebærer at én kommune utfører oppgaver på vegne av de andre. Kommunal- og distriktsdepartementet presiserte i en tolkningsuttalelse 25. juni 2026 at samarbeidskommunens kommunedirektør ikke har fullt internkontrollansvar for oppgaver utført av vertskommunen, men et begrenset ansvar for å påse at oppgavene utføres i tråd med lover og forskrifter. Det er en parallell til personvernrollene, men ikke det samme spørsmålet — og det er verdt å holde dem fra hverandre.

Poenget: selskapsformen forteller deg hvem som kan være part i avtalen. Den forteller deg ikke hvem som fastsetter formålet. Det gjør bare den faktiske arbeidsdelingen.

De fire feilene som går igjen

Feil 1: Én avtale for alt

Et IKT-selskap som drifter både fagsystemer for barnevern, e-postplattform, telefoni og felles innkjøpsløsning har trolig forskjellig rolle i hver av dem. Én databehandleravtale som dekker «IKT-tjenester» skjuler at rollen varierer, og skjuler dermed også hvilke behandlinger som mangler et grunnlag.

KS' databehandleravtalemal er utgangspunktet de fleste bruker, og den er god. Den er ikke ment å dekke ett selskap på tvers av ti ulike behandlinger uten at bilagene faktisk fylles ut per behandling.

Feil 2: Tenanteierskapet er ikke avklart

Dette er den tekniske versjonen av spørsmålet, og den blir sjelden stilt.

Hvem eier Microsoft Entra-tenanten? Hvem står som Global Administrator? Hvis IKT-selskapet har full administrativ kontroll over en tenant der kommunens data ligger, og kommunen ikke selv har noen mekanisme for å se hva selskapet gjør i den, er kommunen behandlingsansvarlig for en behandling hun ikke kan påvise etterlevelse av. Det er direkte i strid med ansvarlighetsprinsippet i artikkel 5 nr. 2.

Dette er ikke et argument for at kommunen skal ha egne administratorrettigheter. Det er et argument for at kommunen må kunne se — i etterkant, uten å be om det — hvem som gjorde hva.

Feil 3: Underdatabehandlerne stopper ved IKT-selskapet

En kommune som har databehandleravtale med et IKS, som har avtale med Microsoft, som har underleverandører, har en kjede. Artikkel 28 krever at underdatabehandlere godkjennes, og at kjeden er kjent.

I praksis stopper listen ofte ved IKS-et. Da vet ikke kommunen hvem som faktisk behandler opplysningene, og protokollen etter artikkel 30 er ufullstendig på det punktet som betyr mest.

Feil 4: Ingen har skrevet ned det vesentlige innholdet i ordningen

Er dere felles behandlingsansvarlige, krever artikkel 26 at ordningen fastsetter ansvarsfordelingen, «særlig med hensyn til utøvelsen av den registrertes rettigheter», og at det vesentligste innholdet gjøres tilgjengelig for den registrerte.

Det siste kravet overses nesten alltid. Det betyr i praksis at ordningen skal være mulig for en innbygger å finne — typisk i personvernerklæringen — ikke bare mulig for et tilsyn å be om.

Hva som er annerledes i et flerkommunalt Entra-miljø

Det tekniske og det juridiske henger sammen her på en måte de sjelden gjør ellers.

Driftes femten kommuner i én felles tenant, må dataadskillelsen mellom dem skje logisk. Microsoft Entra ID har administrative enheter til nettopp det: en administrator kan avgrenses til brukere, grupper og enheter i én enhet i stedet for hele tenanten. Det er en reell mekanisme, og den krever Entra ID P1 for hver administrator som får en slik avgrenset rolle.

Men administrative enheter har begrensninger som betyr noe her. De kan ikke nøstes. De kan bare inneholde brukere, grupper og enheter. Og legger du en gruppe i en administrativ enhet, kommer gruppen selv under avgrensningen — ikke gruppens medlemmer. En administrator avgrenset til Kommune A kan altså styre en gruppe som er lagt i Kommune A, men ikke nødvendigvis medlemmene i den, med mindre de også ligger der.

Driftes de i hver sin tenant, er dataadskillelsen løst, men da har du femten separate revisjonsspor, femten sett med administratorroller, og ingen innebygd mekanisme i Entra ID for å administrere den ene tenanten fra den andre. Vi går gjennom det valget i detalj i artikkelen om identitetsarkitektur for interkommunale IKT-selskaper.

Ingen av de to arkitekturene besvarer rollespørsmålet. Men de avgjør hvor vanskelig det er å dokumentere svaret.

Det korte svaret

De fleste interkommunale IKT-selskaper er databehandlere for eierkommunene i de fleste behandlinger, og behandlingsansvarlige for et lite antall behandlinger de gjør for egen regning — typisk driftsstatistikk, kapasitetsplanlegging og egen HR.

Det er en helt vanlig og helt håndterbar konstruksjon. Det som ikke er håndterbart, er å ikke ha tatt stilling til hvilke behandlinger som hører hvor, og å oppdage det når en innbygger ber om innsyn eller et tilsyn ber om protokollen.

Gjør øvelsen behandling for behandling, ikke selskap for selskap. Den tar en dag.

Entra Logic er norsk programvare for styrt administrasjon av Microsoft Entra ID, bygget for å drifte mange selskaper og kommuner fra én flate. Forespørsel, godkjenning og teknisk utførelse ligger i samme post, per tenant, slik at både kommunen og IKT-selskapet kan se hva som er gjort uten å be noen om det. Vi tilbyr en gratis tilgangsgjennomgang av Entra ID-miljøet, med skriftlig rapport og konkrete funn. Vi endrer ingenting underveis.

Start gratis → · Les mer om Entra Logic for kommune og interkommunalt IT →

Kilder

• Personvernforordningen artikkel 26, 28 (særlig nr. 10), 5 nr. 2 og 30
• Datatilsynet: Felles behandlingsansvar; Behandlingsansvarlig og databehandler
• Lov om interkommunale selskaper (LOV-1999-01-29-6)
• Kommuneloven (LOV-2018-06-22-83) kapittel 19 og 20
• Kommunal- og distriktsdepartementet: Internkontrollansvar for samarbeidskommuner i et vertskommunesamarbeid, tolkningsuttalelse 25.06.2026
• KS: Databehandleravtale, mal versjon 2
• Microsoft: Administrative units in Microsoft Entra ID (learn.microsoft.com), hentet 19.08.2026