Hvorfor DORA krever motstandsdyktighetstesting
Testing av digital operasjonell motstandsdyktighet er den fjerde pilaren i DORA. Art. 24 til 27 etablerer en strukturert tilnærming for å verifisere at finansielle enheter kan motstå, håndtere og gjenopprette seg etter IKT-relaterte forstyrrelser. Forordningen behandler testing ikke som en sporadisk revisjonsøvelse, men som et løpende program som er integrert i enhetens rammeverk for IKT-risikostyring.
Logikken bak art. 24 er enkel: et risikostyringsrammeverk som aldri er testet mot realistiske scenarier gir kun teoretisk trygghet. DORA krever at enheter validerer sine forsvarsmekanismer gjennom praktiske, repeterbare testaktiviteter som dekker hele spekteret av IKT-systemer som understøtter kritiske eller viktige funksjoner.
Testresultater skal føres tilbake inn i rammeverket for IKT-risikostyring. Dersom en sårbarhetsvurdering avdekker en uoppdatert eksponering, eller en scenariotest viser at en gjenopprettingsprosess overskrider definert RTO, skal disse funnene utløse utbedringstiltak. Denne tilbakekoblingen mellom testing og risikostyring er et sentralt krav i art. 24(5), og er ett av områdene tilsynsmyndighetene forventes å granske ved stedlige tilsyn.
DORA skiller mellom to nivåer av testing. Alle enheter innenfor virkeområdet må gjennomføre grunnleggende testing etter art. 25. En undergruppe av større eller systemviktige enheter må i tillegg gjennomføre avansert Threat-Led Penetration Testing (TLPT) etter art. 26 og 27. Forholdsmessighetsprinsippet i art. 4 gjelder gjennomgående, noe som betyr at omfanget og dybden av testprogrammet skal gjenspeile enhetens størrelse, risikoprofil og kritikaliteten til dens IKT-tjenester.
Grunnleggende testprogram
Art. 25 setter grunnlinjen. Alle finansielle enheter innenfor DORAs virkeområde må etablere og vedlikeholde et testprogram som dekker alle kritiske IKT-systemer og -applikasjoner. Programmet skal stå i forhold til enhetens størrelse og forretningsmodell, men minimumsforventningen er tydelig: årlig testing av kritiske systemer ved hjelp av et definert sett med metoder.
Forordningen og RTS 2024/1774 angir følgende typer testing som bør inngå i det grunnleggende programmet:
1 Sårbarhetsvurderinger
Systematisk skanning av IKT-systemer for å identifisere kjente sårbarheter, feilkonfigurerte tjenester og utdaterte komponenter. Sårbarhetsvurderinger bør dekke både eksternt eksponerte systemer og intern infrastruktur som understøtter kritiske funksjoner. Resultater skal klassifiseres etter alvorlighetsgrad og følges opp til utbedring.
2 Nettverkssikkerhetsgjennomganger
Vurdering av nettverksarkitektur, segmentering, brannmurregler og tilgangskontroller. Disse gjennomgangene verifiserer at nettverksdesignet begrenser skadeomfanget ved et eventuelt kompromiss, og at kommunikasjon mellom segmenter er begrenset til det som er operasjonelt nødvendig. Beskyttelsestiltak i art. 9 valideres her.
3 Gap-analyse
En strukturert sammenligning av enhetens nåværende IKT-risikonivå mot DORA-kravene og gjeldende RTS/ITS. Gap-analysen identifiserer områder der retningslinjer, kontroller eller prosesser ennå ikke oppfyller den regulatoriske standarden. DORA GRC tilbyr et gratis gap-analyseverktøy som dekker alle fem pilarer i 25 spørsmål.
4 Kildekodegjennomgang
Der det er gjennomførbart og risikomessig hensiktsmessig, gjennomgang av applikasjonskildekode for å identifisere sikkerhetsfeil, usikre kodemønstre og logikkbaserte sårbarheter. Dette gjelder særlig egenutviklede systemer som understøtter kritiske eller viktige funksjoner. Automatiserte statiske analyseverktøy kan supplere manuelle gjennomganger.
5 Scenariobasert testing
Simuleringsøvelser som tester enhetens respons på spesifikke IKT-forstyrrelsesscenarier, som et løsepengevirus-angrep, bortfall av en kritisk tredjepartsleverandør, eller datasentersvikt. Scenarioer bør utledes fra enhetens risikoregister og trusselbildeanalyse. Resultatene validerer beredskaps- og katastrofegjenopprettingsplaner som kreves etter art. 11.
6 Ytelsestesting
Belastningstesting, stresstesting og kapasitetstesting av kritiske IKT-systemer for å verifisere at de håndterer forventede toppvolumer og degraderer kontrollert under unormale forhold. Ytelsestesting er særlig viktig for systemer som understøtter sanntids transaksjonsbehandling eller markedsrettede tjenester.
Avanserte TLPT-krav
Threat-Led Penetration Testing går utover standard sikkerhetstesting. TLPT simulerer reelle angrepsteknikker mot levende produksjonssystemer ved bruk av aktuell trusselinformasjon rettet mot den spesifikke enheten og dens sektor. Metodikken er definert i RTS 2025/1190 og er tilpasset TIBER-EU-rammeverket som flere EU-medlemsland allerede benytter.
TLPT er ikke valgfritt for utpekte enheter. Nasjonale tilsynsmyndigheter identifiserer hvilke enheter som må gjennomføre TLPT basert på kriterier i art. 26(8), herunder enhetens systemviktighet, IKT-risikoprofil og arten av de kritiske funksjonene den utfører. Når en enhet er utpekt, skal den gjennomføre TLPT minst hvert tredje år.
| Aspekt | Grunnleggende testing (art. 25) | TLPT (art. 26–27) |
|---|---|---|
| Hvem må gjennomføre | Alle finansielle enheter innenfor virkeområdet | Enheter utpekt av tilsynsmyndighet basert på systemviktighet |
| Frekvens | Minst årlig | Minst hvert 3. år |
| Omfang | Alle kritiske IKT-systemer | Kritiske funksjoner og levende produksjonssystemer |
| Metodikk | Standard sikkerhetstestmetoder | Etterretningsbasert, simulerer reelle trusselaktører (RTS 2025/1190) |
| Testere | Interne eller eksterne | Kvalifiserte eksterne testere påkrevd; intern deltakelse begrenset |
| Tilsynskoordinering | Ikke påkrevd | Obligatorisk: tilsynsmyndigheten skal varsles før testing starter |
| Tredjepartsinvolvering | Ikke påkrevd | Kritiske IKT-leverandører skal inkluderes i testomfanget |
Art. 27 stiller ytterligere krav til TLPT-testerne selv. De skal være sertifiserte eller akkrediterte, ha yrkesansvarsforsikring og ikke ha interessekonflikter med enheten som testes. Der det er mulig, bør enheter rotere testere mellom TLPT-sykluser. Tilsynsmyndigheten kan akseptere bruk av interne testere for visse faser, men minst én ekstern tester skal være involvert i enhver TLPT-øvelse.
Kritiske IKT-tredjepartsleverandører som understøtter funksjoner innenfor TLPT-omfanget, skal delta i testingen. Art. 26(3) krever at TLPT-omfanget inkluderer IKT-tjenestene som leveres av disse tredjepartene. Dersom en leverandør nekter å delta, skal enheten dokumentere dette og varsle tilsynsmyndigheten, som kan vurdere det som et tilsynsmessig anliggende under rammeverket for leverandørovervåking.
Styring av testprogrammet
DORA behandler ikke testing som en isolert aktivitet. Art. 25 krever at testprogrammet integreres i rammeverket for IKT-risikostyring og underlegges styringsmessig overvåking. Ledelsesorgan skal godkjenne testprogrammet og motta rapportering om resultater og identifiserte avvik.
Sentrale styringskrav for testprogrammet omfatter:
Programmet skal dokumenteres og definere omfanget av testing, metodene som benyttes, frekvens for hvert system, og kriterier for å avgjøre om en test er bestått eller ikke bestått. Det skal også definere hvordan funn prioriteres, tildeles ansvarlige og følges opp til utbedring.
Testresultater skal rapporteres til ledelsesorganet og brukes til å oppdatere IKT-risikoregisteret. Etter art. 24(5) skal alle sårbarheter, svakheter eller avvik som avdekkes under testing, håndteres raskt og fullstendig. Utbedringstiltak skal dokumenteres og verifiseres gjennom retesting der det er hensiktsmessig.
Testprogrammet skal gjennomgås og oppdateres minst årlig for å gjenspeile endringer i enhetens IKT-landskap, trusselbilde og forretningsdrift. Nye systemer, nye leverandører og vesentlige endringer i eksisterende infrastruktur bør utløse en revurdering av testomfanget.
For enheter som er underlagt TLPT, gjelder ytterligere styringskrav. Tilsynsmyndigheten skal varsles før TLPT starter, og resultatene samt utbedringsplanen skal deles med tilsynsmyndigheten etter gjennomføring. Enhetens ledelsesorgan skal formelt ta stilling til TLPT-funnene og godkjenne utbedringsplanen.
Hva gjelder for mindre enheter
Art. 4 i DORA innfører et forholdsmessighetsprinsipp som gjennomsyrer alle fem pilarer. For motstandsdyktighetstesting innebærer dette at mindre og enklere enheter ikke forventes å operere det samme testprogrammet som en systemviktig bank.
Enheter som kvalifiserer som mikrobedrifter etter EU-definisjonen (færre enn 10 ansatte og årlig omsetning under 2 millioner euro) nyter godt av et forenklet IKT-risikostyringsrammeverk etter art. 16. Dette omfatter også testing: selv om de fortsatt må vurdere sine IKT-risikoer og opprettholde grunnleggende sikkerhetstiltak, er de formelle testkravene nedskalert.
Mindre enheter som er usikre på hvilket testnivå som gjelder, bør rådføre seg med sin nasjonale tilsynsmyndighet. Flere tilsynsmyndigheter har publisert veiledningsdokumenter som gir nærmere detaljer om hvordan forholdsmessighetsprinsippet praktiseres i deres jurisdiksjon. DORA GRCs samsvarguide gir en oversikt over forholdsmessighet på tvers av alle fem pilarer.
Bygg testprogrammet steg for steg
Enten du starter fra bunnen av eller formaliserer eksisterende praksis, gir de følgende stegene en praktisk vei til et DORA-konformt testprogram.
Identifiser kritiske IKT-systemer
Ta utgangspunkt i IKT-aktivaregisteret (art. 8) og CIF-registeret. Identifiser hvilke systemer som understøtter kritiske eller viktige funksjoner, kartlegg deres avhengigheter og klassifiser dem etter risikonivå. Disse systemene utgjør kjernen i testprogrammets omfang. DORA GRCs aktivaregister og avhengighetskartlegging automatiserer denne identifiseringen.
Definer testmetoder og frekvens
For hvert system i omfanget, bestem hvilke testmetoder som er hensiktsmessige og hvor ofte de skal gjennomføres. Kritiske systemer med høy risikovurdering bør testes hyppigere og grundigere. Dokumenter begrunnelsen for hver beslutning slik at den kan fremlegges for tilsynsmyndigheten.
Vurder om TLPT gjelder
Avklar om enheten din sannsynligvis vil bli utpekt for TLPT ved å gjennomgå kriteriene i art. 26(8) med din nasjonale tilsynsmyndighet. Dersom TLPT gjelder, begynn planleggingen av omfang, valg av testere og tilsynskoordinering minst 12 måneder før forventet testperiode. Budsjetter for eksterne testere og de interne ressursene som trengs for å støtte øvelsen.
Etabler styring og rapportering
Opprett et testprogrammandat som definerer roller, ansvar, eskaleringsveier og rapporteringslinjer. Ledelsesorganet bør godkjenne programmet og motta en oppsummering av resultater minst årlig. Integrer testfunn i rammeverket for IKT-risikostyring og prosessen for oppfølging av utbedringstiltak.
Gjennomfør, dokumenter og utbedr
Kjør testene i henhold til den definerte planen. Registrer resultater systematisk, inkludert bestått/ikke bestått-utfall, identifiserte sårbarheter, alvorlighetsgrad og tildelte ansvarlige for utbedring. Følg opp hvert funn til det er lukket, og verifiser gjennom retesting. DORA GRCs testmodul håndterer hele denne livssyklusen og kobler resultater til risikoer, eiendeler og kontroller.
Gjennomgå og forbedre årlig
Minst én gang i året, gjennomgå testprogrammet opp mot det aktuelle trusselbildet, eventuelle endringer i IKT-porteføljen og erfaringer fra tidligere testsykluser. Oppdater omfang, metoder og frekvens etter behov. Dokumenter gjennomgangen og legg konklusjonene frem for ledelsesorganet til godkjenning.
Vanlige spørsmål
DORA krever at alle finansielle enheter innenfor virkeområdet opererer et testprogram for digital operasjonell motstandsdyktighet etter art. 24. Som et minimum omfatter dette sårbarhetsvurderinger, nettverkssikkerhetsgjennomganger, gap-analyser, kildekodegjennomgang der det er gjennomførbart, scenariobasert testing og ytelsestesting. Grunnleggende tester skal gjennomføres minst årlig på kritiske IKT-systemer. Større enheter utpekt av nasjonalt tilsynsorgan må i tillegg gjennomføre Threat-Led Penetration Testing (TLPT) minst hvert tredje år.
TLPT er påkrevd for finansielle enheter som er systemviktige eller har høy IKT-risikoprofil. Nasjonale tilsynsmyndigheter utpeker hvilke enheter som må gjennomføre TLPT basert på kriterier i art. 26(8), herunder systemviktighet, IKT-modenhet, og art og kritikalitet av enhetens funksjoner. Mindre og enklere enheter er normalt unntatt. Er du usikker på om TLPT gjelder for deg, ta kontakt med din nasjonale tilsynsmyndighet for avklaring.
Grunnleggende motstandsdyktighetstesting etter art. 25 skal gjennomføres minst én gang i året på alle kritiske IKT-systemer og -applikasjoner. TLPT etter art. 26 skal gjennomføres minst hvert tredje år for utpekte enheter. Testprogrammet skal være risikobasert, noe som betyr at systemer med høyere risiko kan kreve hyppigere testing enn det regulatoriske minimumskravet. Vesentlige endringer i kritiske systemer bør også utløse ytterligere testing utenom den normale syklusen.
Grunnleggende testing (art. 25) dekker standard sikkerhetsvurderinger som sårbarhetsskanning, nettverkssikkerhetsgjennomganger og scenariobasert testing. Den gjelder alle enheter innenfor virkeområdet og kan gjennomføres av interne eller eksterne testere. TLPT (art. 26–27) er en avansert, etterretningsbasert testmetodikk som simulerer reelle angrep mot levende produksjonssystemer med aktuell trusselinformasjon. TLPT krever kvalifiserte eksterne testere og koordinering med tilsynsmyndigheten før, under og etter øvelsen. Kun enheter som er spesifikt utpekt av sin tilsynsmyndighet, må gjennomføre TLPT.