DORA-forordningen – Implikationer for softwaretest i finanssektoren
Af: Ole Chr. Hansen, Q Nation A/S
Indledning
Digital Operational Resilience Act (DORA-forordningen) er en ny EU-regulering, der skal styrke den digitale modstandsdygtighed i finanssektoren. Forordningen trådte formelt i kraft i slutningen af 2022 og gælder fra 17. januar 2025. Det betyder, at banker, forsikringsselskaber, investeringsfirmaer og en lang række andre finansielle aktører – i alt 20 typer finansielle aktører samt deres kritiske it-leverandører – nu er underlagt fælles krav til robusthed mod it-hændelser. DORA skal sikre, at finansielle virksomheder kan modstå, reagere på og komme sig over it-nedbrud eller cyberangreb, uden at det truer finansiel stabilitet eller forbrugerbeskyttelse.
Reguleringen erstatter et fragmenteret nationalt regelsæt med et ensartet EU-rammeværk, hvilket øger harmonisering på tværs af de enkelte lande. Denne artikel giver et overblik over DORAs omfang og metode, efterfulgt af en dybdegående analyse af dens betydning for softwaretest og kvalitetssikring i finanssektoren. Her belyses fordele og ulemper for testteams og testmanagere, diskuteres risici og udfordringer ved implementeringen, og sammenligner DORA med relevante standarder som ISO 27001, ISO 25010 og ISO 29119. Afslutningsvis præsenteres konkrete anbefalinger til testmanagere.
I artiklen anvendes forkortelsen IKT for Informations- og KommunikationsTeknologi.
Forordningens omfang og fremgangsmåde
Omfang: DORA gælder bredt i den finansielle sektor. Omfattet er bl.a. banker, forsikringsselskaber, pensionskasser, investeringsselskaber, kritiske tredjeparts it-leverandører m.fl. Målet er at styrke it-sikkerheden og den operationelle robusthed i hele sektoren. Forordningen er opbygget omkring en række hovedområder eller piller:
IKT-risikostyring: Krav om et formelt rammeværk til styring af it-risici, herunder løbende risikovurderinger og kontrolforanstaltninger. Virksomheden skal beskytte alle væsentlige it-aktiver (software, hardware, data, infrastruktur) mod trusler.
IKT-relateret hændelseshåndtering og rapportering: Virksomheder skal have procedurer for at håndtere it-hændelser og anmelde større it-sikkerhedshændelser til tilsynsmyndighederne inden for fastsatte frister. Dette skaber et mere ensartet og transparent rapporteringsregime på tværs af EU.
Digital operationel modstandsdygtighedstest: Krav om både grundlæggende og avancerede test af organisationens modstandsdygtighed. Alle virksomheder skal have et omfattende testforløb, der regelmæssigt afprøver it-systemernes robusthed over for driftsforstyrrelser og cyberangreb. For de mest kritiske enheder indebærer det avancerede Threat-Led Penetration Testing (TLPT) – realistiske angrebssimuleringer på kritiske systemer. Disse avancerede tests udføres typisk hvert tredje år og kræver involvering af uafhængige akkrediterede testere under tilsyn af myndighederne.
IKT-tredjepartsrisiko: Fokus på risiko ved brug af eksterne it-leverandører (f.eks. cloud-udbydere). DORA stiller krav om solide leverandørstyringsaftaler, monitorering af leverandørers sikkerhed og nødplaner, samt indfører et tilsynsregime for kritiske it-leverandører. Dette betyder bl.a. at visse store teknologiudbydere kan udpeges som “kritiske” og blive underlagt direkte EU-tilsyn.
Informationsdeling: DORA fremmer frivillig udveksling af trusselsinformation og bedste praksis på tværs af branchen. Tanken er, at finansielle virksomheder gennem samarbejde kan stå stærkere mod nye cybertrusler.
Fremgangsmåde: DORA benytter en risikobaseret og proportional tilgang. Det betyder, at kravene skaleres efter virksomhedens størrelse, kompleksitet og risikoprofil. En stor international bank forventes således at have mere omfattende kontrolforanstaltninger og testforløb end en mindre lokal finansvirksomhed. For alle gælder dog minimumskrav – f.eks. årlig test af kritiske systemer. DORA integrerer også sine krav med eksisterende governance-processer: Virksomheden skal indarbejde det digitale modstandsdygtighedstest i sin overordnede IKT-risikostyringsramme og strategi. Reguleringen ledsages af underliggende tekniske standarder (udformet af de europæiske tilsynsmyndigheder) for f.eks. hændelsesrapportering, risikostyringsrammer og TLPT-metoder. Disse detaljerede standarder præciserer kravene og opdateres løbende – dog var enkelte endnu ikke endeligt vedtaget ved ikrafttrædelsen i 2025 (f.eks. standarden for trusselsbaserede penetrationstests). Samlet set repræsenterer DORA en holistisk tilgangtil digital robusthed, hvor teknisk sikkerhed, operationel kontinuitet og regulativ compliance smelter sammen i ét regelsæt.
Betydning for softwaretest, kvalitetssikring og teststrategier
DORA har markant indflydelse på, hvordan finansielle virksomheder skal planlægge og udføre softwaretest og kvalitetsaktiviteter. Hvor softwaretest traditionelt har fokuseret på funktionalitet og fejlreduktion, sætter DORA fokus på resiliens (overlevelsesevne) – dvs. systemernes evne til at modstå og håndtere ekstreme situationer. Dette udvider testmanagerens ansvar til også at omfatte sikkerheds- og robusthedstest som en del af compliance.
Test som central del af DORA-compliance: DORA forudsætter, at finansielle organisationer ”striks tester deres systemer” for at kunne dokumentere modstandsdygtighed. Digital robusthed er ikke blot noget, man kan skrive politikker om; det skal demonstreres gennem praktiske testøvelser. For softwaretest- og QA-teams betyder det, at test af non-funktionelle krav (sikkerhed, performance, failover, backup mv.) bliver lige så forretningskritisk som funktionelle tests. DORA fremhæver netop, at basischecks og avancerede metoder som red-team tests (en Red Team Test simulerer et realistisk hackerangreb på virksomheden) skal bruges til at validere digital robusthed. I praksis skal QA-afdelingen hjælpe med at opbygge et kontinuerligt testforløb for it-modstandsdygtighed, der løbende vurderer om systemerne lever op til kravene under forskellige scenarier.
Udvidelse af testområder: En DORA-compliant teststrategi skal dække langt mere end traditionelle funktionelle tests. Følgende testområder er centrale:
Sikkerhedstest: Sårbarhedsskanninger og penetrationstests af applikationer er nu eksplicit krævet som led i robusthedstest. QA-teams skal derfor enten opkvalificeres i sikkerhedstest eller samarbejde tæt med sikkerhedsspecialister. Ethvert nyt system eller større ændring bør gennemgå sikkerhedstjek i udviklingslivscyklussen– lige fra kodegennemgang til dynamiske angrebssimulationer. Det handler om at bygge sikkerhed ind fra starten i stedet for kun at lave “sidste-øjebliks” checks. QAs rolle er bl.a. at sikre, at der opstilles sikkerhedskriterier sammen med forretningen, at kendte sårbarheder lukkes inden go-live, og at der køres gentagne tests efter rettelser.
Ydelses- og stresstest: DORA kræver, at systemer kan opretholde kritiske tjenester under belastning og hurtigt komme sig efter nedbrud. Derfor skal teststrategien inkludere performance tests og stresstests under forskellige belastningsscenarier. For eksempel bør der laves spike testing af netbanker og betalingsplatforme for at sikre, at de tåler pludselige trafikstigninger uden at bryde sammen. Tilsvarende skal failover-procedurer (f.eks. skift til backup-datacenter) testes jævnligt under realistiske forhold. DORA forpligter også virksomheder til at teste backup-integritet og datagendannelse – man skal verificere, at kritiske data kan genetableres efter f.eks. et ransomware-angreb. QA-teamet bidrager her ved at opstille testcases for gendannelsestid (RTO – Recovery Time Objective) og datatab (RPO – Recovery Point Objective) og validere resultaterne mod de opstillede kontinuitetsmål.
Katastrofeøvelser og kontinuitetstest: Udover tekniske stresstests lægger DORA vægt på driftskontinuitet. Virksomhederne skal gennemføre disaster recovery-øvelser – både tekniske genoprettelsestests og rundbords-øvelser hvor forskellige afdelinger øver håndtering af en større hændelse. QA og testfolk bør deltage aktivt i disse øvelser for at verificere om beredskabsplaner og nødprocedurer virker efter hensigten. Konkret kan testteamet tjekke om backup-software fungerer korrekt, om data er konsistente efter gendannelse, og måle hvor lang tid det tager at genetablere kritiske systemer. Resultaterne dokumenteres nøje for at se, om de opstillede recovery-mål overholdes. Denne dokumentation er guld værd både internt og over for tilsyn – den demonstrerer compliance og afdækker eventuelle svagheder, som så kan udbedres.
Regelmæssige patch- og release-tests: Robusthed omfatter også at holde systemer opdaterede uden at skabe nye driftsproblemer. QA bør støtte et struktureret patch management ved at teste softwareopdateringer i et kontrolmiljø, før de sættes i produktion. Hermed sikres det, at patches ikke ødelægger eksisterende funktionalitet eller performance. Desuden skal testteamet hjælpe med at føre logbog over alle patches og testresultater som evidens for interne og eksterne auditorer. Denne disciplin medfører, at virksomheden hurtigt kan påvise over for tilsynsmyndigheder, at man proaktivt opdaterer og tester for sårbarheder – hvilket er et kerneelement i DORAs risikostyringskrav.
Dokumentation og kvalitetssikring: Under DORA bliver omfattende dokumentation af testarbejdet påkrævet. Teststrategien bør være formaliseret og alignet med DORA-kravene, så ledelsen og myndigheder kan se præcis hvilke systemer der testes, hvor ofte, hvordan og med hvilke resultater. Hver testcyklus bør dokumenteres med testscope, fundne svagheder og opfølgende tiltag. Dette øger ikke kun organisationens egen indsigt men muliggør også erfaringsdeling af f.eks. sårbarheder med branchefæller, hvilket DORA også tilskynder som del af informationsdeling.
Integration i eksisterende processer: For testorganisationen betyder DORA, at QA skal arbejde endnu tættere sammen med it-sikkerhed og drift. Mange af de påkrævede tests (sikkerhed, performance, kontinuitet) krydser traditionelle siloer. Et godt tiltag er at forankre DORA-kravene i SDLC, hvor testaktiviteterne planlægges ind fra designfasen til deployment. QA kan f.eks. bidrage til at definere sikkerhedskriterier i userstories, sikre at automateserede tests dækker kritiske usecases under load, og at DevOps-pipelines inkluderer sikkerhedsscanning. Tværfunktionelle teams (QA, SecOps, DevOps) bør etableres for at adressere DORA holistisk. Dette fremmer også ”security by design” og kontinuerlig forbedring frem for enkeltstående compliance-tjek.
Praktiske eksempler: Et konkret eksempel på DORAs indflydelse er, at en bank nu skal udføre årlige full-scale driftsprøver af sin kernebankplatform, hvor man i en kontrolleret øvelse stresser platformen og simulerer en stor cyberhændelse. QA-teamet vil her udarbejde et testscript for scenariet (f.eks. et ransomware-angreb der krypterer data), sørge for monitorering af systemrespons under angrebet og måle recovery-tider når backup køres i gang. Efter øvelsen dokumenterer testerne, hvilke fejl og flaskehalse der opstod – måske var der en uafdækket afhængighed til en tredjepartsservice – så ledelsen får indsigt i forbedringspunkter. Et andet eksempel: En fintech-virksomhed under DORA skal ved hver større softwareudgivelse ikke kun udføre unit- og integrationstests, men også køre en sårbarhedsscanning og en mini-pen-test af applikationen, inden den går live. Testmanageren vil her planlægge ekstra tid i release-cyklussen til disse aktiviteter og allokere sikkerhedstestressourcer. Disse eksempler illustrerer, hvordan teststrategien får et bredere scope under DORA, hvor kvalitet ikke kun måles i korrekte funktioner men i robusthed under pres.
Samlet set bliver softwaretest og QA en hjørnesten i at opfylde DORA. Hvor man tidligere kunne betragte robusthedstest som “nice-to-have”, er det nu et regulativt must-have. Den positive sideeffekt er, at organisationer gennem mere omfattende test får højere systemkvalitet: Bedre pålidelighed, højere ydeevne, færre kritiske sårbarheder og mindre downtime. Disse gevinster øger både kundernes tillid og kan spare virksomheden for store tab ved at forhindre alvorlige driftsforstyrrelser. Som DORA tydeliggør, hænger compliance, sikkerhed og kvalitet sammen – man kan ikke vælge én og nedprioritere de andre, for slutmålet er robuste finansielle tjenester, der kører stabilt uanset hvilke digitale udfordringer der opstår.
Fordele og ulemper for testteams og testmanagers
Implementeringen af DORA bringer en række fordele såvel som udfordringer/ulemper for testteams og testmanagere i finanssektoren. Nedenfor er de vigtigste:
Fordele:
Øget fokus og anerkendelse af testfunktionen: DORAs krav gør, at softwaretest og QA nu er i rampelyset på ledelsesniveau. Testaktiviteter, der understøtter lovkrav, får høj prioritet og ressourcer. Dette kan styrke testteamets position i organisationen og gøre det lettere for testmanagers at få opbakning til nødvendige værktøjer, træning og bemanding. Når bestyrelsen spørger “er vi DORA-compliant?”, bliver testmanagerens rapporter om testen centrale.
Mere robust software i produktion: En af DORAs intentioner er at forbedre systemkvaliteten gennem systematiske tests. Testteams der følger DORA, vil arbejde mere med sikkerhed og robusthed, hvilket alt andet lige øger den samlede kvalitet af leverancerne. Over tid kan dette betyde færre kritiske incidents i drift og mindre brandslukning. Som A1QA bemærker, fører stærk testpraksis til mindre nedetid og mere effektiv udvikling, idet fejl og sårbarheder fanges tidligt. Det gør også, at udviklingsteam kan levere nye features hurtigere og mere trygt, da QA har sikret et stabilt fundament.
Krydsfunktionelt samarbejde og kompetenceudvikling: DORA tvinger en brobygning mellem QA, it-sikkerhed, drift og forretning. For testmedarbejdere kan dette give værdifuld vidensudveksling – f.eks. lærer testere om trusselsbilleder fra sikkerhedskolleger, mens sikkerhedsfolk forstår testmetodik. Denne DevSecOps-kultur kan være motiverende og give testere nye færdigheder inden for f.eks. etisk hacking, performance engineering m.m. Det øger også jobprofilens attraktivitet og relevans.
Forbedret risikostyring og færre overraskelser: Ved at følge DORAs strukturerede testkrav (som inkluderer hyppige tests af værst tænkelige scenarier) vil testteams hjælpe organisationen med at identificere svagheder proaktivt. Dette kan forhindre kostbare sikkerhedsbrud eller driftsnedbrud. Den øgede modstandsdygtighed gavner hele virksomheden og giver testafdelingen “ære” for at have forebygget potentielle katastrofer. Det bidrager til en kultur, hvor kvalitet og sikkerhed anskues som investeringer frem for omkostninger.
Ensrettede standarder og best practices: DORA skaber et fælles sprog og mål for robusthed i branchen. For testmanagers betyder det, at de kan læne sig op ad anerkendte standarder og frameworks uden altid at skulle opfinde deres egne krav. Mange af de testmetoder, DORA kræver (penetrationstest, kodegennemgang, osv.), er velkendte og velafprøvede. Det handler i høj grad om at formalisere dem i en testplan. Herved kan testteamet lettere argumentere for at indføre f.eks. faste årlige stresstests – “det står i DORA, at vi skal…”. På sigt kan dette modne testprocesserne (som det ses i ISO 29119-standardens ånd, jf. næste afsnit) og øge professionaliseringen af QA.
Ulemper/Udfordringer:
Øget arbejdsbyrde og kompleksitet: Den mest åbenlyse ulempe er, at DORA tilføjer mange ekstra opgaver til testteams. Udover de sædvanlige tests skal der planlægges og udføres sikkerhedstests, kontinuitetsøvelser, leverandørvurderinger osv. Testmanagers risikerer at skulle “kæmpe på mange fronter” for at holde trit med både udviklingsprojekter og det omfattende testforløb for driftssikkerhed.
Mere dokumentation og bureaukrati: DORA-compliance kræver grundig dokumentation og sporbarhed af alle testaktiviteter. Testafdelingen skal bruge tid på at udarbejde teststrategier, planer, rapporter og revisionsspor, som kan fremvises ved tilsyn. Dette kan opleves som bureaukratisk overhead, der tager tid fra det “reelle” testarbejde. Desuden kan kravene ændre sig, efterhånden som de tekniske standarder justeres, hvilket kræver løbende opdatering af dokumenter og processer. Denne uklarhed kan føre til ekstra administration, mens man afventer fortolkninger.
Krav om nye kompetencer: At leve op til DORA kan indebære, at testteamet skal udføre opgaver, de ikke tidligere har været ansvarlige for – f.eks. avanceret sikkerhedstest eller vurdering af cloud-leverandørers robusthed. Dette kræver enten uddannelse af eksisterende medarbejdere eller inddragelse af eksterne specialister. Begge dele kan være udfordrende: Opkvalificering tager tid, og eksterne eksperter (f.eks. certificerede pen-testere) kan være dyre eller svære at finde. Især Threat-Led Penetration Testing er højt specialiseret, og DORA kræver, at sådanne tests udføres af godkendte uafhængige parter. Testmanageren skal altså kunne navigere i et felt af eksterne leverandører og sikre kvaliteten af disse samarbejder. Derudover kan det være en kulturændring for et traditionelt QA-team at skulle tænke som “angribere” i stedet for blot at følge kravspecifikationer.
Omkostninger og investeringer: Med øget scope følger øgede omkostninger. Virksomheder skal investere i værktøjer (f.eks. til kontinuerlig sårbarhedsscanning, automatiseret test af failover, etc.), eksterne konsulenter til TLPT, og potentielt i flere testansatte. For testafdelingen kan stramme budgetter betyde, at man skal gøre mere med samme eller færre midler – en klar ulempe og stressfaktor.
Mulig begrænsning af agility og innovation: Nogle i branchen udtrykker bekymring for, at de mange regulatoriske krav begynder at bremse innovation. Fra et testperspektiv kan strenge compliance-checks betyde længere release-cykler og mindre fleksibilitet til at eksperimentere. Testmanagers kan føle, at de konstant skal prioritere “det nødvendige for compliance” frem for eks. at prøve nye testværktøjer eller metoder, der ellers kunne forbedre kvaliteten. Balancen mellem at være agil og compliant kan således være svær. Dog skal det siges, at et robust fundament også kan være en forudsætning for sikker innovation – det handler om at finde den rigtige balance.
Risiko for tick-the-box-mentalitet: En mere subtil ulempe er risikoen for, at fokus flyttes fra kvalitet til ren compliance. Hvis testteams blot jagter at opfylde minimumskravene (f.eks. laver en penetrationstest om året for at kunne sætte flueben), kan det gå ud over den dybere forståelse af kvalitet. Testmanageren skal derfor vogte mod en kultur, hvor man kun gør det påkrævede og ikke lærer af det. DORA lægger op til, at man ser robusthed som en kontinuerlig forbedringsproces, ikke bare et tjekskema. Så en udfordring bliver at sikre, at alle disse nye testaktiviteter faktisk integreres meningsfuldt i kvalitetsarbejdet fremfor at blive silo-baserede complianceøvelser.
Overordnet er DORA en blandet pose for testteams: Den giver en unik chance for at løfte kvalitetssikring op på et nyt niveau, men det kommer med omkostninger i form af mere arbejde, mere koordinering og krav om nye evner. Ideelt set vil fordelene – færre alvorlige driftsforstyrrelser, højere kundefortrøstning, og stoltheden ved at levere robuste løsninger – opveje ulemperne. Hvis investeringerne i bedre værktøjer og processer gennemføres, vil de på sigt styrke den digitale modstandsdygtighed og gøre testafdelingens arbejde lettere og mere effektivt. Men det kræver, at ledelsen erkender udfordringerne og understøtter testfunktionerne under transformationen.
Risici og udfordringer i implementeringen
Selvom DORA formelt er trådt i kraft, viser erfaringerne fra 2024-2025, at mange finansielle virksomheder stadig kæmper med implementeringen. Dette afsnit ser på de risici og udfordringer, som særligt berører testmanagers ved indførelsen af DORA.
Manglende efterlevelse og tidspres: Allerede inden deadline 17. januar 2025 advarede mange om, at tiden var knap. Dette understreger risikoen for regulatoriske sanktioner for forsinkelser, men også en generel usikkerhed i branchen om, hvordan kravene præcis indfries. For testmanagers betyder det, at man kan blive bedt om hasteløsninger og lappeløsninger op til revisioner/audits – et risikofyldt miljø, hvor fejl kan ske under tidspres.
Fortolkning og klarhed: En væsentlig udfordring er, at DORA er kompleks og delvis uprøvet, hvilket har gjort nogle firmaer usikre på, hvad der præcist forventes. Ifølge QA-Financial er mange stadig uklare omkring, hvilke tiltag der kræves for at “etablere DORA-compliance fuldt ud”. Især omkring tredjeparter og avancerede tests er der efterspurgt mere guidance. For testmanagers kan denne uklarhed betyde, at man tøver med at igangsætte initiativer eller implementerer noget, som senere viser sig utilstrækkeligt. Risikoen er, at værdifuld tid spildes, eller at man fejlinvesterer i de forkerte testværktøjer. Det understreger behovet for at følge med i tilsynsmyndighedernes udmeldinger og måske engagere sig i branchefora for at tolke kravene korrekt.
Kompleksitet i it-landskabet: Finansielle institutioner har ofte komplekse, heterogene it-miljøer med legacy-systemer (f.eks. mainframes) side om side med nye cloud-løsninger. At opnå fuld robusthed på tværs er ikke trivielt. Et konkret problem er f.eks. forældede teknologier. Hvis kerneapplikationer hviler på usikre platforme, underminerer det DORA-compliance kraftigt. For en testmanager er udfordringen her, at test af sikkerhed og opdateringer måske ligger uden for det man traditionelt har gjort – men nu skal QA være med til at afsløre disse skjulte risici i miljøet. F.eks. skal man sørge for at teste i miljøer, der spejler produktion, ellers kan selv pen-tests give falsk tryghed, hvis de ikke rammer de reelle produktionsversioner.
Tredjepartsrisiko og supply chain: DORAs fokus på tredjepartsleverandører er yderst relevant, men svært i praksis. Mange firmaer har hundredvis af it-leverandører, fra cloud-platforme til små fintech-partnere. Årsagerne er bl.a. begrænset indsigt i underleverandørers sikkerhed og den store skala af leverandørnetværk. For testteams betyder det, at man skal udvide testhorisonten: Det er ikke nok at teste egne systemer, man skal også indregne leverandørers ydelser i testscenarierne. Et eksempel kan være at inkludere cloud-udfald i resilience-tests (“hvad hvis vores cloud-udbyder oplever nedbrud?”). Koordinering med leverandører om fælles beredskabsøvelser eller informationsdeling om sårbarheder bliver en nødvendig men krævende opgave. Her løber testmanageren ind i at skulle afhænge af andre virksomheders samarbejdsvilje og modenhed, hvilket er en ny dimension af risikostyring, som traditionel QA ikke har skullet håndtere.
Kulturel forankring og tværgående samarbejde: Det pointeres ofte, at en af de største udfordringer i DORA-implementeringen er overgangen til en ny kultur omkring digital robusthed. It og test kan ikke længere betragtes som isolerede støttefunktioner; det er et strategisk anliggende, som kræver involvering af topledelsen og samarbejde på tværs af afdelinger. For testmanagers indebærer dette, at man skal kommunikere værdien og nødvendigheden af testaktiviteterne til forretningen i et sprog, de forstår. Det indebærer også, at man i højere grad involverer forretningskontinuitetsfolk, risikomanagere, compliance-officerer mv. i planlægning af testen. Denne interessentinvolvering kan være udfordrende, især hvis der tidligere har været en silo-opdeling. Risikoen er, at hvis ikke kulturen ændres, vil man have lappeløsninger: f.eks. en it-sikkerhedsfunktion der laver sine egne tests uafhængigt af QA, eller forretningen der ser robusthedstest som et “it problem”.
Vedvarende ændring i trusselsbilledet: Cybertrusler udvikler sig konstant. DORAs regelsæt er statisk i teksten, men ånden er, at man skal være forberedt på et “moving target”. Dette stiller krav om en fleksibel og smidig tilgang til testforløbet. Testcases og -scenarier skal løbende opdateres efter nye typer angreb og kendte sårbarheder. For testmanageren er udfordringen at holde testartefakterne levende – f.eks. revidere risikoanalysen hyppigt, inkludere nye tests (som f.eks. hvis AI-baserede angreb pludselig bliver almindelige, eller man ser supply chain-angreb stige). Her hjælper DORAs krav om informationsdeling: virksomheder forventes at dele viden om nye trusler, hvilket testteams kan drage nytte af ved at justere deres testfokus. Alligevel er risikoen, at compliance bliver en snapshot-øvelse – man bestod måske regulatorens review i år, men er ikke klar til næste års nye trusler. Dette kræver vedholdende årvågenhed og udvikling af kompetencer inden for f.eks. threat modeling i testafdelingerne.
Skalerbarhed af testindsatsen: For mange er det også en udfordring at skalere sikkerhedstest og robusthedstest, så det kan ske kontinuerligt uden at vælte hele udviklingsapparatet. Det må forventes, at den stigning i antallet, diversiteten og hyppigheden af sikkerhedstest, som DORA kræver, kan medføre markant øget arbejdsbyrde og omkostninger for uforberedte organisationer. Dette peger på risikoen for test-backlogs og flaskehalse: Hvis et testteam ikke er gearet til løbende at teste alle kritiske systemer årligt og mere til, risikerer man at komme bagud eller at tests bliver overfladiske. En mulig løsning er at investere i automation og nye testmetoder (såsom kontinuerlige bug bounty-forløb (brug af etiske hackere) eller “Pentest-as-a-Service”), hvilket nogle leverandører foreslår for at lette byrden. Men implementeringen af sådanne løsninger er i sig selv et miniprojekt med potentielle integration- og kvalitetsrisici.
Konsekvenser ved fejl: Endelig skal det nævnes, at hvis implementeringen kikser, er konsekvensen ikke blot en intern kvalitetsissue, men potentielt juridiske og økonomiske sanktioner. DORA giver tilsynsmyndigheder beføjelser til at udstede påbud og bøder ved manglende efterlevelse. Et brud på DORA (f.eks. undladelse af at rapportere en hændelse rettidigt, eller systemnedbrud pga. utilstrækkelig testet backup) kan udløse alvorlige konsekvenser. Dette lægger ekstra pres på testmanageren for at levere pålidelige testresultater og for ikke at overse noget væsentligt. Paradoksalt kan dette pres dog også virke positivt ved at skabe en “burning platform” internt: Alle ved, at man skal lykkes, hvilket kan hjælpe med at prioritere opgaven højt.
Som helhed er implementeringsfasen kritisk. Det positive er dog, at DORA ser ud til at drive en holistisk selvransagelse i branchen – f.eks. tvinger den virksomheder til for første gang at kigge dybt i leverandørkæden og stille krav der, hvilket øger den samlede sektorrobusthed. For testmanageren vil de kommende år derfor handle om at modne testorganisationen yderligere, være vedholdende og innovativ i tilgangen, og sikre at robusthedstankegangen forankres bredt i virksomheden.
Sammenligning med relevante standarder (ISO/IEC 27001, 25010, 29119)
DORA-forordningen overlapper med eller supplerer flere kendte internationale standarder inden for sikkerhed, kvalitet og test. Her sammenlignes DORA med tre centrale standarder, som mange testmanagere kender, og der gives perspektiver på, hvordan de kan bruges i implementeringen:
ISO/IEC 27001 (Information Security Management): ISO 27001 er en international standard for etablering af et Information Security Management System (ISMS) og indeholder en række sikkerhedskontroller (Annex A) for at beskytte informationer og systemer. DORA og ISO 27001 deler det overordnede mål om robust informationssikkerhed, men der er forskelle i fokus. DORA er en lovmæssig regulering specifikt for finanssektoren med krav om operationel robusthed, inkl. rapportering til myndigheder ved hændelser, og streng overvågning af tredjepartsleverandører – ting som ligger uden for ISO 27001s frivillige certificeringsramme. Omvendt kan man sige, at virksomheder med en solid ISO 27001-implementering står bedre rustet til DORA. ISO 27001 kræver f.eks. systematisk risikovurdering og beredskabsplaner, hvilket svarer til DORAs IKT-risikostyringskrav. Standardens kontrol for sikker udvikling (Annex A 8.26) fremhæver ”security by design” – at identificere og indbygge sikkerhedskrav ved udvikling og anskaffelse af software. Dette er helt på linje med DORAs forventning om, at finansielle apps er udviklet med indbygget robusthed. Dog går DORA længere på nogle områder: f.eks. at kræve årlige avancerede tests for visse institutioner, eller at pålægge rapportering af selv mindre hændelser, som ISO 27001 ikke eksplicit gør. I praksis vil en testmanager gøre klogt i at mappe DORA-kravene til ISO 27001-kontroller: hvor ISO 27001 giver en struktureret tilgang, kan DORAs detailkrav udfylde eventuelle huller. Et eksempel: ISO 27001 stiller krav om øvelser i forretningskontinuitet (Annex A 5.30, 17.1), mens DORA præciserer hvilke tests (f.eks. worst-case scenario-tests) og hvor hyppigt. Summen er, at ISO 27001 kan fungere som et grundlag for DORA-compliance, men DORA hæver baren og gør mange af principperne obligatoriske i finanssektoren.
ISO/IEC 25010 (Software Product Quality Model): ISO 25010 definerer en omfattende kvalitetsmodel for softwareprodukter med hovedkarakteristika og en række underpunkter. De mest relevante dimensioner ift. DORA er pålidelighed og sikkerhed. ISO 25010 beskriver pålidelighed som evnen til at udføre krævede funktioner under givne betingelser, og den opdeler det bl.a. i tilgængelighed, fejltolerance og genoprettelighed. Dette er præcis de egenskaber DORA ønsker at sikre: finansielle systemer skal have høj oppetid, kunne tåle komponentfejl (redundans) og kunne gendannes hurtigt efter afbrud. Ligeledes dækker ISO 25010 sikkerhed med underkategorier som fortrolighed, integritet, non-repudiation, accountability m.fl. – hvilket flugter med DORAs krav om at beskytte data og forhindre uautoriseret adgang selv under angreb. Så man kan sige, at DORA operationaliserer visse ISO 25010 kvalitetsegenskaber i en finansiel kontekst: Hvor ISO 25010 giver et teoretisk rammeværk for softwarekvalitet, pålægger DORA virksomhederne at måle og teste, at f.eks.availability er tilstrækkelig høj, at fault tolerance faktisk virker (via resilience tests), og at security er implementeret (via pen tests etc.). For en testmanager kan ISO 25010 fungere som tjekliste for at sikre, at testene dækker alle relevante kvalitetsaspekter. F.eks. bør man inkludere tests for performance efficiency (også en ISO 25010 karakteristik) for at adressere DORAs krav om kapacitet under belastning, selvom DORA ikke eksplicit nævner “performance” – det ligger implicit i kontinuitetskravene. Kort sagt er ISO 25010 en nyttig taksonomi at læne sig op ad: Den sikrer at man får tænkt alle vinkler (sikkerhed, pålidelighed, vedligeholdbarhed, osv.) igennem i teststrategien, så man indirekte opfylder DORAs intention om helhedsorienteret robusthed.
ISO/IEC 29119 (Software Testing Standards): ISO 29119 er en serie af standarder, der etablerer en fælles ramme for softwaretestprocesser, testdokumentation og teknikker. Standarden fremmer en systematisk og sporbar testtilgang – fra planlægning og design til udførsel og evaluering. Dette komplementerer DORAs krav om et ”omfattende testforløb” med dokumenterede processer og resultater. DORA fordrer, at finansielle virksomheder definerer, vedligeholder og regelmæssigt gennemgår et testforløb for digital modstandsdygtighed, og her kan ISO 29119s procesmodeller være til stor hjælp. For eksempel beskriver ISO 29119-2 testprocesrammen, inkl. testplanlægning, monitorering, afslutning osv., hvilket direkte kan anvendes til at strukturere DORA-testen, så intet trin overses. Endvidere betoner ISO 29119 vigtigheden af risikobaseret testdesign, hvor testindsatsen fokuseres på de mest kritiske områder – præcis som DORA foreskriver en risikobaseret tilgang for resilience testing. Ved at følge ISO 29119 kan en testmanager således vise, at testprocesserne er ”best practice” og systematiske, hvilket vil gøre det nemmere at demonstrere over for tilsyn, at test af modstandsdygtighed udføres grundigt og konsistent. ISO 29119 indeholder også skabeloner til testpolitikker, teststrategier og rapporter, som kan tilpasses DORA-behov – f.eks. inkludere specifikke DORA-metrikker eller compliance-checks i testafslutningsrapporten. Desuden nævner nogle kilder, at ISO 29119 omfatter retningslinjer for at sikre software-sikkerhed og -kvalitet gennem systematisk test, hvilket jo netop er DORAs kernefokus. Alt i alt kan man sige: ISO 29119 giver metoden, DORA giver målene. Kombineres de, får man en stærk, auditerbar testorganisation der både lever op til branchestandarder og lovkrav.
Sammenfattende fungerer DORA og disse standarder ikke som gensidige erstatninger, men snarere som supplerende brikker i en robusthedsstrategi. En finansiel virksomhed vil ofte vælge at beholde sin ISO 27001-certificering for at have en bred informationssikkerhedsramme, bruge ISO 25010 for at definere kvalitetskrav til it-systemerne, og følge ISO 29119 for at drive testprocessen effektivt – alt imens DORA danner den juridisk bindende ramme og afdækker eventuelle finanssektorspecifikke huller. For testmanagers kan det at oversætte mellem “ISO-sprog” og “DORA-sprog” være en del af jobbet: f.eks. forklare ledelsen, at “vores ISO 27001-tests dækker faktisk store dele af DORAs krav til kontinuitetstest, men vi skal udvide med nogle flere cyber-scenarier og dokumentere dem mere detaljeret for DORA”. Heldigvis peger retningen for dem alle mod det samme overordnede mål: bedre kontrol over risiko og kvalitet i en stadigt mere digitaliseret finansverden.
Afsluttende anbefalinger
For at afslutte samles her anbefalinger til testmanagers i finanssektoren, der skal navigere DORA-compliance og samtidig sikre effektive testprocesser:
Forankr DORA-krav i teststrategien: Opdater jeres overordnede teststrategi, så den eksplicit adresserer DORAs områder (risikostyring, hændelser, test, tredjeparter, etc.). Indarbejd f.eks. et afsnit om robusthedstest med principper for sikkerhedstest, kontinuitetstest og leverandør-assurance. Dette dokument viser både internt og eksternt, at QA er fuldt integreret i DORA-compliance.
Etabler et omfattende testforløb for digital modstandsdygtighed: Sørg for at definere, vedligeholde og gennemgå et forløb af testaktiviteter målrettet robusthed. Testplanen bør inkludere en kalender for løbende tests (mindst årlige for kritiske systemer), klare ansvarsfordelinger og procedurer for opfølgning på fundne problemer. Tænk risikobaseret: Prioriter de mest kritiske tjenester og vær sikker på at få testet dem under realistiske worst-case-scenarier.
Integrer test i tværgående beredskabsøvelser: Deltag aktivt i virksomhedens cyber drills og disaster recovery-øvelser. Sikr at QAs rolle er at verificere systemernes adfærd under disse øvelser og dokumentere resultaterne. Dette vil afsløre eventuelle skjulte svagheder og opbygge erfaring til at håndtere rigtige hændelser. Efter hver øvelse: udarbejd en kort rapport med observationer, opnåede recovery-tider vs. mål, og anbefalinger til forbedringer.
Styrk testteamets kompetencer og samarbejder: Identificér eventuelle kompetencegab i testteamet ift. DORA-krav. Det kan være behov for træning i etisk hacking, sikkerhedsrisikoanalyse eller performance tuning. Overvej certificeringer inden for relevante områder (f.eks. Certified Penetration Tester, ISTQB Advanced Security Tester). Samtidig, opbyg relationer med andre teams: Lav f.eks. faste møder med it-sikkerhedsafdelingen for at planlægge tests (DevSecOps-rutine), og med forretningskontinuitetsfolk for at forstå kritiske processer. Etabler også kontaktpunkter hos vigtige leverandører, så I let kan kommunikere om tests og hændelser.
Automatisér og modernisér hvor muligt: Udnyt moderne testværktøjer til at håndtere den øgede testbyrde. Overvej kontinuerlige scanningstjenester for sårbarheder, automatiseret overvågning af konfigurationer, og integrer sikkerhedstest i CI/CD pipelines for løbende at fange issues. Brug også klassiske testautomation til regression, så tid frigøres til de nye resilience-tests. Hvor avancerede tests er nødvendige, kan “Pentest-as-a-Service” eller bug bounty-forløb (brug af etiske hackere) overvejes for at supplere jeres interne ressourcer. Automation hjælper med at leve op til DORAs princip om løbende tests frem for sjældne, enkeltstående check.
Prioritér dokumentation og evidens: Indfør en praksis, hvor alle testforløb ifm. robusthed dokumenteres stringent. Hav f.eks. en central log eller wiki for DORA-tests, hvor I noterer testdatoer, scenarier, resultater og afhjælpende tiltag. Gem patch-logs og testprotokoller som bevis for, at ændringer er testet. Dette vil være uvurderligt ved audits eller tilsynsforespørgsler, og det gør jer i stand til hurtigt at demonstrere compliance og lave trend-analyser af jeres forbedringer over tid.
Brug standarder som løftestang: Map jeres DORA-indsats til kendte standarder som ISO 27001, 25010, 29119 for at sikre helhed. F.eks.: udfør en gap-analyse mellem jeres nuværende ISO 27001-kontroller og DORAs specifikke krav – luk hullerne via ekstra tests eller procedurer. Brug ISO 25010 kvalitetskarakteristika som tjekliste for at dække alle relevante aspekter (er vi f.eks. også opmærksomme på maintainability og recoverability i vores testcases?). Implementér ISO 29119s testproces og dokumentskabeloner for at strukturere planlægning, design og rapportering af tests – det skaber konsistens og gennemsigtighed, som tilsyn vil værdsætte. Ved at tale standardernes sprog kan I lettere forklare DORA-kravene internt og undgå dobbeltarbejde.
Fokus på tredjepartsstyring i test: Lav en liste over alle kritiske tredjepartsydelser (cloud-platforme, betalingsgateways, datafeed osv.) og integrér dem i jeres testplan. Det kan indebære at anmode leverandører om robusthedsrapporter eller testresultater, eller at aftale fælles tests. Hvis en cloud-leverandør f.eks. afholder en kriseøvelse, bør I deltage. Overvåg leverandørers patches og sikkerhedsmeddelelser og planlæg test af jeres integration, når de opdaterer deres systemer. Givet at tredjeparter er vurderet som svære at håndtere, kan en proaktiv testholdning her være et konkurrencefortrin i compliance.
Kommunikér og træn for robusthedskultur: Sidst men ikke mindst, vær en ambassadør for den kulturændring, DORA kræver. Afhold workshops eller tabletop-øvelser hvor testscenarier gennemspilles med deltagelse af både it, forretning og ledelse, så alle forstår deres rolle under en it-krise. Del succeshistorier, når tests fanger noget vigtigt – det understreger værdien. Og fremhæv at DORA ikke kun er en regel, men en mulighed for at styrke virksomheden og beskytte kunderne. Når topledelsen og resten af organisationen ser robusthed som et fælles ansvar, bliver det meget nemmere for testmanageren at få opbakning til de nødvendige initiativer.
Konklusion: DORA-forordningen repræsenterer et paradigmeskifte for finanssektorens tilgang til it-risiko – og softwaretest står centralt i denne omstilling. For testmanagers gælder det om at være strategiske og proaktive: Udnyt momentum til at løfte testmetoderne, allier jer med sikkerheds- og driftsfolk, og gør jer selv uundværlige i organisationens rejse mod digital robusthed. Med de rette tiltag kan DORA-compliance blive mere end en pligt; det kan blive en katalysator for højere softwarekvalitet, stærkere kunderelationer og en mere resilient (overlevelsesevne) forretning. Ved at følge ovenstående anbefalinger kan testteams navigere udfordringerne og sikre, at deres virksomhed ikke blot opfylder minimumskravene, men blomstrer i en verden af øgede compliance-krav – med software der er testet til at modstå selv stormvejr på det digitale hav.
