DORA-software hjælper danske finansielle virksomheder med at opfylde kravene i DORA-forordningen (forordning (EU) 2022/2554) om digital operationel modstandsdygtighed, som har været i kraft siden den 17. januar 2025 og håndhæves af Finanstilsynet: styring af IKT-risici, håndtering og rapportering af IKT-hændelser, test af modstandsdygtighed, styring af tredjepartsrisici og deling af trusselsinformation. For en dansk bank, forsikringsselskab eller pensionskasse er det rigtige værktøj i 2026 en platform, der samler informationsregisteret over IKT-leverandører, dokumenterer risikostyringen og håndterer hændelsesrapportering til Finanstilsynet – til en årspris på typisk 50.000-300.000 kr. Denne guide gennemgår de danske krav, udvalgskriterierne og hvordan DORA-værktøjer adskiller sig fra NIS2- og GDPR-software.
DORA i Danmark: hvad gælder?
DORA er en forordning og gælder derfor umiddelbart i dansk ret uden national gennemførelse. I Danmark fører Finanstilsynet tilsynet under DORA som led i sit tilsyn med IKT- og datasikkerhed. Finanstilsynet igangsatte i efteråret 2025 de første temaundersøgelser, blandt andet af forsikringsselskabers og pensionskassers implementering.
Forordningen omfatter et bredt spektrum af finansielle virksomheder: kreditinstitutter (banker), betalingsinstitutter, e-pengeinstitutter, investeringsselskaber, forsikrings- og genforsikringsselskaber, pensionskasser, realkreditinstitutter, kryptoaktivtjenesteudbydere, benchmarkadministratorer og udbydere af crowdfundingtjenester. Proportionalitet gælder – mindre virksomheder har lempeligere krav – men grundpligterne rammer bredt.
DORA’s fem søjler
DORA er bygget op om fem søjler, som softwaren bør understøtte:
| Søjle | Indhold | Hvad værktøjet skal kunne |
|---|---|---|
| 1. IKT-risikostyring | Ramme for styring af IKT-risici | Risikoregister og kontroldokumentation |
| 2. Hændelsesrapportering | Klassifikation og rapportering af IKT-hændelser | Arbejdsflow med frister mod Finanstilsynet |
| 3. Modstandsdygtighedstest | Test, herunder trusselsbaseret TLPT | Testplan, resultater og opfølgning |
| 4. Tredjepartsrisiko | Styring af IKT-leverandører | Informationsregister over alle IKT-kontrakter |
| 5. Trusselsdeling | Frivillig deling af trusselsinformation | Struktureret registrering |
Informationsregisteret (søjle 4) er i praksis omdrejningspunktet. Alle finansielle virksomheder skal føre et komplet register over deres kontraktmæssige aftaler om IKT-tjenester og indberette det til Finanstilsynet i et fastlagt format. Et værktøj, der genererer og vedligeholder dette register, er det centrale i enhver DORA-platform.
Udvalgskriterier for danske finansielle virksomheder
- Informationsregister i korrekt format. Registeret skal indberettes til Finanstilsynet efter de europæiske tilsynsmyndigheders tekniske standarder. Manuel udfyldelse er tidskrævende og fejlbehæftet.
- Hændelsesrapportering med frister. DORA fastsætter frister for indberetning af større IKT-hændelser. Et arbejdsflow med fristovervågning er afgørende.
- Overlap med NIS2 og GDPR. IKT-risikostyringen overlapper både NIS2 og artikel 32 i databeskyttelsesforordningen. Et værktøj, der kobler dem sammen, reducerer dobbeltarbejde.
- Dansk output og EU-hosting. Dokumentationen læses af Finanstilsynet; data bør holdes i EU.
Softwarealternativer
For en dansk finansiel virksomhed, der allerede har et GDPR-program, er den mest omkostningseffektive vej ofte at udvide den eksisterende platform med DORA-funktioner frem for at købe et separat system. Sammenlign bredere i GDPR-software sammenligning, og se den overordnede danske ramme i DORA i Danmark.
Kostnad
En DORA-tilpasset platform koster typisk 50.000-300.000 kr. om året. Prisen afhænger af virksomhedens størrelse, antallet af IKT-leverandører og kompleksiteten i testkravene. Mindre virksomheder med lempeligere krav lander i den lave ende, mens store banker med omfattende leverandørkæder og TLPT-krav ligger højere. Se den generelle prisgennemgang for prismodeller; principperne gælder også DORA-værktøjer.
DORA-specifik eller integreret platform?
Det centrale valg for en dansk finansiel virksomhed er, om man skal købe et DORA-specifikt værktøj eller udvide en integreret compliance-platform. Et DORA-specifikt værktøj er skarpt på informationsregisteret og hændelsesrapporteringen, men efterlader NIS2- og GDPR-arbejdet i separate systemer. En integreret platform håndterer alle tre rammer, hvilket er en fordel, fordi de overlapper betydeligt, men kan være mindre dyb på DORA’s mest specialiserede krav som TLPT. For de fleste danske virksomheder – særligt mindre og mellemstore finansielle virksomheder med en overskuelig leverandørkæde – vejer fordelen ved at samle dokumentationen tungest, fordi den samme kontrol kan genbruges på tværs af DORA, NIS2 og GDPR. De største banker med komplekse testkrav kan derimod have behov for et specialiseret testværktøj ved siden af den integrerede platform. Afvej derfor jeres kompleksitet mod ønsket om ét samlet overblik, før I vælger.
Sådan kommer en dansk finansiel virksomhed i gang
En pragmatisk rækkefølge: (1) fastlæg hvilke af DORA’s krav der gælder for jer efter proportionalitetsprincippet, (2) kortlæg alle IKT-leverandører og opret informationsregisteret, (3) etabl er rammen for IKT-risikostyring og dokumentér kontrollerne, (4) opret arbejdsflowet for hændelsesrapportering med DORA’s frister, (5) planlæg og gennemfør modstandsdygtighedstest, herunder TLPT for de største aktører, og (6) samordn med jeres NIS2- og GDPR-dokumentation, hvor det er relevant. Informationsregisteret bør prioriteres først, fordi Finanstilsynet allerede indhenter det, og fordi resten af dokumentationen bygger på et overblik over leverandørerne.
Informationsregisteret: DORA’s omdrejningspunkt
Hvis man skal pege på ét dokument, der afgør DORA-efterlevelsen, er det informationsregisteret. Alle omfattede finansielle virksomheder skal føre et komplet register over deres kontraktmæssige aftaler om IKT-tjenester og indberette det til Finanstilsynet i et fastlagt format defineret af de europæiske tilsynsmyndigheders tekniske gennemførelsesstandarder. Registeret skal blandt andet indeholde oplysninger om hver IKT-leverandør, hvilke funktioner de understøtter, om funktionen er kritisk eller vigtig, hvor data behandles, og hvordan kontrakten kan opsiges. At udfylde og vedligeholde registeret manuelt i regneark er både tidskrævende og fejlbehæftet, fordi formatet er stramt og skal indberettes ensartet. Et værktøj, der genererer registeret i det korrekte format og holder det ajour, når leverandører skiftes ud, er derfor kernen i enhver seriøs DORA-platform. Registeret ligner på mange måder fortegnelsen efter GDPR’s artikel 30 – det er et levende register, der skal kunne fremvises struktureret ved et tilsyn.
Modstandsdygtighedstest og TLPT
DORA’s tredje søjle kræver regelmæssig test af den digitale operationelle modstandsdygtighed. For de fleste virksomheder betyder det sårbarhedsscanninger, penetrationstest og scenariebaserede øvelser. For de største og mest kritiske finansielle aktører kan Finanstilsynet desuden kræve trusselsbaseret penetrationstest (TLPT – threat-led penetration testing), der efterligner virkelige angriberes fremgangsmåde. Et DORA-værktøj bør understøtte planlægning af testene, registrering af resultaterne og opfølgning på de sårbarheder, der findes – ikke for at udføre selve testene, men for at dokumentere, at de gennemføres og følges op. Uden en struktureret ramme risikerer testene at blive engangsøvelser uden sporbar opfølgning, hvilket er præcis det, Finanstilsynet vil efterprøve.
DORA, NIS2 og GDPR: undgå tre parallelle systemer
Den største kilde til spild for danske finansielle virksomheder er at bygge tre adskilte compliance-systemer til DORA, NIS2 og GDPR. De tre regelsæt overlapper betydeligt: IKT-risikostyringen i DORA, sikkerhedsforanstaltningerne i NIS2 og artikel 32 i databeskyttelsesforordningen dækker langt hen ad vejen de samme kontroller. Styringen af IKT-leverandører under DORA ligner håndteringen af databehandlere under GDPR, og hændelsesrapporteringen under DORA minder om brudanmeldelsen under GDPR – blot til en anden myndighed og med andre frister. En platform, der samler disse overlappende krav ét sted, gør det muligt at dokumentere en kontrol én gang og genbruge den på tværs af rammerne. For en dansk finansiel virksomhed med et eksisterende GDPR-program er det både billigere og mere robust end tre parallelle systemer, der skal holdes synkroniseret manuelt.
Ofte stillede spørgsmål
Hvad koster DORA-software i Danmark?
Typisk 50.000-300.000 kr. om året afhængigt af virksomhedens størrelse og antal IKT-leverandører. For en virksomhed, der udvider en eksisterende GDPR- eller NIS2-platform med DORA-funktioner, bliver merprisen ofte lavere end for et selvstændigt DORA-system. Holdt op mod Finanstilsynets tilsyn og de påbud, manglende efterlevelse kan udløse, er investeringen beskeden.
Hvem er omfattet af DORA i Danmark?
Banker, betalings- og e-pengeinstitutter, investeringsselskaber, forsikrings- og genforsikringsselskaber, pensionskasser, realkreditinstitutter, kryptoaktivtjenesteudbydere og flere andre finansielle virksomheder under Finanstilsynets tilsyn. Proportionalitet gælder, men grundpligterne rammer bredt.
Er DORA og NIS2 det samme?
Nej. DORA er en forordning målrettet den finansielle sektor og går forud for NIS2 for de virksomheder, den omfatter (lex specialis). NIS2 er et direktiv, der dækker en bredere kreds af sektorer. En finansiel virksomhed skal primært følge DORA for IKT-risici, men kan være omfattet af begge for forskellige aktiviteter. Se NIS2-software for den bredere ramme.
Konklusion
DORA stiller ensartede krav til digital operationel modstandsdygtighed i den danske finansielle sektor, håndhævet af Finanstilsynet, der allerede er begyndt at føre tilsyn. Den rigtige software samler informationsregisteret over IKT-leverandører, håndterer hændelsesrapporteringen inden for fristerne og dokumenterer risikostyringen og testene – helst integreret med eksisterende GDPR- og NIS2-dokumentation for at undgå dobbeltarbejde. Start med informationsregisteret, forankr risikostyringen hos ledelsen, og vælg en EU-baseret platform med dansk output, der gør DORA-dokumentationen til et levende værktøj frem for et engangsprojekt.