Mange af kravene i DORA skærpes, når en IKT-tjeneste understøtter det, forordningen kalder en kritisk eller vigtig funktion. Det gælder kontrakterne med leverandørerne, registret over aftaler, testprogrammet og vurderingen af, om en hændelse er større. Klassificeringen af jeres funktioner er derfor en af de første beslutninger, en finansiel virksomhed skal have på plads, og den bør træffes af ledelsen på et dokumenteret grundlag. Artiklen forklarer definitionen, viser hvor begrebet går igen, og beskriver, hvem der beslutter, og hvornår listen skal tages op igen.
Definitionen i artikel 3, nr. 22
Forordningen (EU) 2022/2554 beskriver en kritisk eller vigtig funktion ud fra virkningen af et svigt. En funktion hører til, når en forstyrrelse af den kan forringe virksomhedens finansielle resultater væsentligt eller svække robustheden eller kontinuiteten i dens tjenester og aktiviteter. Den hører også til, når afbrydelse, fejl eller svigt i væsentlig grad kan forringe opfyldelsen af betingelserne for tilladelsen eller andre pligter efter den finansielle lovgivning.
Der er altså to spor. Det første handler om forretningen og kunderne. Det andet handler om tilladelsen og regeloverholdelsen. En funktion, der næsten ingen betydning har for indtjeningen, kan derfor stadig være kritisk eller vigtig, fordi virksomheden ellers ikke kan opfylde en lovpligt, fx indberetning eller kundebeskyttelse.
Bemærk, at definitionen taler om funktioner. Klassificeringen starter derfor ved det, virksomheden gør, fx betalinger, kundeoprettelse, skadebehandling eller porteføljeforvaltning. Systemer og leverandører kommer bagefter, når man spørger, hvad der understøtter de funktioner.
Hvor begrebet går igen
Når listen først findes, bruges den mange steder i forordningen. De vigtigste for ledelsen er:
- Art. 3, nr. 10. En større IKT-relateret hændelse er en hændelse med stor negativ indvirkning på systemer, der understøtter kritiske eller vigtige funktioner. Listen bliver dermed en del af beslutningen om, hvorvidt der skal indberettes.
- Art. 5, stk. 2, litra i. Ledelsesorganet skal have indberetningskanaler, så det får besked om aftaler med IKT-leverandører og om planlagte væsentlige ændringer og deres mulige virkning på disse funktioner.
- Art. 24. Testprogrammet skal omfatte test mindst årligt for systemer, der understøtter kritiske eller vigtige funktioner.
- Art. 28. Politikken for IKT-tjenester, der understøtter sådanne funktioner (stk. 2), registret, der skal skelne mellem disse aftaler og de øvrige (stk. 3), vurderingen før en ny aftale (stk. 4) og exitstrategierne (stk. 8).
- Art. 30, stk. 3. De ekstra kontraktkrav om præstationsmål, varsler, leverandørens beredskab, deltagelse i trusselsbaserede test, adgang og revision samt exit med overgangsperiode.
Også beredskabet bygger på listen. Hvilke funktioner der skal genoprettes først, er et naturligt udgangspunkt for planerne for indsats og genopretning efter art. 11. For de virksomheder, der bruger den forenklede ramme i art. 16, kræver stk. 1, litra f, at kontinuiteten af de kritiske eller vigtige funktioner sikres med planer, der mindst omfatter backup og gendannelse.
Hvem beslutter klassificeringen
Forordningen udpeger ikke en bestemt person til at klassificere. Den placerer til gengæld ansvaret for IKT-risikostyringen i sidste instans hos ledelsesorganet (art. 5, stk. 2, litra a), og det er ledelsesorganet, der godkender politikken for brug af IKT-leverandører (litra h). Når klassificeringen styrer, hvilke aftaler der falder ind under den politik, giver det god mening, at bestyrelsen godkender listen og begrundelsen.
I praksis kan arbejdet deles sådan:
- Forretningsområderne beskriver deres funktioner og, hvad et svigt vil betyde for kunderne, økonomien og tilladelsen.
- Den, der leder sikkerhedsarbejdet, sammenholder beskrivelserne med kortlægningen af systemer og afhængigheder efter art. 8 og skriver et udkast med begrundelse for hver funktion.
- Direktionen indstiller listen.
- Bestyrelsen godkender den og ser, hvilke leverandører og aftaler der dermed bliver omfattet af de skærpede krav.
Begrundelsen er den vigtigste del af dokumentet. Står der kun et ja eller nej ud for hver funktion, kan ingen senere se, hvorfor en tjeneste blev holdt uden for. Skriv for hver funktion, hvad et svigt vil ramme, og hvilket af de to spor i definitionen der er afgørende.
For mange eller for få
Klassificeringen har en pris i begge retninger. Bliver for mange funktioner klassificeret som kritiske eller vigtige, får virksomheden flere aftaler med skærpede kontraktvilkår, flere systemer i den årlige test og mere arbejde med exitplaner, end risikoen berettiger. Bliver for få klassificeret, mangler beskyttelsen netop der, hvor et svigt vil gøre mest skade, og virksomheden kan komme til at undervurdere en hændelse.
Art. 4 om proportionalitet giver plads til at tilpasse indsatsen efter størrelse og kompleksitet. Den ændrer ikke på definitionen. En mindre virksomhed har typisk færre funktioner, men den kan ikke vælge en funktion fra, fordi kravene virker tunge.
Hvornår listen tages op igen
En klassificering er et øjebliksbillede. Den skal gennemgås, når grundlaget ændrer sig, og der er flere faste anledninger:
- Før en ny IKT-aftale. Art. 28, stk. 4, kræver, at virksomheden før aftalen tager stilling til, om den berører en kritisk eller vigtig funktion, se før en ny IKT-aftale.
- Når en funktion skifter status. Efter art. 28, stk. 3, skal myndigheden underrettes rettidigt, når en funktion bliver kritisk eller vigtig.
- Ved den årlige gennemgang af rammen. Art. 6, stk. 5, kræver en årlig gennemgang og en ny efter større hændelser. Listen hører naturligt med.
- Når forretningen ændrer sig. Et nyt produkt, en ny kundegruppe eller en ny tilladelse kan skabe funktioner, der ikke fandtes før.
Gennemgangen behøver ikke være lang. Den skal vise, at nogen har spurgt, om listen stadig passer, og hvad svaret blev. Ændringer føres videre til registret og leverandørstyringen.
Sammenhængen med registret
I informationsregistret efter art. 28, stk. 3, skal aftalerne til kritiske eller vigtige funktioner kunne skilles fra resten. Er klassificeringen uklar, bliver registret det også. Ejeren af registret bør derfor have adgang til den godkendte liste og få besked, når den ændres. Hvordan registret ejes og holdes ajour, står i informationsregistret, og den løbende styring af leverandørerne i leverandørstyring.
Det skal I lade være med
- At klassificere systemer i stedet for funktioner. Start med det, virksomheden gør, og find derefter systemerne.
- At overse sporet om tilladelsen. En funktion kan være kritisk eller vigtig alene fordi en lovpligt hviler på den.
- At lade leverandøren afgøre klassificeringen. Vurderingen er jeres, og leverandøren kan kun bidrage med oplysninger.
- At godkende listen uden begrundelser. Uden dem kan beslutningen ikke forklares over for revision eller tilsyn.
Det skal I kræve af den eksterne
- ☐ En skabelon, hvor forretningsområderne beskriver funktion, virkning af svigt og afgørende spor i definitionen.
- ☐ Et udkast til listen med begrundelse for hver funktion, klar til bestyrelsens godkendelse.
- ☐ En oversigt over de systemer, leverandører og aftaler, hver funktion hviler på.
- ☐ En kort beskrivelse af, hvilke krav i art. 24, 28 og 30 listen udløser.
- ☐ Faste anledninger til gennemgang, skrevet ind i årshjulet.
Kilder
- Forordning (EU) 2022/2554 (DORA), EUR-Lex: art. 3, nr. 10 og 22, art. 4, art. 5, stk. 2, litra a, h og i, art. 6, stk. 5, art. 8, art. 11, art. 16, stk. 1, litra f, art. 24, art. 28, stk. 2 til 4 og 8, og art. 30, stk. 3.
- Finanstilsynet: Underretning om planlagt kontraktlig ordning (outsourcing) i henhold til DORA: underretning, når aftaler understøtter kritiske eller vigtige funktioner.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Kontrakten med IT-leverandøren efter DORA · Ledelsen og testprogrammet
→ Kontakt · Tlf. 70 13 63 23 · CISO as a Service hos Nielco IT
