Smarte systemløsninger til danske virksomheder — siden 1999. Admind ERP, webshop, hosting og IT-service samlet ét sted.
Smarte systemløsninger til danske virksomheder — siden 1999. Admind ERP, webshop, hosting og IT-service samlet ét sted.
Du kommer ikke under Finanstilsynets tilsyn. Men banken, pensionskassen eller forsikringsselskabet skal registrere dig, kontraktbinde dig efter artikel 30 og kunne redegøre for hver enkelt af dine underleverandører. Kan du ikke levere de oplysninger, kan de ikke beholde dig.
Svarer du ja til blot ét af punkterne, bliver du behandlet som IKT-tredjepartsudbyder i din kundes DORA-dokumentation — uanset hvor lille leverancen er.
DORA har været direkte gældende i Danmark siden 17. januar 2025. Forordningen forpligter finansielle virksomheder, ikke almindelige it-leverandører. Kun 19 udbydere i hele EU er udpeget som kritiske og får direkte tilsyn. Alle andre leverandører rammes udelukkende gennem kundens kontrakt og dokumentation.
DORA står for Digital Operational Resilience Act og er forordning (EU) 2022/2554 af 14. december 2022. Den blev offentliggjort i EU-Tidende den 27. december 2022 og trådte i kraft den 17. januar 2025. Finanstilsynet skriver det selv lige ud: forordningen finder direkte anvendelse på de omfattede finansielle enheder fra den dato. Der er ingen dansk implementeringslov at vente på — det tilhørende direktiv (EU) 2022/2556, som kun indsætter krydshenvisninger i de finansielle direktiver, blev gennemført 1. juli 2024.
Det afgørende for dig som leverandør ligger i forordningens kapitel V. Første afsnit indeholder de principbaserede regler for styring af IKT-tredjepartsrisiko og de centrale kontraktbestemmelser. Afdeling II opretter en EU-dækkende tilsynsramme for kritiske tredjepartsudbydere. De to afsnit rammer vidt forskelligt, og det er den forskel, der afgør din situation.
Finanstilsynets oversigt over virksomheder omfattet af DORA opregner 21 typer. De første tyve er finansielle: kreditinstitutter, betalingsinstitutter, kontooplysningstjenesteudbydere, e-pengeinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, værdipapircentraler, centrale modparter, markedspladser, transaktionsregistre, forvaltere af alternative investeringsfonde, administrationsselskaber, udbydere af dataindberetningstjenester, forsikrings- og genforsikringsselskaber, forsikringsformidlere, arbejdsmarkedsrelaterede pensionskasser, kreditvurderingsbureauer, administratorer af kritiske benchmarks, udbydere af crowdfundingtjenester og securitiseringsregistre.
Punkt 21 er „tredjepartsudbydere af IKT-tjenester“. Det står der, og det får mange leverandører til at tro, at de nu er under finansielt tilsyn. Det er de ikke. At stå i forordningens anvendelsesområde er ikke det samme som at være underlagt tilsyn. Forskellen afgøres af, om du er udpeget som kritisk.
Den 18. november 2025 offentliggjorde de tre europæiske tilsynsmyndigheder EBA, ESMA og EIOPA den første liste over udpegede kritiske IKT-tredjepartsudbydere, på engelsk critical ICT third-party service providers eller CTPP’er. Listen indeholder 19 navne, og den er værd at læse, fordi den viser niveauet: Accenture, Amazon Web Services EMEA, Bloomberg, Capgemini, Colt Technology Services, Deutsche Telekom, Equinix EMEA, Fidelity National Information Services, Google Cloud EMEA, IBM, InterXion Headquarters, Kyndryl, LSEG Data and Risk, Microsoft Ireland Operations, NTT DATA, Oracle Nederland, Orange, SAP og Tata Consultancy Services.
Ingen dansk mellemstor it-virksomhed står på listen, og det kommer ingen til. Udpegningen rammer udbydere, hvis udfald kan destabilisere den finansielle sektor på EU-niveau. Konsekvensen for alle andre er til at overskue — og samtidig den, der koster mest arbejde i praksis:
Finanstilsynet satte i oktober 2025 sin første temaundersøgelse i gang på grundlag af DORA. 14 forsikringsselskaber og pensionskasser skulle redegøre for, hvordan de har implementeret forordningen, med vægt på it-risikostyring og på ledelsens forankring af den. Kontorchef Adam Al-Saffar sagde ved den lejlighed: „DORA blev ikke kun indført, fordi det eksterne risikobillede har ændret sig.“ Det andet ben er sektorens egen voksende it-afhængighed — altså leverandørerne.
Det er værd at holde fast i, når et spørgeskema lander i indbakken. Kunden spørger ikke af mistillid. Kunden spørger, fordi ledelsen selv skal kunne svare for det over for tilsynet. Det er samme mekanik som i NIS2-spørgeskemaerne fra større kunder, men DORA er mere specifik: der findes faste skemaer, faste datafelter og faste frister.
| Kundetype | Typisk it-leverance fra en dansk SMV | Hvad kunden skal kunne dokumentere om dig |
|---|---|---|
| Pengeinstitut, realkreditinstitut | Netværk, hosting af randsystemer, udvikling, support | Fuld registerpost, artikel 30-kontrakt, kortlagt underleverandørkæde |
| Forsikringsselskab, pensionskasse | Dokumenthåndtering, backup, integrationer, datawarehouse | Samme — og sværere, fordi funktionerne ofte er vigtige |
| Forsikringsformidler | Drift, Microsoft 365, kundeportal | Register og kontrakt; forenklet IKT-ramme kan gælde kunden |
| Betalingsinstitut, e-pengeinstitut | Hosting, overvågning, sikkerhed | Register og kontrakt; undtagne institutter er på forenklet ramme |
| Arbejdsmarkedsrelateret pensionskasse | Drift og rapportering | Små kasser kan være på artikel 16-rammen eller helt uden for DORA |
Bemærk den sidste række. DORA har reelle undtagelser, og de er værd at kende, før du begynder at bygge en dokumentpakke, som kunden måske ikke behøver. Artikel 16 indsætter en forenklet ramme for IKT-risikostyring for små og ikke indbyrdes forbundne investeringsselskaber, undtagne betalingsinstitutter, undtagne e-pengeinstitutter og små arbejdsmarkedsrelaterede pensionskasser — for dem gælder artikel 5-15 ikke. Og artikel 2, stk. 3, holder blandt andet pensionskasser med højst 15 medlemmer i alt samt mikro- og SMV-forsikringsformidlere helt uden for forordningen.
Hver finansiel virksomhed skal føre et register over alle kontraktlige ordninger om IKT-tjenester og indsende det til Finanstilsynet årligt. Skemaerne er fastlagt i gennemførelsesforordning (EU) 2024/2956. Ved første større prøvekørsel havde 93,5 pct. af registrene mindst én fejl, og 86 pct. af fejlene var manglende obligatoriske oplysninger.
Pligten står i DORA artikel 28, stk. 3: finansielle enheder skal på enheds-, delkoncern- og koncernniveau opretholde og opdatere et register over oplysninger om alle kontraktlige ordninger om brug af IKT-tjenester leveret af IKT-tredjepartsudbydere. Myndigheden kan kræve registret udleveret. Og fordi de europæiske tilsynsmyndigheder skal kunne udpege de kritiske udbydere efter artikel 31, stk. 1, litra a, har de besluttet, at alle nationale myndigheder indsamler det fulde register. Der er altså ikke tale om et internt arbejdsdokument. Det er en indberetning.
Formatet er ikke til forhandling. Kommissionens gennemførelsesforordning (EU) 2024/2956 af 29. november 2024 fastsætter gennemførelsesmæssige tekniske standarder for standardskemaerne til registret. Den trådte i kraft 22. december 2024. Skemaerne er navngivet, og de fleste af dem rummer felter, kunden kun kan udfylde med oplysninger fra dig:
| Skema | Hvad det dækker | Hvad kunden skal have fra dig |
|---|---|---|
| B_02.01 og B_02.02 | Kontraktlige ordninger, generelt og specifikt | Kontraktens datoer, opsigelsesvarsel, gældende lov, værdi |
| B_03.01–B_03.03 | Kontraktens parter | Juridisk navn, identifikationskode, land |
| B_04.01 | Enheder, der bruger IKT-tjenesterne | Hvilke af kundens enheder leverancen rører |
| B_05.01 | IKT-tredjepartsudbyderen | Din identifikationskode, din type af tjeneste, dit land |
| B_05.02 | Forsyningskæden af IKT-tjenester | Dine underleverandører med rangorden og land |
| B_06.01 | Identifikation af funktioner | Om leverancen understøtter en kritisk eller vigtig funktion |
| B_07.01 | Vurdering af IKT-tjenesterne | Dataplacering, substituerbarhed, exitforhold |
Hvert skema er en tabel med et fast antal kolonner og et ubegrænset antal rækker. Hvert dataelement udfyldes med én værdi, og gælder flere værdier, tilføjes en række. Forordningens artikel 3 nævner seks datakvalitetsprincipper: nøjagtighed, fuldstændighed, konsistens, integritet, ensartethed og gyldighed. Det lyder abstrakt, men det er netop dem, der afgør, om kundens indberetning bliver afvist.
Artikel 3 kræver, at IKT-tredjepartsudbydere, der er juridiske personer, identificeres med en gyldig og aktiv LEI-kode eller med deres EUID — den europæiske unikke identifikator efter artikel 16 i direktiv (EU) 2017/1132. Findes begge, skal begge angives. Fysiske personer, der handler i erhvervsmæssigt øjemed, er undtaget. Samme krav gælder for underleverandører, der understøtter kritiske eller vigtige funktioner: den direkte udbyder skal sikre, at de enten bruger en gyldig og aktiv LEI eller oplyser deres EUID.
En LEI-kode er en 20-tegns global identifikator, der udstedes af akkrediterede udstedere og skal fornyes løbende for at være „aktiv“. Et EUID tildeles af det nationale selskabsregister som led i registreringen og følger ISO 6523 med landekode, registeridentifikator og registreringsnummer. For danske selskaber bygger EUID på CVR-registreringen. I praksis er det værd at gøre to ting, inden kunden spørger: afklar hvilken af de to koder kunden ønsker, og tjek om din LEI er aktiv eller er udløbet for år tilbage, fordi nogen engang anskaffede den til et enkeltstående formål.
Forordningen definerer en IKT-forsyningskæde som en række kontrakter, der starter hos den direkte udbyder og fortsætter ned gennem underleverandørerne. Hver udbyder får en rang: et naturligt tal på 1 eller derover, hvor et lavere tal betyder tættere på den finansielle virksomhed. Den direkte udbyder har altid rang 1. Underleverandører har altid en højere rang end 1.
Det er ikke hele din leverandørliste, der skal med. Registreres skal de underleverandører, der reelt understøtter IKT-tjenester til kritiske eller vigtige funktioner, samt dem, hvis forstyrrelse ville svække sikkerheden eller kontinuiteten i tjenesten. Øvrige underleverandører behøver ikke stå der. Den afgrænsning er værd at tage alvorligt fra din side: leverer du en komplet liste over alt fra kaffeleverandøren til DNS-udbyderen, giver du kunden et oprydningsarbejde, og de fejl, der kommer ud af det, bliver kundens — og dermed dine.
De europæiske tilsynsmyndigheder gennemførte i 2024 en frivillig prøvekørsel af registret og offentliggjorde resultatet den 17. december 2024. Det er den bedste måling, der findes, af hvor det går galt:
Kun 6,5 pct. af registrene bestod samtlige datakvalitetskontroller. Medregnes koncernenheder under konsoliderede indberetninger, dækkede øvelsen 3.447 enheder og over 9,2 millioner datapunkter. Fejlene fordelte sig på manglende obligatoriske oplysninger (86 pct.), ugyldige LEI-koder (6,5 pct.), ugyldige DPM-værdier (4 pct.) samt dubletter i nøglevariable og ugyldige datoer (2,8 pct.).
Ingen af de fire fejltyper handler om sikkerhedsniveau. De handler om stamdata: felter der ikke er udfyldt, koder der ikke er aktive, datoer der ikke er gyldige. Det kunden mangler fra dig, er et datasæt — ikke en revisionserklæring.
Indsendelsen sker årligt gennem e-Reg. Finanstilsynet forventede, at indberetningsvinduet åbnede 10. marts 2026, med frist for de omfattede virksomheder den 31. marts 2026. Virksomheder i en finansiel koncern indberetter på højeste konsolideringsniveau, så moderselskabet indberetter for koncernen; datterselskaber og filialer af en anden DORA-omfattet finansiel enhed indberetter ikke selv.
Den frist er passeret. Det ændrer intet ved, hvad du skal kunne levere — tværtimod. Registret er en løbende forpligtelse, der skal opdateres, og næste indsendelsesvindue ligger foran os. To ting følger af det:
DORA artikel 30 gør en række kontraktvilkår obligatoriske. Stk. 2, litra a-i, gælder enhver aftale om IKT-tjenester. Stk. 3, litra a-f, lægger yderligere krav oven i, når tjenesten understøtter en kritisk eller vigtig funktion — blandt andet fuld revisionsret, deltagelse i trusselsbaseret penetrationstest og en exitstrategi med overgangsperiode.
Artikel 30, stk. 1, kræver, at rettigheder og forpligtelser fordeles tydeligt og fastlægges skriftligt, og at hele aftalen inklusive serviceniveauaftaler samles i ét skriftligt dokument, der er tilgængeligt for parterne — på papir eller i et downloadbart, varigt og tilgængeligt format. Alene det krav vælter mange leverandøraftaler, hvor SLA’en ligger på en webside, der kan ændres uden varsel.
| Art. 30, stk. 2 | Krav | Hvad det betyder i din kontrakt |
|---|---|---|
| litra a | Klar og fuldstændig beskrivelse af funktioner og tjenester, og om underleverance til kritiske eller vigtige funktioner er tilladt — og på hvilke vilkår | Leverancebeskrivelse og en udtrykkelig underleverandørklausul |
| litra b | De lande eller regioner, hvor tjenesten leveres og data behandles, herunder lagringssted, samt pligt til forudgående besked ved ændringer | Dataplacering skrevet ind — og varsel før du flytter noget |
| litra c | Tilgængelighed, autenticitet, integritet og fortrolighed af data, herunder personoplysninger | Spænder sammen med databehandleraftalen, men er ikke den samme |
| litra d | Adgang til, genoprettelse af og tilbagelevering af data i letbrugeligt format ved insolvens, afvikling, ophør eller kontraktens udløb | Dataudtræk skal være aftalt på forhånd, også hvis du går konkurs |
| litra e | Serviceniveaubeskrivelser inklusive opdateringer og revisioner | Versionsstyret SLA, ikke en levende webside |
| litra f | Pligt til at bistå ved IKT-hændelser — uden ekstra omkostning eller til en på forhånd fastsat pris | Prisen for akutbistand skal stå i aftalen |
| litra g | Fuldt samarbejde med kompetente myndigheder og afviklingsmyndigheder, herunder personer de udpeger | Du forpligter dig over for Finanstilsynet gennem kunden |
| litra h | Opsigelsesrettigheder og minimumsopsigelsesfrister | Lange bindingsperioder bliver svære at fastholde |
| litra i | Vilkår for din deltagelse i kundens IKT-sikkerhedsbevidsthedsprogrammer og træning i digital operationel modstandsdygtighed | Dine medarbejdere kan blive bedt om at deltage i kundens træning |
Understøtter leverancen en kritisk eller vigtig funktion, kommer stk. 3 oven i. Det er her, forhandlingerne bliver reelle:
| Art. 30, stk. 3 | Krav | Det, der typisk mangler hos leverandøren |
|---|---|---|
| litra a | Fulde serviceniveaubeskrivelser med præcise kvantitative og kvalitative mål, så kunden kan overvåge og rette op rettidigt | Målbare tal i stedet for „bedste bestræbelser“ |
| litra b | Opsigelsesfrister og rapporteringspligt, herunder underretning om forhold, der væsentligt kan påvirke din evne til at levere | En pligt til at sige det højt, før det går galt |
| litra c | Implementering og test af forretningskontinuitetsplaner samt IKT-sikkerhedsforanstaltninger, der passer til kundens regulering | Dokumenteret og testet beredskab, ikke en plan i en skuffe |
| litra d | Deltagelse og fuldt samarbejde i trusselsbaseret penetrationstest efter artikel 26 og 27 | Accept af at kundens TLPT også rammer dit miljø |
| litra e | Løbende overvågningsret: ubegrænset adgang til inspektion og revision for kunden, en udpeget tredjepart og myndigheden — med ret til kopier på stedet | Det punkt, der oftest støder mod standardvilkår |
| litra f | Exitstrategi med en obligatorisk, passende overgangsperiode, hvor du fortsætter leverancen | En skriftlig exitplan med varighed, roller og dataformat |
To forhold er værd at kende, før du afviser revisionsretten. For det første åbner litra e selv for alternative sikkerhedsniveauer, hvis andre kunders rettigheder bliver berørt — det er den krog, der gør en delt platform mulig. For det andet kan en finansiel kunde, der er mikrovirksomhed, uddelegere revisionsretten til en uafhængig tredjepart udpeget af dig, og så kan kunden til enhver tid anmode om oplysninger fra den tredjepart. Har du en anerkendt erklæring fra en uafhængig revisor, er du altså ikke nødvendigvis nødt til at lukke hver enkelt kunde ind i serverrummet.
Endelig siger artikel 30, stk. 4, at parterne ved forhandling skal overveje standardkontraktbestemmelser udviklet af offentlige myndigheder for bestemte tjenester. Det er værd at bruge aktivt: kommer du selv med et gennemarbejdet bilag, er det dig, der sætter udgangspunktet — i stedet for at modtage kundens.
Kommissionens delegerede forordning (EU) 2025/532 af 24. marts 2025 præciserer, hvad en finansiel virksomhed skal fastlægge og vurdere, når IKT-tjenester til kritiske eller vigtige funktioner gives i underleverance. Den trådte i kraft 22. juli 2025. Konsekvensen for dig: kunden skal forhåndsgodkende ændringer i din kæde og kunne opsige, hvis risikoen bliver uhåndterlig.
Hjemlen står i DORA artikel 30, stk. 5: de europæiske tilsynsmyndigheder skulle udarbejde reguleringsmæssige tekniske standarder, der præciserer elementerne i stk. 2, litra a, for underleverance til kritiske eller vigtige funktioner — under hensyn til virksomhedens størrelse, risikoprofil og aktiviteternes kompleksitet. Resultatet blev vedtaget 24. marts 2025, offentliggjort i EU-Tidende 2. juli 2025 og fik virkning fra 22. juli 2025. Den gælder direkte, uden national gennemførelse.
1. Due diligence før underleverancen. Før kunden indgår, fornyer eller væsentligt ændrer en aftale om IKT-tjenester til en kritisk eller vigtig funktion, skal både den direkte udbyder og de forudsigelige underleverandører vurderes. Vurderingen dækker teknisk kapacitet, tilstrækkelige ressourcer, finansiel soliditet og informationssikkerhedspraksis. Kæder med udbydere uden for EU, eller i jurisdiktioner med svagere databeskyttelse eller tilsyn, kræver særlig opmærksomhed.
2. Kontrakten skal fastsætte, hvad der må gives videre. Aftalen skal identificere hvilke tjenester der må underleveres, kræve forudgående varsel ved ændringer i underleverandørkæden, indeholde overvågnings- og rapporteringsforpligtelser, give direkte og indirekte adgangs-, revisions- og inspektionsrettigheder og indeholde opsigelsesrettigheder.
3. Kunden skal vurdere hele kæden løbende. Kundens egen risikovurdering skal være proportional, opdateres regelmæssigt og tages op igen efter væsentlige ændringer i it-opsætningen eller i kæden. Den ser på kædens længde, antal lag og struktur samt på hvor underleverandørerne og databehandlingen er placeret — især ved grænseoverskridende aftaler. Tilsynsmyndigheden deltager ikke i vurderingen; den er kundens eget ansvar. I koncerner skal moderselskabet sikre ensartet anvendelse på tværs af EU-datterselskaberne.
4. Væsentlige ændringer skal varsles — og kan bremses. Tilføjes, fjernes eller flyttes en underleverandør, der understøtter en kritisk eller vigtig funktion, skal det meddeles den finansielle virksomhed på forhånd. Kunden kan gøre indsigelse. Kunden skal desuden kunne vise sin myndighed, at den bevarer fuld kontrol og overblik. Og bliver risikoen ved en ændring uhåndterlig, kan kunden opsige aftalen.
Den praktiske konsekvens er værd at sige rent ud: du kan ikke længere skifte cloudregion, datacenter eller supportpartner uden at orientere din finansielle kunde først. Gør du det alligevel, bryder kunden sin egen forpligtelse — og det er en opsigelsesgrund. Samtidig ligger der en mulighed i det: har du kæden kortlagt og en fast proces for varsling, er du markant lettere at vælge end en konkurrent, der skal begynde forfra hver gang. Det er samme logik som i databehandleraftalen med it-leverandøren, hvor underdatabehandlere også skal godkendes — men DORA går længere, fordi den også dækker leverancer helt uden personoplysninger.
En væsentlig IKT-hændelse skal indberettes til Finanstilsynet hurtigst muligt og inden fire timer efter, at den er klassificeret som væsentlig — og under alle omstændigheder senest 24 timer efter, at virksomheden blev opmærksom på den. Mellemliggende rapport følger inden 72 timer, endelig rapport inden én måned. Din reaktionstid er en del af kundens frist.
Fristerne står i Finanstilsynets vejledning om indberetning af IKT-relaterede hændelser og bygger på tre niveau-2-retsakter: delegeret forordning (EU) 2024/1772 om klassifikationskriterier og tærskler, delegeret forordning (EU) 2025/301 om indholdet af og fristerne for rapporterne, og gennemførelsesforordning (EU) 2025/302 om standardformularer og -skemaer. Indberetningen sker via Virk.dk med MitID Erhverv, og hvis det er teknisk umuligt at sende den indledende underretning den vej, skal Finanstilsynet underrettes på anden måde.
| Rapport | Frist for kunden | Hvad kunden skal have fra dig — og hvornår |
|---|---|---|
| Indledende underretning | Hurtigst muligt og inden 4 timer efter klassificering som væsentlig; under alle omstændigheder senest 24 timer efter, at kunden blev opmærksom på hændelsen | Første melding med tidspunkt, berørte systemer og første vurdering — inden for minutter til få timer |
| Mellemliggende rapport | Inden 72 timer efter den indledende underretning, og igen når hændelsens status eller karakter ændrer sig | Opdateret status, omfang, antal berørte, midlertidige tiltag |
| Endelig rapport | Inden én måned efter den seneste opdatering af den mellemliggende rapport | Rodsagsanalyse, afhjælpning og forebyggende tiltag, skriftligt |
Er der ikke præcise tal til rådighed ved den indledende underretning eller den mellemliggende rapport, må skønnede værdier bruges. Falder en frist på en weekend eller helligdag, kan indsendelse ske inden kl. 12.00 på den første efterfølgende arbejdsdag, jf. RTS’ens artikel 5, stk. 4.
Regn baglæns. Kunden skal klassificere hændelsen, vurdere tærsklerne i forordning 2024/1772 og udfylde et skema — og skal have faktuelle oplysninger fra dig, før noget af det kan gøres. Er din første reaktionstid fire timer i åbningstiden, kan kunden ikke overholde sin frist. Det er den enkelte detalje, der oftest diskvalificerer en ellers god leverandør i finanssektoren.
Hertil kommer artikel 30, stk. 2, litra f: du har pligt til at bistå ved IKT-hændelser, der vedrører tjenesten — uden ekstra omkostning eller til en på forhånd fastsat pris. Timeprisen for akutbistand skal altså stå i kontrakten, og den kan ikke sættes efter behov, når uheldet er ude. Det er en reel økonomisk beslutning, som er værd at tage bevidst i stedet for at lade den afgøre af et standardbilag.
Overlapper det med noget, du måske allerede har? Ja. Har du været igennem en cyberforsikrings sikkerhedskrav, har du formentlig både beredskabsplan, logning og eskalationsvej på plads. Forskellen er, at DORA binder tiderne til tal og sender dem videre som en kontraktforpligtelse.
Efter DORA artikel 28, stk. 3, skal en finansiel virksomhed rettidigt underrette Finanstilsynet om enhver planlagt kontraktlig ordning om brug af IKT-tjenester, der understøtter kritiske eller vigtige funktioner — og når en funktion er blevet kritisk eller vigtig. Underretningen sker via et skema på virk.dk, før aftalen sættes i drift.
Det er et trin, de fleste leverandører ikke kender, og som forklarer en del af den langsommelighed, man møder i finansielle salgsforløb. Kunden kan ikke blot sige ja til et godt tilbud. Kunden skal først have vurderet aftalen, kortlagt kæden, sikret artikel 30-vilkårene og underrettet sin tilsynsmyndighed om den planlagte ordning. Finanstilsynet skriver „rettidigt“ og sætter ikke et antal dage, men pointen er, at underretningen ligger før ibrugtagningen.
Det samme gælder i en situation, der er lettere at overse: en aftale, der har kørt i årevis uden at være kritisk, bliver det, fordi kunden har flyttet mere over på den. Så udløser det også en underretning — og så kommer artikel 30, stk. 3, i spil på en kontrakt, der blev skrevet, da leverancen var perifer. Derfor kan du blive bedt om at genforhandle en aftale, hvor intet er ændret fra din side.
Du kan ikke fjerne kundens proces. Du kan gøre den hurtig. Tre ting virker i praksis:
Et ét-sides datablad med juridisk navn, CVR, LEI eller EUID, tjenestetype, leverings- og databehandlingsland samt underleverandører med rang. Det er præcis de felter, kunden mangler.
Et kontraktbilag, der tager stk. 2, litra a-i, og stk. 3, litra a-f, punkt for punkt. Kommer det fra dig, sætter du udgangspunktet — og undgår tre runder med kundens jurist.
En skriftlig exitplan med overgangsperiode, dataformat og roller — og en beskrevet revisionsmodel, så litra e kan opfyldes uden at åbne hele platformen for hver kunde.
Tre vilkår er årsag til de fleste sammenbrudte forhandlinger: exitstrategien med en obligatorisk overgangsperiode, den ubegrænsede revisions- og inspektionsret med ret til kopier på stedet, og pligten til at oplyse hvilke lande tjenesten leveres fra og data behandles i, med varsel før ændringer. Alle tre kan løses på forhånd.
Artikel 30, stk. 3, litra f, kræver exitstrategier med en obligatorisk, passende overgangsperiode, hvor du fortsætter med at levere, og som gør det muligt for kunden at skifte til en anden leverandør eller gå over til egne løsninger. Det er mere end et varsel. Det er en forpligtelse til at holde driften kørende, mens kunden flytter væk fra dig — også hvis det er dig, der har opsagt.
Kombineret med stk. 2, litra d, bliver billedet klart: data skal kunne udleveres i et letbrugeligt format ved insolvens, afvikling, ophør eller ved kontraktens udløb. Et eksportformat, der kun kan læses af dit eget system, opfylder ikke kravet. Har du proprietære datastrukturer, er det værd at beskrive eksportvejen præcist, inden nogen spørger — herunder hvad der følger med, og hvad der ikke gør.
Litra e giver løbende overvågningsret med ubegrænset adgang til inspektion og revision — for den finansielle virksomhed selv, for en tredjepart den udpeger, og for den kompetente myndighed. Der er ret til at tage kopier på stedet. Der skal være samarbejde ved inspektion på lokationen, og du skal oplyse om omfang, procedurer og hyppighed.
Det er hårde vilkår for en leverandør med delt infrastruktur, og forordningen anerkender det: litra e åbner for alternative sikkerhedsniveauer, hvis andre kunders rettigheder bliver berørt. Den praktiske løsning er sjældent at nægte adgang, men at tilbyde en model: en uafhængig erklæring med et defineret kontrolomfang, en årlig gennemgang med kundens revisor efter aftale, og en afgrænset fysisk adgang til de miljøer, der faktisk vedrører kunden. Er kunden mikrovirksomhed, kan revisionsretten uddelegeres til en uafhængig tredjepart, du selv udpeger.
Litra b kræver, at de lande eller regioner, hvor tjenesten leveres og data behandles, fremgår — inklusive lagringsstedet — og at du giver forudgående besked ved ændringer. For en dansk leverandør med drift i danske datacentre er det et konkurrencemæssigt fortrin, som er værd at skrive præcist: ikke „i EU“, men hvilken by, hvilket datacenter og hvilken backuplokation. De samme overvejelser gælder, når man skal dokumentere opbevaring af regnskabsmateriale i skyen, og pointen er den samme: præcis stedangivelse er lettere at godkende end en generel forsikring.
| Vilkår | Det, kunden skal have | Det, der normalt mangler | Hvad du kan gøre |
|---|---|---|---|
| Exitplan | Overgangsperiode med fortsat drift | Kun et opsigelsesvarsel | Skriv perioden, rollerne og dataformatet ned |
| Dataudlevering | Letbrugeligt format, også ved konkurs | Eksport kun til eget format | Dokumentér et åbent eksportformat |
| Revision | Adgang for kunde, tredjepart og myndighed | Henvisning til en generel erklæring | Tilbyd en konkret revisionsmodel med kontrolomfang |
| TLPT | Deltagelse og samarbejde, art. 26-27 | Ingen stillingtagen | Aftal rammer og varsling på forhånd |
| Dataplacering | Lande, regioner og lagringssted | „Inden for EU“ | Angiv lokation og backuplokation navngivet |
| Beredskab | Implementeret og testet kontinuitetsplan | Plan uden testdokumentation | Gem testrapporten og del resuméet |
Der findes ingen DORA-certificering for leverandører. Det, der afgør sagen, er en færdig dokumentpakke: identifikationskoder, kortlagt underleverandørkæde med rang og land, målbar SLA, hændelsesprocedure med tider, testet beredskab, exitplan og en beskrevet revisionsmodel.
Det er værd at sige klart, fordi der sælges meget på det modsatte: du kan ikke blive „DORA-godkendt“. Der findes ingen myndighedsgodkendelse, intet register over godkendte leverandører og ingen mærkningsordning. Hvad der findes, er en kunde med en konkret dokumentationsbyrde. Den leverandør, der gør byrden lille, vinder.
Bemærk, at flere af punkterne overlapper med krav, du måske allerede møder fra anden regulering. Leverer du produkter med digitale elementer, kender du dokumentationskravene fra Cyber Resilience Act. Er du underleverandør til en NIS2-omfattet virksomhed, har du allerede svaret på spørgeskemaer om leverandørkæden. Forskellen ved DORA er detaljeringsgraden: faste skemaer, faste felter og faste frister i timer.
Er din virksomhed omfattet, skal du føre registret, underrette Finanstilsynet om planlagte kritiske aftaler, sikre artikel 30-vilkårene i alle IKT-kontrakter og kunne vurdere hele underleverandørkæden. Små enheder kan være på den forenklede ramme i artikel 16, og nogle er helt uden for forordningen.
En del af vores kunder er på den anden side af bordet: forsikringsformidlere, mindre pensionsordninger, betalingsvirksomheder. Kernen i deres opgave er ikke teknisk, men administrativ. Den består af fire ting: et komplet register over alle IKT-kontrakter, en vurdering af hvilke funktioner der er kritiske eller vigtige, kontraktvilkår der lever op til artikel 30, og en løbende risikovurdering af forsyningskæden efter RTS 2025/532.
Det første skridt er altid det samme og kan gøres på en formiddag: en liste over hver enkelt it-leverandør, hvad de leverer, hvor data ligger, og om funktionen er kritisk. Erfaringen fra prøvekørslen siger, at det er netop dér fejlene opstår — ikke i sikkerhedsniveauet, men i de tomme felter.
Husk også proportionaliteten. Artikel 16 fritager små og ikke indbyrdes forbundne investeringsselskaber, undtagne betalingsinstitutter, undtagne e-pengeinstitutter og små arbejdsmarkedsrelaterede pensionskasser fra artikel 5-15 og sætter dem på en forenklet IKT-risikoramme. Og artikel 2, stk. 3, holder blandt andet pensionskasser med højst 15 medlemmer i alt og mikro- og SMV-forsikringsformidlere helt uden for DORA. Det er værd at fastslå, hvor man står, før man køber et compliance-værktøj.
„DORA blev ikke kun indført, fordi det eksterne risikobillede har ændret sig.“Adam Al-Saffar, kontorchef i Finanstilsynet, oktober 2025 — i forbindelse med tilsynets første temaundersøgelse af 14 forsikringsselskabers og pensionskassers DORA-implementering
Vi har samlet de krav, større og regulerede kunder stiller til deres it-leverandører — og hvad der skal ligge klar, inden spørgeskemaet lander. Særligt brugbar, hvis du leverer til finans, forsyning eller offentlige kunder.
Vi bruger kun din mail til at sende guiden og relevant information om leverandørkrav og it-sikkerhed. Du kan afmelde med ét klik.
Vi gennemgår jeres leverance mod DORA artikel 30 og registrets datafelter og giver jer en skriftlig liste over det, der mangler — identifikationskoder, kædekortlægning, svartider, exitplan. Derefter beslutter I selv, hvad I vil bruge den til.
„Vi sparer det, der svarer til en hel arbejdsdag om ugen på administration.“
Westwind, Admind-kunde i over 10 årFinanstilsynets liste over omfattede virksomheder slutter med „tredjepartsudbydere af IKT-tjenester“, så du står i forordningens anvendelsesområde. Men du kommer kun under direkte tilsyn, hvis du bliver udpeget som kritisk IKT-tredjepartsudbyder, og det er 19 virksomheder i hele EU blevet, alle af global størrelse. I praksis møder du DORA som kontraktkrav og dokumentationskrav fra din finansielle kunde.
Nej. Der findes ingen DORA-certificering, ingen myndighedsgodkendelse og intet register over godkendte leverandører. Det, der afgør sagen, er om du kan levere de oplysninger og kontraktvilkår, kunden skal kunne dokumentere. Bliver du tilbudt en „DORA-godkendelse“, er det en privat ydelse, ikke en officiel ordning.
Fordi registrets skemaer kræver, at IKT-tredjepartsudbydere, der er juridiske personer, identificeres med en gyldig og aktiv LEI-kode eller med deres EUID — og begge, hvis begge findes. En udløbet LEI tæller ikke som aktiv. Ved prøvekørslen i 2024 var der omkring 6.000 ugyldige LEI-koder på tredjepartsudbydere alene, så det er en reel og hyppig fejlkilde.
Nej. Kun de underleverandører, der reelt understøtter IKT-tjenester til kritiske eller vigtige funktioner, samt dem hvis forstyrrelse ville svække sikkerheden eller kontinuiteten i tjenesten. Øvrige underleverandører behøver ikke stå i registret. For hver af dem skal der oplyses navn, identifikationskode, rang og land.
Rangen er et naturligt tal på 1 eller derover, der angiver afstanden til den finansielle virksomhed. Den direkte udbyder har altid rang 1, og underleverandører har altid en højere rang. Jo lavere tal, jo tættere på kunden. Det er altså ikke en rangering af vigtighed, men en placering i kæden.
Ved IKT-tjenester, der understøtter kritiske eller vigtige funktioner, ja. Artikel 30, stk. 3, litra e, giver ubegrænset adgang til inspektion og revision for kunden, for en tredjepart kunden udpeger og for den kompetente myndighed, med ret til kopier på stedet. Bestemmelsen åbner dog for alternative sikkerhedsniveauer, hvis andre kunders rettigheder berøres, og en finansiel mikrovirksomhed kan uddelegere revisionsretten til en uafhængig tredjepart, du selv udpeger.
Ikke uden at sige det først. Artikel 30, stk. 2, litra b, kræver forudgående besked ved ændring af de lande eller regioner, hvor tjenesten leveres og data behandles. Og efter RTS (EU) 2025/532 skal væsentlige ændringer i underleverandørkæden til kritiske eller vigtige funktioner varsles på forhånd, hvorefter kunden kan gøre indsigelse og i sidste ende opsige aftalen.
Hurtigere end kundens frist. Kunden skal sende den indledende underretning hurtigst muligt og inden fire timer efter klassificering som væsentlig, og under alle omstændigheder senest 24 timer efter at have fået kendskab til hændelsen. Da kunden skal have faktuelle oplysninger fra dig for at kunne klassificere og udfylde skemaet, skal din første melding ligge markant under fire timer. Efter artikel 30, stk. 2, litra f, skal din bistand desuden ydes uden ekstra omkostning eller til en på forhånd fastsat pris.
Ja. DORA regulerer digital operationel modstandsdygtighed, ikke databeskyttelse. En leverance helt uden personoplysninger — for eksempel netværksdrift eller overvågning — er stadig en IKT-tjeneste og skal med i registret og følge artikel 30. Databehandleraftalen efter databeskyttelsesforordningen er en selvstændig forpligtelse, der kommer oven i, ikke i stedet for.
En gennemgang tager en formiddag. Resultatet er en liste, I kan handle på — og et datablad, I kan sende, næste gang nogen spørger.