Kritiske eller vigtige funktioner: grundlaget for TLPT’s scope

I en trusselsbaseret penetrationstest efter DORA er det ikke systemerne, der er udgangspunktet, men virksomhedens kritiske eller vigtige funktioner. Hvilke funktioner der vælges, bestemmer testens omfang, scenarier og flag. Gennemgangen bygger på DORA artikel 3 og 26 i den danske tekst, på de tekniske reguleringsstandarder i Kommissionens delegerede forordning (EU) 2025/1190 og på Nationalbankens implementeringsdokument for TIBER-DK.

Kort fortalt skal hver TLPT omfatte flere eller alle kritiske eller vigtige funktioner og foregå på de produktionssystemer, der understøtter dem. Virksomheden vurderer selv, hvilke funktioner der skal med, men myndigheden validerer resultatet, og virksomhedens ledelsesorgan skal godkende dokumentet om afgrænsningen. Teksten er ikke juridisk rådgivning.

Hvad begrebet dækker

DORA artikel 3, nr. 22, definerer en kritisk eller vigtig funktion som en funktion, hvis forstyrrelse i væsentlig grad kan forringe virksomhedens finansielle resultater eller robustheden eller kontinuiteten af dens tjenester og aktiviteter. Det gælder også en funktion, hvis afbrydelse, fejl eller svigt i væsentlig grad kan forringe virksomhedens evne til at opfylde betingelserne for sin tilladelse eller andre forpligtelser efter den finansielle regulering.

Definitionen er bred og forretningsorienteret. Den handler om, hvad virksomheden ikke kan undvære, ikke om hvilke servere der er vigtigst. Betragtning 70 i DORA tilføjer, at funktioner, der er kritiske efter EU’s regler om genopretning og afvikling af banker, også er omfattet.

Hvad artikel 26 kræver

Efter artikel 26, stk. 2, skal hver test omfatte flere eller samtlige kritiske eller vigtige funktioner og foretages på live-produktionssystemer, der understøtter dem. Virksomheden skal identificere alle relevante underliggende systemer, processer og teknologier, herunder tjenester, der er outsourcet til tredjepartsudbydere. Herefter vurderer virksomheden, hvilke funktioner der skal med, og resultatet bestemmer testens nøjagtige omfang og valideres af myndighederne.

Betragtning 59 i DORA understreger, at forordningen ikke kræver, at alle funktioner indgår i én test. Virksomheden kan frit afgøre, hvilke og hvor mange funktioner der tages med. → DORA-TLPT forklaret

Kriterierne for at tage en funktion med

De tekniske standarder giver i artikel 9, stk. 7, syv kriterier, som virksomheden skal tage hensyn til:

funktionens kritiske betydning og mulige indvirkning på den finansielle sektor og den finansielle stabilitet i EU og nationalt
funktionens betydning for virksomhedens daglige forretning
muligheden for at erstatte funktionen
sammenhængen med andre funktioner
funktionens geografiske placering
andre virksomheders afhængighed af funktionen
trusselsefterretning om funktionen, hvor den findes

Betragtning 17 i standarderne tilføjer, at virksomheden ikke kun bør se på den økonomiske betydning, men også på en funktions symbolske eller politiske status. Kriterierne gør valget til en vurdering af både virksomhedens og samfundets afhængighed. Den samme liste går igen i TIBER-DK, hvor kontrolteamet skal bruge kriterierne, når funktionerne til testen udvælges, og når valget begrundes over for Nationalbankens team.

Afgrænsningsdokumentet

Valget skal dokumenteres i et dokument om afgrænsning af anvendelsesområdet, hvis indhold står i bilag II til standarderne. Dokumentet skal liste alle de kritiske eller vigtige funktioner, virksomheden har identificeret, også dem, der ikke kommer med. For de fravalgte skal årsagen angives. For de valgte skal dokumentet bl.a. angive begrundelsen, de understøttende IKT-systemer, om de er outsourcet og til hvem, i hvilke jurisdiktioner de bruges, og foreløbige flag med angivelse af, om de handler om fortrolighed, integritet, autenticitet eller tilgængelighed.

Efter artikel 9, stk. 6, skal dokumentet sendes til testlederne senest seks måneder efter myndighedens meddelelse, og virksomhedens ledelsesorgan skal godkende det. → Ledelsens godkendelse

Et tænkt eksempel

Forestil jer en bank, der har identificeret betalingsformidling, kundernes netbank, långivning og bankens egen likviditetsstyring som kritiske eller vigtige funktioner. Betalingsformidlingen har stor betydning for andre virksomheder og er svær at erstatte. Netbanken har mange afhængigheder og en tydelig symbolsk betydning. Kernesystemet bag flere af funktionerne drives af en ekstern leverandør i et andet land.

Kontrolteamet kan vælge betalingsformidling og netbank til testen og begrunde fravalget af de to andre funktioner. Det skal stadig liste dem i dokumentet, angive leverandøren og jurisdiktionen for kernesystemet og formulere foreløbige flag, fx om integriteten af en betalingsinstruks eller fortroligheden af kundedata. Eksemplet viser, at valget er en afvejning, der skal kunne forklares for både ledelse og myndighed.

Sådan foregår det i TIBER-DK

I TIBER-DK begynder arbejdet tidligt. Kontrolteamet laver en foreløbig liste over de kritiske funktioner og de systemer, der understøtter dem, og drøfter den med Nationalbankens TIBER Cyber Team på et møde før det egentlige scope-arbejde. Ifølge implementeringsdokumentet kan oversigter over systemarkitekturen og interne risikovurderinger bruges til at få overblik.

Scope-dokumentet skal godkendes af TCT og attesteres af den øverste ledelse. Dokumentet nævner, at nogle af de valgte funktioner måske ikke bliver testet, afhængigt af hvilke scenarier der vælges. Efter aftale med TCT kan andre roller, processer og teknologier tages med, hvis det ikke går ud over testen af de kritiske funktioner. Flag skal fastsættes for hver funktion og kan justeres senere i forløbet. → Målet for øvelsen

Det, der allerede bør findes

DORA artikel 8, stk. 1, kræver i forvejen, at virksomheden identificerer, klassificerer og dokumenterer sine IKT-understøttede forretningsfunktioner, de aktiver, der understøtter dem, og deres afhængigheder, og at klassificeringen vurderes mindst én gang om året. En virksomhed, der har gjort det arbejde grundigt, har et godt udgangspunkt for afgrænsningen. For CISO’en er spørgsmålet, om oversigten er detaljeret nok til at pege på konkrete systemer og leverandører.

☐ Funktionsliste · findes der en aktuel liste over kritiske eller vigtige funktioner, som ledelsen kender?
☐ Afhængigheder · er systemer, processer og leverandører bag hver funktion kortlagt?
☐ Outsourcing · ved I, hvilke funktioner der understøttes af tredjepartsudbydere og i hvilke lande?
☐ Begrundelser · kan I forklare, hvorfor en funktion er valgt til eller fra?

Leverandørernes rolle er beskrevet for sig. → IKT-tredjepartsudbydere i TLPT

Det skal I lade være med

At starte med systemlisten · afgrænsningen begynder med funktionerne og deres betydning.
At udelade outsourcede funktioner for nemheds skyld · de skal identificeres og begrundes som alle andre.
At lade sikkerhedsfunktionen vælge alene · forretningen kender funktionernes betydning, og ledelsesorganet skal godkende.
At sætte flag, der ikke kan forklares for ledelsen · de skal knyttes til en funktion og et sikkerhedsaspekt.

Hvad kan og ikke kan konkluderes

Kritiske eller vigtige funktioner er det, der gør TLPT forretningsrelevant, fordi testen måles på, hvor tæt en modstander kommer på de funktioner, virksomheden ikke kan undvære. Begrebet siger ikke, at funktioner uden for testen er sikre, og en enkelt test dækker ikke nødvendigvis alle funktioner. Frivillige øvelser kan låne tankegangen, men afgrænses efter jeres eget formål. → Scope i red teaming

Kilder

Forordning (EU) 2022/2554 (DORA): artikel 3, nr. 22, om definitionen, artikel 8, stk. 1, om identifikation, artikel 26, stk. 2, om testens omfang og betragtning 59 og 70.
Kommissionens delegerede forordning (EU) 2025/1190: artikel 9, stk. 6 og 7, bilag II om afgrænsningsdokumentet og betragtning 17.
Danmarks Nationalbank, TIBER-DK Implementation Document, version 4.1: foreløbig liste og møde om afgrænsning (s. 15 og 16), scope-dokument, flag og attestation (s. 19 og 20).

Senest gennemgået: oktober 2026.