DORA’s testprogram: hvor TLPT ligger i forhold til de øvrige test

Den trusselsbaserede penetrationstest, TLPT, er det mest omtalte testkrav i DORA, men den gælder kun for de virksomheder, myndighederne udpeger. Det almindelige testprogram i DORA artikel 24 og 25 gælder derimod for alle finansielle virksomheder, der ikke er mikrovirksomheder, også de udpegede. Gennemgangen bygger på den danske tekst af forordningen.

Kort fortalt skal alle finansielle virksomheder, der ikke er mikrovirksomheder, have et forsvarligt og omfattende program for test af digital operationel modstandsdygtighed som en del af deres ramme for IKT-risikostyring. Programmet skal indeholde relevante test, fra sårbarhedsscanninger til penetrationstest, og alle systemer, der understøtter kritiske eller vigtige funktioner, skal testes mindst én gang om året. TLPT er et ekstra lag for de udpegede. Teksten er ikke juridisk rådgivning.

Artikel 24: programmet

Artikel 24, stk. 1, beskriver formålet: at vurdere beredskabet til at håndtere IKT-relaterede hændelser, finde svagheder, mangler og huller i modstandsdygtigheden og straks rette dem. Programmet er en integreret del af rammen for IKT-risikostyring i artikel 6 og skal udarbejdes, vedligeholdes og gennemgås.

De øvrige stykker sætter rammerne:

Indhold · programmet skal omfatte en række vurderinger, test, metoder, fremgangsmåder og værktøjer efter artikel 25 og 26 (stk. 2).
Risikobaseret · testene vælges ud fra en risikobaseret tilgang, der tager hensyn til trusselsbilledet, virksomhedens særlige risici og aktivernes betydning (stk. 3).
Uafhængighed · test gennemføres af uafhængige parter, interne eller eksterne; interne testere kræver tilstrækkelige ressourcer og fravær af interessekonflikter (stk. 4).
Afhjælpning · der skal være procedurer for at prioritere, klassificere og afhjælpe problemer og interne metoder til at validere, at de er afhjulpet fuldt ud (stk. 5).
Hyppighed · passende test af alle IKT-systemer og applikationer, der understøtter kritiske eller vigtige funktioner, mindst én gang om året (stk. 6).

Artikel 25: testtyperne

Artikel 25, stk. 1, nævner som eksempler på relevante test sårbarhedsvurderinger og scanninger, open source-analyser, vurderinger af netsikkerheden, mangelanalyser, fysiske sikkerhedsgennemgange, spørgeskemaer og scanningsløsninger, gennemgang af kildekode, hvor det er praktisk muligt, scenariebaserede test, kompatibilitetstest, præstationstest, end-to-end-test og penetrationstest. Listen er ikke en tjekliste, der skal gennemføres i sin helhed, men et katalog, som programmet skal vælge relevant fra efter proportionalitetsprincippet i artikel 4, stk. 2.

Stk. 2 stiller et særligt krav til værdipapircentraler og centrale modparter om sårbarhedsvurderinger, før nye eller ændrede applikationer, infrastrukturkomponenter og IKT-tjenester bag kritiske funktioner tages i brug. Stk. 3 giver mikrovirksomheder en mere fleksibel tilgang. Penetrationstest som disciplin er forklaret på opslagsværket penetrationtest.dk, som også har et kort opslag om finanssektoren.

Artikel 26: det ekstra lag

TLPT står i artikel 26. Kravet rammer kun de virksomheder, myndighederne har identificeret efter artiklens stk. 8, og aldrig mikrovirksomheder eller virksomheder under den forenklede ramme i artikel 16. De skal mindst hvert tredje år gennemføre en avanceret, efterretningsbaseret red team-test af flere eller alle kritiske eller vigtige funktioner på produktion. → DORA-TLPT forklaret

Betragtning 56 forklarer logikken. Test skal spænde fra grundlæggende vurderinger til avancerede test ved hjælp af TLPT, og den avancerede test bør kun kræves af virksomheder, der set fra et IKT-perspektiv er modne nok til at gennemføre den. Betragtningen nævner betalinger, bankvirksomhed samt clearing og afvikling som områder, hvor TLPT er mest relevant. → Hvem skal gennemføre TLPT?

Sådan hænger lagene sammen

For en udpeget virksomhed erstatter TLPT ikke testprogrammet. Den årlige test af systemerne bag de kritiske funktioner, procedurerne for afhjælpning og valideringen gælder fortsat. TLPT lægger en test ovenpå, der afprøver, om forsvaret som helhed kan opdage og reagere på en målrettet modstander, og om mennesker, processer og teknologi spiller sammen.

Omvendt er en virksomhed uden TLPT-krav ikke fritaget for test. Den skal stadig have et program, der er forsvarligt og omfattende i forhold til dens risiko, og den skal teste systemerne bag sine kritiske eller vigtige funktioner hvert år. Forskellen ligger i dybden og formen, ikke i, om der testes. → Finansielle virksomheder uden TLPT-krav

Hvor frivillig red teaming kan passe ind

Artikel 25 nævner scenariebaserede test og penetrationstest, men ikke red teaming som selvstændig testtype. Om en frivillig red team-øvelse kan indgå i programmet som en af de nævnte test, er en vurdering, virksomheden selv må foretage og kunne begrunde over for sit tilsyn. Øvelsen bliver under alle omstændigheder ikke en TLPT, og den kan ikke bruge betegnelsen. → Red teaming uden for TIBER-rammen

Det, der taler for at tage den med i overvejelserne, er formålet i artikel 24: at vurdere beredskabet til at håndtere hændelser. Det er netop det spørgsmål, en red team-øvelse er bygget til at belyse. → Red teaming i sikkerhedsprogrammet

Programmet som styringsværktøj

Programmet er ikke kun en liste over test. Fordi det er en del af rammen for IKT-risikostyring, skal det kunne forklare, hvorfor netop disse test er valgt, hvem der udfører dem, og hvad der sker med resultaterne. For en CISO er det nyttigt at kunne vise sammenhængen mellem trusselsbilledet, de kritiske funktioner, de valgte testtyper og opfølgningen på fundene.

Et tænkt eksempel: et forsikringsselskab uden TLPT-krav har årlige penetrationstest af kundeportalen og skadesbehandlingen, løbende sårbarhedsscanning og en årlig beredskabsøvelse. Programmet beskriver, hvorfor de valg passer til selskabets risiko, og hvordan fund prioriteres og valideres. Hvis selskabet overvejer en red team-øvelse, skal den også kunne begrundes i programmet og ikke stå for sig selv.

Spørgsmål til jeres eget program

☐ Dækning · er alle systemer bag kritiske eller vigtige funktioner testet inden for det seneste år?
☐ Valg af test · kan I forklare, hvorfor programmet indeholder de testtyper, det gør, og ikke andre?
☐ Uafhængighed · er testerne uafhængige af de systemer, de tester?
☐ Afhjælpning · findes der procedurer for prioritering og validering af rettelser?
☐ Udvikling · tester programmet også opdagelse og reaktion, ikke kun forebyggelse?

Det skal I lade være med

At sidestille DORA’s testkrav med TLPT · det brede krav om et testprogram står i artikel 24 og 25.
At se TLPT som erstatning for den årlige test · kravene gælder side om side.
At kalde en frivillig øvelse TLPT · betegnelsen hører til forordningens ramme.
At vælge testtyper efter vane · programmet skal være risikobaseret.

Hvad kan og ikke kan konkluderes

DORA bygger test op i lag: et risikobaseret program for alle finansielle virksomheder, der ikke er mikrovirksomheder, og TLPT for de udpegede. Forordningen siger ikke, hvilke konkrete test den enkelte virksomhed skal vælge, og den kræver ikke red teaming uden for TLPT. Hvad tilsynet forventer i det konkrete tilfælde, må afklares med tilsynet. → Når kunder eller tilsyn spørger til red teaming

Kilder

Forordning (EU) 2022/2554 (DORA): artikel 4, stk. 2, om proportionalitet, artikel 24, stk. 1 til 6, om testprogrammet, artikel 25, stk. 1 til 3, om testtyper, artikel 26, stk. 1, om TLPT og betragtning 56.

Senest gennemgået: oktober 2026.