Rammeverk & status
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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