DORA — krav til IT-leverandører i finanssektoren

DORA (Digital Operational Resilience Act) er EUs forordning for digital operasjonell motstandskraft i finanssektoren. Den har vært gjeldende i Norge siden 1. juli 2025 og stiller strenge krav til banker, forsikringsselskaper, verdipapirforetak, betalingstjenester — og deres IKT-leverandører. Hvis du leverer programvare, skytjenester eller IT-drift til finanssektoren, er du direkte berørt.

DORA representerer et paradigmeskifte i hvordan EU og EØS regulerer IKT-risiko i finansnæringen. Tidligere var kravene fragmentert på tvers av ulike sektordirektiver og nasjonale retningslinjer. Nå får hele finanssektoren — og leverandørkjeden rundt den — ett felles, detaljert regelverk for digital motstandskraft. For IT-leverandører betyr dette at kontraktsvilkår, sikkerhetsprosesser og rapporteringsrutiner må oppfylle spesifikke regulatoriske krav, ikke bare kundenes interne standarder.

I denne artikkelen gir vi en grundig gjennomgang av hva DORA innebærer, hvem som rammes, og konkrete tiltak IT-leverandører bør iverksette nå.

Hva er DORA?

DORA — Digital Operational Resilience Act — er en EU-forordning (2022/2554) som ble vedtatt i desember 2022 og trådte i kraft i EU 17. januar 2025. Formålet er å sikre at finanssektoren kan motstå, reagere på og gjenopprette seg etter IKT-relaterte forstyrrelser og trusler. Forordningen er innlemmet i EØS-avtalen og har vært gjeldende norsk rett siden 1. juli 2025.

I motsetning til mange andre EU-regelverk er DORA en forordning, ikke et direktiv. Det betyr at den gjelder direkte i norsk rett uten behov for nasjonal tilpasningslovgivning — kravene er de samme i hele EØS-området. Dette sikrer et harmonisert regelverk der finansinstitusjoner og deres leverandører møter identiske krav uavhengig av hvilket land de opererer i.

DORA bygger på fem pilarer: IKT-risikostyring, hendelsesrapportering, digital resilience-testing, tredjepartsrisikostyring og informasjonsdeling. Sammen utgjør disse et helhetlig rammeverk for digital operasjonell motstandskraft.

Bakgrunn: Hvorfor DORA?

Finanssektoren er blant de mest digitaliserte næringene i Europa. Banker, forsikringsselskaper og verdipapirforetak er avhengige av komplekse IKT-systemer for alt fra betalingsformidling og verdipapirhandel til kundeservice og risikostyring. Denne avhengigheten skaper en betydelig sårbarhet.

De siste årene har flere alvorlige hendelser vist konsekvensene av utilstrekkelig digital motstandskraft i finanssektoren: tjenestenektangrep mot banker, ransomware-angrep på forsikringsselskaper, og nedetid hos sentrale betalingsleverandører som har lammet hele verdikjeder. Et avbrudd hos én kritisk IT-leverandør kan raskt få systemiske konsekvenser — ikke bare for den enkelte finansinstitusjonen, men for hele det finansielle systemet.

Før DORA var IKT-risikokravene i finanssektoren spredt over ulike regelverk som CRD IV, Solvens II, PSD2 og nasjonale IKT-forskrifter. Dette førte til ulik praksis, overlappende krav og hull i reguleringen — særlig når det gjaldt krav til tredjepartsleverandører.

DORA adresserer dette ved å etablere ett felles, tverrsektorielt rammeverk som dekker hele verdikjeden — fra finansinstitusjonen selv til den minste programvareleverandøren i kjeden.

Tidslinje: Fra EU-vedtak til norsk rapporteringsfrist

• Desember 2022: EU vedtar DORA-forordningen (2022/2554)
• Januar 2024: DORA trer formelt i kraft i EU (24 måneders implementeringsperiode starter)
• 17. januar 2025: DORA blir gjeldende lov i EU-landene
• 1. juli 2025: DORA trer i kraft i Norge gjennom EØS-innlemmelse
• 13. mars 2026: Første frist for Register of Information (RoI) — rapportering til Finanstilsynet
• 2026–2027: Finanstilsynet gjennomfører de første tilsynsaktivitetene under DORA
• Løpende: Kontinuerlig compliance og oppdatering av IKT-risikostyringsrammeverk

Hvem rammes av DORA?

DORA har et bredt virkeområde som favner langt utover tradisjonelle banker. Forordningen rammer over 20 kategorier av finansielle foretak — og, like viktig, deres IKT-tredjepartsleverandører.

Finansielle foretak

Kategori	Eksempler
Kredittinstitusjoner	Banker, sparebanker, kredittforetak
Forsikringsforetak	Livsforsikring, skadeforsikring, gjenforsikring
Verdipapirforetak	Meglerhus, forvaltningsselskaper
Betalingsforetak	Betalingstjenester, e-pengeforetak
Fondforvaltere	UCITS-forvaltere, AIF-forvaltere
Handelsplasser	Børser, multilaterale handelsfasiliteter
Verdipapirregistre	Verdipapirsentraler
Pensjonskasser	Tjenestepensjonsforetak
Kryptoaktiva-tilbydere	Børser, depottjenester for kryptovaluta
Crowdfunding-plattformer	Folkefinansieringstjenesteytere

IKT-tredjepartsleverandører

Like viktig som finansforetakene selv er IKT-tredjepartsleverandørene som betjener dem. DORA definerer en IKT-tredjepartsleverandør som ethvert foretak som leverer digitale tjenester og datamaskintjenester — inkludert, men ikke begrenset til:

• Skyleverandører (IaaS, PaaS, SaaS)
• Programvareleverandører (kjernebanksystemer, betalingsplattformer, CRM, risikomodeller)
• IT-driftsleverandører (managed services, hosting, overvåking)
• Dataanalyse- og rapporteringstjenester
• Cybersikkerhetstjenester (SOC, penetrasjonstesting, sikkerhetsrådgivning)
• Nettverks- og kommunikasjonstjenester

Hvis din virksomhet leverer noen av disse tjenestene til aktører i finanssektoren, er du underlagt DORAs tredjepartskrav — uavhengig av din egen størrelse eller sektor.

De fem pilarene i DORA

DORA er strukturert rundt fem kjerneområder som til sammen utgjør et helhetlig rammeverk for digital operasjonell motstandskraft.

1. IKT-risikostyring

Den første og mest grunnleggende pilaren krever at finansielle foretak etablerer et robust rammeverk for IKT-risikostyring. Dette innebærer:

• IKT-risikostyringsrammeverk: Et dokumentert, helhetlig rammeverk som identifiserer, klassifiserer og håndterer IKT-risikoer. Rammeverket skal gjennomgås og oppdateres minst årlig.
• Identifisering og kartlegging: Alle IKT-eiendeler, systemer, prosesser og avhengigheter — inkludert tredjepartsleverandører — skal kartlegges og klassifiseres etter kritikalitet.
• Beskyttelse og forebygging: Tekniske og organisatoriske tiltak for å beskytte IKT-systemer, inkludert tilgangskontroll, kryptering, nettverkssikkerhet og sikkerhetsbevisstgjøring.
• Deteksjon: Mekanismer for å oppdage avvikende aktiviteter, trusler og sårbarheter i IKT-systemer.
• Respons og gjenoppretting: Dokumenterte planer for hendelseshåndtering, krisekommunikasjon og gjenoppretting av IKT-tjenester etter forstyrrelser.
• Læring og forbedring: Systematisk gjennomgang av hendelser og tester for å forbedre rammeverket over tid.

Ledelsen har et uttrykkelig ansvar for å godkjenne og overvåke IKT-risikostyringsrammeverket. DORA krever at styret og øverste ledelse tar aktivt eierskap til digital operasjonell motstandskraft.

2. Hendelsesrapportering

DORA innfører et standardisert regime for rapportering av IKT-relaterte hendelser:

• Klassifisering: Alle IKT-hendelser skal klassifiseres etter kriterier som varighet, geografisk spredning, antall berørte kunder, datatap og påvirkning på kritiske tjenester.
• Vesentlige hendelser: Hendelser som oppfyller terskelkriteriene (f.eks. påvirker kritiske tjenester, berører et stort antall kunder eller har økonomisk konsekvens over en viss terskel) skal rapporteres til Finanstilsynet.
• Rapporteringsfrister: Innledende varsling innen fire timer etter klassifisering, mellomrapport innen 72 timer og sluttrapport innen én måned.
• Frivillig varsling: Finansielle foretak kan også frivillig rapportere vesentlige cybertrusler de identifiserer, selv om de ikke har resultert i en hendelse.

For IT-leverandører betyr dette at kontraktene med finanskunder må inneholde klare vilkår om varsling ved hendelser — inkludert tidsfrister og rapporteringsformat som gjør det mulig for kunden å oppfylle sine plikter overfor Finanstilsynet.

3. Digital resilience-testing

DORA krever at finansielle foretak gjennomfører regelmessig testing av sin digitale motstandskraft:

• Grunnleggende testing: Alle foretak skal gjennomføre årlig testing inkludert sårbarhetsvurderinger, nettverkssikkerhetstest, gap-analyser, fysisk sikkerhetstesting, kildekodegjennomgang og scenariobaserte tester.
• Avansert testing (TLPT): Foretak som er identifisert av Finanstilsynet — typisk de største og mest systemviktige — skal gjennomføre trusselbasert penetrasjonstesting (Threat-Led Penetration Testing) minst hvert tredje år. TLPT skal gjennomføres i produksjonsmiljøet av kvalifiserte, uavhengige testere og simulere realistiske angrepsscenarioer basert på oppdatert trusseletterretning.
• Testing av tredjeparter: Foretak som bruker IKT-tredjepartsleverandører for kritiske eller viktige funksjoner, skal inkludere disse leverandørene i testprogrammet — enten gjennom felles testing eller ved å kreve dokumentasjon på leverandørens egen testing.

TLPT er en av de mest krevende bestemmelsene i DORA. For IT-leverandører som betjener systemviktige finansinstitusjoner, betyr dette at deres systemer og infrastruktur kan bli direkte gjenstand for penetrasjonstesting — og at de må legge til rette for dette i sine avtaler og prosesser.

4. Tredjepartsrisikostyring

Tredjepartsrisikostyring er kanskje den pilaren som har størst direkte konsekvens for IT-leverandører. DORA stiller detaljerte krav til hvordan finansielle foretak skal håndtere risikoen knyttet til sine IKT-leverandører:

• Forhåndsvurdering: Før et finansielt foretak inngår avtale med en IKT-leverandør, skal det gjennomføre en grundig risikovurdering — inkludert vurdering av leverandørens sikkerhetsnivå, konsentrasjonrisiko og exit-muligheter.
• Kontraktskrav: DORA stiller minimumskrav til innholdet i IKT-leverandøravtaler, inkludert SLA-er, revisjonsrettigheter, hendelsesrapportering, exit-klausuler, datahåndtering og underleverandørkontroll.
• Løpende overvåking: Finansielle foretak skal kontinuerlig overvåke IKT-tredjepartsrisikoen, inkludert jevnlige revisjoner og risikovurderinger.
• Register of Information (RoI): Alle finansielle foretak skal opprettholde et oppdatert register over alle IKT-tredjepartsavtaler, som skal rapporteres til Finanstilsynet.
• Konsentrasjonsrisiko: Finansielle foretak skal vurdere risikoen knyttet til overdreven avhengighet av enkeltstående leverandører.
• Exit-strategier: Det skal foreligge dokumenterte planer for å avslutte leverandørforhold uten å forstyrre kritiske tjenester.

For leverandører som identifiseres som kritiske IKT-tredjepartsleverandører på EU-nivå, innfører DORA i tillegg et direkte tilsynsregime under ledelse av en av de europeiske tilsynsmyndighetene (EBA, EIOPA eller ESMA).

5. Informasjonsdeling

Den femte pilaren oppfordrer — men pålegger ikke — finansielle foretak til å dele informasjon om cybertrusler, angrepsmetoder og sårbarheter seg imellom. Formålet er å styrke den kollektive motstandskraften i sektoren.

DORA legger til rette for etablering av informasjonsdelingsarrangementer mellom finansielle foretak, og sikrer at slik deling kan skje innenfor rammene av konkurranselovgivning og personvern.

Hva betyr DORA for IT-leverandører?

Dette er kjernen: DORA rammer ikke bare finansinstitusjoner — den regulerer hele leverandørkjeden. Hvis du leverer IKT-tjenester til finanssektoren, er du direkte berørt. Her er de viktigste konsekvensene:

Nye kontraktskrav

Finansinstitusjoner er pålagt å innarbeide DORAs minimumskrav i alle IKT-leverandøravtaler. Leverandører som ikke kan akseptere disse vilkårene, risikerer å miste eksisterende kontrakter eller bli ekskludert fra nye anbud. Sentrale kontraktskrav inkluderer:

• Definerte SLA-er med målbare ytelseskrav
• Full revisjonsrett for kunden og Finanstilsynet — inkludert rett til inspeksjon av leverandørens lokaler og systemer
• Plikt til å varsle om IKT-hendelser innen avtalte tidsrammer
• Krav til datahåndtering, inkludert dataenes lokasjon og prosedyrer for tilbakelevering eller sletting ved avtalens opphør
• Underleverandørkontroll — leverandøren må kunne dokumentere og styre risikoen knyttet til egne underleverandører
• Exit-klausuler som sikrer ordnet overgang ved bytte av leverandør

Krav til revisjonsadgang

Et av de mest merkbare kravene for IT-leverandører er at finanskunder har rett til å revidere leverandørens IKT-risikostyring. Dette betyr i praksis at leverandøren må kunne:

• Stille dokumentasjon til rådighet for kundens revisjoner
• Tilrettelegge for inspeksjoner — enten fysisk eller gjennom pooled audits med flere kunder
• Gi Finanstilsynet tilgang til relevant informasjon og systemer ved behov
• Samarbeide med eksterne revisorer utpekt av kunden

Hendelsesrapportering oppover i kjeden

Når en IKT-hendelse rammer leverandørens systemer og påvirker finanskundens tjenester, må leverandøren kunne varsle kunden raskt nok til at kunden oppfyller sine rapporteringsplikter overfor Finanstilsynet. I praksis betyr dette at leverandøren trenger:

• Effektive deteksjons- og klassifiseringsmekanismer
• Forhåndsdefinerte varslingsprosedyrer og kontaktpunkter
• Kapasitet til å levere kvalifisert informasjon om hendelsens omfang, årsak og forventede løsningstid
• Evne til å støtte kundens hendelsesrapportering med tekniske detaljer

Krav til TLPT-deltakelse

Leverandører som yter kritiske tjenester til systemviktige finansforetak, kan bli inkludert i trusselbasert penetrasjonstesting. Dette innebærer at leverandøren må:

• Akseptere at egne systemer og infrastruktur testes av uavhengige trusselaktører
• Ha prosesser for å håndtere slik testing uten å forstyrre tjenestene
• Følge opp funn og implementere utbedringer innen avtalte frister

Hva er Register of Information (RoI)?

Register of Information (RoI) er et sentralt element i DORAs tredjepartsrisikostyring. Alle finansielle foretak er pålagt å opprettholde et oppdatert register over alle sine IKT-tredjepartsavtaler. Registeret skal inneholde detaljert informasjon om:

• Leverandørens identitet og organisasjonsstruktur
• Hvilke IKT-tjenester som leveres
• Om tjenesten støtter kritiske eller viktige funksjoner
• Dataenes lokasjon (prosessering og lagring)
• Underleverandører i leveransekjeden
• Avtalens varighet, oppsigelsesvilkår og exit-strategier

Den første fristen for RoI-rapportering til Finanstilsynet var 13. mars 2026. For IT-leverandører betyr dette at finanskunder har bedt om — eller vil be om — detaljert informasjon om tjenestene du leverer, underleverandører du benytter, og hvor data prosesseres og lagres.

Leverandører som ikke kan levere denne informasjonen på en strukturert og etterprøvbar måte, utgjør en compliance-risiko for sine finanskunder — og risikerer å bli erstattet av leverandører som kan det.

DORA og NIS2: Hvordan henger de sammen?

DORA og NIS2 er to komplementære EU-regelverk som begge adresserer cybersikkerhet, men med ulikt fokus og virkeområde. For virksomheter som berøres av begge, er det viktig å forstå samspillet.

Aspekt	DORA	NIS2
Fokus	Digital operasjonell motstandskraft i finanssektoren	Cybersikkerhet på tvers av kritiske sektorer
Type regelverk	Forordning (gjelder direkte)	Direktiv (krever nasjonal gjennomføring)
Sektor	Finanssektoren og IKT-leverandører til finans	18 sektorer inkl. energi, helse, transport, digital infrastruktur
Tilsyn i Norge	Finanstilsynet	NSM, Nkom og sektortilsyn
Tredjepartskrav	Svært detaljerte — kontraktskrav, RoI, TLPT	Generelle krav til forsyningskjedesikkerhet
Hendelsesrapportering	4 timer (innledende), 72 timer (mellomrapport), 1 måned (sluttrapport)	24 timer (tidlig varsling), 72 timer (hendelsevurdering), 1 måned (sluttrapport)
Resilience-testing	Obligatorisk, inkl. TLPT for systemviktige foretak	Generelle krav til sikkerhetstesting
Lex specialis	DORA går foran NIS2 for finanssektoren	Gjelder der DORA ikke har spesifikke bestemmelser

Et viktig prinsipp er at DORA er lex specialis — den har forrang over NIS2 for finanssektoren. Dersom DORA stiller strengere eller mer spesifikke krav enn NIS2, er det DORA som gjelder. Men NIS2 kan fortsatt gjelde for aspekter som DORA ikke dekker eksplisitt.

For IT-leverandører som betjener kunder i flere sektorer betyr dette at du potensielt må forholde deg til begge regelverk. En pragmatisk tilnærming er å bygge et compliance-rammeverk som dekker de strengeste kravene — typisk DORA — og deretter kartlegge eventuelle tilleggskrav fra NIS2 for kunder utenfor finanssektoren.

Hva er sanksjonene ved brudd på DORA?

Finanstilsynet har fått betydelige håndhevingsverktøy under DORA. Sanksjonsregimet rammer både finansielle foretak og, indirekte, deres leverandører:

For finansielle foretak:

• Administrative bøter etter forholdsmessighetsvurdering — beløpene fastsettes nasjonalt, men skal være «effektive, proporsjonale og avskrekkende»
• Pålegg om å avslutte atferd som bryter med DORA
• Offentliggjøring av overtredelser (naming and shaming)
• Midlertidig forbud mot å utøve ledelsesfunksjoner
• Tvangsmulkt ved manglende etterlevelse av pålegg

For kritiske IKT-tredjepartsleverandører under direkte tilsyn:

• Tvangsmulkt på opptil 1 % av gjennomsnittlig daglig global omsetning for hver dag med manglende etterlevelse, i opptil seks måneder
• Pålegg om å endre praksis, prosedyrer eller sikkerhetstiltak
• Offentliggjøring av manglende etterlevelse
• Anbefaling til finansielle foretak om å suspendere eller avslutte tjenesteavtaler

For IT-leverandører som ikke er under direkte tilsyn, er den mest reelle risikoen indirekte: finanskunder som ikke oppnår tilfredsstillende compliance med sine leverandører, vil se seg nødt til å bytte leverandør. DORA-compliance blir dermed et konkurranseparameter — ikke bare et juridisk krav.

Praktiske tiltak for IT-leverandører

Hvis du leverer IKT-tjenester til finanssektoren, bør du allerede være godt i gang med DORA-tilpasninger. Her er en faseinndelt sjekkliste:

Fase 1: Kartlegging og analyse (bør være fullført)

• Identifiser alle kundeforhold i finanssektoren
• Kartlegg hvilke tjenester du leverer som støtter kritiske eller viktige funksjoner hos finanskunder
• Gjennomfør en GAP-analyse av eksisterende avtaler mot DORAs kontraktskrav
• Kartlegg egne underleverandører og deres rolle i leveransen
• Vurder om du potensielt kan bli klassifisert som kritisk IKT-tredjepartsleverandør
• Kartlegg hvor data prosesseres og lagres for hver finanskunde

Fase 2: Tilpasning av rammeverk og prosesser (pågående)

• Oppdater eller etabler IKT-risikostyringsrammeverk i tråd med DORA-kravene
• Etabler hendelseshåndterings- og varslingsprosedyrer som støtter kundenes rapporteringsfrister
• Implementer eller styrk logging, overvåking og deteksjonskapasitet
• Oppdater sikkerhetspolicyer, tilgangsstyring og krypteringspraksis
• Utarbeid dokumentasjon som støtter kundenes RoI-rapportering
• Etabler prosedyrer for revisjoner og inspeksjoner fra finanskunder

Fase 3: Kontrakt- og avtaleoppdatering (pågående)

• Oppdater standardavtaler med DORA-påkrevde klausuler (SLA, revisjonsrett, hendelsesrapportering, exit, datahåndtering)
• Forhandle oppdaterte vilkår med eksisterende finanskunder
• Etabler prosedyrer for underleverandørkontroll og -rapportering
• Dokumenter exit-strategier som sikrer ordnet overgang ved avtaleopphør

Fase 4: Testing og kontinuerlig forbedring (løpende)

• Gjennomfør regelmessige sårbarhetsvurderinger og sikkerhetstester
• Forbered organisasjonen på å delta i kunders TLPT-programmer
• Øv på hendelseshåndtering gjennom tabletop-øvelser med finanskunder
• Gjennomfør jevnlige revisjoner av underleverandører
• Oppdater risikostyring og dokumentasjon basert på ny trusseletterretning og erfaringer
• Hold ledelse og nøkkelpersonell oppdatert på regulatoriske endringer

Slik kan vi hjelpe

I UNOS SOFTWARE AS arbeider vi med norske virksomheter som utvikler og drifter teknologiløsninger for regulerte bransjer. Sammen med vår samarbeidspartner Unos IT AS tilbyr vi et komplett tjenestetilbud fra utvikling til drift. Vi forstår kravene som DORA stiller til IT-leverandører — fordi vi selv opererer i dette landskapet.

Vi kan bistå med:

• Sikker programvareutvikling for finanssektoren — gjennom vår programvareutviklingstjeneste bygger vi løsninger med innebygd sikkerhet, logging, tilgangsstyring og hendelseshåndtering som oppfyller DORA-kravene
• Teknisk rådgivning om DORA-compliance — vår rådgivningstjeneste hjelper IT-leverandører med GAP-analyser, utforming av IKT-risikostyringsrammeverk og forberedelse til revisjoner
• Systemintegrasjon og API-sikkerhet — gjennom vår integrasjonstjeneste sikrer vi at grensesnittene mellom dine systemer og finanskundenes infrastruktur oppfyller sikkerhetskravene
• Skyinfrastruktur med compliance innebygd — vår sky- og infrastrukturtjeneste leverer dokumenterte, overvåkede og revidérbare miljøer tilpasset regulatoriske krav

DORA er ikke et engangsprosjekt — det er et kontinuerlig compliance-regime som krever løpende oppmerksomhet, oppdatering og forbedring. Jo tidligere du etablerer et solid fundament, desto enklere blir den daglige etterlevelsen.

DORA er del av en bredere regulatorisk bølge fra EU. Les også om Cyber Resilience Act (CRA) som stiller sikkerhetskrav til digitale produkter, og EU Data Act med nye regler for datadeling og skyportabilitet.

Trenger din virksomhet bistand med DORA-tilpasning? Ta kontakt for en uforpliktende samtale om hvordan vi kan hjelpe deg med å møte kravene.

Vanlige spørsmål om DORA

Gjelder DORA for IT-leverandører som ikke er i finanssektoren?

Ja — DORA rammer ikke bare finansinstitusjoner, men også alle IKT-tredjepartsleverandører som leverer tjenester til dem. Hvis du leverer programvare, skytjenester eller IT-drift til banker, forsikringsselskaper eller betalingstjenester, er du direkte berørt.

Hva er forskjellen mellom DORA og NIS2?

DORA er sektorspesifikk for finanssektoren og har mer detaljerte krav til tredjepartsrisiko og resilience-testing. NIS2 dekker bredere på tvers av kritiske sektorer. DORA har forrang (lex specialis) for finanssektoren der kravene overlapper.

Hva er TLPT, og må IT-leverandører delta?

TLPT (Threat-Led Penetration Testing) er trusselbasert penetrasjonstesting som systemviktige finansinstitusjoner må gjennomføre minst hvert tredje år. IT-leverandører som yter kritiske tjenester til disse institusjonene, kan bli inkludert i testene og må legge til rette for dette.

Hva er Register of Information (RoI)?

RoI er et register over alle IKT-tredjepartsavtaler som finansielle foretak skal vedlikeholde og rapportere til Finanstilsynet. Første rapporteringsfrist var 13. mars 2026. IT-leverandører må kunne levere strukturert informasjon om sine tjenester til finanskundene.

Hva risikerer IT-leverandører ved manglende DORA-compliance?

Kritiske IKT-tredjepartsleverandører kan ilegges tvangsmulkt på opptil 1 prosent av daglig global omsetning. For øvrige leverandører er den største risikoen indirekte — finanskunder som ikke oppnår compliance, vil bytte til leverandører som kan oppfylle kravene.

---

Kilder og videre lesning

• Europaparlamentet (2022). «Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA).» eur-lex.europa.eu
• Finanstilsynet (2025). «DORA — krav til digital operasjonell motstandskraft i finanssektoren.» finanstilsynet.no
• Finanstilsynet (2026). «Register of Information (RoI) — veiledning for rapportering.» finanstilsynet.no
• European Supervisory Authorities (2025). «Final Report on DORA Regulatory Technical Standards.» eba.europa.eu
• EIOPA (2025). «DORA Implementation — Guidelines for ICT Third-Party Service Providers.» eiopa.europa.eu
• Regjeringen (2025). «Gjennomføring av DORA i norsk rett.» regjeringen.no
• NSM (2025). «Nasjonalt digitalt risikobilde 2025 — finanssektoren.» nsm.no
• Finans Norge (2025). «DORA — veileder for finansnæringen.» finansnorge.no

---

Ta kontakt med oss

Leverer du IKT-tjenester til finanssektoren og trenger hjelp med DORA-tilpasning? UNOS SOFTWARE AS — i samarbeid med Unos IT AS — bistår med sikkerhet, risikostyring og compliance for IT-leverandører. Send oss en henvendelse gjennom kontaktskjemaet — vi tar en uforpliktende samtale om hvordan din virksomhet kan møte DORA-kravene.