Den beste DORA-programvaren for et norsk foretak må passe til reglene som faktisk gjelder for foretaket. Dette er særlig viktig etter 1. september 2026: enkelte virksomheter utenfor forordningens ordinære virkeområde følger nå utvalgte DORA-regler med norske tilpasninger. En standardpakke som behandler alle som banker, kan gi feil register, feil rapporteringsløp og unødvendige arbeidsoppgaver.
Denne kjøpsguiden gir en fremgangsmåte for å etablere riktig kravprofil og prøve den med konkrete data. Resultatet skal være et begrunnet valg av løsning og et referat som viser hva som er levert, hva som må konfigureres, og hva foretaket selv må gjøre. Vi presenterer ikke en udokumentert leverandørrangering eller standardpris. Rettskilder og myndighetsinformasjon er kontrollert 27. september 2026.
Status for DORA i Norge
DORA er gjennomført i norsk rett gjennom DORA-loven og DORA-forskriften, som trådte i kraft 1. juli 2025. At en EU-forordning er vedtatt, gjør den ikke i seg selv direkte gjeldende i Norge; EØS-innlemmelse og norsk gjennomføring må holdes fra hverandre. Finanstilsynets DORA-side gir inngang til gjeldende regelverk og rapporteringsveiledninger.
For foretak i det ordinære virkeområdet er DORA artikkel 2 utgangspunktet, sammen med EØS-tilpasninger og norsk rett. Bestemmelsen inneholder både omfattede kategorier og unntak. Det er ikke riktig at alle små foretak følger et forenklet regime, eller at hele finanssektoren har identiske plikter.
Bruk den norske DORA-guiden til den bredere juridiske vurderingen. I innkjøpet skal konklusjonen bli en konkret kravprofil med juridisk enhet, virksomhetstype, lovgrunnlag, relevante unntak og ansvarlig godkjenner. En gruppe med flere selskaper kan trenge flere profiler i samme løsning.
De norske endringene fra september 2026
Finansdepartementets forskriftsendring av 20. august 2026 innførte egne regler for finansieringsforetak, eiendomsmeglingsforetak, inkassoforetak og Norsk naturskadepool. Fra 1. september erstattet disse reglene IKT-forskriften. Foretakene følger de delene som er gjort gjeldende i forskriftens kapittel 2, med de angitte tilpasningene.
Finansieringsforetak omfattes av risikostyringsreglene i artiklene 5–15 så langt de passer. Eiendomsmeglingsforetak, inkassoforetak og Norsk naturskadepool følger det forenklede rammeverket i artikkel 16 så langt det passer. Det er en rettslig forskjell som må kunne gjenspeiles i kravlisten; den skal ikke avgjøres av hvor mange brukerlisenser kunden kjøper.
Departementets kunngjøring presiserer også at enkelte andre foretak ikke ble underlagt DORA-regelverket. En påstand om at septemberendringen omfatter alle tidligere eller mulige finansielle virksomheter, er derfor for vid. Programvareleverandøren bør kunne vise hvilken regel som ligger bak hvert obligatoriske felt i det foreslåtte oppsettet.
Registeret er ikke det samme for alle
For de nasjonalt utvidede kategoriene krever forskriften et register på foretaksnivå. Den fastslår uttrykkelig at gjennomføringsforordning 2024/2956 ikke gjelder for dette registeret. Dette skiller seg fra de standardiserte registerkravene for foretak i det ordinære DORA-regimet. Et omfattende internasjonalt rapporteringsoppsett er derfor ikke automatisk et minimumskrav for et mindre norsk inkassoforetak.
Ved valg av løsning skal foretaket undersøke hvilke identifikatorer, tjenestebeskrivelser, landopplysninger, opplysninger om underleverandører, avtaledatoer og datoer for risikovurdering den nasjonale profilen må inneholde. Be om at feltene spores til § 9 og at leverandøren forklarer håndteringen av opplysninger som ikke foreligger. Ikke la et tomt felt fylles med en oppdiktet verdi bare for å fjerne en valideringsfeil.
Tilpasningene gjelder også melding om IKT-tjenesteavtaler. For eiendomsmeglingsforetak er denne plikten begrenset til tjenester for oppgjørsfunksjonen; for inkassoforetak gjelder den mellomstore og større foretak etter den angitte definisjonen. Et nytt registerobjekt og en melding til myndigheten er derfor forskjellige handlinger. Systemet må kunne holde dem adskilt.
Begynn demonstrasjonen med to ulike foretak
En praktisk utprøving kan bruke to hypotetiske selskaper: en bank i ordinært virkeområde og et eiendomsmeglingsforetak under de nasjonale tilpasningene. De bruker begge en skytjeneste, men har forskjellige kravprofiler. Leverandøren skal vise hvordan systemet skiller kravene, uten å kopiere hele bankens kontrollsett til meglerforetaket.
Legg deretter inn en oppgjørstjeneste og et internt planleggingsverktøy hos meglerforetaket. En hendelse som berører oppgjøret og en feil i planleggingsverktøyet skal kunne vurderes etter den relevante avgrensningen. Begge kan kreve intern håndtering, men reglene om klassifisering og rapportering er ikke nødvendigvis de samme.
Denne øvelsen avslører om produktet bare har et generelt DORA-merke, eller om kunden kan forvalte en presis kravprofil. Den tester også om en endring i virksomheten kan behandles kontrollert. Dersom foretaket senere får en annen tillatelse, må vurderingen kunne endres med historikk og ny godkjenning.
Hva må DORA-programvare dekke?
Avklar hvilke oppgaver dere forventer at løsningen utfører. Risikovurderinger, kontraktsoppfølging, dokumentasjon av tester og hendelseskoordinering kan ligge i samme produkt eller i ulike systemer. Det vesentlige er at ansvar, dataflyt og beslutninger kan følges. Programvare som registrerer en sikkerhetskontroll, gjennomfører ikke nødvendigvis kontrollen.
Velg én tjeneste og følg den fra anskaffelse til drift. Hvilken funksjon støtter den, hvilken risiko er vurdert, hvem har godkjent avtalen, og hva skjer ved en vesentlig endring? Kravspesifikasjonen bør beskrive disse sammenhengene før den lister mulige moduler. Et system med få funksjoner kan fungere godt i en avgrenset rolle hvis grenseflatene er klare.
Etter demonstrasjonen skal leverandøren kunne levere en forståelig eksport av prøvesaken. Hvis sammenhengen bare kan forklares av selgeren mens skjermbildet er åpent, er dokumentasjonen for svak. Utprøvingen bør utføres med syntetiske eller rensede data, slik at sensitive kontrakter og sårbarheter ikke spres unødvendig.
Tredjepartsregisteret i praksis
For et foretak i ordinært virkeområde bør prøven vise forholdet mellom juridisk enhet, kontrakt, tjeneste, funksjon og leverandørkjede. Samme leverandør kan levere flere tjenester, og samme kontrakt kan støtte flere funksjoner. Et enkelt kontaktregister kan derfor være utilstrekkelig selv om alle leverandørnavnene er riktige.
La leverandøren importere et lite datasett med en duplikat, en manglende identifikator og en utløpt kontrakt. Undersøk hvordan feilene presenteres, hvem som kan rette dem, og om rettingen kan spores. Eksporten skal bruke riktig gjeldende format for den aktuelle rapporteringen. At et produkt kan eksportere CSV, viser ikke alene at filen kan brukes i myndighetens løsning.
Kritisk eller viktig funksjon er heller ikke det samme som en kritisk IKT-tredjepartsleverandør utpekt under europeisk tilsyn. Hold begrepene adskilt i feltnavn og rapporter. Ellers kan foretaket feilaktig begrense oppfølgingen til leverandører som står på en offentlig liste, og overse en egen vesentlig avhengighet.
Kontraktsgjennomgang krever dokumentert vurdering
Artikkel 30 inneholder kontraktkrav med ytterligere krav for tjenester som støtter kritiske eller viktige funksjoner. Be leverandøren vise et eksempel der en rettighet er omtalt i hovedavtalen, men begrenset i et vedlegg. Automatisk gjenfinning av et nøkkelord er ikke det samme som vurdering av kontraktens samlede innhold.
Et nyttig verktøy bør gjøre kilden til et funn synlig og la en ansvarlig person korrigere eller nyansere vurderingen. Hvis analysen mangler et bilag, skal dette fremgå som usikkerhet. Den juridiske beslutningen bør ikke lagres som endelig bare fordi en automatisk gjennomgang er ferdig.
En databehandleravtale gjelder behandling av personopplysninger på vegne av en behandlingsansvarlig. DORA gjelder IKT-tjenester og operasjonell risiko. Det kan være samme kontraktspart, men vurderingene har ulikt formål. Dokumentlenker og kontaktopplysninger kan gjenbrukes; konklusjoner bør ikke automatisk kopieres mellom regelverkene.
Hendelsesrapportering må følge riktig norsk kanal
Den nasjonale utvidelsen har også praktiske konsekvenser. Finanstilsynets melding om de nye reglene opplyser at de aktuelle foretakene inntil videre ikke kan bruke Altinn-skjema KRT-3190. Myndigheten beskriver en særskilt kanal og alternativer for sensitiv informasjon. Kontroller den løpende veiledningen før rapportering; ikke bygg en uforanderlig arbeidsflyt rundt et skjema som ikke er tilgjengelig for foretaket.
For eiendomsmeglingsforetak gjelder forskriftens tilpasning av artikkel 18 og 19 bare hendelser knyttet til oppgjørsfunksjonen. Kravet om intern håndtering etter artikkel 17 har en annen avgrensning. Programvaren må derfor kunne registrere hendelser uten å utløse samme rapporteringsløp for alle.
I demonstrasjonen bør hendelsen få egne tidsstempler for oppstått, oppdaget, klassifisert og sendt. Vis hvordan nye opplysninger fører til oppdatert vurdering og hvordan en reserveperson overtar ved fravær. Et automatisk varsel uten dokumentasjon av hva som ble sendt, er ikke en fullstendig rapporteringsprosess.
DORA møter GDPR: overlappet
Et angrep kan gi både driftsforstyrrelser og brudd på personopplysningssikkerheten. GDPR-anmeldelse avhenger av risiko for de registrerte, mens DORA bruker sine egne klassifikasjonskriterier. Det er derfor feil å skrive at ethvert angrep som berører personopplysninger automatisk skal meldes til Datatilsynet innen 72 timer.
Arbeidet med avvik etter artikkel 33 og 34 trenger en egen vurdering av risiko og eventuell informasjon til berørte personer. Del faktabeskrivelsen, men behold begrunnelse, frist og mottaker for hvert spor. I øvelsen kan én hendelse være rapporteringspliktig under ett regelverk og ikke under et annet.
Behandlingsprotokollen og IKT-registeret bør også skilles. Protokollen beskriver behandling av personopplysninger, mens DORA-registeret beskriver tjenesteavtaler og relasjoner. Samordning kan redusere dobbelt registrering, men bare dersom løsningen bevarer ulike roller og formål. Sammenligning av personvernverktøy kan hjelpe med denne delen av behovet.
Testing av digital motstandsdyktighet
Programvaren bør støtte det testprogrammet foretaket faktisk er omfattet av. Et arkiv over rapporter erstatter ikke planlegging, gjennomføring eller kontroll av retting. Be om å registrere et testfunn, koble det til den berørte tjenesten og føre saken frem til en ny kontroll. Dersom rettingen mislykkes, skal historikken og den gjenværende risikoen være synlig.
En gjenopprettingsplan med RTO og RPO kan gi konkrete øvingsmål. Planlagt gjenopprettingstid og faktisk målt tid skal holdes adskilt. En godkjent plan dokumenterer en beslutning; en gjennomført øvelse gir annen type informasjon. Leverandøren bør vise begge uten å slå dem sammen til én grønn status.
TLPT gjelder etter egne regler og utpeking, ikke automatisk alle som kjøper et DORA-verktøy. En ordinær penetrasjonstest kan være relevant i testprogrammet uten å være TLPT. Kravlisten må derfor vise hva som er nødvendig nå, og hva som eventuelt er en senere eller separat leveranse.
Ledelse, proporsjonalitet og sanksjoner
Proporsjonalitet betyr at vurderinger skal tilpasses virksomheten innenfor gjeldende regler. Det betyr ikke at et lite foretak kan velge bort plikter uten begrunnelse. Be om en ledelsesrapport som viser vesentlige avhengigheter, åpne risikoer, beslutninger og ansvar. Rapporten bør gjøre det mulig å ta stilling til tiltak, ikke bare registrere at dokumenter eksisterer.
DORA-loven § 4 gir hjemmel for overtredelsesgebyr på inntil 50 millioner kroner for angitte overtredelser. Det er et lovbestemt maksimum, ikke en standardreaksjon eller dokumentasjon på at et foretak faktisk har fått et slikt gebyr. Forskriftens § 11 knytter reaksjoner for de nasjonalt omfattede foretakene til de relevante bestemmelsene og vilkårene.
Et kjøpsvedtak bør begrunnes i faktiske plikter og dokumenterte behov. Det er ikke et økonomisk regnestykke der abonnementet sammenlignes direkte med et maksimalt gebyr. Foretaket må fortsatt vurdere kvaliteten på arbeidsprosessene, kompetansen og de tekniske foranstaltningene utenfor dokumentasjonsverktøyet.
Sikkerhet og leverandørbytte
Et DORA-verktøy kan inneholde detaljer om sårbarheter, kritiske tjenester og kontrakter. Avklar hvilke brukere som kan lese, endre, godkjenne og eksportere disse opplysningene. Prøv en ekstern rådgiverrolle og en administrator som avslutter arbeidsforholdet. Tilgangen skal følge behov og kunne kontrolleres.
Undersøk dataplassering, supporttilgang og underleverandører. EØS-lagring alene avklarer ikke alle spørsmål om overføring til tredjeland. Be om faktiske dataflyter og gjeldende avtalevilkår, særlig dersom dokumentanalyse bruker andre tjenester. Kravene skal gjelde hele den tilbudte løsningen.
Før kjøp bør foretaket prøve en full eksport med relasjoner, bilag og historiske beslutninger. Aftal hvordan materialet kan brukes under et senere bytte, hva bistand koster, og hva som skjer med kopier etter opphør. Uten dette kan en dokumentasjonsplattform selv bli en vanskelig avhengighet.
Gjør kravprofilen til en kontrollert leveranse
Be leverandøren levere en oversikt som viser hvilke regler hver valgt arbeidsflyt bygger på. Oversikten bør skille ordinært DORA-virkeområde fra norsk utvidelse, og den bør angi hva som er kundens egne tilleggskrav. Det gjør det mulig å vedlikeholde oppsettet når virksomheten endres, uten å starte hele vurderingen på nytt.
Prøv også å slå av et irrelevant krav uten å slette begrunnelsen. Et eiendomsmeglingsforetak skal ikke få en uriktig rød status fordi en bankspesifikk prosess ikke er gjennomført. Samtidig må systemet hindre at en bruker tilfeldig fjerner et faktisk obligatorisk krav. Endringer i kravprofilen bør derfor ha ansvarlig godkjenning og en forklaring som kan leses senere.
Etter utprøvingen samles funnene i et akseptreferat med demonstrert funksjon, avvik, behov for konfigurasjon og gjenstående spørsmål. Skill mellom noe som finnes i den tilbudte leveransen og noe som bare er planlagt. Dersom foretaket godtar et midlertidig manuelt arbeid, må arbeidsmengde, ansvar og risiko være vurdert. Referatet bør følge tilbudet helt frem til kontrakten, slik at viktige forutsetninger ikke forsvinner mellom fagteamet og innkjøp.
Ofte stilte spørsmål
Hva koster DORA-programvare i Norge?
Be om et tilbud med samme avgrensning hos alle kandidater. Pris påvirkes blant annet av selskaper, brukere, avtaler, integrasjoner og oppsettarbeid. Et samlet kostnadsgrunnlag bør inkludere interne timer, vedlikehold av kravprofiler og bistand ved eksport. Vi angir ikke et markedsintervall uten dokumenterte sammenlignbare tilbud.
Må små finansforetak følge hele DORA?
Det avhenger av virksomhetstype og hjemmel. Unntak, forenklet rammeverk og nasjonal utvidelse er forskjellige situasjoner. Etter september 2026 må de norske tilpasningene vurderes eksplisitt; antall ansatte alene gir ikke et fullstendig svar.
Hvilket krav bør vi prioritere først?
Begynn med riktig virkeområde og de mest alvorlige dokumenterte manglene. Registeret kan være et naturlig første prosjekt, men et ødelagt rapporteringsløp eller uklar gjenoppretting kan være mer presserende. Velg rekkefølge etter risiko og plikter, og dokumenter hvorfor.
Når er leverandøren klar for endelig valg?
Når riktig kravprofil er demonstrert, prøveeksporten er kontrollert, rapporteringsløpet fungerer for foretaket og åpne punkter har ansvarlige eiere. Lagre avvik og forutsetninger sammen med tilbudet. En planlagt funksjon skal fortsatt stå som uavklart til den er levert og kontrollert.