DORA 2026-køreplan for IKT-risici, leverandører og TLPT

DORA 2026-søgepanikken handler egentlig ikke om regulering, men om bevismateriale

Klokken er 08:15 en mandag morgen, og informationssikkerhedschefen i et mellemstort betalingsinstitut har tre browserfaner åbne: “DORA RTS/ITS checklist”, “DORA ICT third-party register template” og “TLPT requirements financial entities”.

Den complianceansvarlige har allerede spurgt, om bestyrelsesmaterialet bør indeholde den seneste arbejdsgang for klassificering af hændelser. Indkøb vil indføre en ny cloudbaseret analyseplatform. Driftsdirektøren vil have sikkerhed for, at leverandøren af kernebank-SaaS ikke har skjult eksponering mod underleverandører uden for EU. Intern revision beder om en testkalender. Jura spørger, om GDPR-fristerne for underretning om brud er afstemt med DORA-hændelsesrapportering.

Ingen stiller et teoretisk spørgsmål. De spørger: “Kan vi dokumentere det inden fredag?”

Det er den reelle DORA 2026-udfordring. De fleste finansielle enheder forstår hovedforpligtelserne: styring af IKT-risici, rapportering af IKT-relaterede hændelser, test af digital operationel robusthed, styring af IKT-tredjepartsrisici og stærkere tilsyn med kritiske IKT-udbydere. Det vanskelige er at omsætte Regulatory Technical Standards, Implementing Technical Standards og forpligtelser på artikelniveau til kontrolleret, gentagelig og reviderbar praksis.

Digital Operational Resilience Act kræver, at finansielle enheder opretholder robuste kapaciteter til styring af IKT-risici, politikker for håndtering og rapportering af IKT-relaterede hændelser, test af IKT-systemer, kontroller og processer samt struktureret tilsyn med IKT-tredjepartsudbydere. Den forudsætter også proportionalitet. Et mindre investeringsselskab og en stor bankkoncern behøver ikke identiske evidensmodeller, men begge skal dokumentere, at tilgangen er egnet i forhold til størrelse, risikoprofil, kompleksitet og kritiske funktioner.

DORA-projekter fejler typisk af én af tre grunde. For det første behandler organisationen DORA som en juridisk kortlægningsøvelse i stedet for en driftsmodel. For det andet dokumenteres leverandørrisiko som en leverandørliste i stedet for som afhængighed, substitutionsmulighed og koncentrationsrisiko. For det tredje behandles test som en årlig penetrationstest i stedet for et robusthedsprogram, der omfatter sårbarhedsscanninger, scenarietest, hændelsesøvelser og, hvor relevant, trusselsbaseret penetrationstest, ofte søgt som TLPT.

En bedre tilgang er at opbygge ét evidenssystem, der forbinder politikker, registre, ejere, risici, hændelser, leverandører, test, genopretning og ledelsens gennemgang. Det er her, Clarysecs Zenith Blueprint, brugsklare politikker og Zenith Controls hjælper finansielle enheder med at gøre DORA fra en deadline til en driftsrytme.

Start med DORA-driftsmodellen, ikke RTS/ITS-regnearket

Mange teams begynder med et regneark med DORA-artikler og RTS/ITS-krav. Det er nyttigt, men ikke tilstrækkeligt. Et regneark kan vise, hvad der skal findes. Det tildeler ikke ejere, definerer ikke gennemgangsfrekvens, bevarer ikke bevismateriale og dokumenterer ikke, at en kontrol faktisk virker.

I Zenith Blueprint: en auditors 30-trins køreplan adresserer Clarysec dette i fasen for risikostyring, Step 14, risikobehandlingspolitikker og regulatoriske krydshenvisninger:

“DORA: For finansielle virksomheder kræver DORA en styringsramme for IKT-risici, der i høj grad svarer til det, vi har gjort: identificere risici, etablere kontroller (og politikker) og teste dem. DORA lægger også vægt på hændelseshåndtering og rapportering samt tilsyn med tredjepartsudbydere af IKT-tjenester.”

Det praktiske budskab er enkelt: Byg ikke “DORA-efterlevelse” som et parallelt bureaukrati. Opbyg et risikobaseret IKT-styringslag, der kortlægger DORA-krav til politikker, registre, kontrolansvarlige, testregistreringer, leverandørbevismateriale og ledelsens gennemgang.

En praktisk DORA-driftsmodel bør have fem evidenssøjler:

For regulerede finansielle enheder omsætter denne struktur RTS/ITS-implementering til et revisionsklart evidenssystem. For enheder med forenklet styring af IKT-risici kan samme model skaleres ned til færre dokumenter og enklere registre. Kerneområderne er de samme: identificere, beskytte, detektere, reagere, genoprette, teste og styre leverandører.

Styring af IKT-risici: registeret er kontrolrummet

DORAs forventninger til styring af IKT-risici kræver, at finansielle enheder identificerer, klassificerer og styrer IKT-risici på tværs af systemer, data, processer, kritiske eller vigtige funktioner og tredjepartsafhængigheder.

Den typiske mangel er ikke fraværet af et risikoregister. Det er, at registeret er frakoblet leverandører, aktiver, hændelser og test. DORA belønner ikke et flot regneark, hvis det ikke kan forklare, hvorfor en højrisikoleverandør ikke har en exit-plan, eller hvorfor en kritisk platform til kundebetalinger ikke er blevet testet.

Clarysecs SME Politik for risikostyring giver mindre finansielle enheder en kortfattet evidensbaseline:

“Hver risikoregistrering skal indeholde: beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan.”
Fra afsnittet “Styringskrav”, politikklausul 5.1.2.

For større finansielle enheder kræver Clarysecs Enterprise Politik for risikostyring en mere formel proces:

“Der skal opretholdes en formel risikostyringsproces i overensstemmelse med ISO/IEC 27005 og ISO 31000, som omfatter risikoidentifikation, analyse, evaluering, behandling, overvågning og kommunikation.”
Fra afsnittet “Styringskrav”, politikklausul 5.1.

Denne sondring er vigtig. DORA er proportional, men proportionalitet betyder ikke uformelt. Et mindre betalingsinstitut kan bruge et strømlinet register, mens en bankkoncern kan bruge integrerede GRC-værktøjer. I begge tilfælde vil revisor stadig spørge: Hvad er jeres IKT-risici? Hvem ejer dem? Hvad er behandlingsplanen? Hvilket bevismateriale viser fremdrift? Hvordan påvirker leverandører og kritiske funktioner scoren?

Et stærkt DORA IKT-risikoregister bør indeholde disse felter:

En praktisk øvelse er at tage én kritisk IKT-tjeneste, f.eks. en cloudhostet platform til transaktionsovervågning, og oprette en risikoregistrering på 20 minutter. Beskriv fejl- eller kompromitteringsscenariet, vurder sandsynlighed og konsekvens, tildel en ejer, identificér relaterede leverandører, definér en behandlingsplan, og knyt registreringen til bevismateriale såsom leverandør-due diligence, SLA, hændelsesklausuler, BIA, DR-testresultater, overvågningsdashboards og gennemgang af adgangsrettigheder.

Den ene registrering bliver tråden, der forbinder DORA-styring af IKT-risici, tredjepartstilsyn, hændelsesdetektion, forretningskontinuitet og test. Sådan bliver et risikoregister et kontrolrum, ikke et arkivskab.

RTS/ITS-beredskab: kortlæg forpligtelser til politikker, ikke løfter

Det praktiske søgeudtryk “DORA RTS/ITS checklist” betyder typisk “Hvilke dokumenter forventer tilsynsmyndighederne?” Finansielle enheder bør undgå at love efterlevelse gennem generiske udsagn. De har brug for en kortlægning, der knytter hver forpligtelse til en politik, kontrol, ejer og evidenselement.

Clarysecs SME Politik for juridisk og regulatorisk efterlevelse etablerer et enkelt styringsanker:

“Direktionen skal opretholde et enkelt, struktureret efterlevelsesregister, der angiver:”
Fra afsnittet “Styringskrav”, politikklausul 5.1.1.

For DORA 2026 bør jeres efterlevelsesregister indeholde:

• DORA-forpligtelse eller RTS/ITS-kravområde.
• Anvendelighed, herunder begrundelse for proportionalitet.
• Reference til politik eller procedure.
• Kontrolansvarlig.
• Placering af bevismateriale.
• Gennemgangsfrekvens.
• Åbne mangler og frist for afhjælpning.
• Status for rapportering til bestyrelse eller ledelse.

Dette er i tråd med tilgangen i Zenith Blueprint Step 14: kortlæg regulatoriske krav til ISMS-kontroller og politikker, så intet falder mellem stolene. I stedet for at spørge “Er vi DORA-compliant?”, kan ledelsen spørge: “Hvilke DORA-evidenselementer er forsinkede, hvilke kritiske leverandører mangler exit-planer, og hvilke testaktiviteter har endnu ikke produceret afhjælpningsbevismateriale?”

IKT-tredjepartsrisiko: koncentration, substitutionsmulighed og underleverandører

DORA har ændret leverandørdialogen i finansielle tjenester. Det er ikke længere nok at spørge, om en udbyder har en sikkerhedscertificering, forsikring eller databehandleraftale. Finansielle enheder skal vurdere, om en udbyder skaber koncentrationsrisiko, om udbyderen realistisk kan erstattes, om flere kritiske tjenester afhænger af én leverandør eller nært forbundne leverandører, og om brug af underleverandører medfører yderligere juridisk eksponering eller robusthedseksponering.

Det er den problemstilling, der holder mange informationssikkerhedschefer vågne. En virksomhed kan være afhængig af én stor cloududbyder til transaktionsbehandling, dataanalyse, kundeportaler og internt samarbejde. Hvis den udbyder rammes af et langvarigt nedbrud, en regulatorisk tvist eller et svigt hos en underleverandør, er spørgsmålet ikke kun “Har vi en kontrakt?” Spørgsmålet er: “Kan vi fortsætte kritiske tjenester, kommunikere med kunderne og dokumentere, at vi forstod afhængigheden, før den svigtede?”

Clarysecs SME Politik for tredjeparts- og leverandørsikkerhed fastlægger fundamentet:

“Et leverandørregister skal vedligeholdes og opdateres af den administrative kontaktperson eller indkøbskontakten. Det skal indeholde:”
Fra afsnittet “Styringskrav”, politikklausul 5.4.

For enterprise-programmer går Clarysecs Politik for risikostyring af leverandørafhængigheder dybere ind i DORA-specifik afhængighed og substitutionsmulighed:

“Register over leverandørafhængigheder: Leverandørstyringsfunktionen skal opretholde et ajourført register over alle kritiske leverandører, herunder oplysninger såsom leverede tjenester/produkter; om leverandøren er eneleverandør; tilgængelige alternative leverandører eller substitutionsmulighed; gældende kontraktvilkår; og en vurdering af konsekvensen, hvis leverandøren svigter eller kompromitteres. Registeret skal tydeligt identificere leverandører med høj afhængighed (f.eks. dem, hvor der ikke findes et hurtigt alternativ).”
Fra afsnittet “Implementeringskrav”, politikklausul 6.1.

Det er den leverandørevidens, DORA-projekter ofte overser. Et leverandørregister siger, hvem leverandøren er. Et afhængighedsregister siger, hvad der sker, når leverandøren svigter.

Zenith Blueprint, fasen Kontroller i praksis, Step 23, organisatoriske kontroller, giver en praktisk arbejdsgang for leverandørtilsyn. Den anbefaler at udarbejde en fuld leverandørliste, klassificere leverandører ud fra adgang til systemer, data eller driftsmæssig kontrol, verificere at sikkerhedsforventninger er indarbejdet i kontrakter, styre underleverandør- og downstream-risiko, definere ændrings- og overvågningsprocedurer og etablere en proces for vurdering af cloudtjenester.

I Zenith Controls: vejledning til tværgående efterlevelse er ISO/IEC 27002:2022-kontrol 5.21, styring af informationssikkerhed i IKT-forsyningskæden, kortlagt som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den er knyttet til sikkerhed i leverandørrelationer og cybersikkerhedskonceptet Identify. Den forbinder til sikker engineering, sikker kodning, adgangsstyring, sikkerhedstest, indsamling af bevismateriale, sikker udviklingslivscyklus og outsourcet udvikling.

Det er præcis den DORA-virkelighed, der gælder for tredjepartstilsyn. Leverandørrisiko handler ikke kun om indkøb. Den berører arkitektur, udvikling, hændelseshåndtering, adgangsstyring, forretningskontinuitet og jura.

Set fra et tværgående efterlevelsesperspektiv kortlægger Zenith Controls sikkerhed i IKT-forsyningskæden til GDPR Articles 28 og 32, fordi databehandlere og underdatabehandlere skal udvælges og føres tilsyn med ved hjælp af passende tekniske og organisatoriske foranstaltninger. Det understøtter NIS2-forventninger til sikkerhed i forsyningskæden, herunder Article 21 cybersikkerhedsrisikostyringsforanstaltninger og Article 22 koordinerede risikovurderinger af forsyningskæden. Det kortlægges stærkt til DORA Articles 28, 29 og 30, hvor IKT-tredjepartsrisiko, koncentrationsrisiko, videreoutsourcing og kontraktuelle bestemmelser er centrale.

Understøttende standarder styrker bevismaterialet. ISO/IEC 27036-3:2021 understøtter IKT-indkøb og sikker udvælgelse af leverandører. ISO/IEC 20243:2018 understøtter integritet af betroede teknologiprodukter og sikkerhed i forsyningskæden. ISO/IEC 27001:2022 forbinder dette med risikobehandling og leverandørkontroller i Annex A.

Hændelsesrapportering: byg eskalationskæden før hændelsen

DORA-hændelsesrapportering handler ikke kun om at indsende en underretning. Det handler om at detektere, klassificere, eskalere, kommunikere og lære af IKT-relaterede hændelser. Finansielle enheder skal opretholde processer for håndtering og rapportering af IKT-hændelser med definerede roller, klassificeringskriterier, underretningsveje og analyse efter hændelsen.

Clarysecs SME Politik for hændelseshåndtering forbinder tidsfrister for hændelseshåndtering med retlige krav:

“Tidsfrister for respons, herunder datagendannelse og underretningsforpligtelser, skal dokumenteres og afstemmes med retlige krav, såsom GDPR-kravet om underretning om brud på persondatasikkerheden inden for 72 timer.”
Fra afsnittet “Styringskrav”, politikklausul 5.3.2.

For enterprise-miljøer tilføjer Clarysecs Politik for hændelseshåndtering perspektivet for eskalering ved regulerede data:

“Hvis en hændelse medfører bekræftet eller sandsynlig eksponering af personoplysninger eller andre regulerede data, skal Jura og DPO vurdere anvendeligheden af:”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

Citatet slutter ved triggerpunktet, og det er netop dér, mange hændelsesprocesser fejler. Hvis triggeren er uklar, diskuterer teams underretningspligter, mens uret allerede tikker.

Zenith Blueprint, fasen Kontroller i praksis, Step 16, personrelaterede kontroller II, lægger vægt på personaledrevet hændelsesrapportering. Medarbejdere, kontrahenter og interessenter skal vide, hvordan de genkender og rapporterer potentielle sikkerhedshændelser via enkle kanaler såsom en særskilt mailboks, portal eller hotline. Blueprint knytter dette til GDPR Article 33, NIS2 Article 23 og DORA Article 17, fordi regulatorisk rapportering begynder med intern bevidsthed og eskalering.

I Zenith Controls er ISO/IEC 27002:2022-kontrol 5.24, planlægning og forberedelse af håndtering af informationssikkerhedshændelser, kortlagt som en korrigerende kontrol, der understøtter fortrolighed, integritet og tilgængelighed og er afstemt med Respond og Recover. Den knytter direkte an til hændelsesvurdering, læring fra hændelser, logning og overvågning, sikkerhed under afbrydelser, informationssikkerhedskontinuitet og kontakt med myndigheder. Vejledningen kortlægger dette til DORA Articles 17 to 23 for håndtering, klassificering og rapportering af IKT-relaterede hændelser samt frivillig underretning om cybertrusler, GDPR Articles 33 og 34 for underretning om brud og NIS2 Article 23 for underretning om hændelser.

En DORA-klar hændelsesproces bør omfatte:

• Klare kanaler til modtagelse af hændelser.
• Hændelsestriage og klassificeringskriterier.
• Arbejdsgang for eskalering af større IKT-relaterede hændelser.
• Beslutningspunkter for juridisk, DPO- og regulatorisk underretning.
• Triggere for leverandørers hændelsesunderretning.
• Krav til bevaring af bevismateriale.
• Regler for kommunikation til direktion og bestyrelse.
• Efterhændelsesgennemgang og læringspunkter.
• Kobling til opdateringer af risikoregister og afhjælpning af kontroller.

Understøttende standarder giver struktur. ISO/IEC 27035-1:2023 indeholder principper for planlægning og forberedelse af hændelsesstyring. ISO/IEC 27035-2:2023 beskriver trin for håndtering af hændelser. ISO/IEC 22320:2018 understøtter kommando, kontrol og struktureret krisekommunikation. Det er vigtigt, når et IKT-nedbrud bliver en krise med kundepåvirkning, og enheden skal dokumentere, at beslutningerne var rettidige, koordinerede og evidensbaserede.

Test af digital operationel robusthed og TLPT: lad ikke testen blive hændelsen

Test er et af de mest søgte DORA 2026-emner, fordi det både er teknisk og styringstungt. Finansielle enheder skal teste IKT-systemer, kontroller og processer. For udpegede enheder bliver avanceret test som TLPT et centralt krav efter DORA Article 26.

Revisionsspørgsmålet er ikke kun “Har I testet?” Det er: “Var testen risikobaseret, godkendt, sikker, uafhængig hvor påkrævet, afhjulpet og knyttet til robusthedsmål?”

Clarysecs Enterprise Politik for sikkerhedstest og red teaming definerer minimumsprogrammet for test klart:

“Typer af test: Sikkerhedstestprogrammet skal som minimum omfatte: (a) sårbarhedsscanninger, 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 team-øvelser, bestående af scenariebaserede simuleringer af reelle angreb, herunder social engineering og andre taktikker, for at teste organisationens detektions- og responskapaciteter som helhed.”
Fra afsnittet “Implementeringskrav”, politikklausul 6.1.

Dette er broen mellem rutinetest og TLPT-modenhed. Sårbarhedsscanninger finder kendte svagheder. Penetrationstest validerer udnyttelighed. Red teaming tester detektion og respons som et samlet system. TLPT bør, hvor relevant, ligge inden for et styret testprogram med kontrol af omfang, sikkerhedsregler, styring af produktionsrisiko, indsamling af bevismateriale og sporing af afhjælpning.

Zenith Blueprint, fasen Kontroller i praksis, Step 21, behandler beskyttelse af informationssystemer under revision og test. Den advarer om, at revisioner, penetrationstest, forensiske gennemgange og driftsmæssige evalueringer kan introducere risiko, fordi de kan involvere forhøjet adgang, invasive værktøjer eller midlertidige ændringer i systemadfærd. Blueprint kortlægger denne problemstilling til GDPR Article 32, DORA-forventninger til test af digital operationel robusthed, NIS2-kontinuitetsforhold og COBIT 2019-praksisser for sikker gennemførelse af revisioner og vurderinger.

I Zenith Controls er ISO/IEC 27002:2022-kontrol 5.35, uafhængig gennemgang af informationssikkerhed, kortlagt som forebyggende og korrigerende og understøtter fortrolighed, integritet og tilgængelighed. Den knytter an til efterlevelse af politikker, ledelsesansvar, læring fra hændelser, beskyttelse af registreringer, sletning af information, logning og overvågning. For DORA er de relevante testforpligtelser primært Articles 24 to 27, herunder Article 26 for TLPT. Dette understøtter også GDPR Article 32(1)(d), som kræver regelmæssig test og evaluering af tekniske og organisatoriske foranstaltninger, og NIS2 Article 21, som kræver cybersikkerhedsrisikostyringsforanstaltninger.

En DORA TLPT-beredskabspakke bør omfatte:

Den centrale DORA-læring er, at bevismateriale fra test ikke må stoppe ved rapporten. Revisorer vil spørge, om konstateringer blev risikovurderet, tildelt, afhjulpet og gentestet. De kan også kontrollere, om testen dækkede kritiske eller vigtige funktioner, ikke kun internetvendte aktiver.

Forretningskontinuitet og katastrofeberedskab: robusthed skal være operationel

DORA er en regulering for digital operationel robusthed. Genopretning er lige så vigtig som forebyggelse. En dokumenteret styringsramme for IKT-risici hjælper ikke, hvis et nedbrud på en betalingsplatform viser, at Recovery Time Objectives aldrig er blevet testet, leverandørkontakttræer er forældede, og kriseteamet ikke kan blive enige om, hvem der kommunikerer med kunderne.

Clarysecs SME Politik for forretningskontinuitet og Politik for genopretning efter alvorlige hændelser fastlægger en klar baseline:

“Organisationen skal teste både sine BCP- og DR-kapaciteter mindst én gang årligt. Test skal omfatte:”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

Enterprise Politik for forretningskontinuitet og Politik for genopretning efter alvorlige hændelser begynder med forretningskonsekvensen:

“Forretningskonsekvensanalyse (BIA) skal udføres mindst årligt for alle kritiske forretningsenheder og gennemgås ved væsentlige ændringer i systemer, processer eller afhængigheder. BIA-resultater skal definere:”
Fra afsnittet “Styringskrav”, politikklausul 5.2.

For DORA bør BIA’en være forbundet med IKT-aktiver, leverandører, hændelseshåndtering og test. Hvis BIA’en identificerer “kundebetalinger” som en kritisk funktion, bør registeret over leverandørafhængigheder identificere de processorer, cloudtjenester og netværksudbydere, der understøtter den. Risikoregisteret bør omfatte fejlscenarier. Testplanen bør omfatte validering af robusthed. Hændelseshåndteringsplanen bør omfatte eskalering og kommunikation. DR-testen bør producere bevismateriale, ikke blot et mødereferat.

Denne sporbarhed er det, der gør DORA-efterlevelse til et system for operationel robusthed.

Tværgående efterlevelse: ét evidenssæt, mange revisionsspørgsmål

Finansielle enheder står sjældent over for DORA alene. De har ofte GDPR-forpligtelser, NIS2-eksponering, kontraktuelle sikkerhedsforpligtelser, ISO/IEC 27001:2022-mål, interne revisionskrav, kunde-due diligence, SOC-forventninger og bestyrelsesrapportering om risiko. Svaret er ikke at oprette separate evidenssiloer. Svaret er at opbygge en evidensmodel for tværgående efterlevelse.

Zenith Controls er Clarysecs kompas for tværgående efterlevelse. Det opfinder ikke nye forpligtelser. Det kortlægger officielle standarder og rammeværker, så organisationer kan forstå, hvordan ét kontrolområde understøtter flere efterlevelsesresultater.

Det er vigtigt for budget og styring. En informationssikkerhedschef kan forklare bestyrelsen, at forbedret hændelsesklassificering understøtter DORA-rapportering, GDPR-underretning om brud, NIS2-hændelseshåndtering og intern robusthed. En indkøbsansvarlig kan begrunde kortlægning af leverandørafhængigheder, fordi den understøtter DORA-koncentrationsrisiko, GDPR-due diligence af databehandlere og NIS2-sikkerhed i forsyningskæden. En testansvarlig kan vise, at red team-øvelser og uafhængige gennemgange understøtter DORA-test, GDPR-kontrolevaluering og bredere assurance.

Revisionsperspektivet: hvordan assessorer tester jeres DORA-bevismateriale

DORA-beredskab bliver virkeligt, når nogen beder om bevismateriale. Forskellige revisorer og assessorer vil tilgå samme emne fra forskellige vinkler.

En revisor med udgangspunkt i ISO/IEC 27001:2022 vil begynde med ISMS-logikken: omfang, risikovurdering, risikobehandling, anvendelighed af Annex A-kontroller, intern revision, ledelsens gennemgang og bevismateriale for, at kontrollerne er implementeret. For sikkerhed i IKT-forsyningskæden vil de se på politikker, leverandørklassificering, kontraktklausuler, due diligence og løbende overvågning. For hændelsesstyring vil de inspicere planen, roller, eskalationsveje, værktøjer og registreringer. For test vil de forvente planlagte intervaller, uafhængighed hvor relevant, afhjælpning og input til ledelsens gennemgang.

Et revisionsperspektiv efter ISO/IEC 19011:2018 fokuserer på gennemførelsen af revisionen. I Zenith Controls bemærker revisionsmetodikken for sikkerhed i IKT-forsyningskæden, at revisorer undersøger indkøbspolitikker, RFP-skabeloner og leverandørstyringsprocesser for at verificere, at IKT-specifikke sikkerhedskrav er indarbejdet fra anskaffelse til udfasning. For hændelseshåndtering undersøger revisorer hændelseshåndteringsplanen for fuldstændighed og afstemning med bedste praksis. For uafhængig gennemgang leder revisorer efter bevismateriale for, at uafhængige revisioner eller gennemgange er gennemført.

Et ISO/IEC 27007:2020-perspektiv er mere ISMS-revisionsspecifikt. Zenith Controls bemærker, at revisorer kan interviewe indkøbsansvarlige, IT-sikkerhedsmedarbejdere og leverandøransvarlige for at vurdere forståelse og udførelse af IKT-forsyningskædekontroller. For hændelsesforberedelse bekræfter de, at et Incident Response Team findes og er operationelt. For uafhængig gennemgang verificerer de, at det interne revisionsprogram dækker hele ISMS-omfanget og har de nødvendige ressourcer.

En testassessor, der er informeret af NIST SP 800-115, vil fokusere på metode for sårbarhedsvurdering og penetrationstest. De kan undersøge, om testomfang, regler for gennemførelse, konstateringer, alvorlighedsvurderinger, afhjælpning og gentest er dokumenteret. For DORA TLPT betyder det, at assessoren ikke vil være tilfreds med et red team-præsentationsmateriale. De vil se bevis for styring, sikkerhed, teknisk dybde og lukning.

En COBIT 2019- eller ISACA-orienteret revisor vil spørge, om styringsmålene er opfyldt: hvem ejer processen, hvordan måles performance, hvordan godkendes undtagelser, og hvordan modtager ledelsen assurance.

Den praktiske DORA 2026-tjekliste for beredskab

Brug denne tjekliste som arbejdsbaseline til at omsætte DORA-søgninger til handling.

Styring og RTS/ITS-kortlægning

• Oprethold et DORA-efterlevelsesregister med forpligtelsesområde, anvendelighed, ejer, bevismateriale, gennemgangsfrekvens og status på mangler.
• Kortlæg DORA-krav til politikker, registre, kontroller og ledelsesrapportering.
• Definér proportionalitetsbegrundelse for forenklet eller skaleret styring af IKT-risici, hvor relevant.
• Tildel ledelsesansvar for IKT-risiko, hændelsesrapportering, tredjepartstilsyn og test.
• Medtag DORA-status i ledelsens gennemgang og bestyrelsens risikorapportering.

Styring af IKT-risici

• Oprethold et IKT-risikoregister med beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan.
• Knyt risici til kritiske eller vigtige funktioner.
• Knyt risici til IKT-aktiver, leverandører og processer.
• Gennemgå risici efter større hændelser, leverandørændringer, teknologiske ændringer eller testkonstateringer.
• Spor behandlingshandlinger til lukning eller formel risikoaccept.

Tilsyn med IKT-tredjeparter

• Oprethold et leverandørregister og et register over leverandørafhængigheder.
• Identificér leverandører, der understøtter kritiske eller vigtige funktioner.
• Vurdér eneleverandører og substitutionsmulighed.
• Gennemgå underleverandører og videreoutsourcing-arrangementer.
• Indarbejd sikkerheds-, adgangs-, hændelsesrapporterings-, revisions- og exit-klausuler i kontrakter.
• Overvåg kritiske leverandører mindst årligt eller efter væsentlige ændringer.
• Oprethold exit- og beredskabsplaner for udbydere med høj afhængighed.

Hændelsesstyring og rapportering

• Oprethold hændelseshåndteringsprocedurer med klare roller og eskalationsveje.
• Definér klassificeringskriterier for IKT-hændelser.
• Afstem DORA-rapporteringstriggere med GDPR, NIS2 og kontraktuelle underretningsforpligtelser.
• Træn medarbejdere og kontrahenter i kanaler til hændelsesrapportering.
• Oprethold hændelseslogfiler, beslutningsregistreringer og bevismateriale.
• Gennemfør efterhændelsesgennemgange, og opdater risici og kontroller.

Test, red teaming og TLPT

• Oprethold en risikobaseret testkalender.
• Udfør sårbarhedsscanninger og penetrationstest med definerede intervaller.
• Brug scenariebaserede red team-øvelser til at teste detektion og respons.
• For TLPT-beredskab skal omfang, regler for gennemførelse, sikkerhedskontroller og leverandørkoordinering defineres.
• Beskyt produktionssystemer under test.
• Spor konstateringer, afhjælpning, gentest og læringspunkter.
• Rapportér testresultater til ledelsen.

Forretningskontinuitet og genopretning

• Udfør årlig BIA for kritiske forretningsenheder, og opdater efter væsentlige ændringer.
• Definér genopretningsmål for kritiske funktioner og understøttende IKT-tjenester.
• Test BCP- og DR-kapaciteter mindst én gang årligt.
• Medtag scenarier for leverandørnedbrud og cyberhændelser.
• Bevar testbevismateriale, mangler, afhjælpende foranstaltninger og gentestresultater.
• Afstem kontinuitetsplaner med hændelseshåndtering og krisekommunikation.

Hvordan Clarysec hjælper finansielle enheder fra søgeresultater til revisionsklart bevismateriale

DORA 2026-beredskab opnås ikke ved at downloade en tjekliste og håbe, at organisationen kan udfylde hullerne senere. Det kræver en struktureret driftsmodel, der forbinder risiko, leverandører, hændelser, test, forretningskontinuitet og revisionsbevismateriale.

Clarysecs tilgang kombinerer tre lag.

For det første leverer Zenith Blueprint implementeringskøreplanen. Step 14 hjælper organisationer med at krydshenvise regulatoriske krav til risikobehandling og politikker. Step 16 styrker personaledrevet hændelsesrapportering. Step 21 sikrer, at revisioner og test ikke bringer produktionssystemer i fare. Step 23 gør leverandørtilsyn til en praktisk arbejdsgang, der dækker klassificering, kontrakter, underleverandører, overvågning og cloudvurdering.

For det andet leverer Clarysec-politikker styring, der er klar til operationalisering. Politik for risikostyring, Politik for juridisk og regulatorisk efterlevelse, Politik for tredjeparts- og leverandørsikkerhed, Politik for risikostyring af leverandørafhængigheder, Politik for hændelseshåndtering, Politik for sikkerhedstest og red teaming og Politik for forretningskontinuitet og Politik for genopretning efter alvorlige hændelser giver teams konkrete klausuler, ejerskabsmodeller og forventninger til bevismateriale.

For det tredje leverer Zenith Controls kortet over tværgående efterlevelse. Det viser, hvordan sikkerhed i IKT-forsyningskæden, planlægning af hændelsesstyring og uafhængig gennemgang forbinder til DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 og NIST-testpraksisser.

Resultatet er et DORA-efterlevelsesprogram, der er forsvarligt ved revision og nyttigt under en reel hændelse, et leverandørsvigt eller en robusthedstest.

Næste skridt: byg jeres DORA-evidenspakke før næste revisionsanmodning

Hvis jeres team stadig søger efter “DORA RTS/ITS checklist”, “DORA ICT risk management template”, “DORA third-party oversight” eller “DORA TLPT requirements”, er næste skridt at omsætte disse søgninger til kontrolleret bevismateriale.

Start med fire handlinger i denne uge:

1. Opret eller opdater jeres DORA-efterlevelsesregister ved hjælp af Clarysecs politikmodel.
2. Vælg én kritisk funktion, og spor den gennem risikoregisteret, registeret over leverandørafhængigheder, hændelsesarbejdsgangen, BIA’en og testplanen.
3. Gennemgå jeres fem vigtigste IKT-leverandører for substitutionsmulighed, underleverandører, hændelsesklausuler og exit-muligheder.
4. Opbyg en test-evidenspakke med omfang, godkendelse, resultater, afhjælpning og gentest.

Clarysec kan hjælpe jer med at implementere dette ved hjælp af Zenith Blueprint, politikskabeloner og Zenith Controls, så jeres DORA 2026-program er praktisk, proportionalt og revisionsklart.