DORA (Digital Operational Resilience Act) stiller felles europeiske krav til at finansforetak skal tåle, håndtere og komme seg etter IKT-hendelser. Ordlisten forklarer begrepene, viser til riktig artikkel i forordningen og til norsk regelverk og veiledning, og merker hvert begrep med status.

📌 Status i norsk rett DORA: i kraft

DORA gjelder i Norge. Forordningen trådte i kraft i EU 17. januar 2025, ble innlemmet i EØS-avtalen kort etter, og er gjennomført i norsk rett gjennom DORA-loven (lov 2025-05-27-18) og DORA-forskriften – begge i kraft 1. juli 2025.

Finanstilsynet har deretter tatt inn utfyllende nivå 2-regelverk (tekniske reguleringsstandarder) i forskriften, senest i januar 2026. Til forskjell fra NIS2 og AI Act er DORA altså fullt gjeldende rett for omfattede foretak.

Begrepene er derfor merket «Gjeldende rett». Vi viser til selve forordningen (EUR-Lex) for det materielle innholdet, og til DORA-loven/-forskriften og Finanstilsynet for den norske gjennomføringen og veiledningen.

🧭 Usikker på om dere omfattes? Ta den gratis DORA-selvtesten – noen spørsmål, foreløpig svar med en gang.

Rammeverk & status

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-risikostyring

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

Hendelser & rapportering

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

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

Tredjepartsrisiko

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

Tilsyn & sanksjoner

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

Ingen begreper matcher søket.

Etterlever foretaket DORA i praksis?

DORA er gjeldende rett for finansforetak. SPADE Consulting hjelper dere å kartlegge gap mot kravene, få på plass IKT-risikostyring, hendelsesrapportering, testing og leverandøravtaler – og dokumentasjon som tåler tilsyn.