Digital suverænitet

DORA og exitstrategien: finanssektorens krav som model for andre

DORA og exitstrategien: finanssektorens krav som model for andre

Få regelsæt beskriver så præcist som DORA, hvad en exitstrategi for en IKT-leverandør skal indeholde. Kravene gælder kun den finansielle sektor, men opbygningen kan bruges af alle, der vil have en exit-plan, som kan tåle at blive testet.

Artiklen gennemgår, hvad forordning (EU) 2022/2554, DORA, og tre delegerede forordninger kræver om exit. Den slutter med, hvad organisationer uden for finanssektoren kan låne. Den vurderer ingen konkrete virksomheders efterlevelse.

Hvem DORA gælder for

DORA gælder fra 17. januar 2025 (artikel 64) og gælder umiddelbart i alle medlemsstater. Artikel 2 opregner de finansielle enheder, blandt andet kreditinstitutter, betalingsinstitutter, investeringsselskaber, forsikringsselskaber og arbejdsmarkedsrelaterede pensionskasser. I Danmark samler Finanstilsynet sit materiale om forordningen under tilsynet med IKT- og datasikkerhed.

Kravene skal opfyldes proportionalt efter enhedens størrelse, risikoprofil og kompleksitet (artikel 4). Mikrovirksomheder og de enheder, der må bruge den forenklede ramme i artikel 16, er undtaget fra kravet om en egentlig strategi for IKT-tredjepartsrisiko i artikel 28, stk. 2.

Kritiske eller vigtige funktioner

Exitkravene gælder IKT-tjenester, der understøtter kritiske eller vigtige funktioner. Artikel 3, nr. 22, definerer det som en funktion, hvis forstyrrelse i væsentlig grad kan forringe enhedens resultater, robusthed eller kontinuitet. Det gælder også funktioner, hvis svigt kan forringe overholdelsen af tilladelsen eller de finansielle regler.

Den delegerede forordning (EU) 2024/1773 kræver i artikel 3, stk. 2, at enheden har en metode til at afgøre, hvilke tjenester der er omfattet, og fastlægger, hvornår vurderingen gennemgås. Afgrænsningen kommer altså før selve exitplanen. Uden en klar metode kan for mange eller for få tjenester blive omfattet.

Exitstrategien i artikel 28, stk. 8

Artikel 28, stk. 8, kræver exitstrategier for IKT-tjenester, der understøtter kritiske eller vigtige funktioner. Strategierne skal tage højde for svigt hos leverandøren, forringet kvalitet, driftsforstyrrelser og væsentlige risici ved fortsat brug. De skal også dække en opsigelse af en af grundene i stk. 7.

Enheden skal kunne opsige aftalen uden at afbryde forretningen, uden at begrænse efterlevelsen af reglerne og uden at skade kunderne. Exitplanerne skal være omfattende, veldokumenterede, testet i tilstrækkeligt omfang og gennemgået regelmæssigt. Omfanget af testen følger proportionalitetskriterierne i artikel 4, stk. 2, så en lille enhed kan teste enklere end en stor.

Bestemmelsen stiller også krav til indholdet. Enheden skal identificere alternative løsninger og udarbejde overgangsplaner, så tjenesterne og de relevante data kan flyttes sikkert og fuldstændigt til en anden udbyder eller tilbage til egen drift. Der skal desuden være beredskabsforanstaltninger, så driften kan opretholdes.

Bemærk, at loven sidestiller to veje ud. Tjenesten kan flyttes til en anden udbyder, eller den kan tages tilbage i egen drift. En exitstrategi kan altså bygge på egen drift, så længe den peger på en konkret vej.

De fire opsigelsesgrunde

Artikel 28, stk. 7, kræver, at aftalen som minimum kan opsiges i fire situationer:

  • væsentlig overtrædelse af love eller kontraktvilkår hos leverandøren,
  • forhold, der viser sig under overvågningen og kan ændre leverancen, herunder væsentlige ændringer hos leverandøren,
  • dokumenterede svagheder i leverandørens IKT-risikostyring, fx i beskyttelsen af data,
  • at den kompetente myndighed ikke længere kan føre effektivt tilsyn på grund af aftalens vilkår.

Den sidste grund er interessant for en jurisdiktionsvurdering. Den knytter opsigelsesretten til myndighedens adgang til at føre tilsyn med aftalen.

Kontrakten efter artikel 30

Artikel 30, stk. 2, kræver for alle IKT-aftaler blandt andet, at kontrakten angiver de regioner eller lande, hvor tjenesterne leveres, og hvor data behandles og lagres (litra b). Leverandøren skal give besked på forhånd, hvis stederne skal ændres. Kontrakten skal også sikre adgang til og tilbagelevering af data i et lettilgængeligt format ved insolvens, afvikling eller opsigelse (litra d).

For kritiske eller vigtige funktioner kræver stk. 3, litra f, exitstrategier med en obligatorisk overgangsperiode, hvor leverandøren fortsat leverer. Hvordan kravet omsættes til kontrakttekst, er gennemgået i → trin 8 om kontrakten.

Exitplan for hver aftale

Forordning 2024/1773 uddyber politikken for brug af IKT-tjenester til kritiske eller vigtige funktioner. Artikel 10 kræver en dokumenteret exitplan for hver aftale og periodisk gennemgang og test af den.

Planen skal tage højde for tre situationer: uforudsete og vedvarende driftsafbrydelser, mangelfuld levering og uventet opsigelse. Den skal være realistisk, gennemførlig og bygge på plausible scenarier og rimelige antagelser. Den skal have en tidsplan, der passer til kontraktens vilkår for opsigelse.

Artikel 1 nævner de forhold, politikken skal tage hensyn til. Blandt dem er, hvor leverandøren eller dens moderselskab er beliggende (litra b), og om tjenesten leveres fra et tredjeland (litra c). Også muligheden for at flytte tjenesten til en anden leverandør nævnes (litra i). Litra f og g skelner mellem leverandører under tilsyn af en myndighed i en medlemsstat og leverandører under tilsyn i et tredjeland. Efter artikel 3 gennemgår ledelsesorganet politikken mindst én gang om året.

Genopretning og jurisdiktion

Den delegerede forordning (EU) 2024/1774 om IKT-risikostyring stiller krav til planerne for indsats og genopretning. Artikel 26, stk. 2, opregner scenarier, enheden skal tage hensyn til.

Litra b nævner svigt eller insolvens hos en relevant IKT-leverandør. Litra h nævner politisk og social ustabilitet, hvor det er relevant også i leverandørens jurisdiktion og der, hvor data lagres og behandles. Jurisdiktion indgår altså som et selvstændigt scenarie i finanssektorens beredskab. Forskellen mellem beredskabsplan og exit-plan er beskrevet i → exitstrategi, exit-plan og beredskabsplan.

Underleverandører og opsigelse

Den delegerede forordning (EU) 2025/532 handler om underentreprise af IKT-tjenester til kritiske eller vigtige funktioner. Efter artikel 6 kan enheden aftale, at aftalen ophører, hvis leverandøren gennemfører væsentlige ændringer i underentreprisen trods indsigelse. Det gælder også ændringer uden godkendelse og underentreprise, som kontrakten ikke tillader.

Bestemmelsen gør leverandørkæden til en mulig udløser af exit. Kortlægningen af kæden er beskrevet i → trin 3.

Registeret over aftaler

Artikel 28, stk. 3, kræver et register over alle aftaler om IKT-tjenester fra tredjepartsudbydere. Finanstilsynet oplyser, at omfattede virksomheder indsender registeret årligt via e-Reg, og at fristen i 2026 var 31. marts. Registeret er grundlaget for at se, hvor mange kritiske funktioner der hviler på samme leverandør, jf. → koncentrationsrisiko.

Hvad andre organisationer kan låne

DORA forpligter kun finansielle enheder. For andre er kravene en tjekliste for, hvad en exit-plan bør kunne. NIS2 har sine egne krav, jf. → NIS2 og leverandørstyring.

  1. Afgræns de kritiske tjenester · Lav en enkel metode til at udpege de tjenester, hvis svigt rammer kerneopgaven, og gennemgå den årligt.
  2. Én plan pr. aftale · Skriv en kort exitplan for hver kritisk aftale med tre scenarier: længere nedbrud, dårlig leverance og pludselig opsigelse.
  3. Peg på alternativet · Notér en navngiven anden udbyder eller egen drift for hver kritisk tjeneste, jf. → trin 7.
  4. Kend stederne · Notér, hvor tjenesten leveres, hvor data ligger, og hvor moderselskabet hører hjemme, jf. → trin 2.
  5. Skriv udløsere ind · Brug de fire opsigelsesgrunde og ændringer i underleverandører som udløsere for planen.
  6. Test planen · Gennemfør mindst en skrivebordsøvelse, og notér, hvad der manglede, jf. → trin 9.
  7. Lad ledelsen godkende · Lad ledelsen gennemgå planerne årligt, som DORA kræver af politikken.

Uden for finanssektoren giver → Data Act cloudkunder en lovfæstet ret til skifte og overgang, som kan understøtte planen.

Hvad DORA kan og ikke kan som model

DORA giver en gennemprøvet struktur, et fælles sprog og konkrete krav til både plan, kontrakt og test. Den knytter exit til ledelsens ansvar og til tilsynets adgang, og den medtager jurisdiktion som risikofaktor.

Den siger ikke, hvilke leverandører der er acceptable, og den kræver ikke en europæisk leverandør. Den fastsætter heller ingen længde på overgangsperioden. Artikel 30 kræver blot en passende periode, så længden må aftales og begrundes i hver kontrakt. Forordningen er skrevet til regulerede finansielle enheder med tilsyn og ressourcer til det. En mindre organisation bør tage strukturen og skære omfanget ned, jf. → exit-plan i en lille organisation.

Betydningen for exit-planen

DORA viser, at en exitstrategi kan beskrives så konkret, at den kan kontrolleres. Det gælder en plan pr. aftale, scenarier med datoer, et navngivet alternativ og en test, der er gennemført.

Begynd med de tre til fem tjenester, hvis bortfald rammer hårdest, og skriv for hver af dem en plan efter DORA’s opbygning. En uvildig exit-plan pr. kritisk system kan bruges, når planerne skal skrives med et eksternt blik på organisationens eget materiale.

Kilder

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal afhængigheden kortlægges?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad anledningen er. Så vender jeg tilbage. Jeg sælger rådgivning, ikke produkter, og har ingen leverandørpartnerskaber.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.