DORA – forordningen om digital operationel modstandsdygtighed (forordning (EU) 2022/2554) – har været i kraft siden den 17. januar 2025 og gælder umiddelbart i dansk ret uden national gennemførelse. I Danmark fører Finanstilsynet tilsynet som led i sit tilsyn med IKT- og datasikkerhed, og myndigheden igangsatte i efteråret 2025 de første temaundersøgelser af blandt andet forsikringsselskabers og pensionskassers implementering. DORA pålægger banker, forsikringsselskaber, pensionskasser og andre finansielle virksomheder krav om styring af IKT-risici, rapportering af IKT-hændelser, test af modstandsdygtighed og styring af tredjepartsleverandører. Denne guide gennemgår, hvem der er omfattet, de fem søjler, informationsregisteret og hvordan Finanstilsynet fører tilsyn.
Hvad er DORA, og hvorfor gælder den direkte?
DORA er en forordning, ikke et direktiv. Det betyder, at den gælder umiddelbart i alle EU-lande uden national gennemførelseslov – til forskel fra NIS2, der er et direktiv og skal gennemføres i dansk lov. For finansielle virksomheder går DORA forud for NIS2 for så vidt angår IKT-risici (lex specialis). Formålet er at skabe ensartede krav til, hvordan den finansielle sektor håndterer digitale risici, så et IKT-nedbrud eller cyberangreb ikke destabiliserer det finansielle system.
Hvem er omfattet af DORA i Danmark?
DORA omfatter et bredt spektrum af finansielle virksomheder under Finanstilsynets tilsyn:
- Kreditinstitutter (banker)
- Betalingsinstitutter og e-pengeinstitutter
- Investeringsselskaber
- Forsikrings- og genforsikringsselskaber
- Firmapensionskasser
- Realkreditinstitutter
- Kryptoaktivtjenesteudbydere
- Benchmarkadministratorer og udbydere af crowdfundingtjenester
Proportionalitetsprincippet gælder: mindre og mindre komplekse virksomheder har lempeligere krav, blandt andet en forenklet ramme for IKT-risikostyring. Men grundpligterne – herunder informationsregisteret – rammer bredt.
DORA’s fem søjler
Når testplanen omfatter en almindelig penetrationstest, skal scope og opfølgning aftales. Den praktiske indkøbsrutine kan støtte dette arbejde; en sådan test opfylder ikke i sig selv DORA-reglerne om TLPT.
| Søjle | Indhold |
|---|---|
| 1. IKT-risikostyring | Ramme for at identificere, beskytte, opdage og reagere på IKT-risici |
| 2. Hændelsesrapportering | Klassifikation og rapportering af større IKT-hændelser til Finanstilsynet |
| 3. Modstandsdygtighedstest | Test af systemer, herunder trusselsbaseret TLPT for de største aktører |
| 4. Tredjepartsrisiko | Styring af IKT-leverandører og et komplet informationsregister |
| 5. Trusselsdeling | Frivillig deling af trusselsinformation mellem finansielle virksomheder |
For internetvendte tjenester kan kontrol af TLS og certifikatfornyelse være et konkret punkt i den løbende tekniske kontrol. Registrer, hvilke forbindelser der er undersøgt, og hvem der følger op på udløb og fejl.
Den fjerde søjle er i praksis omdrejningspunktet. Alle omfattede virksomheder skal føre et informationsregister over deres kontraktmæssige aftaler om IKT-tjenester og indberette det til Finanstilsynet i et fastlagt format efter de europæiske tilsynsmyndigheders tekniske standarder.
Finanstilsynets rolle og de første tilsyn
Finanstilsynet er den kompetente myndighed for DORA i Danmark. Tilsynet indgår i myndighedens bredere tilsyn med IKT- og datasikkerhed i den finansielle sektor. I efteråret 2025 igangsatte Finanstilsynet de første temaundersøgelser, blandt andet af, hvordan forsikringsselskaber og pensionskasser har implementeret forordningen. For de største og mest kritiske aktører kan Finanstilsynet desuden kræve trusselsbaseret penetrationstest (TLPT). Virksomheder bør forvente, at informationsregisteret er det første, Finanstilsynet efterspørger – på linje med, at fortegnelsen er det første, Datatilsynet beder om i en GDPR-sag.
Frister for hændelsesrapportering
Anden søjle – hændelsesrapporteringen – har konkrete frister, som en dansk finansiel virksomhed skal indarbejde i sin beredskabsplan. Når en IKT-hændelse klassificeres som større efter DORA’s kriterier (blandt andet antal berørte kunder, varighed, geografisk udbredelse og datatab), gælder et rapporteringsforløb i tre trin til Finanstilsynet:
- Indledende underretning: senest 4 timer efter, at hændelsen er klassificeret som større, og under alle omstændigheder senest 24 timer efter, at virksomheden blev opmærksom på hændelsen.
- Mellemliggende rapport: senest 72 timer efter den indledende underretning, med opdateret status og foreløbig årsagsvurdering.
- Endelig rapport: senest én måned efter den mellemliggende rapport eller den seneste opdatering af den, hvis en sådan er indsendt, med rodårsagsanalyse og afhjælpende foranstaltninger.
Fristerne er kortere og mere formaliserede end den 72-timers frist, mange kender fra brudanmeldelsen under GDPR. Kravene til klassifikation og indhold følger af de europæiske tilsynsmyndigheders tekniske standarder (EBA’s DORA-side). En virksomhed bør have forud-definerede kriterier og et fast rapporteringsformat klar, så uret ikke først begynder at tælle, mens man diskuterer, om en hændelse overhovedet er større.
DORA’s overlap med NIS2 og GDPR
DORA står sjældent alene. IKT-risikostyringen overlapper både NIS2 og artikel 32 i databeskyttelsesforordningen. Styringen af IKT-leverandører ligner desuden håndteringen af databehandlere efter artikel 28. En dansk finansiel virksomhed, der allerede har et GDPR-program, kan derfor genbruge meget af risikostyringen og leverandørkontrollen. En fælles evidensliste for leverandører og sikkerhedskontroller kan reducere dobbeltarbejde mellem regelsættene; ansvaret for hver vurdering skal stadig være tydeligt. Se den praktiske værktøjsgennemgang i bedste DORA-software.
Sådan kommer en dansk finansiel virksomhed i gang
En pragmatisk rækkefølge: (1) afklar hvilke af DORA’s krav der gælder for jer efter proportionalitetsprincippet, (2) kortlæg alle IKT-leverandører og opret informationsregisteret i det korrekte format, (3) etabler 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, og (6) samordn med jeres NIS2- og GDPR-dokumentation. Informationsregisteret bør prioriteres først, fordi Finanstilsynet allerede indhenter det, og fordi resten af dokumentationen bygger på et overblik over leverandørerne.
Proportionalitet: hvad gælder for mindre finansielle virksomheder?
DORA anvender et proportionalitetsprincip, så kravene står i forhold til virksomhedens størrelse, risikoprofil og kompleksitet. Mindre og ikke-komplekse finansielle virksomheder – for eksempel mindre betalingsinstitutter eller mindre pensionskasser – kan anvende en forenklet ramme for IKT-risikostyring og er ikke underlagt de mest omfattende testkrav som TLPT. Men proportionalitet betyder ikke fritagelse: også mindre virksomheder skal føre informationsregisteret, klassificere og rapportere IKT-hændelser og dokumentere deres risikostyring. For en dansk virksomhed i den lette ende betyder det, at ambitionsniveauet kan tilpasses, men grundpligterne skal opfyldes. Den valgte dokumentationsform bør kunne tilpasses, hvis virksomheden ekspanderer eller ændrer risikoprofil. Finanstilsynet forventer, at den enkelte virksomhed selv kan begrunde, hvorfor den har valgt et bestemt niveau – og den begrundelse bør dokumenteres.
Kritiske IKT-tredjepartsleverandører
En central nyskabelse i DORA er tilsynet med de største IKT-leverandører til den finansielle sektor. Udbydere, der udpeges som kritiske IKT-tredjepartsleverandører – typisk store cloud- og infrastrukturudbydere, som mange finansielle virksomheder er afhængige af – kommer under et fælleseuropæisk tilsyn ført af de europæiske tilsynsmyndigheder. For en dansk finansiel virksomhed betyder det, at ansvaret for leverandørrisiko ikke forsvinder, selvom en leverandør er stor og velkendt: virksomheden skal fortsat dokumentere afhængigheden i informationsregisteret, vurdere koncentrationsrisikoen ved at samle mange funktioner hos én leverandør og sikre exit-strategier. En opdateret kobling mellem leverandører og kritiske funktioner gør vurderingen efterprøvbar.
DORA i praksis: hvad Finanstilsynet vil se
Når Finanstilsynet fører tilsyn, vil myndigheden forvente at kunne se en sammenhængende dokumentation: et komplet informationsregister, en dokumenteret ramme for IKT-risikostyring godkendt af ledelsen, en klassificerings- og rapporteringsproces for IKT-hændelser med de rigtige frister, og resultater fra modstandsdygtighedstest med opfølgning. Ligesom en fortegnelse er udgangspunktet for et GDPR-tilsyn, er informationsregisteret udgangspunktet for et DORA-tilsyn. Hændelsesrapporteringen under DORA minder om brudanmeldelsen under GDPR – blot til Finanstilsynet og med DORA’s egne frister og klassifikationskriterier. En finansiel virksomhed, der allerede har opbygget disse processer under GDPR, kan genbruge strukturen, men skal tilpasse den til DORA’s specifikke krav og modtager. Genbrug derfor faktagrundlaget, men behold særskilte vurderinger og frister for hvert regelsæt.
Byg informationsregisteret ud fra kontrakterne
Registeret over IKT-tredjepartsaftaler er mere end en leverandørliste. For hver aftale skal virksomheden kunne forbinde leverandør, den leverede IKT-tjeneste, den modtagende enhed, den understøttede funktion og aftalens væsentlige vilkår. Flere juridiske enheder kan bruge samme leverandør til forskellige funktioner; omvendt kan en kritisk funktion bygge på flere underleverandører. Hvis man kun indsamler navnet på fakturamodtageren, kan registeret ikke vise koncentrationsrisiko eller afhængighed. De europæiske tilsynsmyndigheders skabeloner angiver de felter, der skal indberettes, og de bør styre dataindsamlingen fra starten.
Begynd med indkøbs- og kontraktarkiv, men afstem derefter med økonomi, drift og systemejere. Skygge-IT, gratis værktøjer og aftaler indgået af et datterselskab vil ellers blive overset. Bed hver funktionsejer bekræfte, hvilken tjeneste der understøttes, om funktionen er kritisk eller vigtig, hvilke data og miljøer leverandøren kan tilgå, og om der findes en brugbar alternativ leverandør. Dokumentér beslutningen om kritikalitet; det er ikke en egenskab, der kan udledes alene af leverandørens størrelse. Registrer ændringer ved fornyelse, opkøb, ændret hosting eller nedlukning, ikke kun ved den årlige indberetning.
Finanstilsynets vejledning om e-Reg beskriver, at DORA-informationsregisteret indberettes gennem systemet. Det er et godt eksempel på forskellen mellem den løbende interne registrering og den formelle indberetning. Virksomheden bør kontrollere den aktuelle kalender og formatkrav direkte hos myndigheden; en historisk dato i en artikel er ikke en aktiv indberetningsfrist. Når data valideres, skal fejl føres tilbage til den kontrakt- eller funktionsansvarlige, så registeret også bliver rigtigt i driften.
Fra større IKT-hændelse til tre brugbare rapporter
En hændelsesprocedure bør begynde før klassifikationen er endelig. Vagtfunktionen registrerer tidspunkt for første observation, berørte systemer, påvirkede kunder og transaktioner, varighed samt mulige grænseoverskridende følger. Den ansvarlige for hændelsen bruger vejledningen om sikkerhedslogning til at bevare tidslinjen og dokumenterer derefter, hvordan kriterierne for en større IKT-hændelse er vurderet, og hvornår klassifikationen blev truffet. Delegeringen af opgaver skal være klar, hvis juridisk afdeling, IT-ledelse eller presseansvarlig er utilgængelig. At vente på en fuld rodårsagsanalyse før første underretning er ikke en brugbar proces.
Den indledende underretning giver myndigheden et hurtigt billede; den mellemliggende rapport opdaterer status og kendte konsekvenser; slutrapporten behandler årsag, omkostninger og afhjælpning. DORA’s tekniske tidsstandard og Finanstilsynets hændelsesside skal bruges til at kontrollere frister og format, også ved weekender og helligdage. Efter artikel 5, stk. 4, i den delegerede forordning kan en frist, der falder på weekend eller helligdag, i visse tilfælde opfyldes senest kl. 12 næste arbejdsdag. Undtagelsen gælder dog ikke den indledende eller mellemliggende rapport for blandt andet kreditinstitutter, centrale modparter og markedspladsoperatører, jf. stk. 5; andre systemisk vigtige enheder kan også være undtaget efter myndighedsbeslutning. Kontroller derfor enhedens kategori, før en frist flyttes. En intern øvelse bør derfor teste, om klassifikationsgrundlaget, kontaktperson og rapporteringsadgang er til stede en lørdag. DORA-processen bør kobles til GDPR’s brudvurdering, når personoplysninger er berørt; de to regler har forskellige tærskler og modtagere.
Efter hændelsen skal virksomheden kunne vise, at læring faktisk ændrede kontrollen: en lappet sårbarhed, genoprettet backup, ændret leverandørkontakt eller ny overvågning. En rapport uden ansvarlig, deadline og opfølgning er ikke en afsluttet forbedring. Hvis hændelsen først blev klassificeret forkert, skal årsagen til omklassifikationen også dokumenteres. Det gør rapporteringen mere pålidelig end et rent ur, der blot tæller timer.
Test, exit og ledelsesbeslutninger
En årlig testplan bør kombinere tekniske test med praktiske øvelser. En penetrationstest kan finde sårbarheder, men en genoprettelsesøvelse viser, om organisationen faktisk kan fortsætte en kritisk tjeneste. For hvert scenarie fastlægges acceptkriterier, målt resultat, afvigelser og ny testdato. Trusselsbaseret penetrationstest, TLPT, har særskilt regulering og gælder udvalgte virksomheder; man skal ikke markere en almindelig pentest som opfyldelse af TLPT. Den praktiske guide til testscope hjælper med at købe og følge op på almindelige test.
Leverandørstyring kræver også et svar på spørgsmålet: Hvad gør vi, hvis en tjeneste bortfalder? For en kritisk funktion bør exit-planen nævne dataudtræk, format, nødvendig intern kompetence, parallel drift, test af alternativ og den tid, som en overførsel realistisk tager. En klausul om opsigelse er ikke i sig selv en afprøvet exit. Koncentrationsrisiko må vurderes både hos den direkte cloudleverandør og i underliggende afhængigheder. Her kan vurdering af IKT-leverandører og exit give en separat tjekliste, hvis linkets indhold og anvendelse passer til dansk kontekst.
Ledelsen bør regelmæssigt se de samme få, målbare forhold: uafsluttede kritiske hændelser, tests med væsentlige fejl, leverandører uden opdateret klassifikation og kritiske funktioner uden troværdig exit. Samtidig skal den kunne se hvilke undtagelser, den faktisk har accepteret, og hvornår de udløber. Det gør DORA til en styringsramme i stedet for en mappe med politikker. Ressourcer og risikotolerance besluttes af virksomheden selv inden for reglerne; et softwareprodukt kan lagre beviser, men kan ikke overtage ledelsens ansvar.
Kontrolspørgsmål før næste ledelsesmøde
Tag én kritisk funktion og gennemgå den fra slutbruger til datacenter: Hvilke tjenester bærer funktionen, hvilke kontrakter dækker dem, hvor hurtigt kan de gendannes, og hvornår blev det sidst testet? Hvis et led i kæden ikke kan besvares, bør det blive et konkret opfølgningspunkt med ejer og dato. En enkelt gennemført gennemgang viser mere om den faktiske modstandsdygtighed end en bred erklæring om, at alle fem søjler er implementeret.
Ofte stillede spørgsmål
Hvem fører tilsyn med DORA i Danmark?
Finanstilsynet er den kompetente myndighed og fører tilsyn med DORA som led i sit tilsyn med IKT- og datasikkerhed. Myndigheden igangsatte de første temaundersøgelser i efteråret 2025. For de største aktører kan Finanstilsynet kræve trusselsbaseret penetrationstest.
Skal min virksomhed overholde både DORA og NIS2?
For IKT-risici går DORA forud for NIS2 for finansielle virksomheder (lex specialis), så I skal primært følge DORA på det område. I kan dog være omfattet af NIS2 for andre aktiviteter. En finansiel virksomhed bør afklare begge regelsæts anvendelse tidligt og samordne dokumentationen.
Hvad er informationsregisteret i DORA?
Et komplet register over alle en finansiel virksomheds kontraktmæssige aftaler om IKT-tjenester, som skal indberettes til Finanstilsynet i et fastlagt format. Det er i praksis omdrejningspunktet i DORA-efterlevelsen, og et af de første dokumenter Finanstilsynet efterspørger.
Konklusion
DORA gælder direkte i Danmark siden den 17. januar 2025 og håndhæves af Finanstilsynet, der allerede er begyndt at føre tilsyn med den finansielle sektors digitale modstandsdygtighed. Kernen er de fem søjler – IKT-risikostyring, hændelsesrapportering, test, tredjepartsrisiko og trusselsdeling – med informationsregisteret over IKT-leverandører som omdrejningspunkt. For danske banker, forsikringsselskaber og pensionskasser er den mest effektive vej at bygge DORA-dokumentationen oven på det eksisterende GDPR- og NIS2-arbejde, fordi risikostyringen og leverandørkontrollen overlapper. Start med informationsregisteret, forankr risikostyringen hos ledelsen, og behandl DORA som en løbende del af IKT-styringen.
Læs videre: