Stikkord: microsoft365

E-post som passerer tre kontroller for avsender, signatur og domene-policy.

SPF, DKIM og DMARC: e-postsikkerhet uten mystikk

Skrevet av Svein Tore den juli 1, 2026. Publisert i IT-sikkerhet. Ingen kommentarer til SPF, DKIM og DMARC: e-postsikkerhet uten mystikk

Oppdatert 8. september 2026.

`r`n`r`n

E-post er fortsatt en av de viktigste arbeidsflatene i små virksomheter. Den brukes til tilbud, fakturaer, kundehenvendelser, passordreset, møter, dokumenter og intern avklaring. Derfor blir e-post også misbrukt.

Et vanlig problem er at en svindler prøver å sende e-post som ser ut til å komme fra et kjent domene. Det kan være et forsøk på phishing, fakturasvindel eller innloggingstyveri. SPF, DKIM og DMARC er tre tekniske tiltak som gjør dette vanskeligere.

De løser ikke all e-postsikkerhet alene. De stopper ikke alle falske meldinger, og de erstatter ikke tofaktor, opplæring eller godt spamfilter. Men de gir mottakende e-postsystemer bedre grunnlag for å vurdere om en melding faktisk er sendt på vegne av domenet ditt.

Først: avsenderfeltet i e-post kan lyve

E-post ble ikke opprinnelig laget med sterk identitetskontroll. En melding kan vise en avsenderadresse som ser riktig ut, selv om meldingen teknisk kommer fra et annet sted.

Det betyr ikke at alle e-poster er upålitelige. Det betyr at domenet trenger noen ekstra kontroller. De viktigste er:

SPF: hvilke systemer har lov til å sende e-post for domenet?
DKIM: er meldingen signert av et system som har nøkkel for domenet?
DMARC: hva skal mottakere gjøre når SPF eller DKIM ikke stemmer med avsenderdomenet?

Tenk på dette som tre lag. SPF peker på godkjente sendekilder. DKIM signerer meldingen. DMARC knytter kontrollene til domenet mottakeren faktisk ser i Fra-feltet.

SPF: en liste over godkjente sendekilder

SPF står for Sender Policy Framework. I praksis er det en DNS-post som forteller hvilke servere eller tjenester som kan sende e-post for domenet.

For en virksomhet som bruker Microsoft 365, vil SPF ofte inneholde Microsoft sin e-postplattform. Hvis virksomheten også sender fra et nyhetsbrevverktøy, et regnskapssystem, en nettbutikk eller et kontaktskjema, må det vurderes om disse også er legitime sendekilder.

SPF handler derfor ikke bare om å lime inn en standardtekst. Det handler om å vite hvor e-post faktisk sendes fra.

Vanlige feil med SPF er:

domenet har ingen SPF-post
domenet har flere SPF-poster i stedet for én samlet
gamle tjenester står fortsatt som godkjente
nye tjenester mangler og får leveringsproblemer
hoveddomenet brukes til mange tredjepartstjenester uten ryddig oversikt

SPF er nyttig, men ikke komplett. Blant annet sjekker SPF den tekniske konvoluttavsenderen, ikke nødvendigvis domenet brukeren ser i Fra-feltet. Derfor trengs også DKIM og DMARC.

DKIM: en signatur på meldingen

DKIM står for DomainKeys Identified Mail. Med DKIM signeres utgående e-post kryptografisk. Mottakeren kan kontrollere signaturen mot en offentlig nøkkel som ligger i DNS.

Poenget er å vise at meldingen er sendt gjennom en løsning som har lov til å signere for domenet, og at viktige deler av meldingen ikke er endret underveis.

I Microsoft 365 krever DKIM for eget domene vanligvis at det legges inn CNAME-poster i DNS, og at DKIM aktiveres i riktig administrasjonsportal. Andre e-postleverandører har egne fremgangsmåter.

DKIM er spesielt nyttig fordi det tåler enkelte situasjoner bedre enn SPF, for eksempel når e-post videresendes. Men DKIM alene er heller ikke nok. En angriper kan signere e-post med et annet domene og likevel vise et annet navn i meldingen. DMARC hjelper med å kontrollere sammenhengen.

DMARC: policyen som binder det sammen

DMARC står for Domain-based Message Authentication, Reporting and Conformance. Det er også en DNS-post.

DMARC gjør to viktige ting:

den kontrollerer at domenet i SPF eller DKIM henger sammen med domenet mottakeren ser som avsender
den sier hva mottakende systemer bør gjøre når kontrollene feiler

DMARC kan settes opp gradvis. Mange starter med p=none, som gir rapportering uten at meldinger blokkeres. Når man har oversikt over legitime sendekilder, kan policyen strammes inn til quarantine eller reject.

For små virksomheter er dette viktig: ikke gå rett til streng blokkering hvis dere ikke vet hvilke systemer som faktisk sender e-post. Da kan kontaktskjema, fakturasystem, booking, nettbutikk eller gamle varsler plutselig slutte å levere.

Strengere krav fra store mottakere

E-postautentisering er ikke lenger bare en anbefalt forbedring for store utsendere. Googles krav til avsendere sier at alle som sender til personlige Gmail-kontoer må bruke SPF eller DKIM. Domener som sender mer enn 5 000 meldinger per dag til Gmail-kontoer, må bruke SPF, DKIM og DMARC, og minst SPF- eller DKIM-domenet må samsvare med domenet i Fra-feltet.

Microsoft innførte tilsvarende krav for domener som sender mer enn 5 000 meldinger per dag til forbrukeradresser hos Outlook, Hotmail og Live. Kravene omfatter SPF, DKIM og DMARC, med minst p=none for DMARC.

Disse tersklene gjelder store utsendelser til bestemte mottakertjenester. De betyr ikke at mindre virksomheter kan hoppe over autentisering. SPF, DKIM og DMARC beskytter også små domener mot etterligning og gjør feilsøking av leveringsproblemer enklere.

Hvorfor dette betyr noe for små virksomheter

Små virksomheter tenker ofte at dette er et problem for store selskaper. Det stemmer ikke. Et lite domene kan være attraktivt nettopp fordi mottakere stoler på det lokalt.

Hvis domenet misbrukes i falsk e-post, kan konsekvensen bli:

kunder får svindelmeldinger som ser ut til å komme fra virksomheten
ansatte blir lurt av meldinger som ser interne ut
e-post havner oftere i søppelpost
leverandører og kunder mister tillit
oppryddingen tar tid selv om virksomheten ikke ble teknisk kompromittert

God e-postautentisering handler derfor både om sikkerhet og om leveringskvalitet. Det hjelper andre e-postsystemer å skille legitim e-post fra misbruk.

Start med kartlegging, ikke DNS-endring

Den tryggeste starten er å lage en enkel liste over alle steder virksomheten sender e-post fra.

Sjekk særlig:

Microsoft 365, Google Workspace eller annen primær e-postløsning
webhotell eller gammel mailserver
kontaktskjema på nettsiden
WordPress, WooCommerce eller andre publiseringssystemer
regnskap, faktura og betalingsløsninger
nyhetsbrev og markedsføringsverktøy
CRM, supportsystem og booking
skrivere, skannere, overvåking og varsling

For hvert punkt bør dere spørre:

sender systemet e-post med vårt domene som avsender?
sender det direkte, via Microsoft 365, via webhotellet eller via en tredjepart?
finnes det dokumentasjon fra leverandøren om SPF, DKIM eller DMARC?
kan tjenesten heller sende fra et eget underdomene?

Denne kartleggingen er ofte mer verdifull enn selve DNS-endringen. Den viser også hvor det finnes gamle løsninger ingen lenger eier tydelig.

Ikke bruk hoveddomenet ukritisk til alt

Hvis mange tredjepartstjenester sender som firma.no, blir SPF og DMARC fort vanskeligere å kontrollere. For nyhetsbrev, kampanjer eller systemutsending kan det være bedre å bruke et underdomene, for eksempel nyheter.firma.no eller post.firma.no.

Det beskytter hoveddomenet bedre. Hvis en ekstern utsending feiler, påvirker det ikke nødvendigvis den vanlige e-posten fra ansatte like mye.

Dette må planlegges. Et underdomene som sender e-post trenger også riktig SPF, DKIM og DMARC. Poenget er ikke å skjule noe, men å skille ulike typer e-post tydeligere.

Vær forsiktig med gamle og doble DNS-poster

E-postproblemer oppstår ofte fordi DNS har blitt endret mange ganger over flere år. En virksomhet kan ha byttet webhotell, flyttet e-post til Microsoft 365, beholdt et kontaktskjema, lagt til et nyhetsbrevverktøy og senere glemt hva som fortsatt er i bruk.

Typiske faresignaler er:

flere TXT-poster som starter med v=spf1
SPF-poster med gamle leverandører ingen kjenner igjen
DMARC satt til p=none uten at noen leser rapportene
manglende DKIM for eget domene
tjenester som sender e-post uten å være dokumentert
ingen vet hvor DNS faktisk administreres

Rydding bør gjøres kontrollert. Ta vare på nåværende verdier før endring, og test sending fra viktige systemer etterpå.

En praktisk rekkefølge

For en liten virksomhet er en god rekkefølge ofte:

Finn hvor DNS administreres.
Lag liste over alle systemer som sender e-post.
Kontroller eksisterende MX, SPF, DKIM og DMARC.
Rett åpenbare feil, men ikke fjern ukjente sendekilder før de er vurdert.
Aktiver eller kontroller DKIM hos primær e-postleverandør.
Sett opp DMARC med rapportering.
Følg med på rapporter og leveringsproblemer.
Stram inn DMARC-policyen gradvis når legitime sendere er kartlagt.
Dokumenter hvem som har ansvar for fremtidige endringer.

Dette er ikke et engangsprosjekt som aldri må sees på igjen. Hver gang virksomheten tar i bruk et nytt system som sender e-post, bør e-postautentisering vurderes.

Hva bør ikke gjøres i blinde?

Unngå disse snarveiene:

ikke kopier SPF fra en tilfeldig guide uten å vite egne sendekilder
ikke legg inn flere SPF-poster
ikke sett DMARC rett til reject uten kartlegging
ikke fjern gamle DNS-poster før du vet om de fortsatt brukes
ikke anta at webhotell, DNS og e-post ligger hos samme leverandør
ikke glem kontaktskjema, fakturasystem, nettbutikk og skannere

Det er også lurt å skille mellom e-postautentisering og innholdssikkerhet. SPF, DKIM og DMARC gjør domenemisbruk vanskeligere, men de garanterer ikke at en melding er trygg. En legitim konto kan fortsatt bli misbrukt hvis passordet er stjålet.

Kort oppsummert

SPF, DKIM og DMARC er grunnmuren for tryggere e-postdomener.

SPF sier hvilke systemer som kan sende. DKIM signerer meldinger. DMARC binder kontrollene til avsenderdomenet og gir en policy for hva mottakere bør gjøre når noe ikke stemmer.

For små virksomheter er beste start å kartlegge alle sendekilder, rydde gamle DNS-poster forsiktig, aktivere DKIM hos e-postleverandøren og bruke DMARC gradvis. Da blir domenet vanskeligere å misbruke, samtidig som legitim e-post får bedre sjanse til å komme frem.

Videre lesing

Kontrollert kryptert dataflyt mellom europeisk og amerikansk sky med sjekkliste for personvern

Kan man lagre personopplysninger i amerikanske skyløsninger?

Skrevet av Svein Tore den mai 22, 2026. Publisert i IT-sikkerhet. 1 kommentar til Kan man lagre personopplysninger i amerikanske skyløsninger?

Ja, norske virksomheter kan lagre og behandle personopplysninger i amerikanske skyløsninger. Det er ikke automatisk ulovlig å bruke en amerikansk leverandør. Men virksomheten må vite om personopplysninger faktisk overføres til USA, hvilket overføringsgrunnlag som brukes, og om resten av behandlingen oppfyller GDPR.

Det korte svaret er derfor ikke et ubetinget ja eller nei. Microsoft 365, Google Workspace og andre amerikanske skytjenester må vurderes ut fra den konkrete tjenesten, avtaleparten, underleverandørene, tilgangene og opplysningene som behandles.

Denne artikkelen gir en praktisk fremgangsmåte. Den er generell informasjon og ikke juridisk rådgivning i en konkret sak.

Først: Det finnes ikke en egen kategori som heter «GDPR-data»

GDPR gjelder personopplysninger: opplysninger som kan knyttes til en identifisert eller identifiserbar person. Det kan være navn, e-postadresse, kundenummer, IP-adresse, posisjonsdata, bilder eller opplysninger om arbeidsforhold.

Noen opplysninger krever ekstra beskyttelse. Det gjelder blant annet helseopplysninger, biometriske opplysninger brukt til entydig identifikasjon, politisk oppfatning og fagforeningsmedlemskap. Risikoen øker også når opplysningene brukes i stort omfang, til overvåking eller til beslutninger som får betydelige konsekvenser for mennesker.

Før virksomheten vurderer leverandørland, må den derfor kartlegge hvilke personopplysninger tjenesten skal behandle, hvorfor de behandles, og hvor alvorlig konsekvensen kan bli dersom noe går galt.

Når er bruk av en skytjeneste en overføring til et tredjeland?

GDPR kapittel V gjelder når en behandlingsansvarlig eller databehandler som omfattes av GDPR, gjør personopplysninger tilgjengelige for en annen behandlingsansvarlig eller databehandler i et land utenfor EØS.

Det europeiske personvernrådet beskriver kriteriene i sine retningslinjer om internasjonale overføringer. En overføring kan skje ved lagring, men også ved fjernaksess, support, administrasjon eller annen tilgjengeliggjøring fra et tredjeland.

Leverandørens nasjonalitet er ikke alene avgjørende. En amerikansk eier betyr ikke automatisk at enhver behandling i et europeisk datterselskap er en overføring til USA. Samtidig er «data lagres i Europa» ikke nok dersom amerikanske enheter eller andre underleverandører kan få tilgang fra et tredjeland.

Virksomheten må kartlegge den faktiske dataflyten, ikke bare lese adressen til datasenteret.

Overføring til en DPF-sertifisert virksomhet

EU-kommisjonen vedtok 10. juli 2023 en beslutning om tilstrekkelig beskyttelsesnivå for EU-US Data Privacy Framework, forkortet DPF. Beslutningen gjelder amerikanske kommersielle virksomheter som deltar i rammeverket.

Når den konkrete amerikanske mottakeren står på den offisielle DPF-listen, kan overføringen bygge på beslutningen etter GDPR artikkel 45. Det kreves da ikke et eget overføringsverktøy etter artikkel 46 for den aktuelle overføringen.

Kontrollen må være konkret:

Stemmer navnet på den sertifiserte virksomheten med den juridiske mottakeren i avtalen?
Er sertifiseringen aktiv?
Dekker oppføringen de aktuelle personopplysningene og tjenestene?
Er eventuelle amerikanske underleverandører også dekket, eller brukes et annet grunnlag for dem?

EDPBs oppdaterte spørsmål og svar fra 2026 forklarer hva europeiske virksomheter bør kontrollere før de bruker DPF som overføringsgrunnlag.

Når mottakeren ikke står på DPF-listen

Hvis mottakeren ikke omfattes av DPF, må virksomheten finne et annet gyldig overføringsgrunnlag. Vanlige alternativer er EUs standard personvernbestemmelser, Standard Contractual Clauses eller SCC, og bindende virksomhetsregler i konsern.

Et signert sett med standardklausuler er ikke nødvendigvis slutten på vurderingen. Etter Schrems II må virksomheten undersøke om avtalen gir reell beskyttelse i den konkrete overføringen. Det kan være nødvendig med en vurdering av lovgivning, praksis, datatyper, mottaker og tekniske tiltak. Denne vurderingen omtales ofte som en Transfer Impact Assessment.

Aktuelle supplerende tiltak kan være sterk kryptering, kundestyrte nøkler, pseudonymisering, begrenset fjernaksess og tydelige rutiner for myndighetsforespørsler. Tiltaket må faktisk beskytte mot den identifiserte risikoen. Kryptering er ikke et tilstrekkelig svar dersom mottakeren trenger både data og nøkkel i klartekst for å levere tjenesten.

Den juridiske utviklingen etter Schrems II og statusen for DPF er forklart mer detaljert i Hva betyr Schrems II for skylagring?

DPF løser bare overføringsdelen

En DPF-oppføring gjør ikke en skytjeneste automatisk i samsvar med GDPR. Beslutningen løser spørsmålet om overføringsgrunnlag for en kvalifisert mottaker. Alle de vanlige pliktene gjelder fortsatt.

Virksomheten må blant annet ha:

et gyldig behandlingsgrunnlag for formålet
tydelig informasjon til de registrerte
dataminimering og hensiktsmessige lagringstider
databehandleravtale når leverandøren er databehandler
kontroll med underleverandører
egnede tekniske og organisatoriske sikkerhetstiltak
rutiner for innsyn, retting, sletting og dataportabilitet
vurdering av personvernkonsekvenser når behandlingen sannsynligvis medfører høy risiko

Det er fullt mulig å ha et gyldig overføringsgrunnlag og samtidig bryte andre deler av GDPR. Det motsatte gjelder også: En sikker og nyttig tjeneste kan ikke brukes lovlig hvis selve overføringen mangler grunnlag.

Hva betyr europeisk datalagring?

Valg av europeisk dataregion kan redusere dataflyt, forsinkelse og enkelte juridiske risikoer. Det kan også være et viktig krav i kontrakten. Men ord som «EU data residency» eller «European region» må oversettes til konkrete svar.

Spør leverandøren:

Ligger hoveddata, sikkerhetskopier og logger i EØS?
Kan support eller driftspersonell utenfor EØS få tilgang?
Flyttes telemetri, søkeindekser eller sikkerhetsdata til andre regioner?
Kan kunden begrense underleverandører og fjernaksess?
Hvilken juridisk enhet mottar personopplysningene?

En kontrakt som sier «data lagres i Europa» kan være verdifull, men den erstatter ikke et kart over hele behandlingskjeden.

Er europeisk eller egen drift alltid tryggere?

Nei. En europeisk leverandør kan forenkle tredjelandsvurderingen, men må fortsatt ha god sikkerhet, ryddige avtaler og kontroll med underleverandører. En feilkonfigurert europeisk skytjeneste kan være mindre sikker enn en godt konfigurert global tjeneste.

Egen drift gir større teknisk kontroll, men flytter også ansvaret for oppdateringer, sikkerhetskopi, overvåking, tilgangsstyring og hendelseshåndtering til virksomheten. Kontroll uten kapasitet og kompetanse er ikke det samme som beskyttelse.

Leverandørvalg bør derfor bygge på en samlet vurdering av personvern, sikkerhet, funksjon, kompetanse, kostnad og mulighet for å bytte løsning senere.

En praktisk beslutningsrekkefølge

Kartlegg opplysningene. Hvilke personopplysninger skal behandles, og hvor risikofylte er de?
Kartlegg aktørene. Finn avtalepart, databehandlere, underleverandører og land.
Finn dataflyten. Ta med lagring, sikkerhetskopi, fjernsupport, administrasjon og logger.
Fastslå overføringsgrunnlaget. Kontroller DPF-oppføring eller dokumenter et annet grunnlag.
Vurder faktisk beskyttelse. Ved behov, gjennomfør TIA og velg supplerende tiltak.
Kontroller resten av GDPR. Formål, behandlingsgrunnlag, avtaler, sikkerhet, rettigheter og sletting gjelder uansett.
Dokumenter og følg opp. Gjennomgå vurderingen når tjenesten, underleverandørene eller rettstilstanden endres.

Vanlige spørsmål

Er Microsoft 365 eller Google Workspace automatisk ulovlig?

Nei. Lovligheten avhenger av oppsettet, dataflyten, den juridiske mottakeren, overføringsgrunnlaget og hvordan virksomheten oppfyller øvrige GDPR-krav.

Holder det at leverandøren er DPF-sertifisert?

DPF kan gi overføringsgrunnlag til den sertifiserte mottakeren. Virksomheten må fortsatt kontrollere om oppføringen dekker mottakeren og behandlingen, og den må oppfylle resten av GDPR.

Holder det at serveren står i Europa?

Ikke nødvendigvis. Fjernaksess, support, underleverandører og andre dataflyter kan fortsatt innebære overføring til et tredjeland.

Er en europeisk leverandør alltid best?

Ikke alltid. Europeisk jurisdiksjon kan redusere kompleksiteten, men tjenestens sikkerhet, funksjonalitet, avtaler og virksomhetens egen kapasitet må også vurderes.

Konklusjon

Amerikanske skyløsninger kan brukes lovlig til behandling av personopplysninger, men virksomheten må kunne vise hvorfor den konkrete behandlingen er lovlig og forsvarlig. DPF har gjort overføring til sertifiserte amerikanske virksomheter enklere enn i årene rett etter Schrems II. Det har ikke fjernet ansvaret for datakartlegging, leverandørkontroll, sikkerhet og dokumentasjon.

Det tryggeste svaret kommer derfor ikke fra leverandørens flagg eller markedsføring. Det kommer fra en dokumentert oversikt over data, aktører, tilgang, overføringsgrunnlag og tiltak.

Kilder og videre lesning

Artikkelen ble vesentlig oppdatert 16. september 2026 for å ta inn EU-US Data Privacy Framework og gjeldende veiledning om tredjelandsoverføringer.

Illustrasjon av globale datasentre som lagrer Microsoft 365-data

Hvor lagres dataene i Microsoft 365?

Skrevet av Svein Tore den mai 15, 2026. Publisert i IT-sikkerhet. Ingen kommentarer til Hvor lagres dataene i Microsoft 365?

Hvor Microsoft 365-data lagres, avhenger av tenantens geografi, den enkelte tjenesten og hvilke datalagringsforpliktelser abonnementet omfatter. En global administrator kan kontrollere gjeldende og forpliktet geografi i Microsoft 365-administrasjonssenteret. Det er mer presist enn å anta at alle data ligger i Norge, Europa eller ett bestemt datasenter.

For en norsk virksomhet er fysisk lagringssted bare én del av vurderingen. Det er også nødvendig å forstå hvilke data forpliktelsen dekker, hvordan tjenestene behandler drifts- og supportdata, hvilke underleverandører som brukes, og om personopplysninger kan bli overført ut av EØS.

Slik finner du tenantens faktiske datageografi

Microsoft har et eget datalokasjonskort i administrasjonssenteret. En global administrator kan gå til Innstillinger → Organisasjonsinnstillinger → Organisasjonsprofil → Dataplassering. Kortet viser de omfattede tjenestene, nåværende geografi og geografi Microsoft har forpliktet seg til å bruke for de aktuelle dataene.

Microsoft beskriver fremgangsmåten i dokumentasjonen for Data Location Card. Denne kontrollen bør dokumenteres med dato, fordi tjenesteomfang, abonnement og Microsofts produktvilkår kan endres.

Et geografisk navn i administrasjonssenteret betyr normalt en region eller et land med en bestemt datalagringsforpliktelse. Det betyr ikke nødvendigvis at alle dataelementer, logger, supportdata og sikkerhetskopier befinner seg i ett bestemt bygg.

Microsoft 365 består av flere tjenester

Exchange Online, SharePoint, OneDrive, Teams, Entra ID, Purview, Defender og Copilot er forskjellige tjenester med ulike datatyper og datalagringsbeskrivelser. Teams-filer ligger for eksempel ofte i SharePoint eller OneDrive, mens meldinger og andre tjenestedata kan håndteres i andre komponenter.

Microsofts oversikt over hvor Microsoft 365-kundedata lagres lenker videre til tjenestespesifikke beskrivelser. Det er derfor tryggere å kontrollere hver kritiske arbeidslast enn å bruke én generell setning om «Microsoft 365-data».

Hva betyr data i ro?

Datalagringsforpliktelser gjelder ofte kundedata i ro, altså data som er lagret i tjenesten. Begrepet må leses sammen med Microsofts definisjoner og vilkår. Det kan være forskjell på innhold kunden legger inn, kontoinformasjon, systemgenererte logger, diagnostikk, supportdata og midlertidig behandling.

En virksomhet bør derfor spørre:

Hvilke datatyper er uttrykkelig omfattet av forpliktelsen?
Gjelder den både lagring og behandling?
Hvilke begrensede overføringer eller unntak beskriver leverandøren?
Gjelder den nåværende abonnementstype og tenant?
Hvordan håndteres support, feilsøking, sikkerhet og underleverandører?

Dette skillet er viktig når en risikovurdering skal dokumentere mer enn bare navnet på en region.

Norge, EU/EFTA og Advanced Data Residency

Norge er oppført blant Microsofts lokale regiongeografier. Microsoft tilbyr også Advanced Data Residency, som gir kvalifiserte kunder utvidede datalagringsforpliktelser for flere tjenester og datatyper. Tillegget krever at tenant og lisenser oppfyller vilkårene, og det dekker ikke automatisk enhver Microsoft-tjeneste.

Dokumentasjonen for Advanced Data Residency beskriver kvalifisering, tjenesteomfang og lisenskrav. Virksomheter med et konkret krav om norsk eller lokal lagring bør kontrollere at kravet faktisk er dekket av gjeldende produktvilkår, ikke bare at Norge finnes på en liste over datasenterregioner.

For andre kunder kan den forpliktede geografien være EU/EFTA eller en europeisk makroregion. Den eksakte statusen må leses fra tenantens datalokasjonskort og sammenholdes med dokumentasjonen for hver tjeneste.

EU Data Boundary dekker mer enn lagring, men har avgrensninger

Microsofts EU Data Boundary er en geografisk avgrensning der selskapet har forpliktet seg til å lagre og behandle bestemte kundedata og personopplysninger for omfattede nettjenester. Dokumentasjonen omfatter blant annet Microsoft 365, men beskriver også begrensede situasjoner der data fortsatt kan overføres utenfor grensen.

Det er derfor ikke presist å tolke EU Data Boundary som et løfte om at absolutt all behandling alltid skjer innenfor EU og EFTA. Virksomheten må kontrollere tjenesten, datatypen og unntakene i den gjeldende EU Data Boundary-dokumentasjonen.

Fysisk lagring og rettslig kontroll er ulike spørsmål

Et datasenter i Europa gir viktig informasjon om hvor data er lagret, men avgjør ikke alene alle spørsmål om tilgang og jurisdiksjon. Leverandørens selskapsstruktur, avtalene, underleverandørene og lovgivningen leverandøren er underlagt kan også være relevante.

CLOUD Act er en amerikansk lov som under bestemte vilkår kan brukes til å kreve data fra amerikanske tjenesteleverandører, også når data er lagret utenfor USA. Det betyr ikke at amerikanske myndigheter har fri eller automatisk tilgang til alle Microsoft 365-data. Krav må følge rettslige prosesser, og leverandøren kan ha mulighet eller plikt til å vurdere og bestride dem. Den mer detaljerte artikkelen om CLOUD Act forklarer forskjellen mellom lagringssted og leverandørens rettslige tilknytning.

Overføring ut av EØS må vurderes konkret

Datatilsynet understreker at overføring av personopplysninger ut av EØS krever et særskilt grunnlag. Behandling i EØS er i utgangspunktet ikke en tredjelandsoverføring, men vurderingen stopper ikke alltid ved serverens plassering. Fjernaksess, support, underleverandører og tredjelands lovgivning kan påvirke analysen.

Virksomheten bør kartlegge dataflyten og bruke Datatilsynets oppdaterte veiledning om overføring av personopplysninger ut av EØS. For behandlinger med høy risiko eller særlige kategorier opplysninger kan det være nødvendig med juridisk og personvernfaglig bistand.

Schrems II-artikkelen forklarer hvorfor overføringsgrunnlag og tilleggstiltak fortsatt må vurderes, selv om det senere er etablert nye ordninger mellom EU og USA.

Dataplassering løser ikke sikkerhet og backup

En datalagringsforpliktelse sier ikke i seg selv at tilgangene er riktige, at slettede data kan gjenopprettes, eller at virksomheten har en uavhengig backup. Microsoft beskytter infrastrukturen og tilbyr flere sikkerhets- og gjenopprettingsfunksjoner, mens kunden fortsatt må forvalte brukere, administratorroller, deling, oppbevaring og egen beredskap.

Virksomheten bør skille mellom tilgjengelighet i tjenesten, versjonshistorikk, oppbevaringsregler og en sikkerhetskopi som dekker egne krav. Guiden om sikker datalagring for bedrifter viser hvordan tilgang, kryptering, backup, sletting og leverandørbytte kan vurderes samlet.

En praktisk kontroll i sju trinn

Åpne datalokasjonskortet. Noter nåværende og forpliktet geografi per tjeneste.
Kartlegg arbeidslastene. Skill mellom Exchange, SharePoint, OneDrive, Teams og øvrige tjenester.
Les tjenestedokumentasjonen. Kontroller hvilke kundedata og datatyper som er omfattet.
Kontroller abonnementet. Avklar om tenant har ordinær, Multi-Geo eller Advanced Data Residency-forpliktelse.
Kartlegg dataflyt. Ta med support, underleverandører, integrasjoner, diagnostikk og fjernaksess.
Vurder personvern og avtaler. Dokumenter behandlingsgrunnlag, databehandleravtale og eventuelle tredjelandsoverføringer.
Kontroller sikkerhet og gjenoppretting. Test tilganger, logging, oppbevaring, eksport og backup uavhengig av lagringsstedet.

Vanlige spørsmål

Ligger alle norske Microsoft 365-data i Norge?

Ikke nødvendigvis. Norge er en lokal regiongeografi, men faktisk og forpliktet geografi avhenger av tenant, tjeneste og datalagringsordning. Kontroller datalokasjonskortet og den tjenestespesifikke dokumentasjonen.

Ligger alle data i EU hvis administrasjonssenteret viser Europa?

Ikke bruk geografietiketten alene som dokumentasjon for all lagring og behandling. Kontroller hvilke data som omfattes, om regionen er Europa eller EU/EFTA, og hvilke unntak og overføringer som er beskrevet.

Betyr europeisk lagring at CLOUD Act er irrelevant?

Nei. Fysisk plassering og leverandørens rettslige tilknytning er forskjellige spørsmål. Samtidig er det misvisende å beskrive CLOUD Act som automatisk myndighetstilgang. Risikoen må vurderes konkret sammen med avtaler, kryptering, datatyper og øvrige tiltak.

Er Microsoft 365 lovlig å bruke for personopplysninger?

Det kan være lovlig, men svaret avhenger av behandlingen, konfigurasjonen, avtalene, risikoen og dataflyten. Virksomheten er ansvarlig for å dokumentere at personvernkravene er oppfylt for sin bruk.

Konklusjon

Det riktige svaret på hvor Microsoft 365-data lagres finnes i tenantens datalokasjonskort og i dokumentasjonen for den enkelte tjenesten. For norske virksomheter kan data være omfattet av norsk, EU/EFTA- eller annen europeisk datalagring, avhengig av tenant og avtale.

En forsvarlig vurdering kombinerer fysisk lagringssted med dataflyt, leverandørkontroll, personvern, sikkerhet og gjenoppretting. Da blir datalokasjon et dokumentert beslutningsgrunnlag, ikke bare en antakelse.

illustrasjon som viser forskjellen mellom Nextcloud og Microsoft 365 og kontroll over data

Nextcloud vs Microsoft 365 – hvem kontrollerer egentlig dataene?

Skrevet av Svein Tore den mars 28, 2026. Publisert i Teknologi. Ingen kommentarer til Nextcloud vs Microsoft 365 – hvem kontrollerer egentlig dataene?

Hva er Microsoft 365

Microsoft 365 er en komplett skyløsning levert av Microsoft. Plattformen inkluderer tjenester som e‑post, dokumentbehandling, Teams, SharePoint og skylagring via OneDrive. For mange bedrifter er dette en svært praktisk løsning fordi alt leveres ferdig konfigurert i skyen. Det betyr også at infrastrukturen driftes av Microsoft i deres datasentre. Brukere får tilgang til tjenestene via nettleser eller apper, mens dataene lagres i Microsofts skyplattform. Fordelen er enkelhet. Oppsettet er raskt, oppdateringer skjer automatisk og administrasjonen er relativt enkel for små og mellomstore virksomheter. Ulempen er at kontrollen over infrastrukturen ligger hos leverandøren. Selv om virksomheten eier sine egne data juridisk, er det Microsoft som kontrollerer plattformen dataene lagres i.

Hva er Nextcloud

Nextcloud er en open source‑plattform for filsynkronisering, samarbeid og skylagring. Den kan i stor grad gjøre mange av de samme tingene som kommersielle skyløsninger, men med én viktig forskjell: løsningen kan hostes og kontrolleres av virksomheten selv. Nextcloud kan installeres på egne servere, i privat sky eller hos en leverandør som tilbyr dedikert hosting. Det betyr at organisasjonen selv bestemmer hvor dataene lagres, hvordan systemet konfigureres og hvilke sikkerhetstiltak som skal brukes. I tillegg er koden åpen. Det gjør at sikkerhetseksperter kan inspisere hvordan plattformen fungerer, og det gir større transparens enn lukkede systemer. Hvis du vil forstå plattformen bedre kan du lese mer i artikkelen «Hva er Nextcloud – og hvordan fungerer det?».

Den viktigste forskjellen: kontroll over infrastrukturen

Den største forskjellen mellom Nextcloud og Microsoft 365 handler ikke om funksjoner, men om kontroll. Med Microsoft 365 ligger infrastrukturen i Microsofts globale sky. Selv om selskapet har strenge sikkerhetsrutiner og høy driftssikkerhet, er det fortsatt leverandøren som kontrollerer plattformen. Med Nextcloud kan virksomheten selv kontrollere infrastrukturen. Det betyr at servere kan plasseres i eget datasenter, hos en lokal leverandør eller i et miljø som er underlagt nasjonale lover og regler. For noen organisasjoner spiller dette liten rolle. For andre – særlig virksomheter som håndterer sensitive data – kan det være avgjørende.

Personvern og datasuverenitet

Et tema som stadig oftere diskuteres er datasuverenitet. Dette handler om hvem som faktisk har jurisdiksjon over dataene. Store internasjonale skyløsninger opererer på tvers av mange land, og data kan i praksis være underlagt ulike lovverk. For europeiske virksomheter har dette blitt spesielt relevant etter diskusjoner rundt internasjonale dataoverføringer. Self‑hosted løsninger som Nextcloud gir i mange tilfeller mer kontroll over hvor dataene fysisk lagres. Det kan gjøre det enklere å følge lokale krav til personvern og datasikkerhet. Denne problemstillingen er også sentral i fagartikkelen «Hvem kontrollerer egentlig dataene dine?», som går dypere inn i hvordan digitale plattformer påvirker kontroll over informasjon.

Funksjoner og samarbeidsverktøy

Når det gjelder funksjonalitet er Microsoft 365 svært omfattende. Plattformen inkluderer velkjente verktøy som Word, Excel, PowerPoint og Teams, som mange virksomheter allerede er vant til. Nextcloud har også utviklet et økosystem av apper. Dette inkluderer dokumentredigering, kalender, oppgavehåndtering, videosamtaler og filsynkronisering. Mange av disse funksjonene leveres gjennom integrasjoner med andre open source‑prosjekter. Forskjellen ligger ofte i hvor mye som er ferdig integrert fra start. Microsoft 365 er designet som en komplett kommersiell pakke, mens Nextcloud er mer modulært og kan tilpasses etter behov.

Når Microsoft 365 kan være riktig valg

For små virksomheter uten tekniske ressurser kan Microsoft 365 være et svært godt valg. Løsningen er enkel å ta i bruk, krever lite drift og gir tilgang til et bredt sett av verktøy som fungerer godt sammen. For mange bedrifter er det nettopp denne enkelheten som gjør skyløsninger attraktive.

Så lenge bedriften ikke lagrer data som er sensetiv så er det greit. Men husk at all data hos Microsoft er tiljengelig for tredjepart uansett datasenter. Med Microsoft har du ikke data suvereniteten i behold!

Når Nextcloud kan være et bedre alternativ

Nextcloud blir ofte valgt av organisasjoner som ønsker mer kontroll over data, infrastruktur og sikkerhet. Det gjelder blant annet virksomheter med høye krav til personvern, offentlige organisasjoner eller bedrifter som ønsker å redusere avhengigheten av globale teknologiselskaper. En annen fordel er fleksibiliteten. Fordi plattformen er open source kan den tilpasses, integreres med andre systemer og utvides etter behov. Hvis du også vurderer andre skyløsninger kan det være nyttig å lese sammenligningen «Nextcloud vs Google Drive«.

Hva bør virksomheter egentlig velge

Det finnes ikke ett riktig svar som passer for alle. Valget mellom Nextcloud og Microsoft 365 handler først og fremst om prioriteringer. Hvis enkelhet, ferdig integrerte verktøy og minimal drift er viktigst, vil Microsoft 365 ofte være det mest praktiske valget. Hvis kontroll over data, fleksibilitet og uavhengighet fra globale skyløsninger er viktigere, kan Nextcloud være et mer strategisk alternativ. Det viktigste er at virksomheter faktisk tenker gjennom hvem som kontrollerer infrastrukturen de lagrer dataene sine i. Før du tar et endelig valg kan det derfor være nyttig å forstå et mer grunnleggende spørsmål: hvem kontrollerer egentlig dataene dine?.