DORA handler først og fremst om operasjonell motstandsdyktighet. Utfordringen er å omsette kravene knyttet til DORA, til konkrete tiltak og varige strukturer i virksomheten.
De fleste i finanssektoren kjenner nå DORA og hovedkravene i forordningen. DORA er allerede gjeldende, tilsyn er i gang, og virksomheter må kunne dokumentere at kravene er operasjonalisert. Spørsmålet er derfor hvordan man implementerer DORA på en måte som fungerer i praksis, på tvers av organisasjonen, og som kan vedlikeholdes over tid.
I det følgende ser vi nærmere på hvordan DORA kan implementeres steg for steg, med fokus på struktur, prioritering og praktisk gjennomføring.
Steg 1: Forankre arbeidet i ledelsen og organiser implementeringen
Start med å etablere styring før du etablerer detaljer. DORA er et ledelsesansvar, og implementeringen bør derfor formaliseres som et tverrfaglig initiativ, ikke et IT- eller compliance-løp isolert.
I praksis betyr det at ledelsen bør beslutte hvordan arbeidet organiseres, utpeke en ansvarlig for fremdrift, og etablere en fast arena der IT, risikostyring, compliance og relevante forretningsområder møtes jevnlig. Dette gir et felles bilde av hva som faktisk må endres, hvem som eier hvilke leveranser, og hvordan status skal rapporteres til styret.
Når implementeringen i første omgang havner hos IT eller compliance alene, oppstår ofte siloer og uklarhet. DORA berører både forretningsstrategi, leverandørstyring, risikostyring og ledelsesansvar, og krever derfor koordinert innsats på tvers av organisasjonen.
LES OGSÅ: Bryt ned siloarbejde i compliance
Steg 2: Gjennomfør en gap-analyse og gjør kravene om til en plan
Neste steg er å gjøre DORA håndterbart. I stedet for å lese forordningen lineært, bør virksomheten strukturere arbeidet rundt DORAs fem pilarer og bruke disse som ramme for en gap-analyse. Målet med dette er å avklare hva som allerede er på plass, hvor det finnes reelle mangler, og hvilke områder som krever oppdaterte prosesser eller dokumentasjon.
Deretter må funnene oversettes til en konkret implementeringsplan med tydelig eierskap og en gjennomførbar tidslinje. Erfaringene viser at når kravene brytes ned i konkrete aktiviteter med tydelig ansvar og fast oppfølging i styringsgruppen, blir implementeringen mer håndterbar. Det er også viktig å erkjenne at DORA inneholder funksjonskrav med rom for skjønn, for eksempel knyttet til vedlikehold og oppdatering av registre. I slike tilfeller bør man velge en praktisk tilnærming og dokumentere begrunnelsen, fremfor å bruke uforholdsmessig tid på å lete etter én riktig fasit.
Steg 3: Prioriter tredjepartsrisiko og kontrakter tidlig
Derfor bør dette komme tidlig, ikke på slutten. Start med å etablere en strukturert oversikt over leverandørlandskapet og de relevante IKT-arrangementene: hvilke IKT-leverandører dere har, hvilke tjenester de leverer, og hvilke forretningsprosesser og systemer de støtter. Det bør også tidlig vurderes om leverandøren har et gyldig LEI- eller EUID-nummer, ettersom dette er nødvendig for rapportering og registrering etter DORA. Dersom leverandøren ikke har slike identifikatorer og heller ikke kan fremskaffe dem, kan det i praksis innebære atvirksomheten i praksis ikke kan benytte leverandøren videre under DORA, og bør da vurdere behovet for en exitplan. Når oversikten er på plass, må dere identifisere hvilke leveranser som er kritiske eller viktige. Dette prioriteringsarbeidet gjør det mulig å bruke tid der risikoen er størst.
Som del av kartleggings- og vurderingsarbeidet kan virksomheten også benytte IKT due diligence-spørreskjemaer overfor leverandører. Slike spørreskjemaer kan brukes til å innhente strukturert informasjon om leverandørens evne til å oppfylle sentrale DORA-krav, blant annet knyttet til sikkerhet, hendelseshåndtering, underleverandører og operasjonell robusthet.
Deretter kan kontraktene gjennomgås systematisk opp mot DORAs minimumskrav. I praksis handler dette om å sikre at sentrale punkter faktisk er tydelige og dokumenterte i avtalene, som tjenestebeskrivelse, servicenivåer, bestemmelser om oppsigelse og exit, samt kontroll på underleverandører. Mange opplever at mye allerede finnes i kontraktene, men ikke nødvendigvis i en struktur og med en klarhet som gjør det enkelt å dokumentere etterlevelse. En gjennomgang bør derfor baseres på konkrete vurderinger per avtale, og dokumenteres slik at man kan vise hva som er vurdert, hva som må oppdateres, og hvilke tiltak som er gjennomført.
Steg 4: Bygg Register of Information som en del av normal drift
Register of Information er en konkret leveranse med høy detaljgrad. Implementeringen bør derfor handle like mye om prosess som om innhold. Et praktisk første steg er å avklare hvem som har ansvar for at registeret er komplett, oppdatert og rapporteringsklart. Deretter må dere etablere en rutine for hvordan nødvendige datapunkter samles inn, og hvordan endringer fanges opp når avtaler fornyes, leverandører byttes ut eller underleverandørkjeden endres.
Erfaringer fra virksomheter som allerede har rapportert, viser at det er krevende hvis registeret bygges ad hoc rett før fristen. Når det derimot bygges som en integrert del av kontrakts- og leverandørstyringen, blir det mulig å vedlikeholde registeret løpende og samtidig bruke det som styringsinformasjon. Riktig etablert gir registeret bedre oversikt over leverandøravhengigheter og konsentrasjonsrisiko, ikke bare et svar på et rapporteringskrav.
LES OGSÅ: DORA-informasjonsregister: krav, innhold og implementering
Steg 5: Etabler klare rutiner for hendelseshåndtering og rapportering
DORA stiller krav til håndtering og rapportering av alvorlige IKT-hendelser. Implementeringsmessig betyr det at dere må gjøre hendelsesprosessen beslutningsklar før en hendelse oppstår. Start med å definere kriterier for hva som regnes som en alvorlig hendelse i deres kontekst, og avklar eskaleringsløpet internt. Hvem vurderer alvorlighetsgrad, hvem informerer ledelsen, og hvem beslutter om rapportering til tilsynsmyndighetene? Ved å definere dette på forhånd skaper virksomheten forutsigbarhet i en presset situasjon og reduserer risikoen for feilvurderinger og forsinket rapportering.
Det er hensiktsmessig å teste prosessen gjennom scenarioøvelser. Målet er ikke å "øve for øvingens skyld", men å avdekke uklarheter i roller, beslutningslinjer og dokumentasjon. Når en hendelse faktisk oppstår, er det for sent å avklare ansvar og forventninger. En tydelig prosess reduserer usikkerhet internt og gjør det enklere å levere konsistent rapportering.
Steg 6: Gå fra prosjekt til varig struktur og vedlikehold
Til slutt må implementeringen gjøres varig. DORA er ikke et prosjekt med en klar sluttdato. Etter første rapportering eller første tilsyn starter den løpende forpliktelsen. Derfor bør dere integrere oppfølgingen i virksomhetens årshjul og styringsmodell. Det innebærer blant annet å planlegge faste tidspunkt for årlig gjennomgang av registeret, jevnlig kontraktsrevisjon og løpende rapportering av IKT-risiko til styret.
Vedlikehold er en avgjørende suksessfaktor i DORA-arbeidet. Leverandørlandskapet endrer seg, kontrakter fornyes og nye avhengigheter oppstår over tid. Uten en strukturert og planlagt vedlikeholdsprosess vil etterlevelsen gradvis svekkes, selv om implementeringen i utgangspunktet var grundig.
Struktur gir kontroll
Implementering av DORA handler i bunn og grunn om å etablere en gjennomførbar rekkefølge: forankre i ledelsen, kartlegge gap, prioritere tredjepartsrisiko, bygge registeret riktig, tydeliggjøre hendelsesprosesser og integrere alt i løpende drift. Når kravene oversettes til konkrete aktiviteter med tydelig eierskap og dokumenterte vurderinger, blir kompleksiteten håndterbar.
En strukturert implementering styrker ikke bare etterlevelsen. Den gir bedre oversikt over IKT-risiko, tydeligere kontroll over leverandøravhengigheter og større forutsigbarhet i beredskap. Med en trinnvis og praktisk tilnærming kan DORA bli en drivkraft for bedre styring og sterkere digital operasjonell motstandsdyktighet.
LES OGSÅ: Slik implementeres EUs direktiver og forordninger i Skandinavia
