DORA-forordningen — Digital Operational Resilience Act — er EU-lovgivningen om cyberrobusthed i den finansielle sektor. Den angiver, hvordan finansielle virksomheder skal håndtere cybersikkerhed og IT-risiko. Enkelt sagt skal alle banker, betalingsvirksomheder, investeringsselskaber, forsikringsselskaber og kryptobørser i EU kunne fortsætte driften under et hackerangreb, et cloud-nedbrud eller en fejlbehæftet softwareopdatering og holde øje med de IT-leverandører, de er afhængige af.
Denne vejledning er skrevet til personer uden juridisk eller IT-faglig baggrund. Den forklarer, hvem DORA gælder for, hvad den kræver, hvor hurtigt en hændelse skal indberettes, hvordan den adskiller sig fra NIS2 og GDPR, hvilke sanktioner der gælder, og hvad DORA-kravene betyder for fintech- og kryptovirksomheder. Den afsluttes med en kort DORA-tjekliste for compliance.
Hvad er DORA helt enkelt?
DORA — også kaldet EU DORA eller DORA Act — er forordning (EU) 2022/2554 om digital operationel robusthed i den finansielle sektor. »Digital operationel robusthed« lyder kompliceret, men betyder én ting: Kan din virksomhed fortsat betjene sine kunder, når IT’en svigter? Hvis en hacker får adgang, en opdatering fejler eller en leverandør går offline — gennemføres betalinger stadig, kan kunder stadig logge ind, og er deres data fortsat sikre? DORA gør dette spørgsmål til en juridisk pligt frem for blot god praksis.
Før DORA havde hvert EU-land og hver del af den finansielle sektor sine egne regler for IT-sikkerhed og egne hændelsesblanketter. DORA erstatter dette kludetæppe med ét regelsæt for hele EU’s finansielle sektor. Da den er en forordning og ikke et direktiv, gælder den ordret i alle medlemsstater — der kræves ingen national lov for at sætte den i kraft.
Fristen for DORA-compliance er allerede udløbet. Den toårige forberedelsesperiode efter vedtagelsen er afsluttet, alle DORA-forpligtelser er i kraft, og de nationale finanstilsyn kontrollerer dem. DORA-rammen bygger på fem søjler, som resten af denne vejledning gennemgår:
- ICT-risikostyring — en skriftlig plan for IT-risiko, ejet af ledelsesorganet (bestyrelsen);
- håndtering og indberetning af ICT-relaterede hændelser — at opdage, registrere og indberette IT-hændelser til tilsynsmyndigheden;
- test af digital operationel robusthed — fra rutinemæssige sårbarhedsscanninger til fulde »red team«-angrebssimuleringer;
- styring af ICT-tredjepartsrisiko — kontrol med de IT-leverandører, virksomheden er afhængig af, med et register over dem alle;
- informationsdeling — frivillig udveksling af trusselsefterretninger mellem finansielle enheder.
Resultater, ikke teknologier
DORA fortæller ikke, hvilken software eller leverandør du skal bruge. Den fastsætter resultater: vær robust, opdag problemer, genopret hurtigt og kontroller dine leverandører. Bestyrelsen er ansvarlig for at dokumentere, at resultaterne opnås, og ledelsesmedlemmer skal holde deres viden om IT-risiko ajour (forordningen nævner udtrykkeligt uddannelse). At overlade alt til IT-afdelingen og derefter glemme det er netop det, DORA forbyder.
Centrale DORA-begreber forklaret
En række definerede begreber går igen i hver artikel i DORA-forordningen, i alle tilsynsblanketter og leverandørkontrakter. Når du kender dem, bliver resten langt lettere at læse.
| Finansiel enhed | Forordningens betegnelse for en licenseret finansiel virksomhed — en af de tyve typer, der er opført i artikel 2. Har du en af disse licenser, er DORA rettet mod dig. |
|---|---|
| ICT-tredjepartsleverandør | Enhver virksomhed, der leverer IT til en finansiel enhed: cloud-hosting, software, datafeeds, administreret sikkerhed eller betalingsbehandling. |
| Kritisk ICT-tredjepartsleverandør (CTPP) | En meget stor leverandør — tænk på store cloudplatforme — som EU-myndighederne har udpeget til direkte tilsyn af en Lead Overseer, fordi så mange virksomheder er afhængige af den. |
| Kritisk eller vigtig funktion | En forretningsfunktion, hvis ophør alvorligt ville skade virksomhedens økonomi, bryde dens retlige forpligtelser eller afbryde dens licenserede tjenester. Betalinger og kundekonti er typiske eksempler. |
| Større ICT-relateret hændelse | En IT-hændelse, der er stor nok — målt på berørte kunder, varighed, mistede data eller beløb på spil — til at udløse obligatorisk indberetning til tilsynsmyndigheden. |
| Trusselsbaseret penetrationstest (TLPT) | En avanceret test, hvor etiske hackere angriber driftssystemer, som en reel angriber ville gøre. Kræves mindst hvert tredje år for virksomheder, som tilsynsmyndigheden har udpeget; tilsynet kan kræve den oftere. |
| Informationsregister | En struktureret oversigt over alle virksomhedens IT-kontrakter, der holdes opdateret og sendes til tilsynsmyndigheden mindst én gang om året. |
| Reguleringsmæssige tekniske standarder (RTS) | De detaljerede regler om »hvordan« — skabeloner, tærskler og metoder — som EU-myndighederne udsteder for at udfylde forordningen. |
Hvem gælder DORA for?
DORA’s anvendelsesområde fastsættes i artikel 2, der oplister tyve kategorier af finansielle enheder. Hvis en finansiel institution har en af disse licenser et sted i EU, er den omfattet — uanset hvor lille den er — medmindre en konkret undtagelse gælder. Hovedgrupperne fremgår nedenfor.
| Sektor | Hvem er omfattet | Godt at vide |
|---|---|---|
| Banker og betalinger | Banker, betalingsinstitutter, e-pengeinstitutter, udbydere af konto-oplysningstjenester | Udstedere af e-pengetokens under MiCA er omfattet, fordi de skal være banker eller e-pengeinstitutter |
| Investeringer og fonde | Investeringsselskaber, fondsforvaltere (AIFM’er og UCITS), handelspladser, centrale modparter, værdipapircentraler | Små og ikke-forbundne investeringsselskaber følger en lempeligere ramme |
| Kryptoaktiver | Udbydere af kryptoaktivtjenester og udstedere af aktivbaserede tokens | Begge er godkendt under MiCA og omfattet fra den dag, licensen gives |
| Forsikring og pension | Forsikringsselskaber, genforsikringsselskaber, forsikringsformidlere, arbejdsmarkedsrelaterede pensionskasser | Mikro-, små og mellemstore formidlere er undtaget |
| Markedsdata og infrastruktur | Kreditvurderingsbureauer, dataindberetningsudbydere, transaktions- og securitiseringsregistre, administratorer af kritiske benchmarks | Flere af disse er under direkte tilsyn på EU-niveau |
| Andet | Crowdfundingplatforme, ICT-tredjepartsleverandører | Se nedenfor, hvordan IT-leverandører er omfattet |
Hvad med IT-virksomhederne selv? Cloudplatforme, datacentre, softwareleverandører og virksomheder med administrerede sikkerhedstjenester er ikke finansielle enheder, men DORA når dem på to måder. For det første skal alle finansielle enheder indarbejde DORA-lignende vilkår i deres kontrakter med dem, så en leverandør, der afviser, risikerer at miste kunden. For det andet udpeges de største leverandører — store cloud-, datacenter-, tele- og finanssoftwareleverandører — som kritiske ICT-tredjepartsleverandører og er under direkte tilsyn på EU-niveau; listen opdateres hvert år.
Gælder DORA for virksomheder uden for EU? Direkte kun virksomheder med licens i EU — herunder EU-datterselskaber og filialer af britiske, amerikanske eller asiatiske koncerner. Indirekte når den alle udenlandske leverandører, der betjener en EU-finansiel virksomhed, fordi de obligatoriske kontraktklausuler gælder, uanset hvor leverandøren er baseret. En ikke-EU-leverandør, der udpeges som kritisk, skal oprette et EU-datterselskab inden for tolv måneder.
Endelig er DORA forholdsmæssig: Forpligtelserne vokser med den finansielle institutions størrelse og kompleksitet. Mikrovirksomheder — færre end ti ansatte og under to millioner euro i omsætning eller balancesum — undtages fra flere krav, herunder trusselsbaseret penetrationstest og visse ledelses- og indberetningspligter. En defineret gruppe af mindre virksomheder, såsom små og ikke-forbundne investeringsselskaber og visse undtagne betalings- og e-pengeinstitutter, følger en forenklet ramme for ICT-risikostyring efter artikel 16. At være lille tager ikke en licenseret virksomhed ud af DORA; det letter blot byrden.
DORA-krav: De fem søjler forklaret
Kravene til DORA-compliance falder i fem grupper. Sammen udgør de én cyklus — forebyg, opdag, reager, genopret, lær — og tilsynsmyndigheden forventer dokumentation for hvert trin.
Ramme for ICT-risikostyring (artikel 5–16)
Med enkle ord: Kend den IT, du har, vid hvad der kan gå galt, og hav en skriftlig plan for at beskytte og gendanne den. Rammen skal opliste IT-aktiver og afhængigheder, angive hvordan virksomheden forebygger og opdager problemer, hvordan den reagerer og genopretter, og hvordan den lærer af hændelser. Den gennemgås mindst én gang om året og efter hver større hændelse. Ledelsesorganet godkender den, afgør hvor stor risiko der er acceptabel, og stiller budgettet til rådighed. Kritiske funktioner skal kortlægges, backup skal reelt testes, og der skal være en IT-kontinuitetsplan ved siden af virksomhedens generelle kontinuitetsplan.
Hændelsesindberetning: Fristerne på 4 timer, 72 timer og én måned
Alle ICT-relaterede hændelser skal registreres og klassificeres efter de samme kriterier i hele EU: hvor mange kunder der blev berørt, hvor meget virksomhedens omdømme led, hvor længe hændelsen varede, hvor langt den spredte sig, hvilke data der gik tabt, hvor kritisk tjenesten var, og hvor mange penge der var på spil. En hændelse, der overskrider tærsklerne, er »større« og skal indberettes til tilsynsmyndigheden i tre trin: første underretning inden for fire timer efter afgørelsen om, at den er større (og aldrig senere end 24 timer efter, at virksomheden blev bekendt med den), en foreløbig rapport inden for 72 timer efter første underretning og en endelig rapport inden for en måned efter den foreløbige. Kunder, hvis penge eller data påvirkes, skal underrettes uden unødig forsinkelse. Alvorlige cybertrusler, der ikke er blevet til hændelser, kan indberettes frivilligt.
Robusthedstest og trusselsbaseret penetrationstest (TLPT)
Test af digital operationel robusthed er et årligt program: Hvert system, der understøtter en kritisk eller vigtig funktion, skal gennemgå sårbarhedsscanninger, gapanalyser, kildekodegennemgange, scenarietests, ydelsestests og penetrationstests. Virksomheder, som tilsynsmyndigheden anser for væsentlige — på grund af deres størrelse eller konsekvenserne af deres svigt — skal desuden udføre trusselsbaseret penetrationstest mindst hvert tredje år. Det er et kontrolleret angreb på driftssystemer foretaget af kvalificerede etiske hackere efter en anerkendt ramme. Mikrovirksomheder og virksomheder under den forenklede ramme er undtaget fra TLPT og tester efter en lempeligere, risikobaseret plan.
Tredjepartsrisiko, outsourcing og informationsregistret
Outsourcing af IT — til en cloudtjenesteudbyder eller andre — outsourcer ikke ansvaret. Styring af ICT-tredjepartsrisiko starter med en skriftlig strategi for leverandørrisiko; virksomheden skal kontrollere leverandører før underskrivelse, undgå at være for afhængig af én leverandør og føre et informationsregister — en struktureret liste over alle IT-kontrakter — der sendes til tilsynsmyndigheden mindst én gang om året. Kontrakterne skal indeholde et fast sæt klausuler: Hvad tjenesten er og hvilket niveau der loves, hvor data lagres, retten til inspektion og revision, pligten til at hjælpe under hændelser, hvordan kontrakten kan opsiges, og hvordan virksomheden ville skifte til en anden leverandør, hvis nødvendigt. Virksomheden forbliver fuldt ansvarlig, selv når leverandøren er en kritisk leverandør under tilsyn på EU-niveau.
Informationsdeling om cybertrusler
Finansielle enheder kan udveksle trusselsefterretninger — angrebsmønstre og kompromitteringsindikatorer — i betroede grupper. Ingen tvinges til at deltage, men en virksomhed, der gør det, skal underrette sin tilsynsmyndighed, og udvekslingen skal respektere regler om fortrolighed og databeskyttelse.
DORA vs. NIS2 vs. GDPR: Sådan hænger reglerne sammen
Tre EU-regler overlapper om cyberrobusthed og hændelsesindberetning, og mange finansielle institutioner er omfattet af mere end én. Tabellen viser, hvem hver regel omfatter, og hvordan indberetningsfristerne adskiller sig.
| Forhold | DORA | NIS2-direktivet | GDPR |
|---|---|---|---|
| Hvem den omfatter | Finansielle virksomheder og deres IT-leverandører | Væsentlige og vigtige enheder i atten kritiske sektorer, herunder bankvirksomhed | Alle, der behandler personoplysninger |
| Hvad den beskytter | Kontinuiteten i finansielle tjenester og deres IT | Netværks- og informationssikkerhed i kritiske sektorer | Fysiske personers personoplysninger |
| Frist for første rapport | Inden for 4 timer efter klassificering, højst 24 timer fra kendskab | Tidlig varsling inden for 24 timer | Inden for 72 timer til databeskyttelsesmyndigheden |
| Opfølgende rapporter | Foreløbig efter 72 timer; endelig inden for én måned | Underretning efter 72 timer; endelig inden for én måned | Trinvis, efterhånden som fakta bliver kendt |
| Retsform | Forordning — gælder direkte | Direktiv — hvert land vedtager sin egen lov | Forordning — gælder direkte |
| Hvordan de forholder sig | Specialreglen: Går forud for NIS2 for finansielle virksomheder | Gælder kun finansielle virksomheder, hvor DORA ikke regulerer forholdet | Gælder parallelt; én hændelse kan udløse begge |
I praksis indberetter en finansiel virksomhed IT-hændelser til sit finanstilsyn, ikke til den nationale cybersikkerhedsmyndighed. GDPR gælder parallelt: Hvis et cyberangreb lækker kundedata, indberetter virksomheden det to gange — efter DORA til finanstilsynet og efter GDPR til databeskyttelsesmyndigheden — efter to forskellige tidsfrister.
DORA og krypto: Hvad det betyder for CASP’er og tokenudstedere
For kryptovirksomheder fungerer DORA-forordningen og MiCA-rammen som et par. MiCA afgør, hvem der må levere kryptotjenester eller udstede tokens i EU; DORA afgør, hvordan teknologien bag disse tjenester skal drives. En udbyder af kryptoaktivtjenester, der er godkendt under MiCA, er en finansiel enhed under DORA fra det øjeblik, licensen gives, og det samme gælder enhver udsteder af aktivbaserede tokens. MiCA henviser selv til DORA for IT- og sikkerhedskrav, så alle tilsynsmyndigheder læser de to sammen.
I praksis kontrolleres robusthed allerede under licensprocessen, ikke kun bagefter. Når en tilsynsmyndighed gennemgår en CASP-ansøgning, indgår IT-risikorammen, forretningskontinuitetsplanen, hændelsesprocedurerne og outsourcingordningerne i materialet, og DORA er målestokken. En kryptobørs eller depotforvalter kan ikke få — eller beholde — sin licens med en robusthedsplan, der kun findes på papiret.
Kryptovirksomheder har også IT-afhængigheder, som en bank ikke har: opbevaring af private nøgler, blockchain-nodeudbydere, tredjeparts wallet-infrastruktur, smart contract-komponenter og markeder, der handler døgnet rundt uden vedligeholdelsesvindue. Under DORA er hver af disse et IT-aktiv eller et leverandørforhold, der skal oplistes, klassificeres, kontraktreguleres og testes. Sådan kommer ulicenserede leverandører af hosting, nøglehåndtering eller blockchain-infrastruktur også til at opfylde DORA: gennem deres kunders kontrakter.
DORA-sanktioner, bøder og konsekvenser ved manglende compliance
Der findes ingen samlet EU-dækkende tabel over DORA-sanktioner. I stedet pålægger artikel 50 hver medlemsstat at fastsætte sanktioner, der er »effektive, forholdsmæssige og afskrækkende«, og giver tilsynsmyndighederne beføjelse til at kræve dokumenter, gennemføre inspektioner, påbyde rettelser og offentliggøre advarsler. Den nationale kompetente myndighed i hver medlemsstat anvender dem efter sektorens egen licenslovgivning, så en bank, en betalingsvirksomhed og en kryptobørs hver møder deres sektors egen sanktionsstige.
Du har måske set en »DORA-bøde« på én procent af den gennemsnitlige daglige globale omsætning. Tallet er reelt, men det retter sig mod nogen andre: Det er den daglige bøde, de europæiske tilsynsmyndigheder kan pålægge en kritisk ICT-tredjepartsleverandør, der ignorerer en tilsynsafgørelse, i op til seks måneder. Det er ikke en bøde for banker eller kryptovirksomheder. De »2 % af den årlige omsætning«, som nogle gange nævnes sammen med den, findes heller ikke i DORA: De kommer fra NIS2, hvor det er det minimumsloft, landene skal fastsætte for væsentlige enheder. For en finansiel virksomhed er de realistiske konsekvenser:
- tilsynsforanstaltninger — påbud om at rette forhold, begrænsninger af aktiviteter og i alvorlige tilfælde suspension eller tab af licensen;
- administrative bøder efter sektorens nationale lovgivning;
- personligt ansvar for bestyrelsesmedlemmer, fordi DORA gør bestyrelsen ansvarlig for IT-rammen;
- strafferetligt ansvar i lande, der har valgt at indføre det, hvilket artikel 52 tillader;
- omdømme- og forretningsskade — tabte kunder, bankpartnere og investorer.
Licensrisiko for MiCA-godkendte virksomheder
For en udbyder af kryptoaktivtjenester er den største risiko selve licensen. Solid IT-governance er en betingelse for at få en MiCA-licens, så gentagne DORA-svigt kan behandles som manglende opfyldelse af godkendelsesbetingelserne — ikke blot som en enkeltstående compliance-overtrædelse.
Hvem fører tilsyn med DORA? Myndigheder på nationalt plan og EU-plan
Det daglige DORA-tilsyn ligger hos den myndighed, der allerede licenserer virksomheden — centralbanken eller finanstilsynet i dens hjemmedlemsstat. Denne kompetente myndighed modtager hændelsesrapporter og informationsregistre, afgør hvem der skal gennemføre TLPT, og kontrollerer IT-risikorammen som led i det almindelige tilsyn. De fleste offentliggør DORA-vejledning, skabeloner og frister på deres websteder.
På EU-plan deler tre organer arbejdet: Den Europæiske Værdipapir- og Markedstilsynsmyndighed, Den Europæiske Banktilsynsmyndighed og EIOPA, tilsynsmyndigheden for forsikring og pension. De udarbejder de tekniske standarder, der udfylder detaljerne, og udpeger i fællesskab de kritiske ICT-tredjepartsleverandører, som hver derefter føres tilsyn med af én af de tre som Lead Overseer.
DORA-tjekliste for compliance: Sådan overholder du reglerne
Uanset om en virksomhed ansøger om licens eller allerede er under tilsyn, dokumenterer det samme sæt dokumenter DORA-compliance under en revision. Et praktisk udgangspunkt for en DORA-implementeringsplan eller gapanalyse:
- Bekræft dit anvendelsesområde: Hvilken kategori i artikel 2 du tilhører, og om den forenklede ramme eller en mikrovirksomhedsundtagelse gælder.
- Kortlæg alle IT-aktiver, systemer og dataflows, der understøtter en kritisk eller vigtig funktion.
- Vedtag en politik for ICT-risikostyring, der er godkendt af bestyrelsen, med navngivne ansvarlige og årlig gennemgang.
- Indfør hændelsesklassificering, en hændelseslog og indberetningsskabeloner, der matcher de lovbestemte frister.
- Udarbejd en årlig testkalender, og kontroller om tilsynsmyndigheden har sat dig på TLPT-listen.
- Udarbejd informationsregistret over alle IT-leverandører, og opdatér deres kontrakter med de obligatoriske klausuler.
- Kontrollér koncentrationsrisiko, og udarbejd exitplaner for leverandører, der understøtter kritiske funktioner.
- Test backup, gendannelse og IT-kontinuitetsplanen mindst én gang om året.
- Uddan bestyrelsen, og gem dokumentation for, at uddannelsen fandt sted.
Eesti Firma rådgiver fintech- og kryptovirksomheder om den juridiske side af DORA: afklaring af hvilke forpligtelser der gælder, tilpasning af IT-rammen til MiCA-licenskrav, gennemgang af leverandørkontrakter og forberedelse af de dokumenter, en tilsynsmyndighed forventer at se. Kontakt os for at drøfte, hvordan forordningen gælder for din virksomhed.
Ofte stillede spørgsmål om DORA
DORA står for Digital Operational Resilience Act, en EU-forordning med ensartede regler om ICT-risikostyring, hændelsesindberetning, robusthedstest og tredjepartsrisiko i den finansielle sektor. Den gælder direkte i alle medlemsstater og er fuldt i kraft.
For tyve kategorier af EU-licenserede finansielle institutioner — banker, betalings- og e-pengeinstitutter, investeringsselskaber, fondsforvaltere, forsikringsselskaber, udbydere af kryptoaktivtjenester og markedsinfrastrukturer — samt gennem kontrakter og EU-tilsyn for de IT-leverandører, der betjener dem.
Ja. Forberedelsesperioden efter vedtagelsen er afsluttet, og alle forpligtelser gælder fuldt ud. Tilsynsmyndighederne behandler nu DORA som en del af almindelig licensering og inspektion, ikke som et kommende projekt.
Kun for deres EU-licenserede datterselskaber og filialer. Leverandører uden for EU, der betjener EU-finansielle virksomheder, bindes indirekte af obligatoriske kontraktvilkår, og en ikke-EU-leverandør, der udpeges som kritisk, skal oprette et EU-datterselskab inden for tolv måneder.
NIS2 er et generelt cybersikkerhedsdirektiv for kritiske sektorer; DORA er den specialiserede forordning for finanssektoren. Hvor begge kan gælde, har DORA forrang for IT-risikostyring og hændelsesindberetning, og finansielle virksomheder indberetter til deres finanstilsyn frem for den nationale cybersikkerhedsmyndighed.
Ja. Udbydere af kryptoaktivtjenester og udstedere af aktivbaserede tokens med licens under MiCA er finansielle enheder under DORA. Udstedere af e-pengetokens er omfattet som banker eller e-pengeinstitutter. Ulicenserede leverandører til disse virksomheder opfylder DORA indirekte gennem kontraktvilkår.
I tre trin: Første underretning inden for fire timer efter klassificering af hændelsen som større og senest 24 timer efter kendskab til den, en foreløbig rapport inden for 72 timer efter den første og en endelig rapport inden for en måned efter den foreløbige.
Sanktioner for finansielle virksomheder fastsættes i national ret efter artikel 50 og håndhæves af det nationale tilsyn. De spænder fra påbud om at rette problemer over bøder til tab af licensen. Tallet på én procent af den daglige globale omsætning er en bøde for kritiske ICT-tredjepartsleverandører under EU-tilsyn, ikke for finansielle virksomheder.
Ja, men forholdsmæssigt. Mikrovirksomheder undtages fra trusselsbaseret penetrationstest, det faste årlige testkrav og visse ledelsespligter, og en defineret gruppe af mindre virksomheder følger en forenklet ramme for ICT-risikostyring. At være lille tager ikke en licenseret virksomhed ud af anvendelsesområdet.
