DORA er gjennomført i norsk rett gjennom DORA-loven og DORA-forskriften, som trådte i kraft 1. juli 2025. For et norsk foretak er det den norske gjennomføringen, med EØS-tilpasninger og utfyllende regler, som må brukes. EU-forordningens anvendelsesdato 17. januar 2025 er ikke i seg selv norsk ikrafttredelse. Finanstilsynet beskriver dette i sin oversikt over DORA.
Fra 1. september 2026 gjelder dessuten tilpassede DORA-regler for finansieringsforetak, eiendomsmeglingsforetak, inkassoforetak og Norsk naturskadepool. Det gjør eldre norske oversikter utilstrekkelige. Før dere velger kravliste eller rapporteringsskjema, må dere avklare om foretaket omfattes av forordningens ordinære virkeområde eller av den særskilte norske reguleringen. Denne guiden forklarer hvordan avklaringen brukes i arbeidet.
Status: DORA er i kraft i Norge
DORA-forordningen, forordning (EU) 2022/2554, er innlemmet i EØS-avtalen og gjennomført gjennom norsk lov. Finanstilsynet bekreftet ikrafttredelsen i meldingen 28. mai 2025. Det er derfor feil å omtale DORA som et fremtidig forberedelsesprosjekt for foretak som allerede omfattes. De må vurdere sin etterlevelse av gjeldende regler.
Forordningen suppleres av tekniske regler. Norsk gjennomføring av disse må også kontrolleres. Finanstilsynet opplyser at fire ytterligere nivå 2-regelverk ble tatt inn i DORA-forskriften med virkning fra 26. januar 2026, blant annet om underleveranser og trusselbasert penetrasjonstesting. Se meldingen om nivå 2-regelverk. En kravliste frosset ved oppstarten i juli 2025 kan derfor mangle relevant innhold.
Hold en enkel oversikt over hvilket regelverk vurderingen bygger på, hvilken versjon som er brukt og hvem som følger endringer. Skillet mellom forordning, forskrift og tilsynsveiledning er praktisk: de har forskjellig funksjon, selv når de beskriver samme arbeidsprosess. Når en intern instruks endres, bør det fremgå om årsaken er et nytt bindende krav eller en forbedret praktisk løsning.
Hvilke foretak omfattes?
Forordningens artikkel 2 omfatter en rekke finansielle foretak, blant annet kredittinstitusjoner, betalingsforetak, e-pengeforetak, verdipapirforetak, enkelte forvaltere, forsikringsforetak og tjenesteytere på kryptoeiendelsområdet. Listen har presise definisjoner og unntak. Det er ikke tilstrekkelig å si at «hele finanssektoren» eller «alle foretak under Finanstilsynet» omfattes på samme måte.
Revisorer og regnskapsførere blir ikke finansielle enheter etter DORA bare fordi de er underlagt tilsyn eller bruker digitale systemer. IKT-leverandører har dessuten en annen rolle enn kundene som er finansielle foretak. En leverandør kan få kontraktskrav fra en bank uten dermed å være underlagt samtlige plikter som gjelder banken. Kritiske IKT-tredjepartsleverandører har en særskilt europeisk overvåkningsordning.
Avklar foretakets konsesjon, aktivitet, størrelse og eventuelle unntak før vurderingen avsluttes. Registrer også hvilke selskaper i et konsern konklusjonen gjelder. Et felles konsernprogram kan støtte gjennomføringen, men det enkelte foretakets ansvar forsvinner ikke fordi innkjøp eller drift er sentralisert. Filialer og grenseoverskridende virksomhet kan kreve nærmere avklaring av ansvar og tilsyn.
Norske utvidelser fra september 2026
Finanstilsynets melding om de nye reglene forklarer at IKT-forskriften oppheves fra 1. september 2026. De nevnte norske foretakstypene følger regler i DORA med tilpasninger i DORA-forskriften kapittel 2. For eiendomsmeglingsforetak er blant annet bestemte melde- og rapporteringskrav knyttet til oppgjørsfunksjonen. Dette må ikke omtales som identisk med full anvendelse av alle DORA-bestemmelser.
Den samme meldingen beskriver særskilt rapporteringskanal for disse foretakene, som inntil videre ikke kan bruke KRT-3190. Kontroller den oppdaterte veiledningen og sikker innsending før rapportering. Et skjema som er riktig for en bank, er derfor ikke nødvendigvis riktig for et eiendomsmeglingsforetak. Ikke bruk eldre spørsmål-og-svar som fortsatt beskriver en planlagt utvidelse, når nyere regler har trådt i kraft.
For et foretak som nylig er omfattet, er første praktiske oppgave å oversette den nasjonale avgrensningen til egne funksjoner. Hvilke tjenester inngår i oppgjøret, hvilke avtaler støtter dem, og hvem kan vurdere konsekvensene av et bortfall? En generell leverandørliste bør suppleres med denne forbindelsen. Ellers blir det vanskelig å avgjøre hvilke konkrete hendelser og avtaler som skal følges opp.
Hva krever DORA?
Hovedområdene er styring av IKT-risiko, håndtering og rapportering av hendelser, testing av digital motstandsdyktighet og styring av risiko ved IKT-tredjeparter. DORA gir også rammer for frivillig deling av informasjon om cybertrusler. Informasjonsdeling skal derfor ikke presenteres som en generell obligatorisk «femte søyle» alle foretak må delta i for å være etterlevende.
Begynn med tjenestene foretaket må kunne levere. Beskriv hvilke IKT-systemer, data, tilganger og leverandører tjenestene er avhengige av. Kartlegging av IT-systemer kan gi en struktur, men foretaket må også identifisere funksjonenes betydning og avhengigheter. En oversikt som bare inneholder programvarenavn viser ikke konsekvensen av en svikt i betalingsbehandling eller oppgjør.
Ledelsen trenger et beslutningsgrunnlag som skiller bekreftede svakheter, planlagte tiltak og gjenværende risiko. En godkjent policy er ikke tilstrekkelig hvis ingen kan vise hvordan den brukes. Knytt tiltak til eiere, nødvendige ressurser og kontroll av effekten. Informasjonssikkerhetspolicyen kan angi rammene, mens oppfølgingen må vise hva foretaket faktisk har gjennomført.
Forholdsmessighet: ikke alle krav gjelder likt
DORA bygger på forholdsmessighet, og artikkel 16 har et forenklet rammeverk for bestemte foretakstyper. Dette betyr ikke at enhver liten virksomhet fritt kan velge et forenklet regime. Vilkårene må være oppfylt. Skill også et unntak fra virkeområdet fra en tilpasning av hvordan en plikt oppfylles; de gir forskjellige konklusjoner.
Når foretaket bruker forholdsmessighet, bør begrunnelsen beskrive størrelse, risikoprofil, kompleksitet og tjenestenes betydning. «Vi er små» sier lite hvis virksomheten er helt avhengig av én løsning og mangler en fungerende reserve. En enklere organisasjon kan ha kortere beslutningslinjer, men fortsatt store konsekvenser ved utilgjengelige data eller feil i oppgjøret.
En praktisk kontroll er å lese risikovurderingen sammen med den som eier tjenesten. Kan tjenesten leveres manuelt, hvor lenge, og med hvilke feilrisikoer? Hvilke data må være tilgjengelige først ved gjenoppretting? Slike svar gjør det mulig å begrunne tiltakene. Standardformuleringer om «lav kompleksitet» bør ikke erstatte vurderingen av foretakets faktiske avhengigheter.
Registeret over informasjon: kjernen i DORA
Foretak som omfattes av det ordinære regimet skal vedlikeholde et register over informasjon om avtaleforhold for bruk av IKT-tjenester fra tredjeparter. Registeret skal skille tjenestene som støtter kritiske eller viktige funksjoner fra andre. Det er bredere enn en liste over tradisjonell utkontraktering og forskjellig fra en liste over databehandlere etter GDPR.
Start med avtaler, tjenester og funksjoner, og bruk stabile identifikatorer slik at opplysningene kan kobles. Én leverandør kan levere flere tjenester gjennom ulike avtaler. Én tjeneste kan støtte flere funksjoner. Hvis dette presses inn i én fritekstcelle, blir det vanskelig å vedlikeholde opplysningene og forstå hvilke leveranser som påvirkes når en avtale endres.
Sammenhold registeret med innkjøpsoversikten, systemoversikten og de faktiske kontraktene. En faktura kan avdekke en tjeneste som ingen har registrert, men forklarer ikke alene hvilken funksjon den støtter. Oppgi hvem som kan bekrefte tjenestens bruk og betydning. For foretak under den norske tilpasningen må egne registerkrav kontrolleres mot kapittel 2, fremfor å anta identisk skjemaomfang.
Et hypotetisk betalingsforetak oppdager at en intern analyseavtale også brukes til svindelovervåking. Tjenesten kan dermed ha større betydning enn innkjøpskategorien tilsier. Foretaket undersøker hvilke prosesser som stanser ved bortfall, oppdaterer funksjonskoblingen og vurderer kontrakts- og beredskapskrav på nytt. Det er endringen i faktisk bruk, ikke bare kontraktens navn, som utløser gjennomgangen.
Kontraktskrav til leverandøravtaler
DORA artikkel 30 skiller mellom generelle krav til IKT-avtaler og tilleggskrav når tjenesten støtter kritiske eller viktige funksjoner. Kontraktsgjennomgangen må følge denne strukturen. Se blant annet på tjenestebeskrivelse, steder for levering og behandling, tilgang til data, bistand ved hendelser og opphør. De mer omfattende rettighetene må vurderes mot den aktuelle funksjonen og kontrakten.
En databehandleravtale etter artikkel 28 GDPR dekker personopplysninger som behandles på foretakets vegne. Den erstatter ikke DORAs vurdering av driftsavhengighet, konsentrasjonsrisiko og kontinuitet. Omvendt er en DORA-klausul om IKT-tjenester ikke automatisk en komplett databehandleravtale. Samordne vedlegg der det passer, men kontroller de to kravsettene hver for seg.
Finanstilsynets veiledning om melding av IKT-tjenesteavtaler forklarer at planlagte avtaler som støtter kritiske eller viktige funksjoner skal meldes i god tid. Tilsynet legger til grunn minst 30 dager før avtalen eller endringen trer i kraft. Dette er tilsynets konkretisering av «god tid», ikke en ordrett 30-dagersregel i forordningen.
Legg vurderingen før signering og oppstart, slik at eventuelle mangler kan håndteres. En mottaksbekreftelse på meldingen er ikke en generell godkjenning av leverandøren. Avtal også hvem som følger endringer i underleverandører og funksjonenes betydning. En kontrakt som var egnet ved kjøpet kan trenge ny vurdering når tjenesten får andre oppgaver eller leveringsmodellen endres.
Håndtering og rapportering av IKT-hendelser
Alvorlige IKT-relaterte hendelser skal klassifiseres etter DORA og det utfyllende regelverket. Ikke bruk GDPRs terskel for personrisiko som erstatning. En hendelse kan være alvorlig for finansielle tjenester uten at personopplysninger er utlevert. Omvendt kan et personopplysningsbrudd kreve GDPR-melding uten å nå DORAs terskler. Foretaket trenger begge vurderingene når begge regelverk er aktuelle.
Finanstilsynets hendelsesveiledning beskriver for det ordinære regimet innledende varsel så snart som mulig, innen fire timer etter klassifisering som alvorlig og normalt senest 24 timer etter oppdagelse. Første statusrapport skal sendes senest 72 timer etter det innledende varselet, også uten statusendring. Endelig rapport skal normalt sendes innen én måned etter siste statusrapport. Dersom hendelsen først klassifiseres som alvorlig etter 24 timer, gjelder fire timer fra klassifiseringen etter artikkel 5 nr. 2 i forordning 2025/301. Kontroller også særreglene om frister i helger og helligdager; de gjelder ikke alle foretakstyper.
Finanstilsynet presiserte rapporteringen i 2026, blant annet at tiltak ikke trenger å være sluttført før endelig rapport sendes når rotårsaken er identifisert og faktiske påvirkningstall foreligger. Ikke vent på at alle forbedringsprosjekter er ferdige. Dokumenter hva som gjenstår, ansvarlig og forventet sluttføring.
Registrer tidspunktene for hendelse, oppdagelse, klassifisering og rapportering hver for seg. Det gjør fristberegningen etterprøvbar og hindrer at én dato brukes til flere forskjellige formål. Kontroller også hvilken kanal som gjelder foretakstypen, særlig for de norske tilleggskategoriene fra september 2026. En felles intern avvikslogg kan støtte arbeidet, men må ha nødvendige DORA-felter og separate beslutninger.
Testing av digital motstandsdyktighet
Testing skal gi kunnskap om hvorvidt foretakets beskyttelse og gjenoppretting fungerer. En skannet sårbarhetsrapport er ikke det samme som en prøve på om en kritisk tjeneste kan gjenopprettes. Lag en plan som kobler testene til risiko, systemer og funksjoner. Funn trenger prioritering, retting og kontroll av at rettingen faktisk har virket.
Trusselbasert penetrasjonstesting, TLPT, gjelder utpekte foretak etter relevante kriterier. Det er for upresist å si at kravet bare gjelder «de største» eller at alle finansforetak skal gjennomføre TLPT. Avklar om foretaket er omfattet av denne særskilte plikten og hvilke krav som gjelder til omfang, testere og myndighetsoppfølging. En vanlig penetrasjonstest er ikke automatisk en TLPT.
Ved en gjenopprettingsøvelse bør foretaket kunne vise hvilke data som ble brukt, hvor lang tid gjenoppretting tok og hvilke deler av tjenesten som faktisk virket etterpå. Koble funnene til RTO og RPO. Hvis øvelsen bare gjenopprettet en testdatabase uten integrasjonene som tjenesten trenger, må denne begrensningen fremgå av resultatet.
Exit, leverandørkonsentrasjon og reell gjennomførbarhet
En exit-strategi er mer enn en oppsigelsesrett. Foretaket må forstå hva som skal flyttes, hvilke lisenser og kompetanser som kreves, og hvordan nødvendig drift kan opprettholdes under overgangen. Kartlegg også om en alternativ leverandør i realiteten bruker samme underliggende infrastruktur. To kontrakter kan gi mindre uavhengighet enn de ser ut til å gi.
Et praktisk eksempel er en tjeneste der kunden får et datauttrekk, men ikke definisjoner av felter eller nødvendig historikk. Kontrakten kan da gi tilbakelevering uten at materialet er anvendelig hos en ny leverandør. Undersøk eksporten før en krise. Tilbakelevering og slettebekreftelse hjelper med personopplysninger, mens DORA-vurderingen også omfatter fortsatt tjenesteleveranse.
Prioriter de avhengighetene som har størst konsekvens og svakest alternativer. En leverandør som er vanskelig å bytte kan kreve tettere oppfølging, bedre beredskap eller endret arkitektur. Det er ikke nødvendigvis realistisk å etablere full dublering av alt. Begrunn valgene og sørg for at ledelsen forstår hvilke deler av risikoen de planlagte tiltakene faktisk reduserer.
Overlappet med GDPR og NIS2
Ved personopplysningsbrudd må foretaket gjøre en separat vurdering etter GDPR artikkel 33 og 34. Rapportering til Finanstilsynet erstatter ikke automatisk melding til Datatilsynet eller informasjon til personer. En felles undersøkelse kan levere fakta til begge spor, mens terskler, frister og mottakere må holdes tydelige.
NIS2s norske status må kontrolleres separat. På EU-nivå er DORA et sektorspesifikt regelverk i forhold til NIS2 for de relevante finansielle enhetene. Unngå derfor å legge alle NIS2-krav oppå DORA uten vurdering. Kartlegg også øvrige aktiviteter i konsernet som kan ha andre regler enn det finansielle foretaket.
Hva bør norske finansforetak gjøre nå?
Prioriter mangler som påvirker kritiske tjenester og lovpålagte rapporteringsprosesser. Avklar virkeområde, ansvar og endringene i norske regler. Kontroller så funksjonsoversikt, IKT-register, hendelsesrutiner, leverandøravtaler og testing mot det regimet som faktisk gjelder. Et nytt register alene løser ikke manglende gjenoppretting eller uklare beslutningslinjer.
Ved valg av DORA-programvare bør foretaket prøve egne avtaler og funksjoner i løsningen. Undersøk om registerets koblinger, rapporteringsformat og dokumentasjonsbehov støttes. Verktøyet kan organisere arbeidet, men foretaket må fortsatt vurdere risiko, klassifisering og rettslig grunnlag. Ikke legg til grunn en funksjon, sertifisering eller norsk tilpasning uten dokumentasjon fra leverandøren.
Ofte stilte spørsmål
Er DORA gjeldende i Norge?
Ja, gjennom norsk gjennomføring fra 1. juli 2025. Tilpassede regler for ytterligere norske foretakstyper gjelder fra 1. september 2026. Hvilke bestemmelser som gjelder må avklares for det konkrete foretaket.
Hvem fører tilsyn med DORA i Norge?
Finanstilsynet fører tilsyn med de norske foretakene innenfor sitt myndighetsområde. Den europeiske ordningen for kritiske IKT-tredjepartsleverandører har egne roller og prosesser. Foretakets eget ansvar for leverandørrisiko består selv om leverandøren omfattes av slik overvåkning.
Må leverandøravtalene reforhandles på grunn av DORA?
Avtaler må vurderes mot de kravene som gjelder tjenesten og funksjonen. Der innhold mangler, må det håndteres gjennom avtalemessige endringer eller annen forsvarlig løsning. En standard databehandleravtale er ikke alene dokumentasjon på DORA-etterlevelse.
Konklusjon
DORA-arbeidet i Norge må starte med riktig norsk virkeområde og oppdatert regelverk. Koble deretter kritiske funksjoner til systemer, kontrakter, hendelser og testresultater. Dokumentasjonen blir nyttig når den viser både hva foretaket har besluttet og om de nødvendige tjenestene faktisk kan beskyttes, opprettholdes og gjenopprettes.
Sist faglig gjennomgått: 27. september 2026. Praktiske eksempler er hypotetiske. Rapporteringskanaler og norsk nivå 2-regelverk må kontrolleres ved endringer.