DORA (Digital Operational Resilience Act) er EU’s forsøg på at få finanssektoren til at være lige så robust digitalt, som den er god til at være kompleks på papir. Reglerne gælder bredt for finansielle virksomheder og stiller konkrete krav til, hvordan I styrer ICT-risiko, tredjepartsleverandører og håndtering/rapportering af hændelser. DORA trådte i kraft i 2023 og anvendes fra 17. januar 2025.
Denne artikel giver dig en praktisk måde at arbejde med DORA på, uden at det ender som “vi lavede en PowerPoint og kaldte det governance”.
Hvad DORA kræver i praksis
DORA kan koges ned til fem områder (som hænger sammen i virkeligheden, selvom de ofte splittes op internt):
- ICT risk management: governance, kontroller, sikkerhed, beredskab, recovery
- Incident management og rapportering: proces, klassificering, dokumentation, indberetning
- Operational resilience testing: test, øvelser, læring (fx scenarier, tabletop, penetrationstest afhængig af krav)
- ICT third-party risk management: due diligence, kontrakter, løbende kontrol, exit
- Oversight af kritiske ICT-leverandører: myndigheder kan udpege kritiske leverandører og føre tilsyn (på EU-niveau)
I denne guide fokuserer vi på de tre ting, der oftest vælter projekter: ICT-risk, tredjepart og incidents.
Del 1: ICT-risk som en styringsdisciplin (ikke et regneark)
DORA forventer, at ICT-risk er forankret i ledelse og drift, ikke kun i IT-sikkerhed. Det betyder typisk:
1) Et tydeligt risikobillede
- Hvilke systemer, tjenester og data er kritiske?
- Hvilke forretningsprocesser afhænger af dem?
- Hvad er “kritiske eller vigtige funktioner” (CIF) hos jer?
Leverance (praktisk):
En simpel “kritikalitetsmatrix” (system → proces → afhængigheder → RTO/RPO → ejer).
2) Kontroller med ejerskab
Det er ikke nok at have policies. DORA handler om at kunne dokumentere, at kontroller faktisk virker.
Minimum du bør have på plads:
- adgangsstyring (roller, MFA, privilegerede konti)
- patch- og sårbarhedsstyring
- logging/monitorering og alarmer
- backup, recovery og restore-tests
- ændringsstyring (change mgmt)
- leverandørkontroller (se næste afsnit)
Tip: Sæt én ejer pr. kontrolområde og gør status målbar (fx “restore-test gennemført kvartalsvist”).
Del 2: Tredjepartsstyring under DORA (leverandører er ikke “nogen andres problem”)
DORA kræver, at I styrer ICT-tredjepartsrisiko som en integreret del af jeres ICT-risikostyring.
Det betyder ikke “vi har en leverandørliste”. Det betyder lifecycle-styring.
Trin A: Segmentér leverandører efter risiko
Start med at kategorisere leverandører efter:
- om de leverer ICT-services
- om de understøtter kritiske/vigtige funktioner
- datafølsomhed (persondata, finansielle data, nøgledata)
- koncentrationsrisiko (én leverandør, mange systemer)
- substituerbarhed (hvor svært er det at skifte)
Leverance:
Et enkelt scorecard der ender med 3 niveauer: Lav / Medium / Høj (eller CIF / Non-CIF).
Trin B: Due diligence før kontrakt
For højrisiko-leverandører bør due diligence mindst dække:
- sikkerhedsstandarder og kontroller (fx ISO 27001, SOC2-rapport, eller tilsvarende evidens)
- hændelseshåndtering (hvordan de opdager, eskalerer og informerer)
- underleverandører (sub-outsourcing) og kontrolkæde
- drift/availability (SLA, redundans, backup)
- datahåndtering (placering, adgang, kryptering)
- exitmuligheder (plan B, dataudlevering, overgang)
Det her er også stedet, hvor I beslutter: “Kan vi leve med risikoen, hvis de fejler?”
Trin C: Kontraktkrav der faktisk beskytter jer
DORA stiller krav til, hvad kontrakter med ICT-leverandører skal indeholde, især når de understøtter kritiske/vigtige funktioner. En central pointe er adgang til audit/inspektion og klare rammer for underleverandører, sikkerhed, hændelser og exit.
Tjekliste til kontrakt (praktisk):
- Scope: præcis beskrivelse af service og hvilke systemer/processer den påvirker
- SLA/KPI: oppetid, svartider, supportvinduer, eskalationsniveauer
- Security requirements: minimumskrav, ændringer, patching, logging, kryptering
- Incident notification: hvornår og hvordan I informeres, inkl. data til jeres rapportering
- Audit/inspection rights: jeres ret (og evt. myndigheders) til audit/inspektion
- Sub-outsourcing: krav om godkendelse/indsigt og flow-down krav
- Data: ejerskab, adgang, lokation, sletning, udlevering ved exit
- Exit strategy: tid, format, støtte til migration, og hvad der sker ved force majeure/konkurs
Målet: Når en leverandør fejler, skal I ikke stå med en kontrakt, der kun er god til at beskrive fakturaen.
Trin D: Register of Information (RoI)
DORA kræver, at I vedligeholder et register over kontraktuelle arrangementer vedrørende ICT-services fra tredjepartsleverandører. Det er ikke bare dokumentation for dokumentationens skyld. Det skal støtte både jeres egen styring og myndighedernes overblik.
Praktisk indhold (minimalt):
- leverandør, service, start/slut, ansvarlig ejer
- hvilke systemer/processer påvirkes
- kritikalitet (CIF ja/nej)
- data- og lokationsoplysninger
- underleverandører (hvis relevant)
- centrale kontraktvilkår (SLA, audit, incident, exit)
Hvis I vil have en samlet oversigt over hvad “DORA-krav for leverandører” typisk betyder i praksis, kan I tage udgangspunkt i denne ressource: DORA krav for leverandører
Del 3: Incident management og rapportering (så det ikke bliver kaos med billet-system og panik)
DORA forpligter finansielle enheder til at rapportere major ICT-related incidents (og i nogle tilfælde “significant cyber threats”) til relevante myndigheder, efter gældende kriterier og tærskler.
Det kræver, at I har en end-to-end proces, der kan:
- opdage og triagere
- klassificere (major eller ej)
- eskalere og mobilisere
- dokumentere og lære
- rapportere indenfor gældende frister og med rette data
1) Byg en enkel incident playbook
Minimum i playbook:
- definitioner (incident, major, near miss)
- roller (Incident Manager, IT Lead, Security Lead, Business Owner, Comms)
- eskalationskriterier (impact, varighed, data, kritiske funktioner)
- kommunikationsplan (intern, kunde, partner, myndighed)
- logging-krav (hvad dokumenteres fra minut 0)
2) Klassificering: gør det mekanisk
Hvis klassificering bliver en diskussion hver gang, taber I tid.
Brug faste parametre:
- påvirkning på kritiske/vigtige funktioner
- antal brugere/kunder påvirket
- varighed og geografisk spredning
- datatab eller kompromittering
- økonomisk og operationel påvirkning
3) Rapportering: gør datagrundlaget klar på forhånd
DORA-rapportering bruger standardiserede skabeloner i flere EU-lande/tilsyn, så sørg for at kunne udfylde de typiske felter hurtigt: tidslinje, påvirkning, root cause (foreløbig), containment, recovery, og lessons learned.
Praktisk tip:
Lav en “incident data sheet” som auto-udfyldes så vidt muligt fra jeres ITSM/SIEM (tidspunkter, systemnavne, tickets, owners).
Sådan implementerer du det uden at drukne (en realistisk 30-60-90 plan)
0–30 dage: få fundamentet på plads
- Definér kritiske funktioner og afhængigheder
- Lav leverandørsegmentering (Lav/Medium/Høj + CIF)
- Etablér incident playbook v1 og eskalationskæde
- Start register of information (selv som MVP)
31–60 dage: luk de største huller
- Opgrader kontrakter for højrisiko/CIF-leverandører (audit, incident, exit, sub-outsourcing)
- Fastlæg KPI’er/SLA’er og hvordan de måles
- Gennemfør 1 tabletop-øvelse (incident + leverandørsvigt)
61–90 dage: gør det driftbart
- Indfør kvartalsvis leverandørreview for højrisiko
- Restore-test og logging/monitorering valideres
- Incident-dokumentation standardiseres, så rapportering bliver rutine, ikke improvisation
Tjekliste: “er vi nogenlunde DORA-klar på leverandører og ICT?”
Brug den her som hurtig status:
Governance & ICT-risk
- Kritiske funktioner og ICT-afhængigheder er kortlagt
- Kontroller har ejere og måles løbende
- Backup/restore testes og dokumenteres
Tredjepartsstyring
- Leverandører er segmenteret efter risiko og CIF
- Due diligence er standardiseret for højrisiko
- Kontrakter indeholder audit/incident/sub-outsourcing/exit elementer
- Register of Information er oprettet og holdes opdateret
Incident management
- Playbook og roller er på plads
- Klassificering kan ske hurtigt og ensartet
- Datagrundlag til rapportering er klar (templates/fields)
FAQ
Gælder DORA kun banker?
Nej, DORA omfatter mange typer finansielle enheder og rammer bredt i sektoren, samt lægger rammer for oversight af kritiske ICT-leverandører.
Skal alle leverandører have samme krav i kontrakten?
Nej. Kravene bør være risikobaserede. Højrisiko og leverandører der understøtter kritiske/vigtige funktioner kræver typisk skærpede kontraktvilkår og tættere kontrol.
Hvad er “Register of Information”, og hvorfor er det vigtigt?
Det er et register over jeres kontraktuelle arrangementer med ICT-leverandører, som hjælper jer med at styre tredjepartsrisiko og giver myndighederne overblik.
Hvordan undgår vi, at incident-rapportering bliver et kaosprojekt?
Gør klassificering mekanisk, lav en playbook, og sørg for at incident-data (tidslinje, systemer, impact) kan hentes hurtigt og ensartet. Myndigheder forventer rapportering, når kriterier/tærskler er opfyldt.
Konklusion
DORA er i bund og grund en modenhedsopgave: I skal kunne styre ICT-risiko end-to-end, også når den risiko kommer via leverandører, og også når tingene går galt. Den bedste måde at lykkes på er at gøre det praktisk:
- kortlæg kritiske afhængigheder
- segmentér leverandører og stram kontrakter dér hvor det betyder noget
- hold et opdateret register over ICT-kontrakter
- træn incident-processen, så rapportering bliver en kontrolleret proces
Så bliver DORA ikke “endnu et compliance-projekt”, men en måde at undgå, at jeres drift vælter, når virkeligheden gør sit.
Leave a Reply