Den bedste DORA-software til en dansk finansiel virksomhed skal kunne vise sammenhængen mellem forretningsfunktioner, IKT-tjenester, kontrakter, risici og beslutninger. Et informationsregister er vigtigt, men et korrekt register alene opfylder ikke forordningen. Denne guide hjælper med at bestille og vurdere en sammenhængende demonstration, så indkøbet ender med et dokumenteret beslutningsgrundlag.
Den praktiske leverance er en kravspecifikation med acceptkriterier: hvad skal kunne registreres, hvilke ændringer skal udløse handling, og hvilke filer og beslutningsspor skal virksomheden kunne hente ud? Vi udpeger ikke en markedsvinder uden sammenlignelig dokumentation og angiver ikke udokumenterede standardpriser. Regler og myndighedskilder er gennemgået den 27. september 2026; krav til en bestemt tjeneste og dens aktuelle rapporteringsformat skal kontrolleres før aftaleindgåelse.
DORA i Danmark: hvad gælder?
DORA-forordningen finder anvendelse fra den 17. januar 2025. Den regulerer digital operationel modstandsdygtighed for de omfattede finansielle enheder. Artikel 2 fastlægger både kategorier og undtagelser. Det er derfor upræcist at sige, at alle virksomheder under finansielt tilsyn har præcis de samme DORA-pligter.
Finanstilsynets oversigt over omfattede virksomheder skelner blandt andet mellem fuldt anvendelsesområde, undtagelser og det forenklede rammeværk for IKT-risikostyring. Små forsikringsformidlere kan være undtaget; et mindre foretagende er ikke automatisk underlagt et forenklet regime. Indkøbsansvarlige bør få virksomhedens konkrete status bekræftet, inden de bestiller en standardpakke.
Notér juridisk enhed, tilladelse, relevante aktiviteter, undtagelser og koncernrelationer. Gem også begrundelsen for vurderingen. Den generelle guide til DORA i Danmark beskriver lovrammen; denne side omsætter afgrænsningen til krav til et værktøj. En softwareleverandørs fortolkning kan indgå som information, men den fritager ikke den finansielle virksomhed for at kontrollere sin egen anvendelsesvurdering.
Hvad skal indkøbet konkret forbedre?
Vælg en hovedopgave, som kan observeres. Det kan være at samle spredte oplysninger om IKT-aftaler, forbedre eskalation ved hændelser eller sikre, at ledelsen følger op på testfund. Formulér problemet med udgangspunkt i dagens arbejdsgang: hvem sender oplysninger til hvem, hvor opstår fejl, og hvilken beslutning kommer for sent?
En hypotetisk pensionsvirksomhed har eksempelvis kontrakter i indkøbssystemet, risikovurderinger i dokumentmapper og systemejere i et regneark. Den ønsker et register, hvor en ændring i en kritisk tjeneste fører til en ny risikovurdering og en opgave til kontraktejeren. Acceptkriteriet er denne sammenhængende ændring, ikke blot at alle tre oplysninger kan vises på en skærm.
Undersøg samtidig, om eksisterende systemer kan være autoritative kilder. En ekstra kopi af leverandørens navn kan være uproblematisk; to uafhængige lister over gældende aftaler kan skabe usikkerhed. Vælg en ejer for hver central oplysning og beskriv, hvordan ændringer bliver synkroniseret og kontrolleret.
DORA’s fem søjler
IKT-risikostyring, håndtering og rapportering af hændelser, modstandsdygtighedstest, tredjepartsrisiko og informationsdeling bruges ofte som en oversigt over DORA. Informationsdeling efter artikel 45 er frivillig under de fastsatte betingelser. Alle fem områder skal ikke derfor præsenteres som fem ens obligatoriske softwaremoduler.
Et relevant værktøj kan dække dele af arbejdet, mens andre systemer håndterer tekniske hændelser, testudførelse eller kontraktarkiv. Kravspecifikationen skal vise grænserne. Et system, der planlægger penetrationstest, udfører ikke nødvendigvis testen. Et system, der genererer rapportudkast, indsender dem ikke nødvendigvis til myndigheden.
Spørg derfor til leverancen for hver arbejdsgang: data, beslutning, godkendelse og dokumentation. Bed leverandøren vise et komplet eksempel frem for separate funktioner. Det afslører, om sammenhængen er til stede i den tilbudte version, eller om den kræver senere udvikling, yderligere moduler eller manuelt arbejde.
Informationsregisteret: DORA’s omdrejningspunkt
Artikel 28 kræver et informationsregister over kontraktlige ordninger om brug af IKT-tjenester fra tredjepartsudbydere. Registret skal skelne mellem tjenester, der understøtter kritiske eller vigtige funktioner, og andre tjenester. Identifikation af en kritisk funktion er ikke det samme som EU-myndighedernes udpegning af en kritisk IKT-tredjepartsudbyder.
Afprøv en kontrakt, som understøtter to funktioner med forskellig betydning. Tilføj en underleverandør, ændr en ophørsdato, og se, hvilke relationer der påvirkes. Kontroller, at et navneskifte ikke skaber to leverandører, og at en koncernleverandør ikke forveksles med den juridiske kontraktpart. En pæn liste kan skjule alvorlige fejl i disse forbindelser.
Krav til registerets struktur følger blandt andet af gennemførelsesforordning 2024/2956. De aktuelle tekniske instrukser findes via Finanstilsynets DORA-side. Aftal konkret, hvilken skemaversion og indberetningsproces leverandøren understøtter. En generisk Excel-eksport er ikke dokumentation for, at en indberetningsfil kan accepteres.
Gennemfør en acceptprøve af registeret
Giv alle kandidater det samme afgrænsede datagrundlag: en juridisk enhed, flere funktioner, to kontrakter og en tjeneste med en underleverandør. Brug syntetiske eller rensede oplysninger. Medtag bevidst en manglende identifikator og en modstridende dato. I skal se, om systemet opdager problemet, og om det forklarer, hvordan det kan løses.
Dernæst ændres et felt, som bruges flere steder. Leverandøren skal demonstrere, om eksporten følger med, og om ændringen kan spores til en bestemt bruger og kilde. Gem både den første og den rettede eksport sammen med valideringsresultatet. Et acceptreferat bør beskrive fejlen og løsningen, ikke blot skrive, at eksportfunktionen er godkendt.
Vurder også det manuelle restarbejde. Hvis filen skal repareres uden for værktøjet før hver indsendelse, skal arbejdet være beskrevet og prissat. En manuel proces kan være forsvarlig ved begrænset volumen, men den må ikke sælges som en færdig automatisk integration. Aftal, hvem der vedligeholder opsætningen, når myndighedens format ændres.
Kontrakter skal forbindes med faktiske rettigheder
DORA’s artikel 30 indeholder kontraktkrav, med yderligere bestemmelser for tjenester, der understøtter kritiske eller vigtige funktioner. En søgning efter ordet revision afgør ikke, om kontrakten giver tilstrækkelig adgang til kontrol. Vilkår kan ligge i flere bilag, være begrænsede eller blive ændret af dokumenter med højere rang.
Bed om en demonstration, hvor en kontraktgennemgang henviser til det konkrete afsnit og markerer usikkerhed. Den ansvarlige skal kunne acceptere, afvise eller uddybe et fund. Hvis værktøjet bruger automatisk dokumentanalyse, skal en manglende side eller en ulæselig tabel kunne opdages. Et forslag bør ikke fremstå som en endelig juridisk konklusion.
GDPR’s databehandleraftale efter artikel 28 dækker en anden relation. En IKT-leverandør er ikke automatisk databehandler, og en databehandleraftale erstatter ikke DORA’s tjenestespecifikke kontraktkrav. Det er nyttigt at dele kontaktoplysninger og dokumenthenvisninger, men de to vurderinger skal forblive selvstændige.
Hændelsesrapportering: afprøv tiden og modtageren
Hændelser skal først registreres og klassificeres efter de relevante kriterier. For alvorlige IKT-hændelser konkretiserer delegeret forordning 2025/301 rapporteringsfristerne. Den første meddelelse skal som udgangspunkt indsendes hurtigst muligt, senest fire timer efter klassifikation som alvorlig og senest 24 timer efter kendskab. Sen klassifikation, mellemliggende rapporter og endelig rapport kræver særskilt håndtering efter reglerne.
Systemet skal derfor registrere kendskab og klassifikation hver for sig. Afprøv en hændelse, som først ser begrænset ud, men senere rammer flere kunder. Se, om systemet kan forklare fristberegningen og vise, hvem der ændrede vurderingen. En kalenderalarm uden begrundelse er ikke tilstrækkelig til at efterprøve forløbet.
Brug myndighedens aktuelle vejledning til at vælge rapporteringskanal. Afprøv reserveadgang, hvis den normale godkender er utilgængelig, og kontrollér, at en kvittering kan gemmes. Leverandøren må ikke sende en øvelsesrapport til Finanstilsynet som led i en salgsdemonstration. Dokumentér i stedet hele forløbet med en tydeligt afgrænset test eller en kontrolleret eksport.
DORA, NIS2 og GDPR: del fakta, bevar vurderingerne
DORA er sektorspecifik EU-regulering i forhold til de relevante NIS2-krav for omfattede finansielle enheder. Det er derfor ikke korrekt at sælge tre fulde parallelle kravpakker til enhver bank. Andre aktiviteter eller juridiske enheder kan kræve deres egen vurdering. Kriterier til NIS2-værktøjer er relevante, når afgrænsningen faktisk viser et behov.
Et persondatabrud skal vurderes særskilt efter GDPR. Artikel 33 indeholder en risikobetinget anmeldelsespligt, og artikel 34 en særskilt tærskel for underretning af personer. Sammenkobl fakta om hændelsen med arbejdet med brudanmeldelse, men lad ikke en DORA-klassifikation automatisk afgøre GDPR-spørgsmålet.
Det samme gælder registre. Fortegnelsen over behandlingsaktiviteter beskriver behandling af personoplysninger; DORA-registeret beskriver IKT-aftaler. Delte relationer kan være værdifulde, men felter, afgrænsning og eksportkrav er forskellige. Afprøv om systemet bevarer denne forskel, når en tjeneste ændres.
Modstandsdygtighedstest og TLPT
Køb et værktøj, som passer til virksomhedens faktiske testprogram. Trusselsbaseret penetrationstest, TLPT, gælder ikke automatisk alle store virksomheder og heller ikke alle omfattede enheder. Udpegning og de relevante regler skal afklares. Et almindeligt testarkiv kan være nyttigt uden at udgøre en løsning til alle TLPT-processer.
Bed om at registrere et testfund, knytte det til en forretningsfunktion og tildele en ansvarlig med en frist. Lad derefter en ny kontrol vise, at problemet kun er delvist løst. Kan sagen genåbnes uden at miste den første vurdering? Kan ledelsen se konsekvensen af udsættelsen? Det er centrale acceptkriterier.
Den praktiske plan for genopretning og backup og en afgrænset penetrationstest kan levere underlag til dokumentationen. Det indkøbte værktøj skal vise både testens omfang og begrænsninger, så en enkelt vellykket gendannelse ikke bliver bevis for alle systemers modstandsdygtighed.
Ledelsen skal kunne følge forbedringerne
Finanstilsynet offentliggjorde den 23. september 2026 en undersøgelse af forsikrings- og pensionssektorens DORA-implementering. Den pegede blandt andet på behov for bedre ledelsesmæssig opfølgning, sammenhængende dokumentation, kompetencer og operationelt beredskab. Undersøgelsen er ikke en dokumentation for, at bestemte softwareprodukter er godkendt.
Omsæt læringen til en demonstration, hvor ledelsen får et begrænset antal beslutningspunkter med baggrund, konsekvens og ansvar. Rapporten bør vise, hvorfor en udestående opgave betyder noget for driften, og hvilke forudsætninger der har ændret sig siden sidste møde. En sammenlagt score kan indgå, men den må ikke skjule kritiske enkeltproblemer.
Dataplacering, adgang og ophør
Sikkerhedsdokumentation kan indeholde systemarkitektur, sårbarheder og personoplysninger. Vurder adgang efter funktion og juridisk enhed. Bed om at se, at en ekstern konsulent kun kan læse den aftalte del, og at en bruger mister adgang ved fratrædelse. Kontroller også, hvem der kan eksportere hele registeret.
EU-hosting afgør ikke alene, om personoplysninger bliver tilgængelige for en separat modtager i et tredjeland. Undersøg support, underleverandører og automatiske analysefunktioner. Vurderingen af tredjelandsoverførsler skal bygge på de faktiske dataflow og aftaler, ikke på adressen på det primære datacenter.
Planlæg ophør inden underskrift. Eksportér relationer, bilag, versioner og beslutninger, og kontroller, at de kan forstås uden aktivt abonnement. Aftal adgang i overgangsperioden, hjælp til udtræk og håndtering af tilbageværende kopier. En udtrådt leverandør må ikke blive den eneste, der kan forklare jeres historiske register.
Kontroller indberetningsniveau og den aktuelle kalender
Ved den danske registerindberetning i 2026 beskrev Finanstilsynet den konkrete proces: indsendelse gennem e-Reg og forskel mellem koncernens højeste konsoliderede niveau og selvstændige virksomheder. Den offentliggjorte frist den 31. marts 2026 er en historisk indberetningsfrist. Den skal ikke genbruges som en universel frist for senere år eller alle ændringer.
Bed leverandøren demonstrere, hvem der vedligeholder de underliggende oplysninger, og hvem der samler den relevante indberetning. At et datterselskab ikke selv indsender den pågældende koncernindberetning, betyder ikke, at selskabets oplysninger kan udelades. Det er en forskel mellem datagrundlag, ansvar og indsendelsesniveau, som produktet bør kunne understøtte.
Læg derfor ikke rapporteringskalenderen fast alene i en standardopsætning. Udpeg en person til at kontrollere nye instrukser og afklare, om ændringen kræver ny skemaversion eller validering. Aftal, hvordan leverandøren oplyser om relevante produktændringer, og hvad virksomheden skal afprøve før næste indsendelse. En opdateret integration kan stadig give forkert resultat, hvis de lokale data eller tilknytninger ikke er korrekte.
Behandl utilgængelige eller modstridende oplysninger åbent
IKT-aftaler kan være gamle, spredte eller uklare om underleverandører og tjenesteomfang. Registrér manglen med ejer, kilde og plan for afklaring. Et system bør ikke tvinge medarbejderen til at vælge en urigtig standardværdi for at afslutte en opgave. Hvis en midlertidig antagelse er nødvendig for det interne arbejde, skal den kunne genkendes som en antagelse.
I acceptprøven kan en leverandørbesvarelse bevidst være i modstrid med kontrakten. Bed brugeren markere konflikten og indhente en afklaring. Se, om den senere rettelse bevarer det oprindelige spørgsmål og gør den nye begrundelse synlig. Det giver bedre dokumentation end at overskrive det gamle felt uden spor og viser, om værktøjet fungerer i en uperfekt datavirkelighed.
Pris og endelig beslutning
Sammenlign tilbud med samme omfang og forudsætninger. Antal enheder, brugere, aftaler, integrationsarbejde, validering, support og ændringshåndtering kan påvirke udgiften. Medregn interne timer til oprydning og ansvarlig godkendelse. Budgettering af compliance-software giver en struktur, mens en sammenligning af administrative arbejdsgange hjælper med fælles behov.
Den danske håndhævelse skal vurderes efter de relevante nationale bestemmelser sammen med DORA’s tilsynsregler. DORA’s artikel 50–52 opstiller ikke én fælles bødetakst for alle finansielle virksomheder i Europa. Undlad derfor at begrunde købet med et opfundet universelt bødebeløb. Vurder i stedet dokumenterede mangler, driftsrisiko, lovpligter og den sandsynlige arbejdsbyrde ved hver løsning.
Ofte stillede spørgsmål
Skal vi vælge en integreret platform?
Kun hvis integrationen hjælper med de nødvendige arbejdsgange og kan demonstreres. Et specialværktøj med klare forbindelser til kontraktarkiv og risikostyring kan være mere hensigtsmæssigt end en bred platform med svag eksport. Sammenlign den tilbudte opsætning og dens vedligeholdelse, ikke produktkategorien alene.
Er informationsregisteret nok til DORA?
Nej. Registret er en central del af tredjepartsarbejdet, men risikostyring, ledelse, hændelser, test og opfølgning har selvstændig betydning. Acceptprøven bør følge en tjeneste fra registrering til ændring, hændelse og forbedring, så manglende forbindelser bliver synlige.
Hvornår kan vi acceptere løsningen?
Når de aftalte obligatoriske funktioner virker på jeres prøvegrundlag, eksporten kan kontrolleres, og resterende opgaver har en ejer og en realistisk løsning. Gem referat, prøvefiler, afvigelser og kontraktlige forudsætninger samlet. Et salgsløfte om fremtidig funktionalitet bør stå som et åbent punkt med konsekvens for beslutningen.