DORA-revisjonskrav og hva dere rapporterer hvert år

Et DORA-program som er oppe og går, sender tre ting til Finanstilsynet på frist og har en fjerde liggende klar til den som spør. Her er hva hver av dem er, når de går, og hvem som må ha signert først.

Dette er guiden for driften, ikke for oppbyggingen. Holder dere fortsatt på å sette opp programmet, start med DORA-sjekklisten for finansforetak og kom tilbake hit. DORA har gjeldt i Norge siden 1. juli 2025, da den norske DORA-loven og DORA-forskriften trådte i kraft.

1. Rapporter informasjonsregisteret en gang i året

Informasjonsregisteret lister alle IKT-tjenesteavtalene foretaket har, og norske foretak sender det til Finanstilsynet en gang i året.

Registeret skal føres og oppdateres på foretaksnivå, og på delkonsolidert og konsolidert nivå hvis dere sitter i konsern (DORA artikkel 28(3)). Samme bestemmelse krever minst årlig rapportering om nye avtaler, kategorier av IKT-leverandører, avtaletyper og hvilke tjenester som leveres.

I Norge går filen gjennom e-Reg i XBRL-CSV, etter malene i gjennomføringsforordning (EU) 2024/2956. Første runde hadde frist 13. mars 2026 og dekket kalenderåret 2025. Finanstilsynet sender filene videre til de europeiske tilsynsmyndighetene innen 31. mars hvert år.

To ting avgjør om filen blir godkjent. Hver leverandør trenger LEI- eller EUID-kode, og det samme gjelder underleverandører som understøtter en kritisk eller viktig funksjon. Dessuten må hver avtale merkes som kritisk eller viktig på et grunnlag dere kan forsvare, og da må virksomhetsanalysen bak merkingen finnes på papir.

Sett av tid etter fristen, ikke bare før. I den første norske runden kom innsendinger i retur som avvist på EBAs valideringsregler, og Finanstilsynet holdt et rettevindu åpent til 30. april 2026.

2. Meld planlagte IKT-avtaler 30 dager før de trer i kraft

Dere melder fra til Finanstilsynet før en IKT-avtale som understøtter en kritisk eller viktig funksjon trer i kraft, og i Norge betyr det 30 dager i forkant.

Forordningen skriver fristen som “i god tid” (artikkel 28(3)). Finanstilsynet har satt et tall på formuleringen: minst 30 dager før avtalen eller endringen trer i kraft, på Altinn-skjema KRT-1121, ifølge rundskrivet om melding av IKT-tjenesteavtaler.

Denne forskjellen betyr noe. De 30 dagene er norsk tilsynspraksis og ikke et tall i forordningen, men det er likevel tallet tilsynet teller etter. Legg det inn i innkjøpskalenderen, så juridisk ikke oppdager fristen i første uke av en reforhandling.

3. Kjør hendelsesklokka i tre trinn

En alvorlig IKT-hendelse utløser tre rapporter: første melding innen 4 timer, statusrapport innen 72 timer og sluttrapport innen en måned.

Klassifiseringen kommer først. En hendelse regnes som alvorlig når den rammer kritiske tjenester, og enten gir en angriper vellykket, ondsinnet og uautorisert tilgang med fare for datatap, eller slår ut på to eller flere av de øvrige vesentlighetskriteriene: berørte kunder og transaksjoner, omdømme, varighet og nedetid, geografisk spredning, tap av data og økonomiske konsekvenser (delegert forordning (EU) 2024/1772).

Så begynner klokka å gå. Første melding sendes innen 4 timer etter at hendelsen ble klassifisert som alvorlig, og senest 24 timer etter at foretaket ble kjent med den. Statusrapporten følger innen 72 timer etter første melding. Sluttrapporten kommer innen en måned etter siste statusrapport (delegert forordning (EU) 2025/301, artikkel 5).

Det finnes en utsettelse til klokka 12 neste virkedag når fristen faller på helg eller helligdag. Den gjelder ikke kredittinstitusjoner, sentrale motparter, operatører av handelsplasser eller foretak som er utpekt som vesentlige eller viktige etter NIS2. Sjekk hvilken liste dere står på før dere planlegger en lørdag.

I Norge går rapportene gjennom Finanstilsynets rapporteringsløsning, og mekanikken står i rundskrivet om hendelsesrapportering etter DORA. Finanstilsynet presiserte i 2026 at feltene 4.7 og 4.8 tar imot framtidige datoer, slik at dere kan melde planlagt ferdigstilling i stedet for å holde igjen rapporten.

Firetimersfristen starter ved klassifisering, ikke ved deteksjon. Derfor er det klassifiseringsbeslutningen dere skal øve på, ikke skjemaet. Sett navn på den som tar beslutningen, sett navn på en stedfortreder, og logg klokkeslettet de ble nådd.

4. Legg IKT-revisjonsplanen fram for styret

DORA legger planen for IKT-internrevisjon på styrets bord for godkjenning (artikkel 5(2)(f)).

Styret godkjenner og gjennomgår jevnlig planene for IKT-internrevisjon, selve IKT-revisjonene og vesentlige endringer i dem. Dette er en fast sak med protokoll, ikke en engangssignatur i det første året.

Selve revisjonen har to vilkår hengende på seg (artikkel 6(6)). Revisorene trenger tilstrekkelig kunnskap, ferdigheter og kompetanse på IKT-risiko. De trenger dessuten tilstrekkelig uavhengighet. Hyppighet og innretning skal stå i forhold til foretakets IKT-risiko, så et betalingsforetak med ett kjernesystem og en bank med førti integrasjoner får ikke samme plan. Mikroforetak faller utenfor kravet til internrevisjon.

Uavhengigheten har en bestemt form i regelverket. IKT-risikostyring, kontrollfunksjonen og internrevisjonen holdes atskilt, etter en tre-forsvarslinjer-modell eller en tilsvarende modell for risikostyring og kontroll (artikkel 6(4)). Skriv ned hvem som reviderer, og hvorfor de er både kompetente og uavhengige. Kompetanse er en dokumentert vurdering, på samme måte som Lead Implementer og Lead Auditor er to ulike roller i et ISO 27001-prosjekt.

5. Lukk kritiske revisjonsfunn på en nedskrevet frist

En formell oppfølgingsprosess for kritiske IKT-revisjonsfunn er et krav i DORA, ikke god skikk (artikkel 6(7)).

Forordningen ber om regler for rettidig verifisering og utbedring. Den definerer ikke rettidig. Å definere den er deres jobb, og definisjonen er samtidig det revisor tester. Gi hver alvorlighetsgrad en frist i antall dager, sett navn på ansvarlig, og logg beviset som lukket funnet.

Selve rammeverket gjennomgås minst en gang i året (artikkel 6(5)). Det gjennomgås dessuten etter alvorlige hendelser, etter pålegg fra tilsynet og etter konklusjoner fra testing eller revisjon. Disse utløserne kommer i tillegg til den årlige runden, og det er dem foretakene glemmer. Samme bestemmelse gir tilsynet rett til å be om rapporten fra gjennomgangen, så skriv gjennomgangen som et dokument og ikke som et møte.

Etter en alvorlig hendelse som forstyrret kjernevirksomheten skal dere gjøre en gjennomgang i etterkant (artikkel 13(2)). Foretak som ikke er mikroforetak, forteller tilsynet hva som ble endret når tilsynet ber om det. Hold gjennomgangen og endringsloggen i samme mappe.

6. Hold bevismappen for vanlige dager oppdatert

På en helt vanlig dag uten hendelser ber en revisor om seks ting.

• Det gjeldende informasjonsregisteret, og kvitteringen fra siste innsending i e-Reg.
• Styreprotokollen som godkjenner planen for IKT-internrevisjon, og den skriftlige årlige gjennomgangen av rammeverket.
• Hendelsesloggen, medregnet hendelsene dere klassifiserte som ikke alvorlige, og begrunnelsen.
• Oppfølgingsregisteret for kritiske IKT-revisjonsfunn, med dato åpnet og dato lukket.
• KRT-1121-meldingene, datert slik at de kan holdes opp mot signaturdatoene.
• Resultatene fra testprogrammet for digital operasjonell motstandsdyktighet.

Det siste punktet er et eget tema. DORA har et separat testregime, blant annet årlige tester av systemene som understøtter kritiske eller viktige funksjoner (artikkel 24(6)). FM CyberSecurity tar skanning og testing gjennom praksisen vår for sårbarhetshåndtering, og kravene til gjentakende testing hører hjemme i en egen artikkel.

De fem andre er ren dokumentbehandling. De ryker på samme måte hvert år, og grunnen er den samme hver gang: ingen har ansvaret for filene mellom rapporteringsrundene.

Neste steg

Ta de seks punktene over og sjekk om dere kunne lagt fram hvert av dem i dag, uten å spørre noen. Bommer dere på to eller flere, er det gapet som skal lukkes før neste rapporteringsrunde.

Johan Vorgaard leder DORA-arbeidet i compliance-praksisen vår og går gjennom registeret, revisjonsplanen og klassifiseringsreglene med dere på 30 minutter. Viser det seg at gapet handler om kapasitet og ikke om papirarbeid, kan konsulentene våre holde filene mellom rundene. Ta med den siste styreprotokollen som nevner IKT.

Ofte stilte spørsmål

Hvor ofte skal informasjonsregisteret rapporteres etter DORA?

Minst en gang i året (artikkel 28(3)). I Norge hadde første innsending frist 13. mars 2026 og dekket kalenderåret 2025. Den går gjennom e-Reg, og Finanstilsynet sender filene videre til de europeiske tilsynsmyndighetene innen 31. mars.

Når begynner firetimersfristen å løpe?

Ved klassifisering, ikke ved deteksjon. Dere har 4 timer fra hendelsen klassifiseres som alvorlig, med et tak på 24 timer fra foretaket ble kjent med den (forordning (EU) 2025/301, artikkel 5). Klassifiseringsbeslutningen er derfor den delen som er verdt å øve inn.

Kan den som har ansvaret for IKT-risiko også signere internrevisjonen?

Nei. Revisorene som reviderer rammeverket for IKT-risikostyring, skal ha tilstrekkelig uavhengighet (artikkel 6(6)), og DORA krever at IKT-risikostyring, kontrollfunksjoner og internrevisjon holdes atskilt etter en tre-forsvarslinjer-modell eller tilsvarende (artikkel 6(4)). Små foretak løser dette som regel med en ekstern revisor på et navngitt mandat.

Gjelder DORA for oss i Norge, og fra når?

Den norske DORA-loven (lov 2025-05-27-18) og DORA-forskriften (forskrift 2025-06-24-1296) trådte begge i kraft 1. juli 2025. Står foretaket under tilsyn av Finanstilsynet, gjelder DORA nesten helt sikkert.

Hvor slutter DORA og hvor begynner Finanstilsynets egne forventninger?

DORA setter plikten, Finanstilsynet setter den norske mekanikken. Meldefristen på 30 dager for IKT-avtaler er det tydeligste eksempelet: forordningen sier “i god tid”, mens det norske rundskrivet leser det som minst 30 dager. Ta med begge deler i rammeverket, og merk hva som er hva, for revisor spør hvor tallet kommer fra.

Skrevet med AI-assistanse, gjennomgått og redigert av Johan Vorgaard og redaksjonen i FM CyberSecurity.