DORA-testprogram: kortlæg test til ISO 27001

Det er februar 2026. CISO’en i et mellemstort betalingsinstitut har et bestyrelsesmøde om to dage, en ISO/IEC 27001:2022-overvågningsrevision om seks uger og en DORA-tilsynsanmodning liggende i compliance-indbakken.

Tilsynsmyndigheden beder ikke om en poleret cyberstrategi. Anmodningen er praktisk:

• Fremlæg jeres testprogram for digital operationel robusthed for 2026.
• Vis, hvilke test der dækker kritiske eller vigtige funktioner.
• Dokumentér, hvordan konstateringer afhjælpes og gentestes.
• Dokumentér ledelsesorganets tilsyn.
• Forklar, hvordan IKT-tredjepartsudbydere indgår.
• Fremlæg registreringer for sårbarhedsvurderinger, scenariebaserede test, performance- og kapacitetstest samt penetrationstest.

CISO’en åbner fire mapper. Sårbarhedsscanninger ligger i SOC’ets helpdesk-sagsstyringssystem. Noter fra tabletop-øvelser ligger på et fællesdrev. Resultater fra belastningstest ejes af engineering. Penetrationstestrapporter ligger i juridisk afdelings adgangsbegrænsede bevisarkiv. Sporingen af afhjælpning er fordelt mellem Jira, e-mail og et regneark, der blev oprettet til sidste års ISO-revision.

Intet er opdigtet. Meget af det er solidt arbejde. Men det er endnu ikke et styret DORA-testprogram for digital operationel robusthed. Det er en samling af test.

Den forskel er vigtig i 2026. DORA finder anvendelse fra 17. januar 2025 og etablerer en ensartet EU-ramme for digital operationel robusthed på tværs af styring af IKT-risiko, hændelsesrapportering, robusthedstest, deling af oplysninger om cybertrusler og sårbarheder, styring af IKT-tredjepartsrisiko, kontraktlige krav og tilsyn med kritiske IKT-tredjepartsudbydere. Den omfatter en bred vifte af finansielle enheder, herunder kreditinstitutter, betalingsinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, forsikringsselskaber og andre regulerede enheder. DORA fungerer også som den sektorspecifikke EU-retsakt for finansielle enheder, der ellers ville være omfattet af tilsvarende NIS2-cybersikkerhedsforpligtelser.

Det praktiske spørgsmål for bestyrelser, CISO’er, efterlevelsesansvarlige og IKT-udbydere er ikke længere, om der udføres test. Spørgsmålet er, om test planlægges, er risikobaserede, dokumenteres, afhjælpes, gennemgås og kan genbruges på tværs af DORA og ISO/IEC 27001:2022.

Clarysec’s driftsmodel er bygget til netop dette problem. Ved at bruge Zenith Blueprint: en revisors 30-trins køreplan, Clarysec’s ISO-tilpassede politikpakke og Zenith Controls: guiden til tværgående efterlevelse kan organisationer omsætte spredte robusthedsaktiviteter til et kontrolleret årligt testkatalog, der opfylder forventninger fra tilsynsmyndigheder, revisorer, kunder og bestyrelser.

Hvorfor DORA gør test til et governance-spørgsmål

DORA er tydelig om ledelsesansvar. Article 5 placerer ansvaret for styring af IKT-risiko hos ledelsesorganet. Article 6 kræver en sund, omfattende og veldokumenteret ramme for styring af IKT-risiko, der er integreret i organisationens samlede risikostyringssystem. Article 4 tilføjer proportionalitet, hvilket betyder, at kravene skal anvendes ud fra størrelse, samlet risikoprofil samt arten, omfanget og kompleksiteten af tjenester, aktiviteter og drift.

Det gør test af digital operationel robusthed til mere end en teknisk opgave. Det bliver bevismateriale for, at ledelsesorganet forstår risikoen, har godkendt en strategi, modtager meningsfuld rapportering og driver afhjælpning.

ISO/IEC 27001:2022 anvender en tilsvarende ledelsessystemlogik. Klausul 4.1 til 4.4 kræver, at organisationen forstår kontekst, interessenter, retlige og kontraktlige forpligtelser, omfang, grænseflader og afhængigheder. Klausul 5.1 til 5.3 kræver lederskab, politiktilpasning, ressourcer, kommunikation, tildelte ansvarsområder og rapportering til øverste ledelse. Klausul 6.1 kræver risikovurdering og risikobehandling for informationssikkerhed.

Et DORA-testprogram bør derfor forbinde:

• Forretningstjenester og kritiske eller vigtige funktioner
• IKT-aktiver, data og tredjepartsafhængigheder
• Risikovurdering, risikoejere og behandlingsplaner
• Testtyper, frekvens og udløsende forhold
• Autorisation, uafhængighed og regler for gennemførelse
• Konstateringer, afhjælpningsfrister og gentest
• Opbevaring af bevismateriale og adgangsstyring
• Ledelsesrapportering og løbende forbedring

For mindre finansielle enheder eller enheder med lavere risiko indeholder Article 16 en forenklet ramme for styring af IKT-risiko, men forenklet betyder ikke uformel. Selv skalerede programmer kræver fortsat dokumenteret styring af IKT-risiko, overvågning, robuste systemer, identifikation af IKT-risikokilder og anomalier, centrale IKT-tredjepartsafhængigheder, kontinuitets- og genopretningstiltag, regelmæssig test og læring.

Med andre ord belønner DORA ikke testvolumen. DORA belønner styret, risikobaseret test, der dokumenterer robusthed for de tjenester, der betyder mest.

Hvad hører til i et DORA-testprogram for 2026?

Et modent DORA-testprogram bør fungere som et årligt testkatalog. Det bør ikke være begrænset til én årlig penetrationstest eller en bunke eksporter fra sårbarhedsscanninger. Det bør omfatte både grundlæggende og avancerede test, planlagt ud fra risiko, tjenestekritikalitet, regulatoriske forpligtelser, leverandørafhængigheder, væsentlige ændringer og tidligere konstateringer.

DORA Article 24 etablerer testprogrammet for digital operationel robusthed. Article 25 beskriver en række test, herunder sårbarhedsvurderinger og scanninger, open source-analyser, vurderinger af netværkssikkerhed, gapanalyser, gennemgange af fysisk sikring, spørgeskemaer, softwareløsninger til scanning, kildekodegennemgange hvor det er muligt, scenariebaserede test, kompatibilitetstest, performancetest, end-to-end-test og penetrationstest. Article 26 tilføjer trusselsstyret penetrationstest for finansielle enheder, der udpeges af kompetente myndigheder.

For de fleste organisationer bygges det praktiske katalog op omkring fire testfamilier.

Clarysec’s Politik for sikkerhedstestning og red teaming giver et stærkt politikanker for dette katalog:

“Testtyper: Sikkerhedstestprogrammet skal som minimum omfatte: (a) sårbarhedsscanning, bestående af automatiserede ugentlige eller månedlige scanninger af netværk og applikationer for at identificere kendte sårbarheder; (b) penetrationstest, bestående af manuel dybdegående test af specifikke systemer eller applikationer udført af kvalificerede testere for at identificere komplekse svagheder; og (c) red teaming-øvelser, bestående af scenariebaserede simuleringer af virkelige angreb, herunder social engineering og andre taktikker, for at teste organisationens samlede detektions- og responskapacitet.”

Den samme politik kræver regelmæssig planlægning:

“Testplan: Organisationen skal gennemføre sikkerhedstest efter en fast plan. Centrale internetvendte systemer og kritiske interne applikationer skal gennemgå penetrationstest mindst årligt. Højrisikoændringer, såsom udrulning af et nyt kritisk system eller større opgraderinger, kræver ad hoc-test før og/eller kort efter idriftsættelse i produktionsmiljøet.”

Dette er kritisk for DORA. En statisk årsplan er ikke tilstrækkelig, hvis enheden implementerer en ny betalingsgateway, migrerer et kernesystem til cloud, skifter managed service provider eller frigiver et nyt kundeautentifikationsflow. Højrisikoændringer skal udløse yderligere test.

Byg det årlige testkatalog som den fælles sandhedskilde

Den mest effektive måde at opfylde DORA og ISO/IEC 27001:2022 på er at etablere ét kontrolleret årligt testkatalog. Det kan ligge i en GRC-platform, et helpdesk-workflow eller et kontrolleret regneark. Formatet er mindre vigtigt end sporbarheden.

Hver test bør besvare fem revisionsspørgsmål:

1. Hvilken tjeneste, hvilket aktiv, hvilken leverandør, applikation eller proces blev testet?
2. Hvilken risiko, forpligtelse eller hvilket kontrolkrav udløste testen?
3. Hvem godkendte og udførte testen?
4. Hvilke konstateringer blev identificeret, accepteret, afhjulpet eller udskudt?
5. Hvilket bevismateriale dokumenterer, at testen blev gennemført, og at resultatet blev gennemgået?

Et praktisk Clarysec-lignende katalog omfatter disse felter.

Clarysec’s Politik for revision og overvågning af efterlevelse - SME giver en kort styringsregel, der passer til denne struktur:

“Hver revision skal omfatte et defineret omfang, mål, ansvarligt personale og krævet bevismateriale.”

Selvom den er skrevet til revisioner, bør den samme regel gælde for robusthedstest. Hvis en sårbarhedsscanning, tabletop-øvelse, simulation af reserveordning eller penetrationstest ikke har defineret omfang, mål, ejer og krævet bevismateriale, står den svagt under både DORA- og ISO-revisionskontrol.

Den samme politik fastslår:

“Bevismateriale skal opbevares i mindst to år eller længere, hvor det kræves af certificering eller kundeaftaler.”

For DORA-regulerede finansielle enheder og IKT-udbydere bør to år betragtes som et minimum. Kontraktlige forpligtelser, tilsynsforventninger, certificeringscyklusser og hændelsesundersøgelser kan kræve længere opbevaring.

Kortlæg DORA-testtyper til ISO 27001-bevismateriale

Styrken ved et integreret program er, at én test kan opfylde flere forpligtelser. Nøglen er at tagge bevismaterialet korrekt og forbinde det til ISMS’et.

Zenith Blueprint forklarer dette i fasen Audit, Review & Improvement, Step 24:

“Jeres SoA bør være konsistent med jeres risikoregister og risikobehandlingsplan. Dobbelttjek, at hver kontrol, I har valgt som risikobehandling, er markeret som “Applicable” i SoA’en.”

For et DORA-testprogram bliver testkataloget broen mellem risikobehandling og operationelt bevismateriale. Anvendelseserklæringen bør ikke angive, at en kontrol er relevant, mens testbevismaterialet ligger et andet sted, ukortlagt og ustyret.

Denne tabel hjælper en CISO med at besvare CEO’ens typiske spørgsmål: “Er vores ISO-penetrationstest og sårbarhedsscanninger nok til DORA?”

Svaret er: De kan indgå i DORA-efterlevelse, men kun hvis de er risikobaserede, knyttet til kritiske eller vigtige funktioner, styret af politik, fulgt gennem afhjælpning og rapporteret til ledelsen.

Sårbarhedsvurderinger: løbende bevismateriale, ikke kun scanningsoutput

Sårbarhedsvurdering er ofte den letteste testaktivitet at udføre og den letteste at håndtere forkert. Mange organisationer kan fremlægge scanningsrapporter. Færre kan dokumentere, at scanningerne dækker de rigtige aktiver, prioriterer kritiske tjenester, skaber rettidig afhjælpning og føder beslutninger om risikobehandling.

Clarysec’s Politik for sårbarheds- og patchstyring - SME begynder med det rigtige formål:

“Identificere og vurdere kendte sårbarheder på tværs af alle IT-aktiver på en rettidig og konsistent måde”

For DORA understøtter dette identifikation af IKT-risikokilder, robuste og opdaterede systemer, overvågning, anomalidetektion og løbende forbedring. For ISO/IEC 27001:2022 kortlægger det direkte til 8.8 Styring af tekniske sårbarheder, og det bygger også på 5.9 Fortegnelse over information og andre tilknyttede aktiver, 8.16 Overvågningsaktiviteter og 8.32 Ændringsstyring.

En stærk registrering af sårbarhedsvurdering bør omfatte:

• Snapshot af aktivfortegnelsen anvendt til afgrænsning
• Scanningsdato, værktøj og autentificeret eller ikke-autentificeret metode
• Udeladelser og forretningsmæssig begrundelse
• Konstateringer efter alvorlighed, udnyttelighed og forretningstjeneste
• Kortlægning til kritiske eller vigtige funktioner og datatyper
• Sagsreferencer og risikoejer
• Afhjælpnings-SLA og forfaldsdato
• Resultat af gentest
• Undtagelser med godkendelse af restrisiko

Zenith Controls placerer 8.8 Styring af tekniske sårbarheder som et centralt bevisområde for identifikation, vurdering, prioritering og sporing af afhjælpning. Det viser også, hvorfor revisorer vil teste tilstødende processer. Hvis aktivfortegnelsen er ufuldstændig, er sårbarhedsdækningen ufuldstændig. Hvis ændringsstyring omgås, kan patchudrulning skabe ny operationel risiko. Hvis overvågningen er svag, opdages exploitforsøg muligvis ikke.

Scenarietest: dokumentér beslutningstagning før den virkelige hændelse

Scenarietest er dér, hvor operationel robusthed bliver synlig for ledelsen. En ransomware-tabletop, en simulation af nedbrud i en cloudregion, en øvelse med kompromittering af privilegeret adgang eller et scenarie med svigt hos en kritisk IKT-udbyder vil afdække svagheder, som en scanning ikke kan.

DORA Articles 17 to 20 kræver en formel livscyklus for IKT-relaterede hændelser: detektere, styre, underrette, registrere, overvåge, håndtere, følge op, dokumentere rodårsag, afhjælpe, klassificere alvorlighed, tildele roller, eskalere større hændelser og rapportere gennem de krævede faser. Hvor kunders finansielle interesser berøres, skal kunder informeres uden unødig forsinkelse.

NIS2 har tilsvarende hastende krav for enheder inden for sit anvendelsesområde, herunder tidlig varsling, underretning, mellemliggende rapportering og endelig rapportering. For finansielle enheder inden for anvendelsesområdet er DORA den sektorspecifikke retsakt for tilsvarende forpligtelser til styring af cybersikkerhedsrisici og rapportering. IKT-udbydere, SaaS-platforme, MSP’er og MSSP’er skal stadig kontrollere, om de direkte er omfattet af NIS2, eller om de kontraktligt trækkes ind i DORA-dokumentation af regulerede kunder.

Zenith Blueprint, fasen Controls in Action, Step 23, giver den praktiske bevismodel:

“Vælg en nylig hændelse, eller gennemfør en tabletop-øvelse for at validere jeres plan. Registrér og log alle beslutninger, roller og kommunikationer (5.26), og opdater planen med læring (5.27).”

En DORA-scenarietest bør producere revisionsbare registreringer, ikke kun mødenoter:

• Scenariebrief og mål
• Deltagere og roller, herunder jura, kommunikation, IT, SOC, forretningsejer og leverandørkontakter
• Tidslinje for indspil og beslutninger
• Klassificeringsbeslutning og analyse af rapporteringstærskler
• Udkast til intern og ekstern kommunikation
• Tiltag til bevarelse af bevismateriale
• Læring
• Tiltagsansvarlige og forfaldsdatoer
• Opdaterede hændelses-, kontinuitets- eller kommunikationsprocedurer

Clarysec’s Politik for forretningskontinuitet og katastrofeberedskab - SME understreger forventningen om årlig test:

“Organisationen skal teste både sine BCP- og DR-kapaciteter mindst årligt. Test skal omfatte:”

Testkataloget bør omsætte denne forpligtelse til konkrete øvelser, såsom tabletop for krisestyring, test af gendannelse fra backup, test af reserveordning i cloud, test af kontakttræ og simulation af leverandørforstyrrelse.

Performance-, kapacitets- og genopretningstest: det oversete robusthedsbevismateriale

Performancetest behandles ofte som et engineering-anliggende. Under DORA bliver det robusthedsbevismateriale.

En handelsplatform, betalingstjeneste, skadebehandlingssystem, identitetsplatform eller kundeportal behøver ikke et cyberangreb for at svigte kunderne. Kapacitetsudtømning, kø-mætning, databaseflaskehalse, fejlkonfigureret autoskalering eller ødelagte reserveordninger kan skabe samme driftsforstyrrelse som en sikkerhedshændelse.

ISO/IEC 27001:2022 Annex A 8.6 Kapacitetsstyring er det primære anker. Bevismaterialet kan omfatte belastningstest, stresstest, test af serviceforringelse, validering af infrastrukturtærskler, test af gendannelse fra backup og simulationer af reserveordninger.

En god registrering af performance- og kapacitetstest bør dokumentere:

• Baseline for normal belastning og forudsætninger om spidsbelastning
• Testede kritiske transaktionsforløb
• Testede infrastruktur- og cloudgrænser
• Overvågningsdashboards og alarmtærskler
• Fejltilstande, såsom kø-mætning eller databaseflaskehalse
• Relevans for RTO og RPO, hvor reserveordning eller genopretning testes
• Forretningsmæssig konsekvens, hvis tærskler overskrides
• Afhjælpende foranstaltninger, skaleringsbeslutninger eller arkitekturændringer
• Ledelsens accept af restrisiko for kapacitet

Zenith Blueprint, Step 23, forbinder genopretningsforventninger med bevismateriale:

“Verificér, at Recovery Time Objectives (RTO) og Recovery Point Objectives (RPO) for kritiske systemer er i overensstemmelse med forventningerne til forretningskontinuitet (5.30). Gennemfør mindst én teknisk genopretningstest eller simulation af reserveordning, og dokumentér resultaterne.”

Det er forskellen mellem at sige “vi har backups” og at dokumentere, at en kritisk tjeneste blev gendannet inden for den aftalte tolerance, med dokumenterede resultater og synlighed for ledelsen.

Penetrationstest og red teaming: stærkt bevismateriale kræver stærk styring

Penetrationstest er meget værdifuldt bevismateriale, men det medfører også operationel risiko. Dårligt styret test kan påvirke produktionssystemer, eksponere følsomme data, udløse ukontrollerede alarmer, skabe juridiske forhold eller forstyrre kunder.

Politik for krav til applikationssikkerhed - SME fastsætter en klar release-kontrolport:

“Før udrulning skal alle applikationer gennemgå sikkerhedstest for at verificere de grundlæggende funktioner, der er angivet ovenfor.”

For kritiske applikationer bør dette indgå i DORA-kataloget som sikkerhedstest før produktionssætning, validering efter idriftsættelse for højrisikoændringer og periodisk penetrationstest baseret på eksponering og kritikalitet.

Politik for sikkerhedstestning og red teaming styrker afhjælpningskæden:

“Afhjælpning af konstateringer: Alle identificerede sårbarheder eller svagheder skal dokumenteres i en konstateringsrapport med alvorlighedsvurderinger. Ved modtagelse af rapporten er systemejere ansvarlige for at udarbejde en afhjælpningsplan med forfaldsdatoer; for eksempel skal kritiske konstateringer afhjælpes inden for 30 dage og høj-alvorlige konstateringer inden for 60 dage i overensstemmelse med organisationens politik for sårbarheds- og patchstyring. STC skal følge fremdriften i afhjælpningen. Gentest skal udføres for at bekræfte, at kritiske forhold er løst eller tilstrækkeligt afbødet.”

Den samme politik definerer rapporteringsforventninger:

“Rapportering: Der skal udstedes en formel rapport ved afslutningen af hver test. For penetrationstest skal rapporten omfatte et ledelsesresumé, metode og detaljerede konstateringer med understøttende bevismateriale og anbefalinger.”

Zenith Blueprint, Step 21, fremhæver også beskyttelse under revision og test:

“Ingen test eller revision bør fortsætte uden dokumenteret godkendelse fra systemejere eller relevante interessenter.”

Regler for gennemførelse, testvinduer, nødkontakter, midlertidig adgang, datahåndtering, logning, tilbagerulningsprocedurer og juridiske godkendelser er ikke bureaukrati. De er sikkerhedsforanstaltninger for robusthed.

Inddrag IKT-tredjepartsudbydere, før testen fejler

DORA gør IKT-tredjepartsrisiko til et centralt robusthedsspørgsmål. Article 28 kræver, at finansielle enheder styrer IKT-tredjepartsrisiko inden for rammen for styring af IKT-risiko, fortsat er ansvarlige ved brug af IKT-tjenester, opretholder et informationsregister, rapporterer visse aftaler, udfører vurderinger før kontraktindgåelse og anvender udbydere, der opfylder relevante informationssikkerhedsstandarder. Articles 29 og 30 omhandler koncentrationsrisiko, underleverandører, datagendannelse, kontraktlige beskyttelser, serviceniveauer, hændelsesbistand, revisionsrettigheder, udbyderes beredskabstest, deltagelse i test hvor relevant og exit-ordninger.

ISO/IEC 27001:2022 Annex A indeholder understøttende leverandørkontroller, herunder 5.19 Informationssikkerhed i leverandørrelationer, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 5.21 Styring af informationssikkerhed i IKT-forsyningskæden, 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester og 5.23 Informationssikkerhed ved brug af cloudtjenester.

Et DORA-testkatalog bør identificere, hvilke test der kræver leverandørdeltagelse eller leverandørbevismateriale. Eksempler omfatter:

• Antagelser om cloududbyders reserveordninger
• Eskalering hos administreret SOC og bevarelse af bevismateriale
• Hændelseskommunikation for core banking-platform
• Scenarie med nedbrud hos betalingsprocessor
• Genopretningstest hos identitetsudbyder
• Attester for penetrationstest fra SaaS-leverandør
• Konsekvensvurdering af kritisk underleverandørkæde

Et program, der udelukker kritiske IKT-udbydere, vil fejle realitetstesten. Den kundevendte tjeneste kan være jeres, men robusthedsafhængigheden kan ligge i en cloudregion, et outsourcet SOC, en identitetsudbyder, softwareleverandør, betalingsprocessor eller et datacenter.

Tværgående efterlevelseskortlægning: ét sæt bevismateriale, mange forpligtelser

Et veldesignet DORA-testprogram reducerer revisionstræthed. Det samme bevismateriale kan understøtte DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 og COBIT 2019-governancegennemgange, hvis det tagges, opbevares og rapporteres korrekt.

GDPR må ikke glemmes. Hvis robusthedstest omfatter personoplysninger, logfiler, kunderegistre, identitetsdata, HR-registreringer, biometriske data eller særlige kategorier af data, skal organisationen respektere GDPR-principperne, herunder lovlighed, rimelighed, gennemsigtighed, dataminimering, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Kopier af testdata, eksporterede logfiler og bevismateriale fra penetrationstest kan blive regulerede datalagre. Testprogrammet bør definere, hvem der må få adgang til dem, hvor længe de opbevares, og hvordan de bortskaffes sikkert.

Hvordan revisorer vil teste det samme program

En DORA-tilsynsmyndighed, ISO-revisor, NIST-baseret assessor, COBIT-gennemgangsansvarlig og kunderevisor kan inspicere det samme bevismateriale gennem forskellige optikker.

Zenith Controls er nyttig her som et kompas for tværgående efterlevelse. For DORA-test fremhæver Clarysec 5.35 Uafhængig gennemgang af informationssikkerhed, 8.8 Styring af tekniske sårbarheder og 8.6 Kapacitetsstyring som særligt vigtige ISO/IEC 27001:2022 Annex A-ankre. De hjælper kontrolansvarlige med at forbinde test til uafhængig assurance, sårbarhedshåndtering og operationel kapacitet.

Clarysec’s Informationssikkerhedspolitik understøtter også revisionssporet:

“Kontrolansvarlige skal opretholde testresultater, logfiler og gennemgangsregistreringer for at understøtte periodiske revisioner.”

Den sætning bør blive en operationel regel. Hver testejer bør vide, hvad der skal opbevares, hvor det skal opbevares, hvordan det skal beskyttes, og hvordan det knytter sig til risiko- og kontrolbevismateriale.

Byg en DORA-til-ISO-bevispakke på én uge

En finansiel enhed eller IKT-udbyder kan gøre væsentlige fremskridt på fem arbejdsdage.

Dag 1: Definér omfang og kritikalitet

Brug tankegangen fra ISO/IEC 27001:2022 Klausul 4.1 til 4.4. Identificér interessenter, regulatoriske forpligtelser, kontraktlige forpligtelser, grænseflader og afhængigheder. Oplist forretningstjenester, kritiske eller vigtige funktioner, nøgleaktiver, datatyper og IKT-udbydere.

Output: omfangsregister for DORA-test.

Dag 2: Opret det årlige testkatalog

Brug de fire testfamilier: sårbarhed, scenarie, performance og penetration. Definér for hver tjeneste, hvilke test der gælder, frekvens, ejer, uafhængighedsniveau og udløsende forhold. Medtag udløsere for højrisikoændringer.

Output: testkatalog for digital operationel robusthed for 2026.

Dag 3: Kortlæg kontroller og forpligtelser

Kortlæg hver test til ISO/IEC 27001:2022 Annex A, risikoregisteret, SoA, DORA-artikler, leverandørforpligtelser og relevante Zenith Controls-poster. For eksempel kortlægges månedlige eksterne sårbarhedsscanninger til 8.8 Styring af tekniske sårbarheder, risikobehandling, overvågning, DORA-styring af IKT-risiko og NIST CSF-sårbarhedsresultater.

Output: matrix for kontrolkortlægning.

Dag 4: Standardisér mapper til bevismateriale

Opret en kontrolleret bevisstruktur:

• 01 Plan og autorisation
• 02 Omfang og regler for gennemførelse
• 03 Rå resultater
• 04 Endelig rapport
• 05 Register over konstateringer
• 06 Afhjælpningssager
• 07 Bevismateriale fra gentest
• 08 Ledelsesrapportering
• 09 Læring og politikopdateringer

Output: bevisarkiv med opbevaringsregler.

Dag 5: Gennemgå konstateringer og rapportering

Konsolidér åbne konstateringer efter alvorlighed, tjeneste, risikoejer og forfaldsdato. Identificér forsinket afhjælpning, accepterede risici og mangler i gentest. Udarbejd et dashboard til ledelsesorganet, der viser testdækning, større konstateringer, forsinkede handlinger, tredjepartsforhold og restrisiko.

Output: bestyrelsesklar DORA- og ISO-testdashboard.

Almindelige faldgruber i DORA-testprogrammer

Den mest almindelige fejl er ikke mangel på test. Det er mangel på styring.

Vær opmærksom på disse forhold:

• Penetrationstest udføres årligt, men konstateringer følges ikke til lukning
• Sårbarhedsscanninger køres hyppigt, men kritiske aktiver mangler i omfanget
• Tabletop-øvelser gennemføres, men uden beslutningslog eller handlingsplan for læring
• Test af gendannelse fra backup gennemføres, men kortlægges ikke til RTO og RPO
• Belastningstest udføres af engineering, men rapporteres ikke til risiko eller compliance
• IKT-udbydere udelukkes fra scenarie- og genopretningstest
• Bevismateriale opbevares i personlige mapper, chattråde eller ustyrede drev
• Bestyrelsesrapporter fokuserer på aktivitetsantal frem for uafklaret robusthedsrisiko
• SoA siger, at en kontrol gælder, men der findes intet testbevismateriale
• Test skaber produktionsrisiko, fordi autorisation og afgrænsning er uklare

Hver mangel kan løses. Løsningen er ikke flere tilfældige test. Løsningen er ét kontrolleret program, der forbinder risiko, testaktivitet, afhjælpning, bevismateriale og ledelsestilsyn.

Hvad bestyrelsen faktisk bør se

DORA gør IKT-robusthed til et ansvar for ledelsesorganet. En nyttig bestyrelsesrapport bør ikke indeholde hver teknisk konstatering. Den bør besvare, om organisationen er robust nok i forhold til sin risikovillighed og tolerance for driftsforstyrrelser.

En stærk kvartalsvis eller halvårlig rapport omfatter:

• Testdækning i forhold til kritiske eller vigtige funktioner
• Gennemførte test sammenholdt med planlagte test
• Kritiske og høje konstateringer efter tjeneste
• Forsinket afhjælpning efter ejer
• Beståelsesrate for gentest
• Leverandørrelaterede konstateringer og koncentrationsbekymringer
• Læring fra scenarietest, der påvirker krise- eller hændelsesplaner
• Kapacitetsrisici i forhold til forretningsvækst og spidsbelastningsperioder
• Restrisici, der kræver ledelsens accept
• Begrænsninger i budget, ressourcer eller værktøjer

Denne rapport bliver input til ISO-ledelsens gennemgang, DORA-governancebevismateriale og et praktisk beslutningsværktøj.

Fra spredte test til strategisk robusthed

CISO’ens oprindelige problem var ikke, at der manglede test. Organisationen havde scanninger, tabletop-øvelser, belastningsrapporter og PDF’er med penetrationstest. Problemet var, at disse aktiviteter endnu ikke fortalte én sammenhængende bevisfortælling.

Et samlet DORA- og ISO/IEC 27001:2022-testprogram ændrer det. Risikovurderingen driver kataloget. Kataloget driver autoriseret test. Test producerer konstateringer. Konstateringer driver afhjælpning og gentest. Resultater føder ledelsesrapportering. Læring opdaterer politikker, procedurer, kontrakter og kontroller.

Sådan bliver en efterlevelsesbyrde til en strategisk kapacitet.

Clarysec hjælper organisationer med at undgå parallelle efterlevelsesprogrammer. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 og COBIT 2019 behøver ikke separate universer for bevismateriale. De kræver én samlet, styret driftsmodel, der kan præsenteres gennem forskellige revisionsvinkler.

Vores tilgang kombinerer:

• Zenith Blueprint til faseopdelt ISO-implementering og revisionsparathed
• Zenith Controls til tværgående efterlevelseskortlægning på tværs af kontroller, rammeværk og revisionsforventninger
• Enterprise- og SME-politikker for sikkerhedstestning, overvågning af efterlevelse, sårbarhedsstyring, applikationssikkerhed, kontinuitet og informationssikkerhed
• Praktiske registre, bevisstrukturer og skabeloner til ledelsesrapportering

Hvis jeres DORA-testbevismateriale for 2026 er spredt på tværs af scanningsværktøjer, engineering-mapper, tabletop-noter og PDF’er med penetrationstest, er tiden inde til at konsolidere det.

Start med ét årligt testkatalog, der er kortlagt til ISO/IEC 27001:2022-risikobehandling, jeres SoA, kritiske eller vigtige funktioner, IKT-tredjeparter og ledelsesrapportering. Brug derefter Clarysec’s Zenith Blueprint, Zenith Controls og policy toolkit til at omsætte kataloget til juridisk forsvarligt revisionsbevismateriale.

Clarysec kan hjælpe jer med at designe programmet, kortlægge kontrollerne, strukturere bevispakken og forberede robusthedsrapporten på bestyrelsesniveau, før den næste tilsynsanmodning lander.