DORA i praksis: Kan jeres beredskab følge med AI-drevne cyberangreb?

Du får indblik i Finanstilsynets fokus på avanceret AI og cyberrisici i finanssektoren.

Du ser, hvordan DORA forbinder BIA, beredskabsplaner, testresultater og hændelser.

Du får fire konkrete kontrolpunkter, som ledelsen kan bruge i næste beredskabstest.

Den 21. august 2026 opfordrede Finanstilsynet finansielle virksomheder til at vurdere, hvordan avancerede AI-modeller påvirker deres cyberrisiko. Budskabet er ikke, at alle cyberangreb nu er automatiserede, men at AI kan hjælpe angribere med at finde og udnytte sårbarheder hurtigere og i større skala. Den praktiske udfordring under DORA er derfor, om virksomheden kan omsætte ændringer i trusselsbilledet til dokumenterede beslutninger og et beredskab, der er afprøvet i praksis.

Hvad betyder Finanstilsynets udmelding i praksis?

Finanstilsynets budskab er, at finansielle virksomheder ikke længere kan vurdere deres cyberrisiko ud fra, hvordan kendte angreb hidtil har udviklet sig. Når AI kan hjælpe angribere med hurtigere at identificere sårbarheder, tilpasse phishingangreb og gennemføre angreb i større skala, kan virksomhedens tid til at opdage, reagere og genoprette blive kortere.

Det stiller konkrete krav til det eksisterende arbejde under DORA. Virksomheden bør kunne dokumentere, hvem der følger udviklingen i AI-relaterede cybertrusler, hvornår nye trusler fører til en opdateret risikovurdering, og om ændringerne kræver nye sikkerhedsforanstaltninger eller beredskabstests. Hvis trusselsbilledet ændrer sig, skal det med andre ord kunne ses i virksomhedens beslutninger, planer og testscenarier – ikke kun i en orientering til ledelsen.

Finanstilsynet peger blandt andet på ansvar hos bestyrelse og direktion, effektiv sårbarheds- og opdateringsstyring samt opdaterede genopretningsplaner. Udmeldingen indfører ikke nye særskilte krav, men skærper forventningen om, at virksomhederne bruger DORA aktivt til at håndtere nye cyberrisici.

DORA kræver, at finansielle virksomheder etablerer et risikobaseret program for test af deres digitale operationelle modstandsdygtighed. For virksomheder skal alle IKT-systemer og applikationer, som understøtter kritiske eller vigtige funktioner, testes mindst én gang om året. Identificerede svagheder skal prioriteres, håndteres og efterfølgende kontrolleres. Trusselsbaseret penetrationstest, TLPT, er et mere avanceret krav, som kun gælder udvalgte finansielle virksomheder og som udgangspunkt skal gennemføres mindst hvert tredje år.

Det betyder, at et ændret trusselsbillede også skal kunne ændre virksomhedens testprogram. Hvis AI kan hjælpe angribere med at udnytte en sårbarhed hurtigere end tidligere, bør virksomheden undersøge, om dens overvågning, beslutningsveje og beredskab er hurtige nok. Resultatet skal kunne spores fra den opdaterede trusselsvurdering til et relevant testscenarie, konkrete forbedringer og en efterfølgende kontrol af, om de virker.

Nets-inspektionen viser konsekvensen af manglende sammenhæng

I en inspektionsredegørelse fra 10. juli 2026 vurderede Finanstilsynet, at Nets Denmark havde væsentlige mangler i styringen af IKT-risici, beredskab og IKT-tredjepartsrisici. Tilsynet fandt blandt andet en utilstrækkelig sammenhæng mellem beredskabsmålsætninger, forretningskonsekvensanalysen, testresultater og erfaringer fra hændelser.

Finanstilsynet vurderede samtidig, at manglerne havde bidraget til, at to konkrete IKT-hændelser fik mere alvorlige konsekvenser, end de ellers ville have haft. Redegørelsen gælder Nets, men den viser en bredere DORA-relevant risiko: En kritisk funktion kan ikke nødvendigvis opretholdes eller genoprettes som planlagt, hvis mål, afhængigheder, planer og test ikke bygger på de samme forudsætninger.

Forretningskonsekvensanalysen, BIA, skal vise, hvilke funktioner der er kritiske, hvad de afhænger af, og hvor længe organisationen kan acceptere, at de er afbrudt. Beredskabs- og kontinuitetsplanerne skal omsætte dette til handling. Test og reelle hændelser skal derefter bruges til at kontrollere forudsætningerne og opdatere planerne. Ellers risikerer virksomheden at basere sit beredskab på afhængigheder, tidsgrænser eller handlemuligheder, som ikke holder under en reel hændelse.

Fire kontrolpunkter til næste beredskabstest

1. Test konsekvensen for en kritisk funktion

Tag udgangspunkt i en konkret funktion, eksempelvis betalinger, handel eller kundeadgang. Antag derefter, at en sårbarhed bliver udnyttet, før virksomheden normalt ville nå at installere en sikkerhedsopdatering. Test, hvilke systemer, kunder og leverandører der bliver påvirket, hvor hurtigt konsekvenserne udvikler sig, og om tidsgrænserne i virksomhedens BIA fortsat er realistiske.

2. Mål tiden fra varsel til handling

Registrer, hvor lang tid der går, fra at virksomheden modtager et varsel, til det berørte system er identificeret, risikoen er vurderet, og en handling er godkendt. Test også, hvem der kan beslutte at isolere et system, gennemføre en hasteændring, iværksætte en midlertidig sikkerhedsforanstaltning eller acceptere risikoen.

Hvis en teknisk løsning er klar, men afventer en beslutning eller en utilgængelig godkender, ligger svagheden i organisationens reaktionsevne.

3. Kontroller, at testen fører til forbedringer

Efter testen bør virksomheden registrere, hvilke antagelser der ikke holdt, hvilke oplysninger der manglede, og hvilke afhængigheder der forsinkede reaktionen eller genopretningen. Resultaterne skal bruges til at opdatere relevante risikovurderinger, beredskabsplaner, forretningskonsekvensanalyser og procedurer for sårbarhedshåndtering.

Hvert fund bør have en ansvarlig, en frist og en tydelig prioritet. Når forbedringen er gennemført, skal virksomheden kontrollere, at den faktisk løser det identificerede problem.

4. Test leverandørernes rolle i beredskabet

Hvis en leverandør understøtter den valgte funktion, bør testen også omfatte leverandørens varsling, eskalation, tekniske bistand og genopretning. Virksomheden skal blandt andet vide, hvem der kontaktes uden for normal arbejdstid, hvilke oplysninger leverandøren kan levere, og om alternative arbejdsgange eller exitplaner virker.

AI ændrer ikke virksomhedens ansvar for leverandørstyringen, men hurtigere angreb kan gøre uklare kontaktveje og uprøvede aftaler mere kritiske.

Ledelsen behøver ikke en lang teknisk rapport efter hver test. Den har derimod brug for et overblik, der viser, hvor beredskabet svigter, og om besluttede forbedringer bliver gennemført. Det kan eksempelvis omfatte:

tiden fra varsel til godkendt handling

kritiske funktioner med en opdateret og afprøvet BIA

testfund, hvor fristen for afhjælpning er overskredet

kritiske leverandørafhængigheder uden et afprøvet alternativ

planer, der endnu ikke er opdateret efter test eller hændelser

Tallene skal ikke dokumentere, at virksomheden er fri for risiko. De skal vise, om den kan opdage ændringer, træffe beslutninger og genoprette kritiske funktioner inden for de fastsatte tidsgrænser.

Nesp.ONEs guide til en IT-beredskabsplan kan bruges som grundstruktur for blandt andet roller, kritiske processer og genopretningsmål. DORA-omfattede virksomheder skal samtidig indarbejde forordningens sektorspecifikke krav og deres egen juridiske og tilsynsmæssige vurdering.

Det afgørende er, at et nyt AI-understøttet angrebsscenarie ikke alene bliver beskrevet i en risikovurdering. Det skal føre til en vurdering af, om virksomhedens beslutningsveje, beredskabsplaner, leverandøraftaler og test fortsat er tilstrækkelige.