Søk på tvers av alle regelverkene, eller filtrer på ett om gangen. Hvert begrep har en kort definisjon, en forklaring i klartekst, et praktisk eksempel og lenker til kilden. Vil du gå i dybden på ett regelverk, velg det fra oversikten.

GDPR – Personvernforordningen

Behandlingsansvarlig

#
GDPRArt. 4(7)Data Controller

Den som bestemmer hvorfor og hvordan personopplysninger skal behandles.

Behandlingsansvarlig er virksomheten (eller personen) som avgjør formålet med og midlene for behandlingen av personopplysninger. Det er den behandlingsansvarlige som har hovedansvaret for at personvernreglene følges, og som de registrerte og Datatilsynet holder ansvarlig ved brudd.

Ansvaret kan ikke avtales bort ved å la en leverandør gjøre selve jobben – du forblir ansvarlig for at behandlingen er lovlig.

Eksempel

En nettbutikk bestemmer at den vil lagre kundenes navn, adresse og kjøpshistorikk for å levere varer og sende nyhetsbrev. Nettbutikken er behandlingsansvarlig – selv om den bruker et eksternt e-postverktøy til å sende ut nyhetsbrevene.

Sist oppdatert: 14. juni 2026

Databehandler

#
GDPRArt. 4(8)Data Processor

Den som behandler personopplysninger på vegne av en behandlingsansvarlig, etter dennes instrukser.

En databehandler tar ikke selvstendige beslutninger om hvorfor opplysningene skal behandles – den følger oppdraget fra den behandlingsansvarlige. Typiske databehandlere er skyleverandører, regnskapssystemer, e-postverktøy og IT-driftsleverandører.

Databehandleren har egne plikter etter GDPR: tilstrekkelig sikkerhet, ingen bruk av underleverandører uten godkjenning, og bistand ved innsynskrav og brudd. Forholdet skal alltid reguleres i en databehandleravtale.

Eksempel

Et regnskapsbyrå fører lønn og regnskap for en kunde. Byrået bestemmer ikke selv hva dataene skal brukes til – det utfører oppdraget kunden har gitt. Regnskapsbyrået er dermed databehandler, og kunden er behandlingsansvarlig.

Sist oppdatert: 14. juni 2026

Underdatabehandler

#
GDPRArt. 28(2)(4)Sub-processor

En leverandør som databehandleren selv bruker for å utføre deler av behandlingen.

Når en databehandler setter ut deler av jobben – for eksempel ved å bruke en underliggende skyplattform til drift – blir denne leverandøren en underdatabehandler. Databehandleren kan ikke ta i bruk en underdatabehandler uten forhåndsgodkjenning fra den behandlingsansvarlige, og må binde underdatabehandleren til de samme pliktene.

Dette skaper en kjede av ansvar: den behandlingsansvarlige skal ha oversikt over hele kjeden, ikke bare sin direkte leverandør.

Eksempel

Et norsk SaaS-selskap (databehandler) kjører tjenesten sin på Amazon Web Services. AWS blir da en underdatabehandler, og kunden (behandlingsansvarlig) må informeres og kunne protestere før den tas i bruk.

Sist oppdatert: 14. juni 2026

Felles behandlingsansvarlige

#
GDPRArt. 26Joint Controllers

To eller flere virksomheter som sammen bestemmer formål og midler for en behandling.

Når flere aktører i fellesskap avgjør hvorfor og hvordan personopplysninger skal behandles, er de felles behandlingsansvarlige. De må inngå en avtale som tydelig fordeler ansvaret mellom seg – særlig hvem som svarer på de registrertes henvendelser.

De registrerte kan uansett gjøre rettighetene sine gjeldende overfor hvem som helst av partene.

Eksempel

To bedrifter arrangerer en felles kundeundersøkelse og deler både planlegging og resultatene. Siden de sammen bestemmer formålet, er de felles behandlingsansvarlige og må avklare ansvarsfordelingen skriftlig.

Sist oppdatert: 14. juni 2026

Personvernombud (DPO)

#
GDPRArt. 37–39Data Protection Officer

En uavhengig rådgiver som overvåker at virksomheten følger personvernregelverket.

Personvernombudet gir råd, kontrollerer etterlevelse og er kontaktpunkt mot Datatilsynet og de registrerte. Rollen er obligatorisk for offentlige myndigheter og for virksomheter som driver storskala overvåking eller behandler særlige kategorier i stor skala.

Ombudet skal være uavhengig, ikke instrueres i utførelsen av oppgavene, og ikke ha en rolle som skaper interessekonflikt.

Eksempel

En kommune behandler helse- og skoleopplysninger om innbyggerne i stor skala. Kommunen plikter å utpeke et personvernombud som kan rapportere direkte til øverste ledelse.

Sist oppdatert: 14. juni 2026

Registrert

#
GDPRArt. 4(1)Data Subject

Den fysiske personen som personopplysningene gjelder.

Den registrerte er personen i sentrum av personvernet – kunden, den ansatte, brukeren eller pasienten. Det er den registrertes rettigheter (innsyn, retting, sletting m.m.) hele regelverket er bygget for å beskytte.

Bare levende, fysiske personer kan være registrerte; virksomheter og avdøde omfattes ikke.

Eksempel

Når en jobbsøker sender CV til en bedrift, er søkeren den registrerte. Bedriften må kunne svare på et innsynskrav om hvilke opplysninger den har lagret om søkeren.

Sist oppdatert: 14. juni 2026

Tilsynsmyndighet (Datatilsynet)

#
GDPRArt. 51–58Supervisory Authority

Den offentlige myndigheten som fører tilsyn med at personvernregelverket følges.

I Norge er dette Datatilsynet. Tilsynet veileder, behandler klager, gjennomfører tilsyn og kan ilegge overtredelsesgebyr på inntil 20 millioner euro eller 4 % av global årsomsetning. Det er også hit brudd på personopplysningssikkerheten meldes.

Den enkelte har alltid rett til å klage til tilsynsmyndigheten dersom de mener personvernet er krenket.

Eksempel

En kunde som mener en bedrift ulovlig har solgt e-postadressen hennes til markedsføring, kan klage til Datatilsynet, som kan undersøke saken og eventuelt ilegge gebyr.

Sist oppdatert: 14. juni 2026

Personopplysninger

#
GDPRArt. 4(1)Personal Data

Enhver opplysning om en identifisert eller identifiserbar fysisk person.

Begrepet er bredt. Det dekker det åpenbare som navn, fødselsnummer, e-postadresse og bilde – men også indirekte identifikatorer som IP-adresse, lokasjonsdata, enhets-ID og kundenummer, så lenge de kan knyttes til en person direkte eller i kombinasjon med andre opplysninger.

Opplysninger om døde personer eller om virksomheter regnes i utgangspunktet ikke som personopplysninger. Anonymiserte data faller også utenfor – men kun hvis det er reelt umulig å identifisere personen igjen.

Eksempel

En logg som bare inneholder IP-adresser kan virke harmløs, men IP-adressen regnes som en personopplysning fordi den – sammen med opplysninger fra internettleverandøren – kan spores til en bestemt person. Loggen er derfor omfattet av GDPR.

Sist oppdatert: 14. juni 2026

Særlige kategorier personopplysninger

#
GDPRArt. 9Special category / sensitive data

Sensitive personopplysninger med forsterket vern – behandling er som hovedregel forbudt uten et særskilt unntak.

Dette omfatter opplysninger om helse, etnisk opprinnelse, religiøs eller politisk overbevisning, fagforeningsmedlemskap, seksuell legning, genetiske data og biometriske data brukt til entydig identifikasjon. Fordi misbruk kan ramme den enkelte spesielt hardt, krever GDPR både et alminnelig behandlingsgrunnlag og et særskilt unntak i artikkel 9 nr. 2.

I praksis betyr det strengere krav til samtykke, sikkerhet og dokumentasjon. Behandling av slike data utløser også oftere krav om personvernkonsekvensvurdering (DPIA).

Eksempel

En treningsapp som registrerer hvilestepuls og søvnmønster behandler helseopplysninger. Det holder ikke å vise til «berettiget interesse» – appen må ha et gyldig unntak etter artikkel 9, typisk uttrykkelig samtykke fra brukeren.

Sist oppdatert: 14. juni 2026

Behandling

#
GDPRArt. 4(2)Processing

Enhver operasjon som utføres med personopplysninger – fra innsamling til sletting.

«Behandling» er et samlebegrep for alt man gjør med personopplysninger: innsamling, registrering, lagring, endring, bruk, utlevering, sammenstilling, sperring og sletting. Også ren lagring uten aktiv bruk regnes som behandling.

Det betyr at GDPR slår inn i det øyeblikket opplysninger samles inn, ikke først når de «brukes».

Eksempel

Å arkivere gamle e-poster med kundeopplysninger på en server er behandling – selv om ingen leser dem. Derfor må også arkivet ha et behandlingsgrunnlag og en sletterutine.

Sist oppdatert: 14. juni 2026

Profilering

#
GDPRArt. 4(4)Profiling

Automatisert behandling som vurderer eller forutsier personlige forhold ved en person.

Profilering bruker personopplysninger til å analysere eller forutsi forhold som arbeidsytelse, økonomi, helse, preferanser, atferd eller bevegelser. Det er lov, men utløser informasjonsplikt og krav om at den registrerte forstår logikken bak.

Profilering som inngår i en helautomatisk avgjørelse med betydelig virkning er underlagt de strengere reglene i artikkel 22.

Eksempel

En strømmetjeneste analyserer hva du ser på for å anbefale nytt innhold. Dette er profilering, og tjenesten må informere om at den gjør det.

Sist oppdatert: 14. juni 2026

Automatiserte individuelle avgjørelser

#
GDPRArt. 22Automated decision-making

Avgjørelser som utelukkende treffes automatisk og har rettsvirkning eller tilsvarende betydelig innvirkning.

Når en avgjørelse tas helt uten menneskelig vurdering og får stor betydning for personen, har den registrerte som hovedregel rett til å slippe å være underlagt den. Det finnes unntak (avtale, lov eller uttrykkelig samtykke), men da må det innføres garantier – blant annet rett til menneskelig inngripen og til å bestride avgjørelsen.

Dette er et av de mest aktuelle GDPR-temaene i møte med KI-baserte beslutningssystemer.

Eksempel

En bank avslår en lånesøknad utelukkende basert på en automatisk kredittscore. Kunden har rett til å få en menneskelig vurdering og til å forklare sin situasjon.

Sist oppdatert: 14. juni 2026

Pseudonymisering

#
GDPRArt. 4(5)Pseudonymisation

Å behandle data slik at de ikke kan knyttes til en person uten tilleggsinformasjon som holdes adskilt.

Ved pseudonymisering byttes direkte identifikatorer ut med en nøkkel eller kode, mens koblingen mellom kode og person lagres separat og sikret. Dataene er fortsatt personopplysninger og omfattet av GDPR, men risikoen reduseres betydelig.

GDPR fremhever pseudonymisering som et anbefalt sikkerhetstiltak og som et virkemiddel for innebygd personvern.

Eksempel

I et forskningsprosjekt erstattes pasientnavn med koden «P-0481», mens koblingslisten oppbevares i et adskilt, kryptert system som bare prosjektleder har tilgang til.

Sist oppdatert: 14. juni 2026

Anonymisering

#
GDPRFortale 26Anonymisation

Å fjerne koblingen til en person permanent slik at opplysningene faller utenfor GDPR.

Til forskjell fra pseudonymisering er anonymisering uopprettelig: det skal ikke være mulig å identifisere personen igjen, verken direkte eller ved å kombinere med andre data. Først da regnes opplysningene ikke lenger som personopplysninger.

Reell anonymisering er vanskelig å oppnå i praksis, fordi rike datasett ofte kan re-identifiseres ved sammenstilling.

Eksempel

En bedrift publiserer statistikk som «42 % av kundene er under 30 år» uten noen mulighet til å spore tallene tilbake til enkeltpersoner. Da er datagrunnlaget anonymisert.

Sist oppdatert: 14. juni 2026

Samtykke

#
GDPRArt. 4(11) & 7Consent

En frivillig, spesifikk, informert og utvetydig viljeserklæring om å godta behandling av egne data.

Et gyldig samtykke krever en aktiv handling – forhåndsutfylte avkrysningsbokser teller ikke. Samtykket må kunne dokumenteres, og det skal være like enkelt å trekke det tilbake som å gi det. Samtykke er ofte upraktisk som behandlingsgrunnlag nettopp fordi det kan trekkes når som helst.

Hvis det er ubalanse mellom partene – som mellom arbeidsgiver og ansatt – er samtykke sjelden «frivillig» nok til å være gyldig.

Eksempel

En nettside ber besøkende aktivt krysse av for å motta nyhetsbrev, med tydelig informasjon om hva de samtykker til. Avmeldingslenken i hver e-post gjør det like lett å trekke samtykket tilbake.

Sist oppdatert: 14. juni 2026

Dataminimering

#
GDPRArt. 5(1)(c)Data minimisation

Man skal bare behandle de personopplysningene som faktisk er nødvendige for formålet.

Prinsippet sier at innsamlingen skal være adekvat, relevant og begrenset til det nødvendige. Det er fristende å samle inn «alt som kan være nyttig en gang», men det er i strid med GDPR – mer data betyr mer ansvar og større risiko.

Spørsmålet du alltid bør stille er: trenger vi virkelig dette feltet for å oppnå formålet?

Eksempel

Et skjema for å melde seg på et nyhetsbrev trenger bare e-postadresse. Å kreve fødselsnummer og adresse i tillegg bryter med dataminimering.

Sist oppdatert: 14. juni 2026

Formålsbegrensning

#
GDPRArt. 5(1)(b)Purpose limitation

Personopplysninger kan bare brukes til de formålene de ble samlet inn for.

Formålet skal være fastsatt, uttrykkelig angitt og legitimt før innsamlingen starter. Opplysninger som er samlet inn til ett formål kan ikke uten videre gjenbrukes til et nytt og uforenlig formål.

Dette beskytter mot «funksjonskryp», der data sakte tas i bruk til stadig nye ting brukeren aldri var med på.

Eksempel

En bedrift samler inn kundenes telefonnummer for å bekrefte ordrer. Å senere bruke de samme numrene til telefonsalg er et nytt formål som krever eget grunnlag.

Sist oppdatert: 14. juni 2026

Lagringsbegrensning

#
GDPRArt. 5(1)(e)Storage limitation

Personopplysninger skal ikke lagres lenger enn nødvendig for formålet.

Når formålet er oppfylt, skal opplysningene slettes eller anonymiseres – med mindre annen lovgivning krever lengre oppbevaring (for eksempel bokføringsloven). Virksomheten bør ha en sletterutine med definerte lagringstider for hver type data.

«Vi beholder det for sikkerhets skyld» er ikke et gyldig grunnlag for evig lagring.

Eksempel

CV-er fra avslåtte jobbsøkere bør slettes kort tid etter ansettelsesprosessen, ikke ligge i innboksen i årevis – med mindre søkeren har samtykket til videre lagring.

Sist oppdatert: 14. juni 2026

Ansvarlighet (accountability)

#
GDPRArt. 5(2)Accountability

Plikten til ikke bare å følge personvernreglene, men også å kunne dokumentere at man gjør det.

Ansvarlighet snur bevisbyrden: det er virksomheten som må vise at den etterlever GDPR, ikke tilsynet som må bevise det motsatte. I praksis betyr det dokumentasjon – behandlingsprotokoll, retningslinjer, risikovurderinger, databehandleravtaler og opplæring.

Uten dokumentasjon hjelper det lite at man «egentlig» gjør ting riktig.

Eksempel

Ved et tilsyn ber Datatilsynet om behandlingsprotokollen og sletterutinene. En virksomhet som kan vise frem oppdatert dokumentasjon, demonstrerer ansvarlighet.

Sist oppdatert: 14. juni 2026

Innebygd personvern og personvern som standard

#
GDPRArt. 25Privacy by Design & by Default

Personvern skal bygges inn i systemer fra start, og standardinnstillingene skal være de mest personvernvennlige.

«By design» betyr at personvern tas hensyn til allerede når en løsning utvikles, ikke som et tillegg etterpå. «By default» betyr at brukeren ikke skal måtte aktivt skru på personvernet – det skal være på som utgangspunkt.

Tiltak som dataminimering, pseudonymisering og strenge standardvalg er typiske virkemidler.

Eksempel

En ny app settes opp slik at profilen er privat som standard, og at posisjonsdeling er avskrudd inntil brukeren selv velger å slå den på.

Sist oppdatert: 14. juni 2026

Behandlingsgrunnlag

#
GDPRArt. 6Legal basis / rettslig grunnlag

Det rettslige grunnlaget som gjør en behandling av personopplysninger lovlig.

All behandling må hvile på minst ett av de seks grunnlagene i artikkel 6: samtykke, oppfyllelse av avtale, rettslig forpliktelse, vitale interesser, allmennhetens interesse eller berettiget interesse. Grunnlaget må være valgt før behandlingen starter, og kan ikke byttes ut underveis for samme formål.

Mange tror «samtykke» alltid er riktig grunnlag, men for et kundeforhold er «oppfyllelse av avtale» som regel et bedre og mer robust grunnlag.

Eksempel

En bedrift lagrer ansattes kontonummer for å utbetale lønn. Riktig behandlingsgrunnlag er ikke samtykke (ansatte kan ikke fritt si nei til lønn), men «rettslig forpliktelse» og «oppfyllelse av arbeidsavtalen».

Sist oppdatert: 14. juni 2026

Berettiget interesse

#
GDPRArt. 6(1)(f)Legitimate interest

Et fleksibelt behandlingsgrunnlag der virksomhetens interesse veies mot de registrertes rettigheter.

Berettiget interesse krever en interesseavveining i tre trinn: er interessen legitim, er behandlingen nødvendig for den, og veier den tyngre enn personens interesser og forventninger? Avveiningen skal dokumenteres (LIA – legitimate interest assessment).

Grunnlaget kan ikke brukes av offentlige myndigheter i utøvelsen av oppgavene sine, og den registrerte har alltid rett til å protestere.

Eksempel

En nettbutikk bruker berettiget interesse til å logge IP-adresser for å avdekke svindel. Behandlingen er nødvendig, begrenset, og kundene forventer rimelig sikkerhet – avveiningen kan da gå i butikkens favør.

Sist oppdatert: 14. juni 2026

Databehandleravtale

#
GDPRArt. 28Data Processing Agreement (DPA)

En bindende avtale som regulerer hvordan en databehandler skal behandle personopplysninger på vegne av den behandlingsansvarlige.

Når du lar en leverandør behandle personopplysninger for deg, krever GDPR en databehandleravtale. Den skal fastsette formål og varighet, hvilke typer opplysninger som behandles, sikkerhetskrav, bruk av underleverandører, bistand ved innsyn og brudd, samt sletting eller tilbakelevering når oppdraget avsluttes.

En signert avtale er ikke nok i seg selv – innholdet må stemme med hvordan behandlingen faktisk foregår.

Eksempel

En bedrift tar i bruk et skybasert CRM-system. Før kundedata legges inn, må bedriften inngå CRM-leverandørens databehandleravtale – og sjekke at den lister opp eventuelle underleverandører.

Sist oppdatert: 14. juni 2026

Behandlingsprotokoll (ROPA)

#
GDPRArt. 30Records of Processing (ROPA)

En oversikt over alle behandlinger av personopplysninger virksomheten utfører.

Behandlingsprotokollen dokumenterer hva slags opplysninger som behandles, til hvilke formål, hvem de deles med, lagringstider og sikkerhetstiltak. Den er selve grunnmuren i å vise ansvarlighet og som regel det første Datatilsynet ber om.

Plikten gjelder i praksis nesten alle virksomheter, til tross for unntaket for de aller minste.

Eksempel

En bedrift fører en oversikt med linjer som «Lønnskjøring – ansattes kontonummer – formål: utbetaling – lagres i 5 år (bokføringsloven) – delt med: bank og regnskapsbyrå».

Sist oppdatert: 14. juni 2026

Personvernkonsekvensvurdering (DPIA)

#
GDPRArt. 35Data Protection Impact Assessment

En strukturert vurdering av personvernrisiko ved behandling som sannsynligvis medfører høy risiko for de registrerte.

En DPIA kartlegger hva behandlingen innebærer, vurderer nødvendighet og forholdsmessighet, identifiserer risikoer for de registrerte og fastsetter tiltak for å redusere dem. Den er påkrevd ved blant annet systematisk overvåking, storskala behandling av særlige kategorier, og automatiserte avgjørelser med rettsvirkning.

Vurderingen skal gjøres før behandlingen starter. Hvis risikoen forblir høy etter tiltak, må den behandlingsansvarlige rådføre seg med Datatilsynet før oppstart.

Eksempel

En kommune skal innføre ansiktsgjenkjenning ved inngangen til et offentlig bygg. Dette er storskala behandling av biometriske data på et sted folk ikke kan unngå – og krever en DPIA før systemet tas i bruk.

Sist oppdatert: 14. juni 2026

Innsynsrett

#
GDPRArt. 15Right of access

Retten til å få vite om, og få kopi av, personopplysninger som behandles om en selv.

Den registrerte kan be om bekreftelse på om opplysninger behandles, og i så fall få innsyn i blant annet formål, kategorier, mottakere og lagringstid – samt en kopi av selve opplysningene. Svaret skal gis uten ugrunnet opphold og senest innen én måned, og som hovedregel gratis.

Innsynsretten er ofte den første rettigheten en virksomhet møter i praksis, og en god rutine for håndtering er viktig.

Eksempel

En tidligere ansatt ber arbeidsgiveren om innsyn i alle opplysninger som er lagret om vedkommende. Bedriften må samle sammen og utlevere disse innen en måned.

Sist oppdatert: 14. juni 2026

Rett til retting

#
GDPRArt. 16Right to rectification

Retten til å få uriktige eller ufullstendige opplysninger om seg selv rettet.

Hvis opplysningene en virksomhet har om en person er feil eller mangelfulle, kan personen kreve at de rettes eller suppleres. Virksomheten må også, der det er aktuelt, informere mottakere som har fått de uriktige opplysningene.

Riktige data er ikke bare en rettighet, men også et eget GDPR-prinsipp (riktighet).

Eksempel

En kunde oppdager at fakturaadressen i et system er feil og ber om retting. Virksomheten plikter å oppdatere opplysningen.

Sist oppdatert: 14. juni 2026

Rett til sletting

#
GDPRArt. 17Right to erasure / «retten til å bli glemt»

Retten til å få slettet personopplysninger under nærmere bestemte vilkår.

Den registrerte kan kreve sletting blant annet når opplysningene ikke lenger er nødvendige, samtykket trekkes tilbake, eller behandlingen er ulovlig. Retten er ikke absolutt – den viker for eksempel der lov krever oppbevaring, eller ved ytrings- og informasjonsfrihet.

For en virksomhet er det viktig å kunne skille mellom det som kan og det som må beholdes.

Eksempel

En bruker sletter kontoen sin på en tjeneste og ber om at alle data slettes. Tjenesten må slette det den ikke er lovpålagt å beholde – regnskapsbilag kan likevel måtte oppbevares i fem år.

Sist oppdatert: 14. juni 2026

Dataportabilitet

#
GDPRArt. 20Right to data portability

Retten til å motta egne data i et maskinlesbart format og overføre dem til en annen tjeneste.

Retten gjelder opplysninger personen selv har gitt fra seg, der behandlingen bygger på samtykke eller avtale og skjer automatisert. Formålet er å hindre innlåsing hos én leverandør og styrke konkurransen.

Der det er teknisk mulig, kan personen kreve at dataene overføres direkte fra en tjeneste til en annen.

Eksempel

En bruker av en treningsapp ber om å få treningshistorikken sin eksportert som en strukturert fil, slik at den kan importeres i en konkurrerende app.

Sist oppdatert: 14. juni 2026

Rett til å protestere

#
GDPRArt. 21Right to object

Retten til å motsette seg behandling – blant annet til direkte markedsføring.

Når behandlingen bygger på berettiget interesse eller allmennhetens interesse, kan den registrerte protestere ut fra sin særlige situasjon, og virksomheten må da stanse med mindre den har tungtveiende grunner. Mot direkte markedsføring er retten absolutt: behandlingen skal stanse umiddelbart.

Virksomheten må informere tydelig om denne retten senest ved første kontakt.

Eksempel

En kunde reserverer seg mot å motta reklame-e-poster. Bedriften må straks stanse markedsføringen mot denne kunden, uten å kreve noen begrunnelse.

Sist oppdatert: 14. juni 2026

Brudd på personopplysningssikkerheten

#
GDPRArt. 33 & 34Personal Data Breach

Et sikkerhetsbrudd som fører til utilsiktet eller ulovlig tap, endring, sletting eller tilgang til personopplysninger.

Begrepet er bredere enn «hacking». Det dekker også tapt minnepinne, e-post sendt til feil mottaker, feilkonfigurert tilgang eller utro tjener. Ved et brudd skal den behandlingsansvarlige som hovedregel melde fra til Datatilsynet uten ugrunnet opphold og senest innen 72 timer, med mindre bruddet neppe medfører risiko for de registrerte.

Medfører bruddet sannsynligvis høy risiko for personene, må også de berørte varsles direkte. Alle brudd skal dokumenteres internt – også de som ikke meldes.

Eksempel

En ansatt sender ved en feil et regneark med 400 kunders navn og personnummer til feil e-postadresse. Dette er et brudd på personopplysningssikkerheten – og fristen på 72 timer for å vurdere melding til Datatilsynet begynner å løpe.

Sist oppdatert: 14. juni 2026

Tredjelandsoverføring

#
GDPRKap. V (art. 44–50)Third-country transfer

Overføring av personopplysninger til land utenfor EØS.

Personopplysninger kan bare overføres ut av EØS dersom mottakerlandet gir et tilstrekkelig vernenivå. Grunnlaget kan være en adekvansbeslutning, standard personvernbestemmelser (SCC), bindende virksomhetsregler eller særskilte unntak. Etter Schrems II må man også vurdere om landets myndigheter kan undergrave vernet.

Bruk av amerikanske skytjenester gjør dette til en svært praktisk problemstilling for norske virksomheter.

Eksempel

En bedrift lagrer kundedata hos en amerikansk skyleverandør. Bedriften må sikre et gyldig overføringsgrunnlag – for eksempel at leverandøren er sertifisert under Data Privacy Framework, eller at det er inngått SCC.

Sist oppdatert: 14. juni 2026

Standard personvernbestemmelser (SCC)

#
GDPRArt. 46(2)(c)Standard Contractual Clauses

EU-godkjente standardkontrakter som gir et lovlig grunnlag for å overføre data til tredjeland.

SCC er ferdig formulerte kontraktsvilkår vedtatt av EU-kommisjonen, som partene tar inn i avtalen uten å endre kjernen. De forplikter mottakeren til å verne opplysningene etter europeisk standard. Etter Schrems II må man i tillegg gjøre en vurdering av om vilkårene faktisk kan etterleves i mottakerlandet, og eventuelt legge til tilleggstiltak.

SCC er det mest brukte grunnlaget når en adekvansbeslutning ikke dekker overføringen.

Eksempel

En norsk bedrift bruker en utviklingsleverandør i India. For å overføre kundedata dit lovlig, inngår partene EUs standard personvernbestemmelser og vurderer behovet for tilleggstiltak som kryptering.

Sist oppdatert: 14. juni 2026

Data Privacy Framework (DPF)

#
GDPRArt. 45 (adekvans)EU–US Data Privacy Framework

Adekvansbeslutningen som gir lovlig grunnlag for overføring til sertifiserte virksomheter i USA.

DPF er EU-kommisjonens beslutning fra 2023 om at USA gir tilstrekkelig vern for personopplysninger som overføres til amerikanske virksomheter som har sertifisert seg under ordningen. Overføring til en DPF-sertifisert mottaker krever da ikke ytterligere grunnlag som SCC.

Ordningen er omstridt og kan utfordres rettslig (en mulig «Schrems III»), så virksomheter bør følge med på utviklingen og vurdere reserveløsninger.

Eksempel

En bedrift sjekker at den amerikanske SaaS-leverandøren står oppført på DPF-listen før den tar tjenesten i bruk – og dokumenterer dette som overføringsgrunnlag.

Sist oppdatert: 14. juni 2026

NIS / NIS2 – Cybersikkerhet

NIS1-direktivet

#
NIS1Dir. 2016/1148Gjeldende rettNetwork and Information Security Directive

EUs første direktiv om nettverks- og informasjonssikkerhet, gjennomført i norsk rett gjennom digitalsikkerhetsloven.

NIS1 fra 2016 var EUs første felles regelverk for cybersikkerhet. Det stilte krav til tilbydere av samfunnsviktige tjenester (som energi, transport, helse og bank) og til enkelte digitale tjenester.

I Norge er NIS1 gjennomført gjennom digitalsikkerhetsloven, som trådte i kraft 1. oktober 2025. Det er altså denne loven – ikke direktivet direkte – du forholder deg til i norsk rett i dag.

Eksempel

En kraftleverandør omfattet av NIS1 må i dag oppfylle sikkerhets- og varslingskravene slik de er gjennomført i digitalsikkerhetsloven med forskrift.

Sist oppdatert: 14. juni 2026

NIS2-direktivet

#
NIS2Dir. 2022/2555Ikke i kraft i NorgeNetwork and Information Security Directive 2

EUs reviderte cybersikkerhetsdirektiv som utvider omfanget kraftig – ennå ikke gjennomført i norsk rett.

NIS2 fra 2022 erstatter NIS1 i EU og utvider regelverket betydelig: flere sektorer omfattes, kravene til risikostyring og hendelsesrapportering skjerpes, og ledelsen får et tydelig personlig ansvar.

NIS2 er foreløpig ikke norsk lov. Direktivet må først tas inn i EØS-avtalen, og per juni 2026 er det ikke fastsatt en endelig ikrafttredelsesdato i Norge. NSM har varslet en ny lov som vil gjennomføre NIS2 og CER, og som vil erstatte digitalsikkerhetsloven.

Eksempel

En mellomstor avfallshåndteringsbedrift som i dag faller utenfor digitalsikkerhetsloven, kan bli omfattet når NIS2 gjennomføres – og bør forberede seg nå.

Sist oppdatert: 14. juni 2026

Digitalsikkerhetsloven

#
DigitalsikkerhetslovenLov 2023-12-20-108Gjeldende rettLov om digital sikkerhet

Den norske loven som gjennomfører NIS1. Trådte i kraft 1. oktober 2025.

Digitalsikkerhetsloven (lov 2023-12-20-108) er det gjeldende norske regelverket for digital sikkerhet i samfunnsviktige og digitale tjenester. De overordnede pliktene står i loven, mens de konkrete kravene er fastsatt i forskrift.

Loven gjennomfører NIS1. Når NIS2 og CER en gang tas inn i EØS-avtalen, er det varslet at digitalsikkerhetsloven vil bli erstattet av en ny lov. Inntil da er det denne loven som gjelder.

Eksempel

En tilbyder av en samfunnsviktig tjeneste må kartlegge hvilke plikter digitalsikkerhetsloven og tilhørende forskrift pålegger virksomheten.

Sist oppdatert: 14. juni 2026

CER-direktivet

#
CERDir. 2022/2557Ikke i kraft i NorgeCritical Entities Resilience

EU-direktivet om kritiske enheters motstandsdyktighet – søsterregelverket til NIS2, også ennå ikke norsk lov.

CER-direktivet handler om fysisk og organisatorisk robusthet hos kritiske enheter, mens NIS2 dekker den digitale siden. De to henger tett sammen og innføres i EU som en pakke.

I Norge er CER, som NIS2, ikke gjennomført ennå. Den varslede nye loven er ventet å gjennomføre begge direktivene samlet.

Eksempel

Et vannverk kan bli omfattet av både CER (fysisk sikring og kontinuitet) og NIS2 (digital sikkerhet) når regelverket innføres.

Sist oppdatert: 14. juni 2026

EØS-prosessen

#
EØSEØS-avtalenIkke i kraft i Norge

Grunnen til at NIS2 ikke gjelder i Norge ennå: EU-direktiver må først innlemmes i EØS-avtalen.

Norge er ikke EU-medlem, men EØS-medlem. EU-direktiver blir ikke automatisk norsk rett – de må først tas inn i EØS-avtalen og deretter gjennomføres i nasjonal lovgivning.

For NIS2 og CER er denne innlemmelsen ikke fullført per juni 2026. Det er derfor heller ikke satt en endelig dato for når reglene trer i kraft i Norge. Følg med på NSM og regjeringen for oppdatert status.

Eksempel

Selv om NIS2 gjelder i EU fra oktober 2024, kan en norsk virksomhet ikke pålegges NIS2-pliktene før direktivet er innlemmet i EØS og gjennomført i norsk lov.

Sist oppdatert: 14. juni 2026

Tilbyder av samfunnsviktige tjenester

#
Digitalsikkerhetsloven§ 6Gjeldende rettOperator of essential services

Virksomhet som leverer en tjeneste samfunnet er sterkt avhengig av, og som er utpekt etter digitalsikkerhetsloven.

Dette er kjernen i NIS1 slik den er gjennomført i Norge. Det gjelder tilbydere i sektorer som energi, transport, helse, vannforsyning, bank og finansiell markedsinfrastruktur, samt digital infrastruktur.

Slike tilbydere må oppfylle sikkerhetskravene i § 7 og varsle hendelser etter § 8. Hvem som regnes som tilbyder fastsettes nærmere i forskrift.

Eksempel

Et større sykehus eller en nettselskap-operatør vil typisk være en tilbyder av samfunnsviktige tjenester etter § 6.

Sist oppdatert: 14. juni 2026

Tilbyder av digitale tjenester

#
Digitalsikkerhetsloven§ 9Gjeldende rettDigital service provider

Tilbyder av nettbasert markedsplass, nettbasert søkemotor eller skytjeneste, omfattet av digitalsikkerhetsloven.

Digitale tjenester er en egen, mer avgrenset kategori under NIS1. Den dekker tre tjenestetyper: nettbaserte markedsplasser, søkemotorer og skytjenester.

Disse tilbyderne har noe lempeligere krav enn samfunnsviktige tjenester, men må fortsatt ivareta sikkerhet (§ 10) og varsle vesentlige hendelser (§ 11). Svært små virksomheter er i utgangspunktet unntatt.

Eksempel

En norsk leverandør av en skytjeneste kan være en tilbyder av digitale tjenester etter § 9 og må da sikre tjenesten og varsle ved alvorlige hendelser.

Sist oppdatert: 14. juni 2026

Vesentlige virksomheter

#
NIS2Art. 3Ikke i kraft i NorgeEssential entities

NIS2-kategori for de mest kritiske virksomhetene, med strengest tilsyn – kommer ved norsk gjennomføring.

NIS2 deler virksomheter i to: vesentlige og viktige. Vesentlige virksomheter er de mest kritiske (typisk store aktører i sektorer som energi, helse, transport, bank og digital infrastruktur) og underlegges proaktivt tilsyn.

Kategorien finnes ikke i dagens digitalsikkerhetslov – den kommer først når NIS2 gjennomføres i norsk rett.

Eksempel

Et stort kraftselskap vil sannsynligvis bli klassifisert som en vesentlig virksomhet under NIS2, med løpende tilsyn fra myndighetene.

Sist oppdatert: 14. juni 2026

Viktige virksomheter

#
NIS2Art. 3Ikke i kraft i NorgeImportant entities

NIS2-kategori for virksomheter som er viktige, men ikke fullt så kritiske som vesentlige – med tilsyn i etterkant.

Viktige virksomheter omfattes av de samme grunnleggende kravene som vesentlige, men tilsynet er reaktivt: myndighetene griper inn først ved mistanke om brudd, ikke løpende.

Mange mellomstore virksomheter i de utvidede NIS2-sektorene vil havne i denne kategorien. Skillet får betydning for tilsynsintensitet og gebyrnivå.

Eksempel

En mellomstor produsent av næringsmidler eller en avfallsaktør kan bli en viktig virksomhet under NIS2.

Sist oppdatert: 14. juni 2026

Nasjonal sikkerhetsmyndighet (NSM)

#
NSMTilsynGjeldende rettNational security authority

Norges fagmyndighet for forebyggende sikkerhet, sentral i oppfølgingen av digitalsikkerhetsloven og kommende NIS2.

NSM koordinerer arbeidet med digital sikkerhet i Norge, drifter det nasjonale responsmiljøet (NCSC/CSIRT) og bistår sektormyndighetene. NSM har også varslet og forberedt den nye loven som skal gjennomføre NIS2 og CER.

Tilsynet med digitalsikkerhetsloven er fordelt på sektormyndigheter, men NSM har en samordnende og rådgivende rolle på tvers.

Eksempel

Ved en alvorlig hendelse vil mange virksomheter varsle og få bistand gjennom NSMs nasjonale responsmiljø.

Sist oppdatert: 14. juni 2026

Tilsynsmyndighet

#
Digitalsikkerhetsloven§§ 13–17Gjeldende rettSupervisory authority

Myndigheten som fører tilsyn med at kravene i digitalsikkerhetsloven følges, og som kan reagere ved brudd.

Tilsynet i Norge er sektorbasert: den myndigheten som ellers regulerer en sektor, fører som regel også tilsyn med digital sikkerhet der. Tilsynet kan gi pålegg og ilegge administrative reaksjoner.

Under NIS2 skjerpes tilsynet, med tydeligere skille mellom proaktivt tilsyn (vesentlige) og reaktivt tilsyn (viktige) og høyere gebyrtak.

Eksempel

Et energiselskap som ikke har varslet en hendelse, kan møte pålegg og reaksjoner fra sin sektortilsynsmyndighet etter §§ 13–17.

Sist oppdatert: 14. juni 2026

CSIRT (responsmiljø)

#
NIS1/NIS2Art. 10 (NIS2)Gjeldende rettComputer Security Incident Response Team

Det nasjonale miljøet som håndterer og koordinerer respons på alvorlige digitale hendelser.

Et CSIRT (også kalt CERT) tar imot varsler, analyserer trusler og bistår virksomheter under og etter hendelser. I Norge fyller NSM/NCSC denne rollen nasjonalt.

Både NIS1 og NIS2 forutsetter at hver stat har et velfungerende CSIRT. NIS2 stiller tydeligere krav til samarbeid og informasjonsdeling mellom landenes responsmiljøer.

Eksempel

Ved et pågående løsepengevirusangrep kan en virksomhet få teknisk bistand og koordinering fra det nasjonale responsmiljøet.

Sist oppdatert: 14. juni 2026

Samfunnsviktige tjenester

#
Digitalsikkerhetsloven§§ 2, 6Gjeldende rettEssential services

Tjenester samfunnet er kritisk avhengig av, og som utløser pliktene i digitalsikkerhetsloven.

Loven retter seg mot tjenester der bortfall får store konsekvenser for samfunnet – innen energi, transport, helse, vannforsyning, bank, finansiell markedsinfrastruktur og digital infrastruktur.

Hvilke konkrete tjenester og terskler som gjelder, er presisert i forskrift. Det er leveransen av selve tjenesten, ikke bransjen generelt, som er avgjørende.

Eksempel

Drift av et drikkevannsanlegg er en samfunnsviktig tjeneste; bortfall rammer mange og raskt.

Sist oppdatert: 14. juni 2026

Digitale tjenester

#
Digitalsikkerhetsloven§ 9Gjeldende rettDigital services

Nettbaserte markedsplasser, søkemotorer og skytjenester – en egen kategori i NIS1.

Digitale tjenester er presist avgrenset til tre typer: nettbaserte markedsplasser, nettbaserte søkemotorer og skytjenester. Kategorien er smalere enn samfunnsviktige tjenester.

Under NIS2 utvides og omklassifiseres digital infrastruktur og IKT-tjenester, slik at flere typer leverandører omfattes enn i dag.

Eksempel

En nettbasert markedsplass som formidler handel mellom tredjeparter, er en digital tjeneste etter § 9.

Sist oppdatert: 14. juni 2026

Sektorer (NIS2)

#
NIS2Vedlegg I og IIIkke i kraft i NorgeSectors of high criticality

NIS2 utvider antallet omfattede sektorer kraftig sammenlignet med NIS1.

NIS2 deler sektorer i «svært kritiske» (vedlegg I) og «andre kritiske» (vedlegg II). I tillegg til NIS1-sektorene kommer blant annet avløp, avfallshåndtering, post- og kurértjenester, næringsmidler, produksjon, kjemikalier, romvirksomhet og offentlig forvaltning.

Denne utvidelsen er en av de største endringene fra NIS1 til NIS2, og er hovedgrunnen til at mange flere norske virksomheter vil bli omfattet når regelverket gjennomføres.

Eksempel

En avfallshåndteringsbedrift er ikke omfattet av dagens digitalsikkerhetslov, men vil sannsynligvis falle inn under NIS2.

Sist oppdatert: 14. juni 2026

Størrelsesterskel (size-cap)

#
NIS2Art. 2Ikke i kraft i NorgeSize-cap rule

NIS2-regelen om at som hovedregel bare mellomstore og større virksomheter omfattes.

NIS2 bruker en størrelsesregel: virksomheten omfattes vanligvis hvis den har minst 50 ansatte eller mer enn 10 millioner euro i omsetning/balanse. Mindre virksomheter faller i utgangspunktet utenfor.

Det finnes viktige unntak – enkelte aktører omfattes uansett størrelse fordi de er kritiske (for eksempel deler av digital infrastruktur og offentlig forvaltning).

Eksempel

En bedrift med 60 ansatte i en NIS2-sektor vil normalt være omfattet, mens en med 15 ansatte normalt faller utenfor – med mindre den er kritisk uavhengig av størrelse.

Sist oppdatert: 14. juni 2026

Sikkerhetskrav

#
Digitalsikkerhetsloven§§ 7, 10Gjeldende rettSecurity requirements

Plikten til å iverksette forholdsmessige tekniske og organisatoriske tiltak for å sikre tjenesten.

Digitalsikkerhetsloven krever at tilbydere gjennomfører tiltak som står i forhold til risikoen, for å forebygge og håndtere hendelser. Kravene er funksjonelle – de sier hva som skal oppnås, ikke nøyaktig hvordan.

De konkrete kravene utdypes i forskrift. Under NIS2 erstattes og utvides dette av en mer detaljert liste over risikostyringstiltak.

Eksempel

En tilbyder gjennomfører tilgangsstyring, logging, sikkerhetskopiering og beredskapsøvelser som forholdsmessige sikkerhetstiltak etter loven.

Sist oppdatert: 14. juni 2026

Risikostyringstiltak

#
NIS2Art. 21Ikke i kraft i NorgeRisk-management measures

NIS2s detaljerte minimumsliste over sikkerhetstiltak virksomheter må ha på plass.

NIS2 artikkel 21 lister konkrete tiltak: risikoanalyse og sikkerhetspolicy, hendelseshåndtering, kontinuitet og sikkerhetskopiering, forsyningskjedesikkerhet, sikkerhet i anskaffelse og utvikling, kryptografi, tilgangskontroll, og opplæring.

Dette er mer presist enn dagens funksjonelle sikkerhetskrav, og innebærer at mange virksomheter må dokumentere tiltakene grundigere enn i dag.

Eksempel

Under NIS2 må en virksomhet kunne vise frem dokumenterte rutiner for blant annet hendelseshåndtering, backup og leverandøroppfølging.

Sist oppdatert: 14. juni 2026

Ledelsesansvar

#
NIS2Art. 20Ikke i kraft i NorgeGovernance / management

NIS2-kravet om at styret og ledelsen skal godkjenne og følge opp sikkerhetstiltakene – med personlig ansvar.

NIS2 løfter cybersikkerhet til styrenivå. Ledelsen må godkjenne risikostyringstiltakene, føre tilsyn med gjennomføringen og gjennomgå opplæring. Ansvaret kan ikke fullt ut delegeres bort.

Dette er en markant endring fra NIS1: ledelsen kan holdes personlig ansvarlig, og manglende oppfølging kan få konsekvenser for den enkelte leder.

Eksempel

Et styre må under NIS2 kunne dokumentere at det har behandlet og godkjent virksomhetens sikkerhetstiltak, ikke bare overlatt det til IT-avdelingen.

Sist oppdatert: 14. juni 2026

Forsyningskjedesikkerhet

#
NIS2Art. 21(2)Ikke i kraft i NorgeSupply chain security

Plikten til å vurdere og håndtere sikkerhetsrisiko hos leverandører og i forsyningskjeden.

NIS2 krever at virksomheter tar hensyn til sårbarheter hos sine direkte leverandører og tjenesteytere, og til kvaliteten på deres sikkerhetsarbeid. Forsyningskjedeangrep er en hovedbegrunnelse for regelen.

I praksis betyr det leverandørkartlegging, sikkerhetskrav i avtaler og løpende oppfølging – noe som ligner sterkt på god tredjeparts-risikostyring etter andre rammeverk.

Eksempel

En virksomhet stiller dokumenterte sikkerhetskrav til sin IT-driftsleverandør og følger opp at de etterleves, som ledd i forsyningskjedesikkerheten.

Sist oppdatert: 14. juni 2026

Registreringsplikt

#
NIS2Art. 27Ikke i kraft i NorgeRegistration

NIS2-kravet om at omfattede virksomheter må registrere seg hos myndighetene.

NIS2 forutsetter at omfattede virksomheter melder seg inn og oppgir nøkkelopplysninger, slik at myndighetene har oversikt over hvem som er underlagt regelverket. Dette gjør tilsyn og varsling mer effektivt.

Hvordan registreringen konkret skal skje i Norge, avklares ved den nasjonale gjennomføringen av NIS2.

Eksempel

Når NIS2 gjennomføres, må en omfattet virksomhet registrere kontaktopplysninger og sektor hos rett myndighet.

Sist oppdatert: 14. juni 2026

Representant i Norge

#
Digitalsikkerhetsloven§ 12Gjeldende rettRepresentative

Krav om at enkelte utenlandske tilbydere uten etablering i Norge utpeker en representant her.

Tilbydere av digitale tjenester som tilbyr tjenester i Norge, men ikke er etablert her, kan måtte utpeke en representant i landet. Representanten er kontaktpunkt overfor norske myndigheter.

Regelen sikrer at også grenseoverskridende tjenester kan følges opp av norsk tilsyn.

Eksempel

En utenlandsk skytjeneste som retter seg mot det norske markedet, kan måtte oppnevne en representant i Norge etter § 12.

Sist oppdatert: 14. juni 2026

Sikkerhetssertifisering

#
Digitalsikkerhetsloven§ 19Gjeldende rettCybersecurity certification

Bruk av europeiske sertifiseringsordninger for å dokumentere sikkerhet i produkter og tjenester.

Digitalsikkerhetsloven åpner for at IKT-produkter, -tjenester og -prosesser kan sertifiseres etter EUs cybersikkerhetssertifiseringsrammeverk. Sertifisering kan gjøre det enklere å dokumentere at sikkerhetskrav er oppfylt.

Sertifisering er i utgangspunktet frivillig, men kan bli stilt som krav i enkelte sammenhenger.

Eksempel

En leverandør kan velge å sertifisere en skytjeneste etter en europeisk ordning for å vise kunder at sikkerheten er uavhengig vurdert.

Sist oppdatert: 14. juni 2026

Hendelse (sikkerhetshendelse)

#
Digitalsikkerhetsloven§ 4Gjeldende rettIncident

En hendelse som faktisk virker negativt inn på sikkerheten i nettverk og informasjonssystemer.

Begrepet dekker mer enn vellykkede angrep: enhver hendelse som går ut over tilgjengelighet, integritet eller konfidensialitet i systemene kan regnes som en sikkerhetshendelse. Definisjonen står i § 4.

Det er konsekvensen for tjenesten som er avgjørende, ikke om det dreier seg om et bevisst angrep, en feil eller et uhell.

Eksempel

Et nettverksutfall som gjør en samfunnsviktig tjeneste utilgjengelig, er en hendelse – uavhengig av om årsaken er angrep eller teknisk svikt.

Sist oppdatert: 14. juni 2026

Varsling av hendelser

#
Digitalsikkerhetsloven§§ 8, 11Gjeldende rettIncident notification

Plikten til å varsle myndighetene om hendelser som vesentlig påvirker tjenesten.

Tilbydere av samfunnsviktige tjenester (§ 8) og digitale tjenester (§ 11) skal uten ugrunnet opphold varsle om hendelser som har betydelig innvirkning på leveransen. Formålet er rask respons og læring på tvers.

Under NIS2 blir varslingsreglene mer detaljerte, med konkrete frister og flere trinn i rapporteringen.

Eksempel

Når en hendelse fører til langvarig bortfall av en samfunnsviktig tjeneste, må tilbyderen varsle rett myndighet etter § 8.

Sist oppdatert: 14. juni 2026

Vesentlig hendelse

#
NIS2Art. 23Ikke i kraft i NorgeSignificant incident

NIS2-terskelen for hvilke hendelser som utløser varslingsplikt.

Under NIS2 må «vesentlige» hendelser varsles. En hendelse er vesentlig blant annet hvis den har forårsaket eller kan forårsake alvorlige driftsforstyrrelser eller økonomisk tap, eller har rammet andre gjennom betydelig skade.

Terskelen avgjør hva som må rapporteres, og henger sammen med de strenge varslingsfristene i NIS2.

Eksempel

Et løsepengevirusangrep som stanser produksjonen i flere dager vil typisk være en vesentlig hendelse under NIS2.

Sist oppdatert: 14. juni 2026

Varslingsfrister (NIS2)

#
NIS2Art. 23Ikke i kraft i NorgeReporting deadlines

NIS2s trinnvise frister for å varsle om vesentlige hendelser – 24 og 72 timer.

NIS2 innfører en trinnvis varsling: en tidlig forhåndsvarsel innen 24 timer, en mer utfyllende hendelsesmelding innen 72 timer, og en sluttrapport senest innen én måned.

Dette er strengere og mer presist enn dagens norske regler, og krever at virksomheten har en innøvd varslingsrutine før en hendelse inntreffer.

Eksempel

Etter et alvorlig angrep må virksomheten under NIS2 sende et første varsel innen 24 timer og en oppdatert melding innen 72 timer.

Sist oppdatert: 14. juni 2026

AI Act – KI-forordningen

KI-forordningen (AI Act)

#
AI ActForordning (EU) 2024/1689Ikke i kraft i NorgeArtificial Intelligence Act

EUs forordning som regulerer kunstig intelligens etter en risikobasert tilnærming.

KI-forordningen er verdens første brede regelverk for kunstig intelligens. Den deler KI-systemer inn etter risiko og stiller strengere krav jo høyere risikoen er. I EU trådte den i kraft 1. august 2024 og fases inn gradvis frem mot 2027.

I Norge er forordningen ennå ikke i kraft. Den er EØS-relevant og skal gjennomføres gjennom en egen norsk KI-lov ved inkorporasjon. Loven er ventet å tre i kraft sensommeren 2026. Inntil da viser vi til selve forordningen og til norsk veiledning.

Eksempel

En norsk bedrift som utvikler et KI-verktøy bør allerede nå kartlegge hvilken risikoklasse verktøyet havner i, slik at den er klar når forordningen gjelder i Norge.

Sist oppdatert: 14. juni 2026

KI-system

#
AI ActArt. 3(1)Ikke i kraft i NorgeAI system

Et maskinbasert system som, med en viss grad av autonomi, utleder hvordan det skal generere resultater som påvirker omgivelsene.

Definisjonen er bevisst teknologinøytral og bred. Et KI-system kjennetegnes ved at det utleder (inferens) fra inndata hvordan det skal produsere utdata som prediksjoner, innhold, anbefalinger eller beslutninger – med en viss autonomi og mulig tilpasningsevne.

Definisjonen avgjør om noe i det hele tatt omfattes av forordningen. Enkel, regelstyrt programvare uten læring eller inferens faller normalt utenfor.

Eksempel

En modell som anbefaler hvilke søkere som skal innkalles til intervju er et KI-system; et regneark som summerer tall er det ikke.

Sist oppdatert: 14. juni 2026

Risikobasert tilnærming

#
AI ActStrukturIkke i kraft i NorgeRisk-based approach

Prinsippet om at kravene til et KI-system skal stå i forhold til risikoen det utgjør.

Forordningen sorterer KI i fire nivåer: uakseptabel risiko (forbudt), høy risiko (strenge krav), begrenset risiko (transparensplikt) og minimal risiko (ingen særkrav). Jo større fare for helse, sikkerhet og grunnleggende rettigheter, desto strengere regler.

Tilnærmingen gjør at de fleste hverdagslige KI-systemer treffes lite, mens de mest inngripende reguleres hardt eller forbys.

Eksempel

Et spamfilter er minimal risiko, en CV-screener er høyrisiko, og sosial skåring er forbudt – tre nivåer i samme rammeverk.

Sist oppdatert: 14. juni 2026

EØS-status og KI-loven

#
AI ActEØS / KI-lovIkke i kraft i NorgeEEA implementation

Statusen for hvordan KI-forordningen blir norsk rett: gjennom EØS og en ny norsk KI-lov.

Som forordning gjelder AI Act direkte i EU, men ikke automatisk i Norge. Den må først tas inn i EØS-avtalen og gjennomføres i norsk rett. Regjeringen har valgt gjennomføring ved inkorporasjon – en henvisning som gjør forordningen til norsk lov.

Et lovutkast var på høring med frist 30. september 2025, og målet er ikrafttredelse sensommeren 2026. Nkom er utpekt som nasjonal koordinerende tilsynsmyndighet, og «KI-Norge» etableres som nasjonal arena.

Eksempel

Selv om forbudene i AI Act gjelder i EU fra februar 2025, kan en norsk virksomhet ikke pålegges pliktene før den norske KI-loven trer i kraft.

Sist oppdatert: 14. juni 2026

Generell KI-modell (GPAI)

#
AI ActArt. 51–55Ikke i kraft i NorgeGeneral-purpose AI model

En KI-modell trent på store datamengder som kan utføre et bredt spekter av oppgaver, som store språkmodeller.

GPAI-modeller (general-purpose AI) er grunnmodellene bak mange tjenester – for eksempel store språkmodeller. Forordningen stiller egne krav til leverandører av slike modeller, blant annet teknisk dokumentasjon, informasjon til de som bygger videre på modellen, og etterlevelse av opphavsrett i treningsdata.

Modeller som utgjør «systemisk risiko» får strengere krav. GPAI-reglene gjelder i EU fra august 2025.

Eksempel

En leverandør av en stor språkmodell må dokumentere modellen og gi nedstrømsutviklere nok informasjon til at de kan oppfylle sine egne plikter.

Sist oppdatert: 14. juni 2026

Uakseptabel risiko (forbudt praksis)

#
AI ActArt. 5Ikke i kraft i NorgeUnacceptable risk

KI-bruk som anses uforenlig med grunnleggende rettigheter og derfor er forbudt.

Øverst i risikopyramiden ligger praksis som er helt forbudt fordi den truer menneskers rettigheter og verdighet. Dette omfatter blant annet sosial skåring, visse former for biometrisk overvåking og manipulerende systemer.

Forbudene er den delen av forordningen som gjelder først – i EU fra 2. februar 2025.

Eksempel

Et system som rangerer innbyggere etter «pålitelighet» og gir fordeler eller straff basert på skåren, er forbudt praksis.

Sist oppdatert: 14. juni 2026

Høyrisiko-system

#
AI ActArt. 6 + Vedlegg IIIIkke i kraft i NorgeHigh-risk AI system

KI-system som kan ha betydelig negativ innvirkning på helse, sikkerhet eller grunnleggende rettigheter.

Høyrisiko-systemer er tillatt, men underlagt strenge krav. To hovedgrupper: KI som er en sikkerhetskomponent i et regulert produkt, og KI brukt på utpekte områder i vedlegg III – blant annet ansettelse, utdanning, kredittvurdering, kritisk infrastruktur og rettshåndhevelse.

Disse systemene må blant annet ha risikostyring, datakvalitet, teknisk dokumentasjon, menneskelig tilsyn og samsvarsvurdering før de tas i bruk. Kravene gjelder i EU hovedsakelig fra august 2026.

Eksempel

Et KI-verktøy som automatisk siler jobbsøkere er et høyrisiko-system og må oppfylle hele kravlisten før det settes i drift.

Sist oppdatert: 14. juni 2026

Begrenset risiko (transparensplikt)

#
AI ActArt. 50Ikke i kraft i NorgeLimited risk

KI-systemer som er tillatt, men der brukeren må få vite at de samhandler med eller ser KI.

For systemer med begrenset risiko er hovedkravet åpenhet. Folk skal vite at de snakker med en chatbot, og KI-generert eller -manipulert innhold skal merkes. Hensikten er å hindre villedning.

Utover transparenskravene stilles det ikke de samme tunge pliktene som for høyrisiko.

Eksempel

En chatbot på en nettside må gjøre det tydelig at det er en KI som svarer, ikke et menneske.

Sist oppdatert: 14. juni 2026

Minimal risiko

#
AI ActHovedregelIkke i kraft i NorgeMinimal risk

De aller fleste KI-systemer, som faller utenfor de strengere kategoriene og ikke får særkrav.

Mesteparten av KI i bruk i dag – spamfiltre, anbefalingsmotorer for underholdning, KI i dataspill – regnes som minimal risiko. Her stiller forordningen i utgangspunktet ingen særskilte plikter.

Virksomheter oppfordres likevel til frivillig å følge god praksis og etiske retningslinjer.

Eksempel

Et e-postfilter som sorterer søppelpost er minimal risiko og kan brukes fritt under forordningen.

Sist oppdatert: 14. juni 2026

Leverandør (provider)

#
AI ActArt. 3(3), 16Ikke i kraft i NorgeProvider

Den som utvikler et KI-system eller en KI-modell og bringer det på markedet under eget navn.

Leverandøren bærer hovedtyngden av pliktene i forordningen. Det er leverandøren som må sørge for at et høyrisiko-system oppfyller kravene, gjennomføre samsvarsvurdering, utarbeide dokumentasjon og CE-merke systemet.

Merk: også den som vesentlig endrer eller setter sitt eget navn på et eksisterende system, kan bli regnet som leverandør.

Eksempel

Et selskap som utvikler og selger et KI-basert kredittscoringsverktøy er leverandør og må oppfylle høyrisiko-kravene.

Sist oppdatert: 14. juni 2026

Ibruktaker (deployer)

#
AI ActArt. 3(4), 26Ikke i kraft i NorgeDeployer

Den som tar i bruk et KI-system i egen virksomhet (unntatt rent privat bruk).

Ibruktakeren – tidligere ofte kalt «bruker» i forordningssammenheng – er virksomheten som anvender systemet. For høyrisiko-systemer har ibruktaker egne plikter: følge bruksanvisningen, sikre menneskelig tilsyn, overvåke driften og oppbevare logger.

I noen tilfeller må ibruktaker også gjennomføre en vurdering av konsekvenser for grunnleggende rettigheter.

Eksempel

En kommune som tar i bruk et innkjøpt KI-verktøy for å prioritere søknader er ibruktaker og må sikre menneskelig tilsyn med avgjørelsene.

Sist oppdatert: 14. juni 2026

Importør og distributør

#
AI ActArt. 23–24Ikke i kraft i NorgeImporter / distributor

Aktører i omsetningskjeden som bringer KI-systemer fra utlandet inn på, eller videre i, markedet.

En importør bringer et KI-system fra en leverandør utenfor EØS inn på markedet, mens en distributør gjør et system tilgjengelig videre i kjeden. Begge må kontrollere at systemet er CE-merket og har nødvendig dokumentasjon.

De fungerer som et kontrolledd: oppdager de at et system ikke er i samsvar, må de avstå fra å gjøre det tilgjengelig og varsle videre.

Eksempel

En norsk forhandler som videreselger et høyrisiko-KI-system må sjekke at det er CE-merket før det tilbys kunder.

Sist oppdatert: 14. juni 2026

Berørt person

#
AI ActRettigheterIkke i kraft i NorgeAffected person

Personen som påvirkes av et KI-systems resultater eller beslutninger.

Forordningen verner ikke bare markedet, men menneskene som rammes av KI. Berørte personer har blant annet rett til informasjon når de er underlagt et høyrisiko-system, og rett til en forklaring på avgjørelser som påvirker dem vesentlig.

Dette henger tett sammen med rettighetene i personvernregelverket (GDPR), særlig ved automatiserte avgjørelser.

Eksempel

En jobbsøker som er silt ut av et KI-verktøy kan ha rett til informasjon om at KI ble brukt og en forklaring på resultatet.

Sist oppdatert: 14. juni 2026

Sosial skåring

#
AI ActArt. 5(1)(c)Ikke i kraft i NorgeSocial scoring

Forbudt vurdering av personer over tid basert på atferd eller egenskaper, som gir urettferdig behandling.

Forordningen forbyr at offentlige eller private aktører gir personer en sosial «skår» basert på atferd eller personlige egenskaper, når dette fører til ufordelaktig behandling i sammenhenger uten saklig forbindelse, eller til uforholdsmessig straff.

Forbudet retter seg mot den typen altomfattende borgerskåring som undergraver likebehandling og verdighet.

Eksempel

Et system som senker en persons tilgang til tjenester fordi vedkommende har «feil» handlemønster på sosiale medier, er forbudt sosial skåring.

Sist oppdatert: 14. juni 2026

Biometrisk fjernidentifikasjon

#
AI ActArt. 5(1)(h)Ikke i kraft i NorgeRemote biometric identification

Identifisering av personer på avstand via biometri – sterkt begrenset, og i sanntid på offentlig sted som hovedregel forbudt.

Sanntids biometrisk fjernidentifikasjon (typisk ansiktsgjenkjenning) i offentlig tilgjengelige rom for rettshåndhevelse er som hovedregel forbudt, med svært snevre unntak (for eksempel søk etter ofre for alvorlig kriminalitet) underlagt strenge vilkår og forhåndsgodkjenning.

Etterfølgende (ikke-sanntids) biometrisk identifikasjon og annen biometrisk bruk er ofte høyrisiko snarere enn forbudt.

Eksempel

Kontinuerlig ansiktsgjenkjenning av alle forbipasserende på et torg for politiformål vil som hovedregel være forbudt.

Sist oppdatert: 14. juni 2026

Skadelig manipulasjon

#
AI ActArt. 5(1)(a)Ikke i kraft i NorgeManipulative techniques

Forbud mot KI som bruker underbevisste eller villedende teknikker for å vri folks atferd til skade.

Forordningen forbyr KI-systemer som benytter subliminale, manipulerende eller villedende teknikker for å vesentlig forvrenge folks atferd på en måte som påfører dem, eller andre, betydelig skade.

Det avgjørende er at teknikken undergraver evnen til å ta informerte valg og fører til skade.

Eksempel

Et system som skjult dytter sårbare brukere mot stadig mer pengebruk på en måte som påfører dem økonomisk skade, kan rammes av forbudet.

Sist oppdatert: 14. juni 2026

Utnyttelse av sårbarhet

#
AI ActArt. 5(1)(b)Ikke i kraft i NorgeExploitation of vulnerabilities

Forbud mot KI som utnytter sårbarhet knyttet til alder, funksjonsnedsettelse eller sosial/økonomisk situasjon.

Det er forbudt å bruke KI som utnytter sårbarheter hos bestemte grupper – for eksempel barn, eldre eller personer i en vanskelig økonomisk situasjon – for å vesentlig vri atferden deres på en skadelig måte.

Bestemmelsen verner særlig de som lettest lar seg påvirke.

Eksempel

Et KI-drevet leketøy som oppmuntrer barn til farlig atferd vil kunne rammes av forbudet.

Sist oppdatert: 14. juni 2026

Emosjonsgjenkjenning på jobb og skole

#
AI ActArt. 5(1)(f)Ikke i kraft i NorgeEmotion recognition

Forbud mot KI som utleder følelser hos ansatte og elever (med snevre unntak).

Bruk av KI for å gjenkjenne følelser på arbeidsplassen og i utdanningsinstitusjoner er som hovedregel forbudt, med unntak for medisinske eller sikkerhetsmessige formål. Slike systemer regnes som inngripende og lite pålitelige.

Utenfor disse arenaene kan emosjonsgjenkjenning være tillatt, men er da ofte underlagt transparens- eller høyrisikokrav.

Eksempel

Et system som overvåker ansiktsuttrykkene til ansatte for å måle «engasjement» i møter vil som hovedregel være forbudt.

Sist oppdatert: 14. juni 2026

Prediktivt politiarbeid

#
AI ActArt. 5(1)(d)Ikke i kraft i NorgePredictive policing

Forbud mot KI som forutsier kriminalitet utelukkende basert på profilering av enkeltpersoner.

Forordningen forbyr KI-systemer som vurderer eller forutsier risikoen for at en person vil begå en straffbar handling, når dette utelukkende bygger på profilering eller personlighetstrekk.

Forbudet skal hindre at folk mistenkeliggjøres på grunnlag av hvem de er, ikke hva de har gjort.

Eksempel

Et system som flagger enkeltpersoner som «sannsynlige lovbrytere» basert på bakgrunn og personlighetsprofil er forbudt.

Sist oppdatert: 14. juni 2026

Samsvarsvurdering

#
AI ActArt. 43Ikke i kraft i NorgeConformity assessment

Prosessen som dokumenterer at et høyrisiko-system oppfyller forordningens krav før det tas i bruk.

Før et høyrisiko-system bringes på markedet, må det gjennom en samsvarsvurdering som viser at alle kravene er oppfylt. For noen systemer kan leverandøren vurdere selv (intern kontroll); for andre kreves et utpekt teknisk kontrollorgan.

Resultatet er en samsvarserklæring og grunnlaget for CE-merking. Vesentlige endringer kan utløse ny vurdering.

Eksempel

En leverandør av et høyrisiko-KI-verktøy gjennomfører samsvarsvurdering og utsteder en EU-samsvarserklæring før salg.

Sist oppdatert: 14. juni 2026

Risikostyringssystem

#
AI ActArt. 9Ikke i kraft i NorgeRisk management system

Et kontinuerlig system for å identifisere, vurdere og redusere risiko gjennom hele KI-systemets livsløp.

Høyrisiko-systemer må ha et dokumentert risikostyringssystem som løper gjennom hele livsløpet – ikke en engangsøvelse. Det skal kartlegge kjente og forutsigbare risikoer, vurdere dem og iverksette tiltak, og testes opp mot fastsatte formål.

Systemet ligner på risikostyring etter ISO-rammeverk, men er spisset mot helse, sikkerhet og grunnleggende rettigheter.

Eksempel

Leverandøren av et medisinsk KI-verktøy oppdaterer risikovurderingen løpende når nye feilkilder oppdages i bruk.

Sist oppdatert: 14. juni 2026

Datastyring og datasett

#
AI ActArt. 10Ikke i kraft i NorgeData governance

Krav til kvalitet, relevans og representativitet i dataene som brukes til å trene og teste høyrisiko-KI.

Trenings-, validerings- og testdata for høyrisiko-systemer må være relevante, representative og så langt som mulig feilfrie og fullstendige. Leverandøren må vurdere mulige skjevheter (bias) som kan føre til diskriminering.

God datastyring er ofte avgjørende for både rettssikkerhet og ytelse, og henger tett sammen med personvernreglene når dataene er personopplysninger.

Eksempel

Før en CV-screener settes i drift må treningsdataene sjekkes for skjevheter som kan ramme bestemte grupper urettferdig.

Sist oppdatert: 14. juni 2026

Teknisk dokumentasjon

#
AI ActArt. 11Ikke i kraft i NorgeTechnical documentation

Dokumentasjonen som viser hvordan et høyrisiko-system er bygget og at det oppfyller kravene.

Leverandøren må utarbeide og holde oppdatert teknisk dokumentasjon som beskriver systemets formål, design, data, ytelse og risikohåndtering. Dokumentasjonen skal være detaljert nok til at myndighetene kan vurdere samsvar.

Den er en forutsetning for samsvarsvurderingen og må kunne fremlegges ved tilsyn.

Eksempel

Ved tilsyn må leverandøren kunne vise teknisk dokumentasjon som forklarer hvordan høyrisiko-systemet fungerer og er testet.

Sist oppdatert: 14. juni 2026

Menneskelig tilsyn

#
AI ActArt. 14Ikke i kraft i NorgeHuman oversight

Krav om at mennesker effektivt kan overvåke og gripe inn i et høyrisiko-systems virkemåte.

Høyrisiko-systemer skal utformes slik at mennesker kan forstå, overvåke og om nødvendig overstyre dem. Det inkluderer mulighet til å gripe inn, stanse systemet og unngå blind tillit til resultatene (automatiseringsskjevhet).

Menneskelig tilsyn er et av de viktigste vernene mot at automatiserte avgjørelser får uforholdsmessige konsekvenser.

Eksempel

En saksbehandler må kunne overstyre et KI-verktøys innstilling og fatte den endelige avgjørelsen i en søknad.

Sist oppdatert: 14. juni 2026

CE-merking

#
AI ActArt. 48Ikke i kraft i NorgeCE marking

Merket som viser at et høyrisiko-system er vurdert til å være i samsvar med forordningen.

Når samsvarsvurderingen er bestått, påfører leverandøren CE-merket. Det signaliserer til marked og myndigheter at systemet oppfyller kravene og lovlig kan gjøres tilgjengelig i EØS.

CE-merking kjenner mange fra produktsikkerhet; for KI er det det synlige beviset på gjennomført samsvarsvurdering.

Eksempel

Et høyrisiko-KI-system må være CE-merket før det kan selges i det europeiske markedet.

Sist oppdatert: 14. juni 2026

EU-database for høyrisiko-KI

#
AI ActArt. 71Ikke i kraft i NorgeEU database

Et offentlig EU-register der høyrisiko-systemer registreres før de tas i bruk.

Forordningen oppretter en EU-database hvor leverandører (og enkelte ibruktakere) registrerer høyrisiko-systemer. Registeret skal gi åpenhet og gjøre det mulig for myndigheter og publikum å se hvilke systemer som er i bruk.

Registreringen skjer som hovedregel før systemet bringes på markedet eller tas i bruk.

Eksempel

Før et høyrisiko-system fra vedlegg III tas i bruk, skal det registreres i EUs database.

Sist oppdatert: 14. juni 2026

Merking av KI-innhold

#
AI ActArt. 50Ikke i kraft i NorgeContent marking

Plikten til å merke innhold som er generert eller manipulert av KI, slik at det er gjenkjennelig.

Leverandører av generativ KI må sørge for at utdata er maskinlesbart merket som kunstig generert. Den som publiserer KI-generert eller -manipulert innhold må også informere om det, særlig når innholdet kan villede.

Formålet er å motvirke desinformasjon og bevare tilliten til informasjon.

Eksempel

Et bilde laget av en bildegenerator bør merkes slik at både systemer og lesere kan se at det er KI-generert.

Sist oppdatert: 14. juni 2026

Deepfake

#
AI ActArt. 50(4)Ikke i kraft i NorgeDeepfake

KI-generert eller -manipulert lyd, bilde eller video som fremstår som ekte – må merkes.

En deepfake er realistisk innhold som er kunstig laget eller endret. Den som sprer slikt innhold må som hovedregel opplyse tydelig om at det er kunstig, med visse unntak for åpenbar kunst, satire og lignende.

Merkeplikten er et sentralt transparenskrav rettet mot manipulert media.

Eksempel

En reklamevideo med et KI-generert «vitnesbyrd» fra en person som aldri har uttalt seg, må merkes som kunstig.

Sist oppdatert: 14. juni 2026

Chatbot-opplysningsplikt

#
AI ActArt. 50(1)Ikke i kraft i NorgeChatbot disclosure

Plikten til å gjøre det klart for folk at de samhandler med et KI-system, ikke et menneske.

Når en person interagerer med et KI-system som en chatbot, skal det være tydelig at motparten er kunstig – med mindre det er åpenbart ut fra sammenhengen. Dette gir folk mulighet til å tilpasse tilliten sin.

Kravet gjelder uavhengig av om systemet ellers er lav- eller høyrisiko.

Eksempel

En kundeservice-chatbot må innledningsvis gjøre det klart at brukeren snakker med en KI-assistent.

Sist oppdatert: 14. juni 2026

Systemisk risiko (GPAI)

#
AI ActArt. 51Ikke i kraft i NorgeSystemic risk

Risiko fra de kraftigste generelle KI-modellene som kan få bred, samfunnsmessig påvirkning.

De mest kapable GPAI-modellene kan utgjøre «systemisk risiko» – for eksempel gjennom storskala påvirkning, misbrukspotensial eller uforutsette evner. Slike modeller får skjerpede krav, blant annet modellvurdering, risikoreduksjon, hendelsesrapportering og cybersikkerhet.

Terskelen knyttes blant annet til modellens beregningskraft og kapabilitet.

Eksempel

En svært kraftig språkmodell kan klassifiseres med systemisk risiko og må da blant annet teste og rapportere alvorlige hendelser.

Sist oppdatert: 14. juni 2026

AI Office (EU)

#
AI ActArt. 64Ikke i kraft i NorgeEuropean AI Office

EU-organet som fører tilsyn med generelle KI-modeller og koordinerer håndhevingen på tvers av EU.

AI Office i EU-kommisjonen har en sentral rolle, særlig for GPAI-modeller, og bidrar til ensartet anvendelse av forordningen i hele EU. Det utvikler veiledning, praksiskodekser og koordinerer med nasjonale myndigheter.

For norske virksomheter er AI Office relevant fordi det former hvordan reglene tolkes, selv om den daglige håndhevingen i Norge ligger hos nasjonale myndigheter.

Eksempel

En leverandør av en stor GPAI-modell forholder seg til AI Office for spørsmål om modellens plikter på EU-nivå.

Sist oppdatert: 14. juni 2026

Nkom – nasjonal tilsynsmyndighet

#
AI ActNorgeIkke i kraft i NorgeNational authority

Nkom er utpekt som Norges koordinerende tilsynsmyndighet for KI-forordningen.

Regjeringen har besluttet at Nasjonal kommunikasjonsmyndighet (Nkom) skal være nasjonal koordinerende tilsynsmyndighet for KI. Sektormyndigheter (som Datatilsynet og Helsedirektoratet) vil ha roller på sine områder.

I tillegg etableres «KI-Norge» som en nasjonal arena for ansvarlig og innovativ KI-bruk. Strukturen trer i kraft sammen med den norske KI-loven.

Eksempel

En virksomhet med spørsmål om KI-forordningen i Norge vil etter hvert kunne henvende seg til Nkom som koordinerende myndighet.

Sist oppdatert: 14. juni 2026

Regulatorisk sandkasse

#
AI ActArt. 57–58Ikke i kraft i NorgeRegulatory sandbox

Et veiledet testmiljø der virksomheter kan utvikle KI under tett dialog med myndighetene.

Forordningen pålegger statene å opprette regulatoriske sandkasser der KI kan utvikles og testes under tilsyn før lansering. Det senker risikoen og terskelen for ansvarlig innovasjon, særlig for mindre aktører.

Norge har allerede erfaring her: Datatilsynets sandkasse for kunstig intelligens har siden 2020 gitt veiledning om personvern i KI-prosjekter.

Eksempel

En oppstartsbedrift kan teste et KI-produkt i en sandkasse og få myndighetenes vurdering før den investerer tungt i lansering.

Sist oppdatert: 14. juni 2026

Overtredelsesgebyr

#
AI ActArt. 99Ikke i kraft i NorgeAdministrative fines

De økonomiske sanksjonene ved brudd på forordningen – blant de høyeste i EU-retten.

Forordningen har et trappet gebyrsystem. Brudd på forbudene (uakseptabel risiko) kan gi gebyr på inntil 35 millioner euro eller 7 % av global årsomsetning. Andre brudd har lavere, men fortsatt betydelige, tak.

Nivået understreker at etterlevelse ikke er valgfritt. For norske virksomheter aktiveres gebyrene når den norske KI-loven trer i kraft.

Eksempel

Et selskap som tar i bruk forbudt KI-praksis kan i ytterste konsekvens risikere gebyr på inntil 7 % av global omsetning.

Sist oppdatert: 14. juni 2026

DORA – Finanssektoren

DORA (forordningen)

#
DORAForordning (EU) 2022/2554Gjeldende rettDigital Operational Resilience Act

EUs forordning som stiller felles krav til digital operasjonell motstandsdyktighet i finanssektoren.

DORA samler og skjerper kravene til IKT-sikkerhet for finansforetak i Europa. Målet er at hele finanssystemet skal tåle, håndtere og komme seg etter IKT-hendelser. Forordningen dekker risikostyring, hendelsesrapportering, testing, tredjepartsrisiko og tilsyn.

DORA trådte i kraft i EU 17. januar 2025 og ble innlemmet i EØS-avtalen kort etter. I Norge er den gjeldende rett gjennom DORA-loven og DORA-forskriften.

Eksempel

En bank, et forsikringsselskap og en betalingsforetak må alle innrette IKT-arbeidet sitt etter DORA.

Sist oppdatert: 14. juni 2026

DORA-loven og -forskriften

#
DORA-lovenLov 2025-05-27-18Gjeldende rettDORA Act (Norway)

Det norske regelverket som gjennomfører DORA: DORA-loven og DORA-forskriften.

DORA er gjennomført i norsk rett ved inkorporasjon: DORA-loven (lov 2025-05-27-18) gjør forordningen til norsk lov gjennom en henvisning, og utfyllende regler ligger i DORA-forskriften. Begge trådte i kraft 1. juli 2025.

Finanstilsynet har deretter tatt inn nivå 2-regelverk (tekniske reguleringsstandarder) i forskriften – senest i januar 2026. Det er altså denne loven og forskriften, sammen med selve forordningen, du forholder deg til i Norge.

Eksempel

Et norsk finansforetak finner pliktene sine i forordningsteksten, gjort gjeldende gjennom DORA-loven § 1 og utdypet i DORA-forskriften.

Sist oppdatert: 14. juni 2026

Finansielle foretak (virkeområde)

#
DORAArt. 2Gjeldende rettFinancial entities

De foretakene DORA gjelder for – et bredt spekter av finanssektoren.

DORA gjelder svært bredt: banker, kredittforetak, betalings- og e-pengeforetak, verdipapirforetak, forsikrings- og pensjonsforetak, forvaltningsselskaper, markedsplasser, kredittvurderingsbyråer og flere. Også enkelte IKT-tredjepartsleverandører trekkes inn gjennom tilsynsrammeverket.

Hvor omfattende kravene blir, avhenger av foretakets størrelse og risiko (proporsjonalitet).

Eksempel

Et lite betalingsforetak og en stor bank er begge omfattet av DORA, men kan ha ulikt kravnivå.

Sist oppdatert: 14. juni 2026

Proporsjonalitet

#
DORAArt. 4Gjeldende rettProportionality

Prinsippet om at DORA-kravene skal tilpasses foretakets størrelse, risiko og kompleksitet.

DORA skal anvendes forholdsmessig. Et lite foretak med enkel IKT-bruk skal ikke pålegges like omfattende tiltak som en stor, kompleks aktør. Prinsippet går igjen i hele regelverket.

For de minste foretakene finnes et eget forenklet IKT-risikostyringsrammeverk.

Eksempel

En liten aktør kan oppfylle DORA med enklere dokumentasjon enn en systemkritisk storbank, så lenge risikoen faktisk er lavere.

Sist oppdatert: 14. juni 2026

IKT-risiko

#
DORAArt. 3Gjeldende rettICT risk

Risiko knyttet til informasjons- og kommunikasjonsteknologi som kan ramme foretakets drift og data.

IKT-risiko omfatter alt fra cyberangrep og systemfeil til menneskelige feil og leverandørsvikt som kan gå ut over tilgjengelighet, integritet eller konfidensialitet. DORA gjør håndtering av denne risikoen til en kjerneoppgave for finansforetak.

Begrepet er bredt og dekker både tekniske og organisatoriske årsaker.

Eksempel

Et nedetidsbrudd i kjernebanksystemet på grunn av en feilet oppdatering er materialisert IKT-risiko.

Sist oppdatert: 14. juni 2026

IKT-risikostyringsrammeverk

#
DORAArt. 6Gjeldende rettICT risk management framework

Et helhetlig, dokumentert rammeverk for å styre IKT-risiko gjennom hele livsløpet.

Hjertet i DORA. Foretaket må ha et dokumentert rammeverk med strategier, retningslinjer, prosedyrer og verktøy for å beskytte alle IKT-ressurser, oppdage trusler, respondere og gjenopprette. Rammeverket skal gjennomgås minst årlig.

Det skal være integrert i foretakets samlede risikostyring og forankret i ledelsen.

Eksempel

Foretaket etablerer et IKT-risikostyringsrammeverk som beskriver alt fra tilgangsstyring og logging til gjenoppretting etter hendelser.

Sist oppdatert: 14. juni 2026

Ledelsesansvar

#
DORAArt. 5Gjeldende rettManagement body responsibility

Styret og ledelsen har det endelige ansvaret for foretakets IKT-risikostyring.

DORA legger ansvaret tydelig på ledelsesorganet: det skal godkjenne og følge opp IKT-risikostrategien, sette av ressurser og holde seg oppdatert gjennom opplæring. Ansvaret kan ikke skyves ned i IT-avdelingen.

Dette speiler utviklingen i annet regelverk (som NIS2), der cybersikkerhet løftes til styrenivå.

Eksempel

Styret må behandle og godkjenne IKT-risikostrategien og kunne dokumentere at det følger den opp.

Sist oppdatert: 14. juni 2026

Forenklet IKT-rammeverk

#
DORAArt. 16Gjeldende rettSimplified framework

En lettere variant av kravene for enkelte små og mindre komplekse foretak.

Visse små foretak kan følge et forenklet IKT-risikostyringsrammeverk med færre formelle krav, som et utslag av proporsjonalitetsprinsippet. De grunnleggende pliktene består, men omfanget er tilpasset.

Finanstilsynet har laget veiledning og informasjonsmateriell om det forenklede rammeverket.

Eksempel

Et lite foretak med begrenset IKT-bruk kan oppfylle DORA gjennom det forenklede rammeverket fremfor det fulle.

Sist oppdatert: 14. juni 2026

Beredskap og kontinuitet

#
DORAArt. 11–12Gjeldende rettICT business continuity

Krav til kontinuitetsplaner, sikkerhetskopiering og gjenoppretting etter IKT-hendelser.

Foretaket må ha planer som sikrer at kritiske funksjoner kan opprettholdes og gjenopprettes raskt etter en hendelse. Det omfatter sikkerhetskopiering, gjenopprettingsprosedyrer og regelmessig testing av planene.

Målet er at en alvorlig hendelse ikke skal sette foretaket – eller finanssystemet – ut av spill.

Eksempel

Foretaket tester årlig at det kan gjenopprette kjernesystemene fra backup innenfor fastsatte tidsmål.

Sist oppdatert: 14. juni 2026

IKT-relatert hendelse

#
DORAArt. 3Gjeldende rettICT-related incident

En uforutsett hendelse som går ut over sikkerheten i nettverk og informasjonssystemer.

En IKT-hendelse er en enkelthendelse eller serie hendelser som kompromitterer sikkerheten og påvirker tilgjengelighet, autentisitet, integritet eller konfidensialitet. Begrepet dekker både angrep og driftsfeil.

Hendelser skal håndteres i en strukturert prosess og klassifiseres etter alvorlighet.

Eksempel

Et tjenestenektangrep som gjør nettbanken utilgjengelig er en IKT-relatert hendelse.

Sist oppdatert: 14. juni 2026

Klassifisering av hendelser

#
DORAArt. 18Gjeldende rettIncident classification

Metoden for å avgjøre hvor alvorlig en IKT-hendelse er, og om den må rapporteres.

DORA fastsetter kriterier for å klassifisere hendelser – blant annet antall berørte kunder, varighet, geografisk spredning, datatap og økonomisk virkning. Klassifiseringen avgjør om en hendelse er «alvorlig» og dermed rapporteringspliktig.

De nærmere tersklene er fastsatt i nivå 2-regelverk (tekniske standarder).

Eksempel

En hendelse som rammer mange kunder over lengre tid vil typisk klassifiseres som alvorlig og må rapporteres.

Sist oppdatert: 14. juni 2026

Hendelsesrapportering

#
DORAArt. 19Gjeldende rettMajor incident reporting

Plikten til å rapportere alvorlige IKT-relaterte hendelser til tilsynsmyndigheten.

Alvorlige hendelser skal rapporteres til Finanstilsynet i flere trinn: en første melding, en mellomrapport og en endelig rapport, etter fastsatte frister og maler. Hensikten er rask oversikt og læring på tvers av sektoren.

Rapporteringen følger felleseuropeiske maler fastsatt i nivå 2-regelverk.

Eksempel

Etter et alvorlig dataangrep sender foretaket en innledende hendelsesmelding til Finanstilsynet og følger opp med mer detaljerte rapporter.

Sist oppdatert: 14. juni 2026

Vesentlig cybertrussel

#
DORAArt. 19Gjeldende rettSignificant cyber threat

En alvorlig trussel som foretak frivillig kan rapportere, selv uten at en hendelse har inntruffet.

DORA åpner for frivillig rapportering av vesentlige cybertrusler – altså trusler som kunne ha blitt en alvorlig hendelse. Dette gir myndighetene et tidlig bilde og lar sektoren forberede seg.

Frivillig deling støtter opp under den bredere informasjonsdelingen i regelverket.

Eksempel

Oppdager et foretak en pågående, alvorlig angrepskampanje mot sektoren, kan det varsle dette frivillig.

Sist oppdatert: 14. juni 2026

Testing av motstandsdyktighet

#
DORAArt. 24–25Gjeldende rettResilience testing

Krav om regelmessig testing av IKT-systemer for å avdekke svakheter.

Foretak må ha et program for testing av digital operasjonell motstandsdyktighet, tilpasset størrelse og risiko. Grunnleggende tester omfatter blant annet sårbarhetsvurderinger, scenariotester og penetrasjonstesting.

Testing skal skje regelmessig og resultatene skal følges opp med tiltak.

Eksempel

Foretaket gjennomfører årlige sårbarhetsskanninger og scenariobaserte tester av kritiske systemer.

Sist oppdatert: 14. juni 2026

Trusselbasert penetrasjonstesting (TLPT)

#
DORAArt. 26–27Gjeldende rettThreat-led penetration testing

Avanserte, etterligningsbaserte angrepstester som enkelte større foretak må gjennomføre.

TLPT (threat-led penetration testing) er realistiske angrepstester basert på faktisk trusseletterretning, rettet mot foretakets produksjonssystemer. De mest kritiske foretakene må gjennomføre slik testing med jevne mellomrom, ofte i tråd med TIBER-rammeverket.

TLPT er betydelig mer krevende enn ordinær penetrasjonstesting og involverer tilsynsmyndighetene.

Eksempel

En systemkritisk bank gjennomfører hvert tredje år en TLPT der etiske hackere etterligner reelle angripere mot produksjonsmiljøet.

Sist oppdatert: 14. juni 2026

Sårbarhetsvurdering

#
DORAArt. 25Gjeldende rettVulnerability assessment

Systematisk kartlegging av svakheter i IKT-systemer som del av testprogrammet.

Sårbarhetsvurderinger og -skanninger er blant de grunnleggende testene alle omfattede foretak skal gjennomføre. De avdekker kjente svakheter som kan utnyttes, slik at de kan lukkes før de blir et problem.

Slike vurderinger er mindre omfattende enn TLPT, men skal gjøres jevnlig.

Eksempel

En månedlig sårbarhetsskanning avdekker et uoppdatert system, som deretter patches.

Sist oppdatert: 14. juni 2026

IKT-tredjepartsrisiko

#
DORAArt. 28Gjeldende rettICT third-party risk

Risiko som oppstår når foretak bruker eksterne leverandører til IKT-tjenester.

DORA stiller egne krav til styring av risiko knyttet til IKT-leverandører. Foretaket må ha en strategi for tredjepartsrisiko, vurdere leverandører før avtaleinngåelse og følge dem opp gjennom hele avtaleforholdet.

Dette ligner forsyningskjedekravene i NIS2, men er mer detaljert for finanssektoren.

Eksempel

Før en bank tar i bruk en ny skytjeneste, vurderer den leverandørens IKT-risiko og sikrer at avtalen oppfyller DORA-kravene.

Sist oppdatert: 14. juni 2026

IKT-tjenesteleverandør

#
DORAArt. 3Gjeldende rettICT third-party service provider

Et foretak som leverer IKT-tjenester til finansielle foretak.

Dette er leverandørene av tjenester som skydrift, programvare, datasentre og databehandling som finansforetak er avhengige av. DORA stiller krav både til foretakenes oppfølging av dem og – for de viktigste – til direkte tilsyn.

Leverandører innenfor samme konsern regnes også med.

Eksempel

En skyplattform som drifter en banks kjernesystemer er en IKT-tjenesteleverandør etter DORA.

Sist oppdatert: 14. juni 2026

Kontraktskrav til IKT-avtaler

#
DORAArt. 30Gjeldende rettContractual provisions

Minimumskravene til hva avtaler om IKT-tjenester må inneholde.

DORA fastsetter hva kontrakter med IKT-leverandører som et minimum skal regulere: tjenestebeskrivelse, tilgang og revisjonsrett, sikkerhetskrav, bistand ved hendelser, exit-strategier og – for kritiske funksjoner – ytterligere krav.

Foretaket må gå gjennom og om nødvendig reforhandle eksisterende avtaler for å oppfylle kravene.

Eksempel

En bank tar inn DORAs obligatoriske bestemmelser om revisjonsrett og exit i avtalen med sin skyleverandør.

Sist oppdatert: 14. juni 2026

Informasjonsregister

#
DORAArt. 28(3)Gjeldende rettRegister of information

Et register foretaket må føre over alle avtaler om bruk av IKT-tjenester.

Foretak må føre og vedlikeholde et register over alle avtaler om IKT-tjenester, med detaljer om leverandører, tjenester og hvilke som understøtter kritiske funksjoner. Registeret rapporteres til Finanstilsynet etter felles maler.

Registeret er et sentralt verktøy for både foretakets egen oversikt og myndighetenes tilsyn med konsentrasjonsrisiko.

Eksempel

Foretaket leverer årlig sitt informasjonsregister over IKT-avtaler til Finanstilsynet på fastsatt mal.

Sist oppdatert: 14. juni 2026

Konsentrasjonsrisiko

#
DORAArt. 29Gjeldende rettConcentration risk

Risikoen ved at mange foretak er avhengige av de samme få IKT-leverandørene.

Når store deler av finanssektoren bruker samme skyleverandør eller datasenter, kan svikt hos én leverandør ramme mange samtidig. DORA krever at foretak vurderer slik konsentrasjonsrisiko før og under avtaleforhold.

Konsentrasjonsrisiko er også en hovedgrunn til det direkte tilsynet med kritiske leverandører.

Eksempel

En bank vurderer om det å samle alle kritiske tjenester hos én skyleverandør gir for høy konsentrasjonsrisiko.

Sist oppdatert: 14. juni 2026

Utkontraktering av kritiske funksjoner

#
DORAArt. 28–30Gjeldende rettOutsourcing

Bruk av eksterne leverandører til funksjoner som er kritiske for foretaket.

Når en kritisk eller viktig funksjon settes ut, gjelder de strengeste kravene: grundig forhåndsvurdering, detaljerte kontraktsbestemmelser, løpende oppfølging og realistiske exit-planer slik at foretaket kan bytte leverandør uten å miste funksjonen.

Ansvaret for funksjonen forblir hos foretaket, selv om driften er utkontraktert.

Eksempel

En bank som utkontrakterer kjernedriften må ha en exit-plan som gjør at den kan flytte tjenesten ved leverandørsvikt.

Sist oppdatert: 14. juni 2026

Kritisk IKT-tredjepartsleverandør

#
DORAArt. 31Gjeldende rettCritical ICT third-party provider

En IKT-leverandør som er så viktig for finanssektoren at den underlegges direkte EU-tilsyn.

De viktigste IKT-leverandørene – typisk store skyaktører – kan utpekes som «kritiske» og blir da underlagt et eget europeisk tilsynsregime, uavhengig av de enkelte finansforetakene som bruker dem.

Dette er nytt: tilsynet retter seg direkte mot leverandøren, ikke bare mot finansforetaket.

Eksempel

En global skyleverandør som mange europeiske banker er avhengige av, kan bli utpekt som kritisk IKT-tredjepartsleverandør.

Sist oppdatert: 14. juni 2026

Tilsynsrammeverk (Lead Overseer)

#
DORAArt. 31–44Gjeldende rettOversight framework

Det europeiske rammeverket for tilsyn med kritiske IKT-leverandører.

For hver kritisk leverandør utpekes en hovedtilsynsfører (Lead Overseer) blant de europeiske tilsynsmyndighetene. Denne kan kreve informasjon, gjennomføre undersøkelser og inspeksjoner og gi anbefalinger om å redusere risiko.

Rammeverket sikrer koordinert oppfølging av leverandører som er felles for mange foretak og land.

Eksempel

En hovedtilsynsfører kan inspisere en kritisk skyleverandør og kreve at den retter opp avdekkede svakheter.

Sist oppdatert: 14. juni 2026

Finanstilsynet

#
DORATilsynsmyndighetGjeldende rettCompetent authority

Den norske tilsynsmyndigheten som håndhever DORA overfor finansforetak i Norge.

Finanstilsynet fører tilsyn med at norske finansforetak etterlever DORA, tar imot hendelsesrapporter og informasjonsregistre, og fastsetter utfyllende forskrifter. Tilsynet har også publisert veiledere og Q&A om regelverket.

For kritiske IKT-leverandører skjer det overordnede tilsynet på europeisk nivå, i samarbeid med nasjonale myndigheter.

Eksempel

Et foretak sender hendelsesrapporter og det årlige informasjonsregisteret til Finanstilsynet.

Sist oppdatert: 14. juni 2026

Informasjonsdeling

#
DORAArt. 45Gjeldende rettInformation sharing

Frivillig deling av trusselinformasjon mellom finansforetak.

DORA oppmuntrer foretak til å dele etterretning om cybertrusler og sårbarheter seg imellom, innenfor betrodde fellesskap. Bedre felles situasjonsforståelse styrker hele sektorens motstandsdyktighet.

Delingen er frivillig og skal skje innenfor rammene av blant annet personvern og konkurranseregler.

Eksempel

Flere banker deler indikatorer på en pågående phishing-kampanje slik at alle kan beskytte seg raskere.

Sist oppdatert: 14. juni 2026

Sanksjoner og pålegg

#
DORAArt. 50Gjeldende rettSanctions

Reaksjonene tilsynsmyndigheten kan bruke ved brudd på DORA.

Ved manglende etterlevelse kan Finanstilsynet gi pålegg og bruke administrative reaksjoner. DORA krever at statene har effektive, forholdsmessige og avskrekkende sanksjoner, og rammene er tatt inn i norsk rett gjennom DORA-loven og -forskriften.

For kritiske IKT-leverandører kan tilsynsorganet på europeisk nivå ilegge tvangsmulkt.

Eksempel

Et foretak som gjentatte ganger unnlater å rapportere alvorlige hendelser, kan møte pålegg og reaksjoner fra Finanstilsynet.

Sist oppdatert: 14. juni 2026

ISO/IEC 27001 – Informasjonssikkerhet

ISO/IEC 27001

#
ISO/IEC27001:2022Frivillig standardInformation security management

Den internasjonale standarden som angir kravene til et ledelsessystem for informasjonssikkerhet (ISMS).

ISO/IEC 27001 er den anerkjente standarden for å styre informasjonssikkerhet systematisk. Den beskriver hvordan en virksomhet skal etablere, drifte, vedlikeholde og forbedre et ledelsessystem (ISMS) basert på risiko. Gjeldende utgave er fra 2022.

Standarden er frivillig – den er ikke en lov. Men sertifisering brukes ofte for å dokumentere god sikkerhet overfor kunder og myndigheter, og den støtter etterlevelse av blant annet GDPR, NIS2 og DORA.

Eksempel

En leverandør sertifiserer seg etter ISO/IEC 27001:2022 for å vise kunder at informasjonssikkerheten er systematisk styrt.

Sist oppdatert: 14. juni 2026

Ledelsessystem for informasjonssikkerhet (ISMS)

#
ISO/IEC27001Frivillig standardInformation Security Management System

Det helhetlige systemet av policyer, prosesser og kontroller som styrer informasjonssikkerheten.

Et ISMS (Information Security Management System) er kjernen i ISO/IEC 27001. Det er ikke et IT-verktøy, men et styringssystem: en strukturert måte å identifisere risiko på og forvalte tiltak, roller, dokumentasjon og forbedring over tid.

Et velfungerende ISMS gjør sikkerhet til en kontinuerlig, ledelsesforankret prosess fremfor en engangsjobb.

Eksempel

Virksomheten etablerer et ISMS som binder sammen risikovurdering, policyer, kontroller og jevnlig forbedring.

Sist oppdatert: 14. juni 2026

ISO/IEC 27002

#
ISO/IEC27002:2022Frivillig standardInformation security controls

Veiledningsstandarden som beskriver de enkelte sikkerhetskontrollene i detalj.

Mens ISO/IEC 27001 stiller kravene til selve ledelsessystemet, gir ISO/IEC 27002 utfyllende veiledning om hvordan hver enkelt kontroll i Tillegg A kan utformes. De to brukes sammen.

2022-utgaven omorganiserte kontrollene til fire temaer og innførte nye kontroller for blant annet trusseletterretning og skytjenester.

Eksempel

Når virksomheten skal implementere en konkret kontroll fra Tillegg A, slår den opp detaljert veiledning i ISO/IEC 27002.

Sist oppdatert: 14. juni 2026

ISO/IEC 27000-familien

#
ISO/IEC27000-serienFrivillig standardISO 27k family

Familien av standarder som utdyper ulike sider ved informasjonssikkerhetsstyring.

Rundt ISO/IEC 27001 finnes en hel familie: 27000 (begreper), 27002 (kontroller), 27005 (risikostyring), 27017/27018 (sky og personvern i sky) med flere. Sammen utgjør de et komplett verktøysett.

Du sertifiseres mot 27001, men trekker på de øvrige for veiledning.

Eksempel

I et risikoarbeid kan virksomheten støtte seg på ISO/IEC 27005 i tillegg til kravene i 27001.

Sist oppdatert: 14. juni 2026

NS-ISO/IEC 27001

#
Standard NorgeNS-EN ISO/IEC 27001:2022Frivillig standardNorwegian adoption

Den norske utgaven av ISO/IEC 27001, fastsatt som Norsk Standard av Standard Norge.

Internasjonale ISO-standarder gjøres til Norsk Standard gjennom Standard Norge. Den norske versjonen heter NS-EN ISO/IEC 27001:2022 og har samme innhold som den internasjonale standarden, tilgjengelig på norsk.

Det er denne du kjøper og refererer til i en norsk sammenheng, men sertifiseringen er internasjonalt anerkjent.

Eksempel

En norsk virksomhet anskaffer NS-EN ISO/IEC 27001:2022 fra Standard Norge som grunnlag for ISMS-arbeidet.

Sist oppdatert: 14. juni 2026

Informasjonssikkerhet

#
ISO/IEC27000Frivillig standardInformation security

Å bevare konfidensialiteten, integriteten og tilgjengeligheten til informasjon.

Informasjonssikkerhet handler om å beskytte informasjon uansett form – digitalt, på papir eller i hodene til folk. Målet uttrykkes gjennom tre egenskaper (CIA-triaden), og oppnås gjennom en kombinasjon av tekniske, organisatoriske og menneskelige tiltak.

ISO/IEC 27001 gir en systematisk måte å oppnå og opprettholde dette på.

Eksempel

Å låse arkivskap, kryptere disker og lære opp ansatte er alle tiltak for informasjonssikkerhet.

Sist oppdatert: 14. juni 2026

CIA-triaden

#
ISO/IEC27000Frivillig standardConfidentiality, Integrity, Availability

De tre grunnpilarene i informasjonssikkerhet: konfidensialitet, integritet og tilgjengelighet.

Konfidensialitet betyr at informasjon bare er tilgjengelig for de som skal ha den; integritet at den er korrekt og uendret; tilgjengelighet at den er der når man trenger den. Et sikkerhetstiltak handler alltid om å beskytte én eller flere av disse.

Triaden er den felles målestokken når man vurderer risiko og velger kontroller.

Eksempel

Et løsepengevirus rammer tilgjengelighet (data låst) og kan true konfidensialitet (data stjålet) – to av tre pilarer samtidig.

Sist oppdatert: 14. juni 2026

Virkeområde (scope)

#
ISO/IECKlausul 4Frivillig standardScope

Avgrensningen av hva ISMS-et – og dermed en eventuell sertifisering – faktisk dekker.

Virksomheten må definere hvilke deler av organisasjonen, hvilke lokasjoner, systemer og informasjon ISMS-et omfatter. Virkeområdet styrer hva som skal risikovurderes og kontrolleres, og hva en sertifisering gjelder for.

Et for snevert virkeområde kan gjøre sertifiseringen lite verdt; et for bredt kan gjøre arbeidet uoverkommelig.

Eksempel

En virksomhet kan velge å la ISMS-et først dekke driftsavdelingen og kundedataene, og utvide senere.

Sist oppdatert: 14. juni 2026

Risikoeier

#
ISO/IECKlausul 6Frivillig standardRisk owner

Den personen eller rollen som har ansvaret for en bestemt risiko og for å håndtere den.

ISO/IEC 27001 krever at hver identifisert risiko har en eier som kan ta beslutninger om hvordan den skal håndteres, og som godkjenner restrisikoen. Det plasserer ansvaret tydelig.

Risikoeierskap kobler risikoarbeidet til reell beslutningsmyndighet i organisasjonen.

Eksempel

Lederen for kundeservice utpekes som risikoeier for risikoer knyttet til behandling av kundehenvendelser.

Sist oppdatert: 14. juni 2026

Risikovurdering

#
ISO/IECKlausul 6.1.2Frivillig standardRisk assessment

Prosessen med å identifisere, analysere og evaluere informasjonssikkerhetsrisiko.

Risikovurderingen er motoren i ISO/IEC 27001. Virksomheten kartlegger hva som kan gå galt, hvor sannsynlig det er og hvor alvorlige konsekvensene blir, og prioriterer deretter. Vurderingen skal være konsistent og gjentakbar.

Resultatet styrer hvilke kontroller som faktisk trengs – sikkerhet skal være risikobasert, ikke synsebasert.

Eksempel

Virksomheten vurderer at tap av kundedatabasen har høy konsekvens og middels sannsynlighet, og prioriterer tiltak deretter.

Sist oppdatert: 14. juni 2026

Risikohåndtering

#
ISO/IECKlausul 6.1.3Frivillig standardRisk treatment

Beslutningen om hva man skal gjøre med hver risiko, og valg av kontroller.

Etter vurderingen velges håndtering: redusere risikoen med kontroller, akseptere den, unngå aktiviteten eller overføre risikoen (f.eks. forsikring). Valgte kontroller knyttes til Tillegg A og dokumenteres i erklæringen om anvendelighet.

Restrisikoen skal godkjennes av risikoeier.

Eksempel

For risikoen for datatap velger virksomheten å redusere den med kryptering og backup, og aksepterer den lille restrisikoen som gjenstår.

Sist oppdatert: 14. juni 2026

Erklæring om anvendelighet (SoA)

#
ISO/IECKlausul 6.1.3 dFrivillig standardStatement of Applicability

Dokumentet som viser hvilke kontroller fra Tillegg A som gjelder, og hvorfor.

Statement of Applicability (SoA) er et av de viktigste dokumentene i et ISMS. Det lister alle kontrollene i Tillegg A, om de er tatt i bruk eller ikke, begrunnelsen, og statusen for hver. Det knytter risikohåndteringen til konkrete kontroller.

Revisor bruker SoA-en som inngang til å vurdere om virksomheten faktisk gjør det den sier.

Eksempel

I SoA-en begrunner virksomheten hvorfor en kontroll om fysisk adgangskontroll er relevant, mens en om utviklingssikkerhet ikke er det.

Sist oppdatert: 14. juni 2026

Risikoakseptkriterier

#
ISO/IECKlausul 6.1.2Frivillig standardRisk acceptance criteria

De forhåndsdefinerte grensene for hvilken risiko virksomheten er villig til å akseptere.

For å vurdere risiko konsistent må virksomheten på forhånd bestemme hva som er akseptabelt og hva som krever tiltak. Akseptkriteriene gjør risikobeslutninger etterprøvbare og forankret i ledelsens risikovilje.

Uten klare kriterier blir risikohåndtering vilkårlig.

Eksempel

Virksomheten bestemmer at all risiko vurdert som «høy» må reduseres, mens «lav» kan aksepteres uten ytterligere tiltak.

Sist oppdatert: 14. juni 2026

Tillegg A (Annex A)

#
ISO/IECTillegg AFrivillig standardAnnex A controls

Referanselisten med sikkerhetskontroller som virksomheten velger fra ut fra risiko.

Tillegg A i ISO/IEC 27001:2022 inneholder 93 kontroller organisert i fire temaer: organisatoriske, personell, fysiske og teknologiske. Kontrollene er ikke en obligatorisk sjekkliste – man velger de som er relevante ut fra risikovurderingen.

Detaljert veiledning til hver kontroll finnes i ISO/IEC 27002.

Eksempel

Ut fra risikovurderingen velger virksomheten relevante kontroller fra Tillegg A og dokumenterer valget i SoA-en.

Sist oppdatert: 14. juni 2026

Organisatoriske kontroller

#
ISO/IECTillegg A 5Frivillig standardOrganizational controls

Kontroller knyttet til styring, policyer, roller og leverandørforhold.

Den største temagruppen i Tillegg A dekker det organisatoriske: sikkerhetspolicyer, roller og ansvar, leverandørstyring, hendelseshåndtering, klassifisering av informasjon og kontinuitet. Dette er «styringssiden» av sikkerheten.

Mange av disse kontrollene handler om prosess og ansvar snarere enn teknologi.

Eksempel

En kontroll om leverandørstyring krever at virksomheten stiller og følger opp sikkerhetskrav til leverandørene sine.

Sist oppdatert: 14. juni 2026

Personellkontroller

#
ISO/IECTillegg A 6Frivillig standardPeople controls

Kontroller knyttet til ansatte – fra ansettelse og opplæring til ansvar og avslutning.

Mennesker er ofte den største sårbarheten. Personellkontrollene dekker bakgrunnssjekk, taushetsplikt, sikkerhetsopplæring og bevisstgjøring, og håndtering av tilganger ved rollebytte og fratredelse.

Godt sikkerhetsarbeid forutsetter at folk forstår sin rolle i det.

Eksempel

En kontroll krever at tilganger fjernes umiddelbart når en ansatt slutter.

Sist oppdatert: 14. juni 2026

Fysiske kontroller

#
ISO/IECTillegg A 7Frivillig standardPhysical controls

Kontroller som beskytter lokaler, utstyr og fysiske medier.

Fysisk sikkerhet er en del av informasjonssikkerhet. Temaet dekker adgangskontroll til bygg og rom, beskyttelse av utstyr, sikker avhending av medier og kontroll med fysiske trusler.

Selv det beste digitale forsvaret hjelper lite hvis noen kan gå rett inn i serverrommet.

Eksempel

En kontroll krever adgangskort og logging for å komme inn i serverrommet.

Sist oppdatert: 14. juni 2026

Teknologiske kontroller

#
ISO/IECTillegg A 8Frivillig standardTechnological controls

Tekniske kontroller som tilgangsstyring, kryptering, logging og sårbarhetshåndtering.

Den teknologiske temagruppen dekker det de fleste forbinder med IT-sikkerhet: autentisering og tilgangsstyring, kryptering, sikkerhetskopiering, logging og overvåking, beskyttelse mot skadevare og sårbarhetshåndtering.

Kontrollene skal velges ut fra risiko og samspille med de organisatoriske.

Eksempel

En kontroll krever flerfaktorautentisering for tilgang til kritiske systemer.

Sist oppdatert: 14. juni 2026

Ledelsens forpliktelse

#
ISO/IECKlausul 5Frivillig standardLeadership

Kravet om at toppledelsen aktivt eier og driver ISMS-et.

ISO/IEC 27001 krever synlig lederengasjement: ledelsen skal fastsette sikkerhetspolicy, sørge for ressurser, integrere ISMS-et i virksomhetens prosesser og følge opp at det virker. Sikkerhet kan ikke delegeres bort som «noe IT styrer med».

Uten reell ledelsesforankring kollapser et ISMS over tid.

Eksempel

Toppledelsen vedtar sikkerhetspolicyen og setter av budsjett og personer til sikkerhetsarbeidet.

Sist oppdatert: 14. juni 2026

Informasjonssikkerhetspolicy

#
ISO/IECKlausul 5.2Frivillig standardSecurity policy

Det styrende dokumentet som angir virksomhetens mål og rammer for informasjonssikkerhet.

Sikkerhetspolicyen er ledelsens overordnede erklæring: hva virksomheten vil oppnå med informasjonssikkerheten og hvilke prinsipper som gjelder. Den er forankret i toppledelsen og danner paraplyen over mer detaljerte retningslinjer.

Policyen skal være kjent i organisasjonen og gjennomgås jevnlig.

Eksempel

Virksomhetens sikkerhetspolicy slår fast at all sensitiv informasjon skal klassifiseres og beskyttes etter klassifisering.

Sist oppdatert: 14. juni 2026

Dokumentert informasjon

#
ISO/IECKlausul 7.5Frivillig standardDocumented information

Dokumentasjonen ISMS-et krever for å styre og bevise etterlevelse.

Et ISMS må dokumenteres: policyer, prosedyrer, risikovurdering, SoA, registre og bevis for at aktiviteter er gjennomført. Dokumentasjonen skal være styrt – riktig versjon, tilgjengelig for de som trenger den, beskyttet mot endring.

Ved revisjon er det dokumentasjonen, sammen med praksis, som viser at systemet faktisk virker.

Eksempel

Virksomheten holder oppdaterte prosedyrer og loggfører at internrevisjon og ledelsens gjennomgang er gjennomført.

Sist oppdatert: 14. juni 2026

Internrevisjon

#
ISO/IECKlausul 9.2Frivillig standardInternal audit

Virksomhetens egen, planlagte kontroll av at ISMS-et fungerer og følges.

ISO/IEC 27001 krever at virksomheten med jevne mellomrom reviderer sitt eget ISMS for å sjekke at det er i samsvar med både standarden og egne krav, og at det faktisk etterleves. Funn følges opp som avvik.

Internrevisjon er en forutsetning for ledelsens gjennomgang og for en vellykket sertifiseringsrevisjon.

Eksempel

En intern revisor går gjennom tilgangsstyringen og avdekker at noen sluttede ansatte fortsatt har kontoer – et avvik som må lukkes.

Sist oppdatert: 14. juni 2026

Ledelsens gjennomgang

#
ISO/IECKlausul 9.3Frivillig standardManagement review

Toppledelsens regelmessige vurdering av om ISMS-et er egnet, tilstrekkelig og effektivt.

Med jevne mellomrom skal ledelsen gjennomgå ISMS-et: status på risiko, resultater fra revisjoner og målinger, hendelser, og behov for endringer. Gjennomgangen sikrer at systemet utvikler seg i takt med virksomheten og trusselbildet.

Den er et konkret uttrykk for ledelsens forpliktelse og leder til beslutninger om forbedring.

Eksempel

På ledelsens gjennomgang besluttes det å styrke opplæringen etter at flere hendelser skyldtes phishing.

Sist oppdatert: 14. juni 2026

Avvik og korrigerende tiltak

#
ISO/IECKlausul 10.1Frivillig standardNonconformity & corrective action

Håndtering av avvik fra kravene, med tiltak for å rette årsaken.

Når noe ikke er i samsvar med standarden eller egne krav, er det et avvik. ISO/IEC 27001 krever at avvik håndteres systematisk: rette feilen, finne rotårsaken og iverksette tiltak som hindrer gjentakelse.

Avvikshåndtering er selve mekanismen som gjør at systemet lærer og blir bedre.

Eksempel

Etter et avvik om svake passord innføres krav om passordhåndtering og flerfaktor, og endringen verifiseres.

Sist oppdatert: 14. juni 2026

Kontinuerlig forbedring (PDCA)

#
ISO/IECKlausul 10Frivillig standardContinual improvement

Prinsippet om at ISMS-et stadig skal forbedres – ofte beskrevet som Planlegg–Utfør–Kontroller–Korriger.

Et ISMS er aldri «ferdig». Gjennom sykluser av planlegging, gjennomføring, kontroll og korrigering (PDCA) skal virksomheten stadig heve sikkerhetsnivået i takt med endringer i risiko, teknologi og organisasjon.

Det er denne forbedringssløyfen som skiller et levende styringssystem fra en perm i hylla.

Eksempel

Erfaringer fra fjorårets hendelser og revisjoner brukes til å forbedre kontrollene neste syklus.

Sist oppdatert: 14. juni 2026

Sertifisering

#
ISO/IEC27001Frivillig standardCertification

Uavhengig bekreftelse på at virksomhetens ISMS oppfyller ISO/IEC 27001.

Sertifisering er en frivillig, men verdifull bekreftelse: et uavhengig sertifiseringsorgan reviderer ISMS-et og utsteder et sertifikat hvis kravene er oppfylt. Sertifikatet er gyldig i en periode (typisk tre år) med årlige oppfølgingsrevisjoner.

For mange virksomheter er sertifisering et konkurransefortrinn og et krav fra kunder.

Eksempel

Etter en vellykket revisjon mottar virksomheten et ISO/IEC 27001:2022-sertifikat som den kan vise til i anbud.

Sist oppdatert: 14. juni 2026

Sertifiseringsorgan og akkreditering

#
ISO/IEC27006Frivillig standardCertification body & accreditation

Den uavhengige tredjeparten som utsteder sertifikatet, og som selv er akkreditert til å gjøre det.

Et sertifikat er bare så troverdig som den som utsteder det. Sertifiseringsorganet må være akkreditert (i Norge av Norsk akkreditering) etter egne krav, slik at sertifiseringen er upartisk og anerkjent internasjonalt.

Akkrediteringen er det som gjør at et norsk sertifikat anerkjennes i utlandet.

Eksempel

Virksomheten velger et akkreditert sertifiseringsorgan slik at sertifikatet godtas av internasjonale kunder.

Sist oppdatert: 14. juni 2026

Sertifiseringsrevisjon

#
ISO/IEC27006Frivillig standardCertification audit

Den eksterne revisjonen som fører til sertifisering, gjennomført i trinn.

Sertifisering skjer i trinn: trinn 1 (dokumentasjonsgjennomgang og modenhet) og trinn 2 (vurdering av at ISMS-et faktisk etterleves). Deretter følger årlige oppfølgingsrevisjoner og en full resertifisering etter tre år.

Avvik funnet under revisjonen må lukkes før sertifikat utstedes eller beholdes.

Eksempel

I trinn 2 verifiserer revisor at kontrollene i SoA-en er implementert og virker i praksis.

Sist oppdatert: 14. juni 2026

Lead Implementer og Lead Auditor

#
ISO/IECPersonsertifiseringFrivillig standardLead Implementer / Auditor

Personsertifiseringer for de som henholdsvis innfører og reviderer et ISMS.

I tillegg til at virksomheter sertifiseres, finnes personsertifiseringer. En Lead Implementer er trent i å etablere og drifte et ISMS, mens en Lead Auditor er trent i å revidere det. Disse tilbys av organer som PECB.

Slik kompetanse hos en rådgiver gir trygghet for at arbeidet holder standardens nivå.

Eksempel

En konsulent med ISO/IEC 27001 Lead Implementer-sertifisering hjelper virksomheten å bygge ISMS-et riktig fra start.

Sist oppdatert: 14. juni 2026

Sikkerhetsloven – Nasjonal sikkerhet

Sikkerhetsloven

#
SikkerhetslovenLov 2018-06-01-24Gjeldende rettLov om nasjonal sikkerhet

Loven som skal trygge nasjonale sikkerhetsinteresser gjennom forebyggende sikkerhetsarbeid.

Sikkerhetsloven (lov 2018-06-01-24) trådte i kraft 1. januar 2019 og gjelder forebyggende sikkerhet for å beskytte Norges nasjonale sikkerhetsinteresser. Den retter seg mot virksomheter som rår over informasjon, systemer, objekter eller infrastruktur av avgjørende betydning for staten.

NSM (Nasjonal sikkerhetsmyndighet) er fagmyndighet. Loven er gjeldende rett og bygger på risiko og forsvarlig sikkerhetsnivå fremfor detaljerte sjekklister.

Eksempel

En virksomhet som drifter et anlegg avgjørende for kraftforsyningen kan bli underlagt sikkerhetsloven.

Sist oppdatert: 14. juni 2026

Virkeområde

#
Sikkerhetsloven§ 1-3Gjeldende rettScope

Hvilke virksomheter loven gjelder for – de som er av betydning for grunnleggende nasjonale funksjoner.

Loven gjelder statlige, fylkeskommunale og kommunale organer, og virksomheter som et departement fatter vedtak om fordi de rår over noe avgjørende for en grunnleggende nasjonal funksjon. Den omfatter altså ikke alle – men de som treffes, får omfattende plikter.

Et departement kan fatte vedtak om at en privat virksomhet skal omfattes.

Eksempel

Et privat selskap som leverer kritiske komponenter til forsvarssektoren kan bli vedtatt omfattet av loven.

Sist oppdatert: 14. juni 2026

Nasjonale sikkerhetsinteresser

#
Sikkerhetsloven§ 1-5Gjeldende rettNational security interests

Landets mest grunnleggende interesser, som suverenitet, territoriell integritet og demokratisk styreform.

Nasjonale sikkerhetsinteresser er definert i loven og omfatter blant annet Norges suverenitet, territorielle integritet, demokratiske styreform og overordnede sikkerhetspolitiske interesser. Det er disse loven til syvende og sist skal beskytte.

Begrepet er styrende for hva som regnes som grunnleggende nasjonale funksjoner og skjermingsverdige verdier.

Eksempel

Evnen til å opprettholde nasjonal krisehåndtering er en del av de nasjonale sikkerhetsinteressene.

Sist oppdatert: 14. juni 2026

Grunnleggende nasjonale funksjoner (GNF)

#
Sikkerhetsloven§ 1-5Gjeldende rettBasic national functions

Tjenester og funksjoner som er så viktige at helt eller delvis bortfall truer nasjonal sikkerhet.

GNF er aktiviteter, tjenester eller produksjon som er av en slik betydning at et helt eller delvis bortfall vil få konsekvenser for statens evne til å ivareta nasjonale sikkerhetsinteresser. Departementene identifiserer GNF innenfor sine sektorer.

GNF er navet i loven: det er koblingen til en GNF som avgjør om en verdi er skjermingsverdig og en virksomhet omfattet.

Eksempel

Strømforsyningen til landet og evnen til nasjonal krisehåndtering er eksempler på grunnleggende nasjonale funksjoner.

Sist oppdatert: 14. juni 2026

Nasjonal sikkerhetsmyndighet (NSM)

#
SikkerhetslovenFagmyndighetGjeldende rettNational security authority

Fagmyndigheten for forebyggende nasjonal sikkerhet etter sikkerhetsloven.

NSM er den sentrale fagmyndigheten: den gir råd og veiledning, fører tilsyn, utvikler regelverk og forvalter ordninger som sikkerhetsklarering. NSM utgir også veiledere og håndbøker til loven.

NSM samarbeider med sektormyndighetene, som har ansvar innenfor sine områder.

Eksempel

En virksomhet som skal etablere sikkerhetsstyring kan bruke NSMs veiledere til sikkerhetsloven som grunnlag.

Sist oppdatert: 14. juni 2026

Departementenes ansvar

#
Sikkerhetsloven§ 2-1Gjeldende rettMinistry responsibility

Hvert departement har ansvar for forebyggende sikkerhet i egen sektor, inkludert å identifisere GNF.

Sikkerhetsloven bygger på sektoransvar: hvert departement skal identifisere de grunnleggende nasjonale funksjonene i sin sektor, og fatte vedtak om hvilke virksomheter som skal omfattes av loven.

Dette gjør at ansvaret er fordelt etter fagområde, med NSM som tverrgående fagmyndighet.

Eksempel

Olje- og energidepartementet identifiserer GNF innen energiforsyning og utpeker virksomheter som omfattes.

Sist oppdatert: 14. juni 2026

Tilsynsmyndighet

#
SikkerhetslovenKap. 3Gjeldende rettSupervisory authority

Myndigheten som fører tilsyn med at virksomhetene følger sikkerhetsloven.

Tilsynet er fordelt mellom NSM og sektortilsyn. Tilsynsmyndigheten kan kreve opplysninger, gjennomføre tilsyn og følge opp at virksomhetene har et forsvarlig sikkerhetsnivå.

Tilsynet er risikobasert og retter oppmerksomheten mot de mest kritiske verdiene.

Eksempel

NSM gjennomfører tilsyn hos en omfattet virksomhet og vurderer om sikkerhetsstyringen er forsvarlig.

Sist oppdatert: 14. juni 2026

Tilsyn

#
SikkerhetslovenKap. 3Gjeldende rettSupervision

Den løpende kontrollen med at omfattede virksomheter etterlever loven.

Tilsyn etter sikkerhetsloven skal påse at virksomhetene oppfyller kravene til forebyggende sikkerhet. Det omfatter både dokumentkontroll og stedlig tilsyn, og kan lede til pålegg om utbedring.

Tilsynet er et viktig virkemiddel for å sikre at sikkerhetsnivået faktisk opprettholdes over tid.

Eksempel

Etter et tilsyn får en virksomhet pålegg om å rette mangler i adgangskontrollen til et skjermingsverdig objekt.

Sist oppdatert: 14. juni 2026

Pålegg og sanksjoner

#
SikkerhetslovenKap. 11Gjeldende rettEnforcement

Reaksjonene myndighetene kan bruke ved brudd på sikkerhetsloven.

Ved manglende etterlevelse kan tilsynsmyndigheten gi pålegg om retting, og det finnes hjemler for tvangsmulkt og straff ved alvorlige brudd. Reaksjonene skal sikre at kravene faktisk oppfylles.

Alvorlige sikkerhetstruende forhold kan også håndteres med mer inngripende tiltak.

Eksempel

En virksomhet som ikke retter alvorlige avvik innen fristen, kan ilegges tvangsmulkt.

Sist oppdatert: 14. juni 2026

Skjermingsverdige verdier

#
SikkerhetslovenKap. 5–7Gjeldende rettProtected values

Informasjon, systemer, objekter og infrastruktur som må beskyttes av hensyn til nasjonal sikkerhet.

Skjermingsverdige verdier er fellesbetegnelsen på det loven beskytter: skjermingsverdig informasjon (kap. 5), informasjonssystemer (kap. 6) og objekter og infrastruktur (kap. 7). En verdi er skjermingsverdig dersom den har betydning for en grunnleggende nasjonal funksjon.

Verdiene klassifiseres ut fra hvor alvorlige konsekvensene av bortfall eller kompromittering vil være.

Eksempel

Et datasystem som styrer en kritisk infrastruktur kan være en skjermingsverdig verdi.

Sist oppdatert: 14. juni 2026

Skjermingsverdig informasjon

#
SikkerhetslovenKap. 5Gjeldende rettClassified information

Informasjon som må beskyttes mot uautorisert innsyn, endring eller bortfall av hensyn til nasjonal sikkerhet.

Informasjon er skjermingsverdig dersom det kan skade nasjonale sikkerhetsinteresser om den blir kjent for uvedkommende, går tapt, endres eller blir utilgjengelig. Slik informasjon skal sikkerhetsgraderes og beskyttes deretter.

Beskyttelsen omfatter hele livsløpet – fra produksjon og lagring til deling og avhending.

Eksempel

Detaljerte planer for sikring av et kritisk anlegg kan utgjøre skjermingsverdig informasjon.

Sist oppdatert: 14. juni 2026

Skjermingsverdig objekt og infrastruktur

#
SikkerhetslovenKap. 7Gjeldende rettProtected objects/infrastructure

Fysiske objekter og infrastruktur som må beskyttes fordi de understøtter en grunnleggende nasjonal funksjon.

Objekter og infrastruktur kan utpekes som skjermingsverdige og klassifiseres etter hvor alvorlig et bortfall ville være for en GNF. Eieren må da iverksette beskyttelsestiltak tilpasset klassifiseringen.

Dette dekker både selve anlegget og det som er nødvendig for at det skal fungere.

Eksempel

En sentral node i kraftnettet kan utpekes som skjermingsverdig infrastruktur og må sikres fysisk og digitalt.

Sist oppdatert: 14. juni 2026

Sikkerhetsgradering

#
Sikkerhetsloven§ 5-3Gjeldende rettSecurity classification

Inndelingen av skjermingsverdig informasjon i graderingsnivåer etter skadepotensial.

Skjermingsverdig informasjon graderes i fire nivåer – BEGRENSET, KONFIDENSIELT, HEMMELIG og STRENGT HEMMELIG – ut fra hvor alvorlig skade uautorisert kjennskap kan forårsake. Graderingen styrer hvordan informasjonen skal håndteres og hvem som kan få tilgang.

Jo høyere gradering, desto strengere krav til klarering, lagring og deling.

Eksempel

Informasjon der kompromittering kan skade nasjonal sikkerhet alvorlig, graderes HEMMELIG.

Sist oppdatert: 14. juni 2026

Forebyggende sikkerhetsarbeid

#
Sikkerhetsloven§ 4-1Gjeldende rettPreventive security

Det systematiske arbeidet med å beskytte skjermingsverdige verdier mot sikkerhetstruende virksomhet.

Kjernen i loven er å forebygge, ikke bare reagere. Virksomheten skal arbeide systematisk og risikobasert for å beskytte sine skjermingsverdige verdier mot blant annet spionasje, sabotasje og terror.

Arbeidet skal være forankret i ledelsen og integrert i virksomhetens styring.

Eksempel

En virksomhet etablerer rutiner for adgangskontroll, klarering og hendelseshåndtering som del av det forebyggende sikkerhetsarbeidet.

Sist oppdatert: 14. juni 2026

Sikkerhetsstyring

#
Sikkerhetsloven§ 4-1Gjeldende rettSecurity management

Et ledelsessystem for å planlegge, gjennomføre og følge opp sikkerhetsarbeidet.

Virksomheter omfattet av loven skal ha et styringssystem for sikkerhet, på linje med et ledelsessystem etter ISO/IEC 27001. Det omfatter risikovurdering, tiltak, roller, dokumentasjon og kontinuerlig forbedring.

Sikkerhetsstyring gjør sikkerheten til en styrt prosess og ikke et sett enkelttiltak.

Eksempel

Virksomheten oppretter et sikkerhetsstyringssystem med årlige risikovurderinger og fast oppfølging i ledelsen.

Sist oppdatert: 14. juni 2026

Forsvarlig sikkerhetsnivå

#
Sikkerhetsloven§ 4-1Gjeldende rettAdequate security level

Kravet om at sikkerhetstiltakene skal stå i forhold til risikoen verdiene utsettes for.

Loven krever ikke maksimal sikkerhet, men et forsvarlig nivå – tilpasset verdienes betydning og det aktuelle trusselbildet. Det er en funksjonell standard som virksomheten må vurdere konkret.

Hva som er forsvarlig endrer seg med trusselbildet, og nivået må derfor vurderes løpende.

Eksempel

En virksomhet øker sikkerhetstiltakene rundt et objekt når trusselvurderingen forverres, for å opprettholde et forsvarlig nivå.

Sist oppdatert: 14. juni 2026

Risikovurdering

#
Sikkerhetsloven§ 4-2Gjeldende rettRisk assessment

Den systematiske vurderingen av trusler, sårbarheter og verdier som styrer sikkerhetstiltakene.

Virksomheten skal jevnlig vurdere risikoen for sine skjermingsverdige verdier – sammenhengen mellom verdi, trussel og sårbarhet. Vurderingen er grunnlaget for hvilke tiltak som er nødvendige for et forsvarlig sikkerhetsnivå.

Risikovurderingen skal oppdateres ved endringer i trusselbilde, verdier eller virksomhet.

Eksempel

En forverret trusselvurdering fra etterretningstjenestene utløser en oppdatert risikovurdering hos virksomheten.

Sist oppdatert: 14. juni 2026

Informasjonssystemsikkerhet

#
SikkerhetslovenKap. 6Gjeldende rettInformation system security

Beskyttelse av skjermingsverdige informasjonssystemer mot kompromittering.

Skjermingsverdige informasjonssystemer skal sikres gjennom hele livsløpet, med tiltak for konfidensialitet, integritet og tilgjengelighet. Kravene henger tett sammen med anerkjente rammeverk for IKT-sikkerhet.

NSMs grunnprinsipper for IKT-sikkerhet brukes ofte som praktisk veiledning her.

Eksempel

Et gradert saksbehandlingssystem sikres med strenge tilgangskontroller, logging og godkjenning før det tas i bruk.

Sist oppdatert: 14. juni 2026

Personellsikkerhet

#
SikkerhetslovenKap. 8Gjeldende rettPersonnel security

Tiltakene som skal sikre at personer med tilgang til skjermingsverdige verdier er til å stole på.

Personellsikkerhet skal redusere risikoen for at personer med tilgang til skjermingsverdige verdier utgjør en sikkerhetsrisiko. Virkemidlene er blant annet sikkerhetsklarering, autorisasjon og sikkerhetssamtaler.

Det handler om å balansere tillit og kontroll, og om å følge opp gjennom hele ansettelsesforholdet.

Eksempel

Før en ansatt får tilgang til gradert informasjon, gjennomføres klarering og autorisasjon.

Sist oppdatert: 14. juni 2026

Sikkerhetsklarering

#
SikkerhetslovenKap. 8Gjeldende rettSecurity clearance

En vurdering av om en person kan gis tilgang til informasjon gradert KONFIDENSIELT eller høyere.

Sikkerhetsklarering er en grundig vurdering av en persons sikkerhetsmessige skikkethet, basert på personkontroll. Den gjelder for tilgang til informasjon gradert KONFIDENSIELT, HEMMELIG eller STRENGT HEMMELIG.

Klarering er ikke det samme som tilgang – den må følges av en konkret autorisasjon.

Eksempel

En ansatt som skal håndtere HEMMELIG-gradert informasjon må først sikkerhetsklareres for nivået.

Sist oppdatert: 14. juni 2026

Autorisasjon

#
SikkerhetslovenKap. 8Gjeldende rettAuthorisation

Den konkrete beslutningen om at en klarert person faktisk gis tilgang til bestemte verdier.

Mens klarering vurderer skikkethet, er autorisasjon den konkrete tildelingen av tilgang ut fra tjenstlig behov. Begge må være på plass – og bare det den enkelte trenger for jobben skal gis (need-to-know).

Autorisasjon kan trekkes tilbake uavhengig av klareringen.

Eksempel

En klarert ansatt autoriseres bare for de graderte dokumentene som er nødvendige for vedkommendes oppgaver.

Sist oppdatert: 14. juni 2026

Klareringsmyndighet

#
SikkerhetslovenKap. 8Gjeldende rettClearance authority

Organet som behandler og avgjør søknader om sikkerhetsklarering.

Klareringsmyndigheten gjennomfører personkontroll og fatter vedtak om klarering. Avgjørelsene skal være forsvarlige og kan påklages. Sentralisering av klareringsmyndighet har styrket likebehandlingen.

Myndigheten balanserer hensynet til nasjonal sikkerhet mot den enkeltes rettssikkerhet.

Eksempel

Klareringsmyndigheten innhenter opplysninger og avgjør om en søker kan klareres for HEMMELIG.

Sist oppdatert: 14. juni 2026

Sikkerhetsgradert anskaffelse

#
SikkerhetslovenKap. 9Gjeldende rettClassified procurement

Anskaffelser der leverandøren får tilgang til skjermingsverdige verdier.

Når en anskaffelse innebærer at en leverandør får tilgang til skjermingsverdig informasjon eller objekter, gjelder særlige krav. Leverandøren må sikkerhetsklareres, og det inngås sikkerhetsavtale som regulerer hvordan verdiene skal beskyttes.

Dette sikrer at sikkerhetsnivået opprettholdes også i leverandørkjeden.

Eksempel

Før en IT-leverandør får drifte et gradert system, må selskapet leverandørklareres og inngå sikkerhetsavtale.

Sist oppdatert: 14. juni 2026

Leverandørklarering

#
SikkerhetslovenKap. 9Gjeldende rettSupplier clearance

Klarering av en virksomhet som leverandør i en sikkerhetsgradert anskaffelse.

På samme måte som personer klareres, må leverandører som skal håndtere skjermingsverdige verdier klareres som virksomhet. Vurderingen ser blant annet på eierforhold, styring og evne til å ivareta sikkerheten.

Leverandørklarering er et virkemiddel mot risiko i forsyningskjeden.

Eksempel

Et selskap som skal levere tjenester til et gradert prosjekt må gjennom leverandørklarering før kontrakt.

Sist oppdatert: 14. juni 2026

Eierskapskontroll

#
SikkerhetslovenKap. 10Gjeldende rettOwnership control

Statlig kontroll med erverv av virksomheter som er omfattet av sikkerhetsloven.

For å hindre at sikkerhetstruende aktører får kontroll over kritiske virksomheter, må visse erverv av eierandeler meldes og kan stanses av myndighetene. Dette er et stadig viktigere virkemiddel i en spent sikkerhetspolitisk tid.

Kontrollen retter seg mot oppkjøp som kan true nasjonale sikkerhetsinteresser.

Eksempel

Et oppkjøp av en virksomhet som drifter kritisk infrastruktur må meldes og kan bli stanset etter eierskapskontrollen.

Sist oppdatert: 14. juni 2026

Sikkerhetstruende økonomisk virksomhet

#
SikkerhetslovenKap. 10Gjeldende rettSecurity-threatening investment

Investeringer eller oppkjøp som kan utgjøre en trussel mot nasjonale sikkerhetsinteresser.

Begrepet dekker økonomisk aktivitet – typisk oppkjøp og investeringer – som kan gi uønskede aktører innflytelse over, tilgang til eller mulighet til å skade skjermingsverdige verdier eller grunnleggende nasjonale funksjoner.

Eierskapskontrollen er hovedverktøyet for å håndtere slik risiko.

Eksempel

Et utenlandsk oppkjøp som ville gitt tilgang til sensitiv teknologi kan vurderes som sikkerhetstruende økonomisk virksomhet.

Sist oppdatert: 14. juni 2026

Ekomloven – Elektronisk kommunikasjon

Ekomloven

#
EkomlovenLov 2024-12-13-76Gjeldende rettLov om elektronisk kommunikasjon

Loven som regulerer elektroniske kommunikasjonsnett og -tjenester i Norge.

Ny ekomlov (lov 2024-12-13-76) trådte i kraft 1. januar 2025 og erstattet ekomloven fra 2003. Den regulerer blant annet mobil- og bredbåndstjenester, kommunikasjonstjenester i apper og sosiale medier, og – for første gang – datasentre.

For de fleste virksomheter er det cookie-reglene i § 3-15 som er mest aktuelle, fordi de gjelder nesten alle som har en nettside.

Eksempel

En norsk nettbutikk må følge ekomlovens cookie-regler selv om den ikke er en teletilbyder.

Sist oppdatert: 14. juni 2026

Virkeområde

#
Ekomloven§ 1-2Gjeldende rettScope

Hva og hvem loven gjelder for – fra teletilbydere til alle som lagrer cookies.

Loven gjelder elektronisk kommunikasjon, nett, tjenester og tilhørende utstyr. Mens de tradisjonelle pliktene retter seg mot tilbydere, gjelder cookie-bestemmelsen i § 3-15 langt bredere – i praksis enhver som lagrer eller leser opplysninger på en brukers utstyr.

Det gjør at ekomloven angår mange flere virksomheter enn man kanskje skulle tro.

Eksempel

Et lite firma med en enkel nettside omfattes av cookie-reglene, selv om resten av ekomloven ikke gjelder dem.

Sist oppdatert: 14. juni 2026

Ekomtilbyder

#
Ekomloven§ 1-5Gjeldende rettProvider

Virksomhet som tilbyr elektroniske kommunikasjonsnett eller -tjenester.

En ekomtilbyder leverer for eksempel mobil-, bredbånds- eller meldingstjenester. Tilbydere har særskilte plikter etter loven, blant annet om sikkerhet, robusthet, taushetsplikt og varsling.

Den nye loven utvider tilbyderbegrepet til også å omfatte enkelte nettbaserte kommunikasjonstjenester.

Eksempel

En leverandør av en meldingstjeneste i en app kan regnes som ekomtilbyder etter den nye loven.

Sist oppdatert: 14. juni 2026

Datasenter

#
EkomlovenNyttGjeldende rettData centre

Datasentre er for første gang regulert i ekomloven.

Den nye ekomloven innfører regulering av datasentre, blant annet med registreringsplikt og krav til sikkerhet. Bakgrunnen er datasentrenes økende betydning for digital infrastruktur og beredskap.

Dette er en av nyhetene som skiller den nye loven fra 2003-loven.

Eksempel

En aktør som drifter et datasenter må forholde seg til de nye kravene i ekomloven.

Sist oppdatert: 14. juni 2026

Informasjonskapsler (cookies)

#
Ekomloven§ 3-15Gjeldende rettCookies

Små datafiler eller annen lagring/tilgang på brukerens utstyr, regulert av ekomloven.

Informasjonskapsler («cookies») og lignende teknologi lagrer eller henter informasjon på brukerens enhet. Ekomloven § 3-15 regulerer all slik lagring og tilgang – ikke bare klassiske cookies, men også for eksempel sporingspiksler og lokal lagring.

Reglene er sentrale fordi de gjelder nesten alle nettsteder.

Eksempel

En sporingspiksel som måler atferd på et nettsted omfattes av cookie-reglene på linje med en vanlig cookie.

Sist oppdatert: 14. juni 2026

Samtykke til cookies

#
Ekomloven§ 3-15Gjeldende rettCookie consent

Krav om gyldig, GDPR-basert samtykke før ikke-nødvendige cookies settes.

Den store endringen i ny ekomlov: lagring og tilgang krever samtykke som oppfyller GDPR. Det betyr at samtykket må være frivillig, spesifikt, informert og uttvetydig – og like lett å trekke tilbake som å gi. Forhåndskryssede bokser og «fortsatt bruk = samtykke» er ikke lenger nok.

Brukeren skal informeres om hvilke opplysninger som behandles, formålet og hvem som er behandlingsansvarlig, før samtykke gis.

Eksempel

En cookie-banner må gi et reelt valg der «avvis alle» er like lett tilgjengelig som «godta alle».

Sist oppdatert: 14. juni 2026

Unntak for nødvendige cookies

#
Ekomloven§ 3-15Gjeldende rettStrictly necessary

Cookies som er strengt nødvendige for tjenesten kan settes uten samtykke.

Det finnes et snevert unntak: cookies som er strengt nødvendige for å levere en tjeneste brukeren uttrykkelig har bedt om, krever ikke samtykke. Det gjelder for eksempel handlekurv-funksjon eller innlogging – men ikke analyse og markedsføring.

Unntaket skal tolkes strengt; «nødvendig for oss» er ikke det samme som «nødvendig for brukeren».

Eksempel

En cookie som husker hva som ligger i handlekurven er nødvendig og krever ikke samtykke; en analyse-cookie gjør det.

Sist oppdatert: 14. juni 2026

Sporing og profilering på nett

#
Ekomloven§ 3-15Gjeldende rettOnline tracking

Bruk av cookies og lignende til å følge brukere på tvers av tjenester.

Mye sporing skjer gjennom tredjeparts cookies og sporingsteknologi, ofte for markedsføring og profilering. Slik sporing krever samtykke etter ekomloven, og når den behandler personopplysninger, også et behandlingsgrunnlag etter GDPR.

Ekomloven og GDPR spiller her tett sammen.

Eksempel

Et annonsenettverk som følger en bruker mellom nettsteder via tredjeparts cookies krever gyldig samtykke.

Sist oppdatert: 14. juni 2026

Kommunikasjonsvern

#
Ekomloven§ 3-10Gjeldende rettConfidentiality of communications

Vernet av innholdet i og opplysninger om elektronisk kommunikasjon.

Ekomloven verner kommunikasjonen mellom brukere: innhold, trafikkdata og lokasjon skal beskyttes mot avlytting og urettmessig tilgang. Dette er en grunnpilar for tillit til elektroniske tjenester.

Vernet henger sammen med tilbydernes taushetsplikt.

Eksempel

En tilbyder kan ikke lese eller utlevere innholdet i kundenes kommunikasjon uten gyldig hjemmel.

Sist oppdatert: 14. juni 2026

Taushetsplikt

#
Ekomloven§ 3-10Gjeldende rettDuty of confidentiality

Tilbyderes plikt til å bevare taushet om kommunikasjon og bruk av tjenestene.

Tilbydere og deres ansatte har taushetsplikt om innholdet i kommunikasjonen og om hvem som kommuniserer med hvem. Plikten beskytter brukernes privatliv og er en forutsetning for kommunikasjonsvernet.

Brudd kan få både tilsynsmessige og strafferettslige følger.

Eksempel

En ansatt hos en teletilbyder kan ikke fortelle utenforstående hvem en kunde har ringt.

Sist oppdatert: 14. juni 2026

Ekomsikkerhet og robusthet

#
EkomlovenKap. 2Gjeldende rettNetwork security & resilience

Krav til at kommunikasjonsnett og -tjenester er sikre og robuste.

Tilbydere må sikre nett og tjenester mot hendelser og opprettholde tilgjengelighet, også i krise. Loven stiller krav til risikohåndtering, beredskap og varsling av sikkerhetshendelser – viktig for samfunnets digitale grunnmur.

Dette overlapper med kravene i digitalsikkerhetsloven for kritisk infrastruktur.

Eksempel

En bredbåndstilbyder må ha beredskap som sikrer at nettet fungerer også ved strømbrudd og uvær.

Sist oppdatert: 14. juni 2026

Sluttbrukervern

#
EkomlovenKap. 4Gjeldende rettEnd-user rights

Rettighetene som beskytter forbrukere og andre sluttbrukere av ekomtjenester.

Loven gir sluttbrukere rettigheter knyttet til avtaler, åpenhet om priser og vilkår, nummerportabilitet og leverandørbytte. Formålet er en velfungerende og rettferdig konkurranse til brukernes beste.

Sluttbrukervern er en stor del av ekomreguleringen, ved siden av sikkerhet og personvern.

Eksempel

En kunde skal lett kunne bytte mobilleverandør og beholde telefonnummeret sitt.

Sist oppdatert: 14. juni 2026

Nasjonal kommunikasjonsmyndighet (Nkom)

#
EkomlovenTilsynGjeldende rettNational Communications Authority

Tilsynsmyndigheten for elektronisk kommunikasjon i Norge.

Nkom fører tilsyn med ekomtilbydere, forvalter frekvenser og nummer, og følger opp krav til sikkerhet, robusthet og sluttbrukervern. For cookie-reglene deler Nkom tilsynsansvaret med Datatilsynet.

Nkom er også utpekt som koordinerende tilsynsmyndighet for KI-forordningen.

Eksempel

En tilbyder som ikke oppfyller sikkerhetskravene i ekomloven kan møte tilsyn og pålegg fra Nkom.

Sist oppdatert: 14. juni 2026

Datatilsynet og Nkom (cookie-tilsyn)

#
Ekomloven§ 3-15Gjeldende rettJoint supervision

Det delte tilsynsansvaret for cookie-reglene.

Cookie-bestemmelsen håndheves i fellesskap: Datatilsynet har ansvar for samtykkekravet (som bygger på GDPR), mens Nkom har ansvar for de øvrige sidene av § 3-15. Virksomheter må derfor forholde seg til begge.

Det delte ansvaret gjenspeiler at cookie-regelen ligger i skjæringspunktet mellom personvern og ekom.

Eksempel

Ved en klage på en nettsides cookie-banner kan både Datatilsynet og Nkom være involvert.

Sist oppdatert: 14. juni 2026

Sanksjoner

#
EkomlovenKap. 15Gjeldende rettSanctions

Reaksjonene tilsynsmyndighetene kan bruke ved brudd på ekomloven.

Ved brudd kan tilsynsmyndighetene gi pålegg om retting og ilegge overtredelsesgebyr og tvangsmulkt. For cookie-brudd kan også personvernregelverkets reaksjoner komme til anvendelse via samtykkekravet.

Nivået skal være tilstrekkelig til at det virker avskrekkende.

Eksempel

En virksomhet som fortsetter å sette cookies uten gyldig samtykke etter pålegg, kan ilegges gebyr.

Sist oppdatert: 14. juni 2026

Ingen begreper matcher søket.

Trenger dere hjelp med regelverkene i praksis?

Det er forskjell på å kjenne begrepene og å vite hvordan de slår ut hos dere. SPADE Consulting hjelper norske virksomheter med pragmatisk personvern, sikkerhet og KI-styring.