DORA-beredskapsplaner for norske finansforetak

Slik ser DORA på IKT-beredskap: hvilke dokumenter som må finnes, hvilke av dem som må testes, og hvem som skriver under.

DORA har hatt virkning i EU siden 17. januar 2025 (forordning (EU) 2022/2554, artikkel 64). Norge kom med gjennom EØS. Finanstilsynet skriver at DORA ble innlemmet i EØS-avtalen 20. februar 2025, og at både DORA-loven og DORA-forskriften trådte i kraft 1. juli 2025. Fra samme dato gikk de fleste foretakene under tilsyn ut av IKT-forskriften og inn under DORA.

Beredskapen er der den gamle permen og det nye regelverket skiller lag. En kontinuitetsplan skrevet før DORA modellerer gjerne bortfall i datasenteret og et strømbrudd. DORA spør hva som skjer hvis kjernebankleverandøren går konkurs, om fjorårets test hadde et scenario med cyberangrep, og hvilket styremøte som godkjente den versjonen dere sitter med.

1. Avklar hvilket regime dere er i før dere skriver en linje

DORA har to regimer for beredskapsarbeidet: det fulle IKT-risikorammeverket, og et forenklet rammeverk for en avgrenset gruppe mindre foretak (artikkel 16).

Skriv ned hvilket av dem foretaket hører til, og navngi hjemmelen dere lener dere på. Finanstilsynets Q&A om DORA peker på at mindre foretak, mikroforetak blant dem, er unntatt fra flere av kravene. Et mikroforetak har under 10 ansatte og en omsetning eller balanse på 2 millioner euro eller mindre (artikkel 3 nr. 60). Har dere ikke kartlagt virkeområdet ennå, start med DORA-sjekklisten for finansforetak og kom tilbake hit.

2. Start med virkningsanalysen, ikke med planen

Virkningsanalysen er inngangsdata til alle de andre beredskapsdokumentene, ikke et vedlegg til dem (artikkel 11 nr. 5).

Sett opp listen over kritiske eller viktige funksjoner. For hver funksjon setter dere et gjenopprettingstidsmål (RTO) og et gjenopprettingspunktmål (RPO), og knytter begge til hvordan avbruddet slår ut for kundene og for markedet (artikkel 12 nr. 6). Deretter noterer dere hvilke IKT-ressurser som bærer funksjonen, og hvilke av dem som ligger hos en tredjepart. Analysen skal bruke både kvantitative og kvalitative kriterier og se på alvorlige avbruddsscenarioer, så en enkelt oppetidsprosent holder ikke.

3. Skriv IKT-kontinuitetspolicyen som et eget dokument

DORA peker ut IKT-kontinuitetspolicyen som en egen leveranse inne i IKT-risikorammeverket (artikkel 11 nr. 1).

Delegert forordning (EU) 2024/1774 sier hva policyen skal inneholde: mål hentet fra virkningsanalysen, virkeområde og tidsrammer, kriterier for å aktivere og deaktivere planene, roller i gjennomføringen, hvordan IKT-delen henger sammen med den øvrige kontinuitetsplanleggingen, rekkefølgen gjenopprettingen skjer i, og koblingen til krisekommunikasjon (artikkel 24). Samme artikkel gir sentrale motparter og verdipapirsentraler et hardt tak: kritiske funksjoner skal være tilbake innen to timer. Handelsplasser skal gjenoppta handelen innen eller nær to timer.

4. Bygg respons- og gjenopprettingsplanene rundt en navngitt scenarioliste

Respons- og gjenopprettingsplanene skal skrives mot konkrete avbruddsscenarioer, ikke mot et generelt driftsavbrudd (delegert forordning (EU) 2024/1774, artikkel 26).

Listen er satt opp for dere: cyberangrep og omlegging mellom primær infrastruktur og reservekapasitet, svikt hos en IKT-tredjepartsleverandør, konkurs inkludert, tap av lokaler eller datasenter, svikt i IKT-ressursene en kritisk funksjon hviler på, bortfall av personell, natur- og klimahendelser, innsideangrep, politisk ustabilitet og omfattende strømbrudd. Hver plan sier når den aktiveres og deaktiveres, hvilke tiltak som verner tilgjengelighet og integritet, hvilke gjenopprettingsvalg dere har på kort og lang sikt, og hva som teller som vellykket. Sett navn på rollene i dokumentet, og hold en kopi lesbar når nettet er nede. For alle foretak utenom mikroforetak skal respons- og gjenopprettingsplanene gjennom en uavhengig internrevisjon (artikkel 11 nr. 3).

5. Få planene godkjent i styret, og før neste gjennomgang inn i protokollen

Styret skal godkjenne, følge opp og jevnlig gjennomgå IKT-kontinuitetspolicyen og respons- og gjenopprettingsplanene (artikkel 5 nr. 2).

Her hjelper det ikke å delegere. I DORA-gjennomgangene jeg har sittet i, er avviket som går igjen på denne artikkelen en plan signert av sikkerhetslederen alene. IKT-risikorammeverket skal gjennomgås minst en gang i året, og dessuten etter alvorlige IKT-hendelser, etter pålegg fra tilsynet og etter konklusjoner fra testing eller revisjon (artikkel 6 nr. 5). Protokollfør dato, versjonsnummer og vedtak. Protokollen er beviset.

6. Test minst en gang i året, og la testen svikte

Beredskapsplanene skal testes minst en gang i året, og på nytt ved større endringer i IKT-systemene som understøtter kritiske eller viktige funksjoner (artikkel 11 nr. 6).

For alle andre enn mikroforetak skal årstesten inneholde et scenario med cyberangrep og en omlegging fra primær infrastruktur til reservekapasitet, sikkerhetskopier og reserveanlegg. Den delegerte forordningen strammer til: alvorlige, men troverdige scenarioer, svikt hos en IKT-tredjepart, og en reell utfordring av antakelsene i planen, styringen og krisekommunikasjonen inkludert (artikkel 25). Rutinene for sikkerhetskopiering og gjenoppretting testes jevnlig for seg (artikkel 12 nr. 2), og gjenoppretting av data skjer på systemer som er fysisk og logisk atskilt fra kildesystemet (artikkel 12 nr. 3). Dokumenter resultatene, avvikene og planen for å lukke dem, og ta alle tre til styret. Testprogrammet for digital robusthet er for øvrig bredere enn beredskapstestene alene, og gjentakende penetrasjonstesting hører til det samme kapittelet i DORA.

7. Ta vare på sporene som viser at planen ble brukt

Når en beredskapsplan aktiveres, skal dere ha lett tilgjengelige spor over aktiviteter før og under avbruddet (artikkel 11 nr. 8).

Tre plikter til henger på den samme bunken. Foretak utenom mikroforetak setter opp en krisehåndteringsfunksjon med skrevne rutiner for intern og ekstern kommunikasjon (artikkel 11 nr. 7), og minst en person får ansvaret for å gjennomføre kommunikasjonsstrategien ved IKT-hendelser (artikkel 14 nr. 3). Etter en alvorlig hendelse gjør dere en gjennomgang i etterkant og rapporterer funnene til styret (artikkel 13 nr. 2). Og på forespørsel skal foretak utenom mikroforetak gi tilsynet et anslag over samlede årlige kostnader og tap fra alvorlige IKT-hendelser (artikkel 11 nr. 10). Lager en overvåkingstjeneste tidslinjen deres, så skriv det inn i planen. Det er den tidslinjen MDR-kundene våre legger på bordet hos revisor.

Dette mangler de fleste beredskapsplaner fra før DORA

Fem hull går igjen når en perm skrevet før juli 2025 leses mot DORA:

• Ingen navngitt tredjepartssvikt. Datasenteret er med, leverandørkonkurs er nesten aldri med.
• Ingen cyberangrep i årstesten, og ingen omlegging til reservekapasitet.
• En gjenopprettingsrutine som skriver tilbake på kildesystemet i stedet for på atskilte systemer.
• Gjenopprettingstider satt for infrastrukturen, ikke for de kritiske eller viktige funksjonene foretaket lever av.
• Godkjenning fra IT i stedet for fra styret, uten en datert gjennomgangssyklus bak seg.

Er dokumentasjonen bygget for ISO 27001, tar dere med dere det meste av strukturen. Tiltak 5.29 og 5.30 i vedlegg A dekker allerede informasjonssikkerhet under avbrudd og IKT-beredskap for kontinuitet, og ISO 27001-sjekklisten for SMB går gjennom den delen. Det ISO 27001 ikke gir dere, er scenariolisten, gulvet på en test i året og sporet etter styrebehandlingen. Der ligger DORA-tilleggene. Faller foretaket utenfor DORA, men leverer en samfunnsviktig tjeneste, finner dere de tilsvarende pliktene i digitalsikkerhetsloven.

Driftsstabiliteten i norsk finans holdt seg i fjor. Finanstilsynets ROS-analyse for 2026 slår fast at driftsstabiliteten og tilgjengeligheten til betalingstjenester i 2025 var tilfredsstillende, mens det digitale trusselnivået vurderes som høyt. Planene blir prøvd av tilsynet lenge før de blir prøvd av en hendelse.

Neste steg

Hent fram testrapporten fra i fjor og les den mot artikkel 11 nr. 6 i DORA. Mangler den et scenario med cyberangrep og en omlegging til reservekapasitet, har dere det første avviket, og dere har det før tilsynet. Send Johan Vorgaard en melding, eller se hvordan compliance-teamet vårt jobber, så leser vi kontinuitetspolicyen og respons- og gjenopprettingsplanene sammen med dere før de går til styret.

FAQ

Hvor ofte krever DORA at vi tester beredskapsplanene?

Minst en gang i året, og på nytt ved større endringer i IKT-systemene som understøtter kritiske eller viktige funksjoner (artikkel 11 nr. 6). Rutinene for sikkerhetskopiering og gjenoppretting testes jevnlig for seg (artikkel 12 nr. 2). Er dere ikke et mikroforetak, skal årstesten inneholde et scenario med cyberangrep og en omlegging til reservekapasitet og sikkerhetskopier.

Må styret godkjenne selve planene, eller holder det med policyen?

Begge deler. Styret skal godkjenne, følge opp og jevnlig gjennomgå både IKT-kontinuitetspolicyen og respons- og gjenopprettingsplanene (artikkel 5 nr. 2). Å godkjenne policyen og overlate planene til IT treffer ikke ordlyden. Protokollfør godkjenningen med versjonsnummer og dato.

Vi har allerede en konsernberedskapsplan. Trenger vi en egen for IKT?

Dere trenger IKT-beredskap som står på egne bein mot DORA, og forordningen åpner for at den ligger som en egen del av den samlede kontinuitetsplanleggingen. Poenget er at IKT-innholdet finnes og kan spores: virkningsanalysen, scenariolisten, aktiveringskriteriene, gjenopprettingsmålene og testloggen. En konsernplan som nevner IT i ett avsnitt, går ikke gjennom en tilsynsgjennomgang.

Gjelder DORA i Norge, og fra når?

Ja for de fleste foretak under Finanstilsynets tilsyn. DORA fikk virkning i EU fra 17. januar 2025, ble innlemmet i EØS-avtalen 20. februar 2025, og DORA-loven og DORA-forskriften trådte i kraft 1. juli 2025. Sjekk deres eget virkeområde mot artikkel 2 i forordningen, og skriv konklusjonen ned.

Hva endrer seg hvis vi bruker det forenklede rammeverket?

Mindre dybde, ikke færre dokumenter. Foretak på det forenklede rammeverket skal fortsatt ha en IKT-kontinuitetsplan bygget på en analyse av alvorlige avbrudd, godkjent av styret, dokumentert og tilgjengelig i en krisesituasjon, med gjenopprettingsfrister, aktiveringskriterier, sikkerhetskopiering og kommunikasjonsrutiner (delegert forordning (EU) 2024/1774, artikkel 39). Navngi hjemmelen dere lener dere på, så slipper dere å ta diskusjonen på nytt hver tilsynssyklus.

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