DORA-hændelsesrapportering og ISO 27001-kontroller i 2026

Klokken er 08:17 en tirsdag morgen i 2026. Sarah, CISO i en europæisk FinTech-virksomhed, ser et dashboard blinke gult, ikke rødt. En kritisk platform til betalingsafvikling begynder at blive langsom. Transaktionerne fejler ikke fuldstændigt, men de tager tre gange længere tid, end serviceniveauaftalen tillader. SOC observerer usædvanlige autentifikationsforsøg mod en administratorkonto. Udbyderen af cloudinfrastruktur rapporterer serviceforringelse i én availability zone. Kundesupport begynder at modtage opkald fra erhvervskunder, der spørger, hvorfor betalingsfiler er forsinkede.

Ingen ved endnu, om der er tale om et cyberangreb, et svigt i operationel robusthed, en leverandørafbrydelse, en databeskyttelseshændelse eller det hele på én gang.

Sarah har et DORA-problem, før de tekniske fakta er fuldt afdækket. Er dette en større IKT-relateret hændelse? Påvirker den en kritisk eller vigtig funktion? Har den overskredet den interne alvorlighedstærskel? Hvem skal underrettes, hvornår og med hvilket bevismateriale? Hvis personoplysninger er involveret, er GDPR-underretningsfristen så også begyndt at løbe? Hvis en IKT-tredjepartsudbyder indgår i hændelseskæden, hvem ejer så fakta?

Det er her, finansielle enheder opdager forskellen mellem at have en hændelseshåndteringsplan og at have en revisionsbar driftsmodel for DORA-hændelsesrapportering.

DORA-hændelsesrapportering i 2026 kræver mere end hurtig eskalering. Den kræver en forsvarlig kæde fra detektion til klassificering, fra klassificering til tilsynsrapportering, fra rapportering til afhjælpning og fra afhjælpning til læring. ISO/IEC 27001:2022 leverer ledelsessystemets struktur. ISO/IEC 27001:2022 Annex A-kontroller og ISO/IEC 27002:2022-kontrolvejledning leverer de praktiske kontrolforventninger. Clarysec’s politikker, 30-trins køreplan og guide til tværgående compliance omsætter disse forventninger til revisionsklar implementering.

Hvorfor DORA-hændelsesrapportering fejler under pres

De fleste fejl i DORA-hændelsesrapportering begynder ikke med forsømmelse. De begynder med uklarhed.

En sikkerhedsanalytiker ser en alarm, men ved ikke, om den kvalificerer som en IKT-relateret hændelse efter DORA. Den IT-serviceansvarlige behandler forringet performance som et teknisk serviceproblem, mens compliancefunktionen behandler det som en regulatorisk hændelse. Juridisk funktion afventer bekræftelse, før der eskaleres. Forretningsejeren kan endnu ikke kvantificere kundepåvirkningen. CISO’en har brug for bevismateriale, men de relevante logfiler er spredt på cloudtjenester, endpoints, identitetssystemer, SIEM og leverandørplatforme.

Når organisationen når til enighed om klassificeringen, er rapporteringsvinduet allerede under pres.

DORA Article 17 til 21 etablerer en struktureret forventning til styring, klassificering, rapportering, rapporteringsindhold og tilsynsmæssig behandling af IKT-relaterede hændelser. For finansielle enheder er det praktiske krav klart: overvåg, styr, log, klassificér, rapportér, opdatér og lær af IKT-relaterede hændelser på en måde, der efterfølgende kan rekonstrueres.

Clarysec’s Politik for hændelseshåndtering [IRP] indarbejder DORA direkte i referencerammen:

EU DORA (2022/2554): Article 17: krav til finansielle institutioners rapportering af IKT-hændelser til kompetente myndigheder.

Den samme politik forbinder hændelsesstyring med ISO/IEC 27002:2022 Controls 5.25 til 5.27, som dækker ansvar for hændelsesvurdering, respons, kommunikation og forbedring.

For mindre finansielle teknologivirksomheder og slanke regulerede enheder gør Clarysec’s Politik for hændelseshåndtering - SME [IRP-SME] forpligtelsen operationel ved at fremhæve, at DORA kræver, at finansielle enheder klassificerer, rapporterer og følger op på IKT-relaterede hændelser og driftsforstyrrelser.

Den formulering er vigtig. DORA-efterlevelse er ikke kun en rapporteringsskabelon. Organisationen skal klassificere, rapportere og følge op. Det betyder bevismateriale for den indledende hændelse, beslutningskriterier, alvorlighedsniveau, rapporteringsbeslutning, kommunikation, genopretningshandlinger, leverandørinvolvering og opfølgning.

ISO/IEC 27001:2022 som kommandocenter for DORA-hændelser

Et modent ISO/IEC 27001:2022-ledelsessystem for informationssikkerhed bør ikke blive endnu en compliance-silo ved siden af DORA. Det bør være kommandocenteret for DORA-hændelsesrapportering.

Et ISMS kræver allerede risikoejerskab, kontroludvælgelse, intern revision, ledelsens gennemgang, dokumenteret information, løbende forbedring og bevismateriale for, at kontroller fungerer. DORA tilføjer sektorspecifikt rapporteringspres, men ISO/IEC 27001:2022 giver styringsstrukturen, der gør processen gentagelig.

Clarysec’s Zenith Blueprint: En revisors 30-trins køreplan [ZB] styrker denne integration i Step 13, planlægning af risikobehandling og Anvendelseserklæring. Blueprint anbefaler at kortlægge kontroller til risici og klausuler for at sikre sporbarhed, herunder at tilføje en Annex A-kontrolreference til risici og angive, hvornår kontroller understøtter GDPR, NIS2 eller DORA.

For Sarahs hændelse på betalingsafviklingsplatformen kunne posten i risikoregisteret være:

“Driftsafbrydelse eller kompromittering af platform til betalingsbehandling.”

De kortlagte ISO/IEC 27001:2022 Annex A-kontroller ville omfatte 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 og 8.16, med en DORA-note om klassificering og rapportering af større IKT-relaterede hændelser.

Clarysec’s Zenith Controls: Guide til tværgående compliance [ZC] fungerer derefter som kompas for tværgående compliance. I Zenith Controls kortlægger Clarysec ISO/IEC 27002:2022-kontroller til andre ISO/IEC 27001:2022-kontroller, relaterede standarder, revisionsforventninger og reguleringer som DORA, GDPR og NIS2. Den opretter ikke særskilte “Zenith controls”. Den viser, hvordan de eksisterende ISO-kontroller virker sammen, og hvordan de testes.

DORA-rapporteringsarbejdsgangen kan betragtes som en kontrolkæde:

Du kan ikke rapportere det, du ikke har detekteret. Du kan ikke klassificere det, du ikke har vurderet. Du kan ikke begrunde en rapporteringsbeslutning uden registreringer. Du kan ikke forbedre uden en efterhændelsesgennemgang.

Kontrol 6.8: DORA-uret starter med mennesker

I Sarahs scenarie kommer det første brugbare signal måske ikke fra SOC. Det kan komme fra en kundeansvarlig, der hører kundeklager, en økonomimedarbejder, der ser fejlede afviklingsbatches, eller en ingeniør, der bemærker unormal latenstid.

Derfor er ISO/IEC 27001:2022 Annex A control 6.8, rapportering af informationssikkerhedshændelser, afgørende for DORA. Den gør rapportering til et ansvar for hele arbejdsstyrken, ikke kun en funktion i sikkerhedsdriften.

I Zenith Blueprint, Step 16, People Controls II, anfører Clarysec:

Et effektivt hændelseshåndteringssystem begynder ikke med værktøjer, men med mennesker.

Step 16 anbefaler klare rapporteringskanaler, awareness-træning, en kultur uden skyldplacering, triage, fortrolighed og periodiske simuleringer. Det mest brugbare praktiske budskab er enkelt:

“Er du i tvivl, så rapportér.”

Det er et DORA-kontrolprincip. Hvis medarbejdere venter, til de er sikre, mister organisationen tid. Hvis de rapporterer tidligt, kan organisationen vurdere, klassificere og beslutte.

I Zenith Controls er 6.8 kortlagt som en detekterende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den kobler til 5.24, fordi rapporteringskanaler skal være en del af hændelsesplanen. Den føder 5.25, fordi hændelser kun kan vurderes, hvis de bliver rapporteret. Den udløser 5.26, fordi formel respons starter, når rapporter er evalueret.

For DORA understøtter dette Articles 17 og 18, hvor finansielle enheder skal styre, klassificere og rapportere større IKT-relaterede hændelser og væsentlige cybertrusler. Det understøtter også GDPR Article 33 og Recital 85, fordi intern rapportering afgør, hvor hurtigt et brud på persondatasikkerheden identificeres og eskaleres.

En praktisk Clarysec-implementering er en énsides instruks: “Sådan rapporterer du en IKT-hændelse”. Den bør omfatte:

• Hvad der skal rapporteres, herunder driftsafbrydelser, mistænkelige e-mails, mistede enheder, usædvanlig systemadfærd, mistanke om leverandørkompromittering, uautoriseret adgang, datalækage og serviceforringelser med kundepåvirkning.
• Hvordan der rapporteres, via en overvåget postkasse, ticketkategori, hotline, samarbejdskanal eller SOC-portal.
• Hvad der skal medtages, f.eks. tidspunkt, system, bruger, forretningsproces, observeret påvirkning, skærmbilleder hvis det er sikkert, og om kunder eller personoplysninger kan være berørt.
• Hvad man ikke må gøre, herunder ikke slette logfiler, ikke genstarte kritiske systemer uden instruks, ikke kontakte kunder eksternt uden godkendelse og ikke undersøge ud over egen rolle.
• Hvad der sker derefter, herunder triage, klassificering, eskalering, respons, bevarelse af bevismateriale og eventuel regulatorisk vurdering.

Formålet er ikke at gøre alle medarbejdere til efterforskere. Formålet er at gøre alle medarbejdere til pålidelige signalkilder.

Kontrol 5.25: DORAs klassificeringsbeslutning

DORA-rapportering af større IKT-relaterede hændelser afhænger af klassificering. Her bliver ISO/IEC 27001:2022 Annex A control 5.25, vurdering og beslutning om informationssikkerhedshændelser, central.

Zenith Blueprint, Step 23, forklarer den praktiske udfordring:

Ikke enhver anomali er en katastrofe. Ikke enhver alarm er tegn på kompromittering.

Den beskriver derefter formålet med 5.25 som:

at skelne det harmløse fra det skadelige og vide, hvad der kræver eskalering.

For DORA er dette tidspunktet, hvor en sikkerhedshændelse, serviceforringelse, leverandørafbrydelse, dataeksponering eller driftsforstyrrelse vurderes mod kriterierne for større hændelser. Organisationen skal overveje driftsmæssig påvirkning, berørte tjenester, kritiske eller vigtige funktioner, berørte kunder og transaktioner, varighed, geografisk udbredelse, datapåvirkning, omdømmemæssige konsekvenser og økonomisk påvirkning.

I Zenith Controls er 5.25 direkte kortlagt til DORA Article 18, klassificering af større IKT-hændelser. Det er den strukturerede evalueringsproces til at afgøre, om en observeret begivenhed kvalificerer som en sikkerhedshændelse. Den kobler også til 8.16, overvågningsaktiviteter, fordi alarmer og logdata skal triageres, og til 5.26, fordi klassificering udløser respons.

Det er her, mange organisationer fejler ved revisioner. De har tickets, men ikke klassificeringsregistreringer. De har alvorlighedsmærkater, men ikke kriterier. De har regulatoriske rapporter, men ikke beslutningssporet, der dokumenterer, hvorfor en hændelse blev eller ikke blev anset for større.

Clarysec håndterer dette ved at indbygge DORA-klassificering i modellen for hændelsers alvorlighed. I virksomhedsversionen af Politik for hændelseshåndtering indeholder clause 5.3.1 et klart Tier 1-eksempel:

Tier 1: Kritisk (f.eks. bekræftet brud på persondatasikkerheden, ransomwareudbrud, kompromittering af produktionssystem)

For mindre organisationer tilføjer Politik for hændelseshåndtering - SME en præcis driftsmæssig forventning:

Direktøren skal med input fra IT-leverandøren klassificere alle hændelser efter alvorlighed inden for én time efter underretning.

Klassificeringsmålet på én time er stærkt, fordi det gennemtvinger styringsdisciplin. En mindre reguleret enhed har måske ikke et 24/7 SOC, men den kan stadig definere, hvem der klassificerer, hvem der rådgiver, og hvor hurtigt beslutningen skal træffes.

En DORA-til-ISO-triageregistrering for hændelser

For at gøre klassificeringen forsvarlig bør der oprettes en DORA-triageregistrering for hændelser i ticketing-, GRC- eller hændelsesstyringssystemet. Registreringen bør oprettes for enhver potentielt væsentlig IKT-hændelse, også hvis den senere nedklassificeres.

Tilføj et beslutningsnotat:

“På baggrund af driftsforstyrrelse i betalingstjenesten, der påvirker en kritisk forretningsproces, uafklaret rodårsag og potentiel kundepåvirkning, eskaleres begivenheden som en potentiel større IKT-relateret hændelse. Compliancefunktionen og juridisk funktion skal vurdere krav til regulatorisk underretning. Bevarelse af bevismateriale er igangsat.”

Denne ene registrering understøtter DORA Article 17-sporing, Article 18-klassificering, Article 19-rapporteringsbeslutninger, ISO/IEC 27001:2022 Annex A 5.25-vurdering, 6.8-rapportering, 5.26-respons og 5.28-håndtering af bevismateriale.

Kontroller 5.24 og 5.26: Planlægning, roller og respons

Når en DORA-hændelse indtræffer, skal responsplanen allerede kunne besvare de vanskelige spørgsmål.

Hvem har bemyndigelse til at klassificere? Hvem kontakter den kompetente myndighed? Hvem godkender den indledende underretning? Hvem kommunikerer med kunderne? Hvem kontakter IKT-tredjepartsudbyderen? Hvem beslutter, om hændelsen også udløser GDPR-underretning? Hvem bevarer bevismateriale? Hvem ejer den endelige rapport?

ISO/IEC 27001:2022 Annex A control 5.24, planlægning og forberedelse af håndtering af informationssikkerhedshændelser, besvarer disse spørgsmål før krisen. Control 5.26, respons på informationssikkerhedshændelser, sikrer, at planen omsættes til kontrolleret handling under hændelsen.

I Zenith Controls er 5.24 knyttet til DORA Articles 17 til 21, fordi den operationaliserer dokumenteret, testet og gennemgået hændelseshåndtering, herunder intern eskalering, ekstern regulatorisk underretning, kommunikation med interessenter og læring.

ISO/IEC 27035-1:2023 understøtter dette ved at udvide hændelsesstyring ud over responsprocedurer til politik, planlægning, kapabiliteter, relationer, støttemekanismer, bevidsthed, træning og regelmæssig test. ISO/IEC 27035-2:2023 beskriver yderligere hændelsesstyringsprocessen fra forberedelse til læring.

Zenith Blueprint, Step 23, giver en direkte implementeringsinstruks:

Sørg for, at I har en ajourført hændelseshåndteringsplan (5.24), der dækker forberedelse, eskalering, respons og kommunikation.

En DORA-klar hændelseshåndteringsplan bør definere:

• IKT-hændelseshåndteringsteamet og stedfortrædere.
• Bemyndigelse til klassificering af alvorlighed og eskalering af DORA-rapportering.
• Ansvar for juridisk funktion, compliance, databeskyttelse, kommunikation, IT, sikkerhed, leverandør og forretningsejer.
• Kriterier for klassificering af større IKT-relaterede hændelser.
• Procedurer for indledende, mellemliggende og endelig regulatorisk rapportering.
• Vurdering af underretningsudløsere for GDPR, NIS2, kontrakter, cyberforsikring og bestyrelse.
• Trin for inddæmning, fjernelse, genopretning og validering.
• Krav til bevarelse af bevismateriale.
• Procedurer for leverandøreskalering og adgang til logfiler.
• Læring og sporing af korrigerende handlinger.

Politik for hændelseshåndtering - SME forbinder også responstider med retlige krav:

Responstider, herunder datagendannelse og underretningsforpligtelser, skal dokumenteres og tilpasses retlige krav, såsom GDPR-kravet om underretning om brud på persondatasikkerheden inden for 72 timer.

Dette er afgørende, fordi en enkelt IKT-hændelse kan blive en større DORA-hændelse, et GDPR-brud på persondatasikkerheden, en væsentlig NIS2-hændelse, en kontraktuel kundeunderretningshændelse og et leverandørstyringsproblem. Planen skal koordinere disse lag i stedet for at behandle dem som adskilte verdener.

Kontroller 8.15 og 8.16: Logfiler gør rapporten forsvarlig

DORA-hændelsesrapportering afhænger af fakta. Fakta afhænger af logning og overvågning.

I betalingsafviklingsscenariet skal Sarah vide, hvornår forringelsen begyndte, hvilke systemer der var berørt, om privilegerede konti blev brugt, om data forlod miljøet, om cloududbyderens driftsafbrydelse stemmer overens med intern telemetri, og hvornår genopretningen var afsluttet.

ISO/IEC 27001:2022 Annex A control 8.15, logning, og 8.16, overvågningsaktiviteter, understøtter dette bevisgrundlag. I Zenith Controls kobler begge til 5.24, fordi planlægning af hændelseshåndtering skal omfatte brugbare logdata og overvågningskapacitet. Control 8.16 kobler også til 5.25, fordi alarmer skal triageres til beslutninger.

Clarysec’s Lognings- og overvågningspolitik - SME [LMP-SME] indeholder et praktisk eskaleringskrav:

Højprioritetsalarmer skal eskaleres til den administrerende direktør og databeskyttelseskoordinatoren inden for 24 timer.

For DORA-regulerede enheder kræver potentielt større IKT-hændelser normalt en hurtigere driftsmæssig eskaleringsmodel, især hvor kritiske eller vigtige funktioner er berørt. Styringsmønstret er dog korrekt: højprioritetsalarmer må ikke forblive i IT. De skal nå forretningen, databeskyttelsesrollen og ledelsesroller.

En DORA-klar logningsmodel bør omfatte:

• Centraliseret logning for kritiske systemer, identitetsplatforme, endpoints, cloudtjenester, netværkssikkerhedsværktøjer og forretningsapplikationer.
• Tidssynkronisering på tværs af systemer, så hændelsestidslinjer er pålidelige.
• Alarmkategorisering tilpasset hændelsens alvorlighed og DORA-klassificering.
• Logopbevaring tilpasset regulatoriske, kontraktuelle og forensiske behov.
• Adgangsstyring, der beskytter logfilernes integritet.
• Procedurer for indsamling af logsnapshots under større hændelser.
• Krav om adgang til leverandørlogfiler for kritiske IKT-tjenester.

Revisorer accepterer ikke “det ligger i SIEM” som tilstrækkeligt bevismateriale. De vil spørge, om de rigtige logfiler fandtes, om alarmer blev gennemgået, om eskalering skete rettidigt, og om logfiler blev bevaret, da hændelsen blev potentielt rapporteringspligtig.

Kontrol 5.28: Indsamling af bevismateriale og chain of custody

Ved en større IKT-relateret hændelse tjener bevismateriale tre formål: teknisk undersøgelse, regulatorisk ansvarlighed og juridisk forsvarlighed.

Hvis bevismateriale er ufuldstændigt, overskrevet, ændret eller udokumenteret, kan organisationen få svært ved at dokumentere, hvad der skete. Den kan også få svært ved at begrunde sin klassificeringsbeslutning.

Clarysec’s Politik for indsamling af bevismateriale og digital efterforskning [ECF] fastslår:

En chain-of-custody-log skal følge alt fysisk eller digitalt bevismateriale fra erhvervelsestidspunktet gennem arkivering eller overførsel og skal dokumentere:

SME-versionen, Politik for indsamling af bevismateriale og digital efterforskning - SME [ECF-SME], holder kravet enkelt:

Hvert element af digitalt bevismateriale skal logges med:

Den driftsmæssige læring er direkte. Håndtering af bevismateriale kan ikke begynde, efter juridisk funktion beder om det. Den skal være indbygget i hændelseshåndteringen.

ISO/IEC 27006-1:2024 styrker denne revisionsforventning ved at fremhæve procedurer til at identificere, indsamle og bevare bevismateriale fra informationssikkerhedshændelser. For DORA kan det samme bevismateriale understøtte den indledende underretning, mellemliggende opdateringer, den endelige rapport, efterhændelsesgennemgangen og tilsynsspørgsmål.

En praktisk evidenstjekliste for DORA-relaterede hændelser bør omfatte:

• Hændelsesticket og triagenotater.
• Tidslinje for detektion, eskalering, klassificering, rapportering, inddæmning, genopretning og lukning.
• SIEM-alarmer og korrelerede logfiler.
• Artefakter fra endpoints og servere.
• Identitets- og privilegerede adgangslogfiler.
• Opsummeringer af netværkstrafik.
• Cloududbyderstatus og revisionslogfiler.
• Leverandørkommunikation og hændelseserklæringer.
• Registreringer af forretningspåvirkning, herunder kunder, tjenester, transaktioner og nedetid.
• Udkast og indsendelser vedrørende regulatorisk underretning.
• Ledelsesbeslutninger og godkendelser.
• Rodårsagsanalyse.
• Læring og korrigerende handlinger.

Bevismaterialet skal vise både tekniske fakta og styringsbeslutninger. DORA-rapportering handler ikke kun om, hvad der skete med systemerne. Den handler også om, hvordan ledelsen erkendte, vurderede, eskalerede, kontrollerede og forbedrede sig på baggrund af hændelsen.

Kontrol 5.27: Læring og løbende forbedring

En DORA-hændelse er ikke lukket, når den endelige rapport er indsendt. Den er lukket, når organisationen har lært af den, tildelt korrigerende handlinger, opdateret kontroller og verificeret forbedring.

ISO/IEC 27001:2022 Annex A control 5.27, læring af informationssikkerhedshændelser, forbinder DORA-rapportering med ISO/IEC 27001:2022-cyklussen for løbende forbedring. I Zenith Controls er 5.24 knyttet til 5.27, fordi hændelsesstyring er ufuldstændig uden rodårsagsanalyse, læring og forbedring af kontroller.

Zenith Blueprint, Step 23, instruerer organisationer i at opdatere planen med læring og give målrettet uddannelse i hændelseshåndtering og håndtering af bevismateriale. Dette er særligt vigtigt for DORA, fordi tilbagevendende klassificeringsforsinkelser, manglende leverandørbevismateriale, svage logfiler eller uklar kommunikation kan blive tilsynsmæssige bekymringer.

En læringsskabelon bør registrere:

• Hvad der skete og hvornår.
• Hvilke kritiske eller vigtige funktioner der var berørt.
• Om klassificeringen var rettidig og korrekt.
• Om DORA-rapporteringsbeslutninger blev truffet med tilstrækkeligt bevismateriale.
• Om udløsere for GDPR-, NIS2-, kontraktuel eller kundeunderretning blev vurderet.
• Om leverandører reagerede inden for aftalte tidsfrister.
• Om logfiler og forensisk bevismateriale blev bevaret.
• Hvilke kontroller der svigtede eller manglede.
• Hvilke politikker, playbooks, træning eller tekniske kontroller der skal forbedres.
• Hvem der ejer hver korrigerende handling og med hvilken frist.

Dette føder også ISO/IEC 27001:2022 ledelsens gennemgang. Hændelsestendenser bør gennemgås af ledelsen, ikke begraves i tekniske postmortems.

Tværgående compliance: DORA, GDPR, NIS2, NIST og COBIT 2019

DORA er overskriften for finansielle enheder, men hændelsesrapportering hører sjældent kun til ét framework.

En enkelt IKT-hændelse kan omfatte DORA-rapportering af større IKT-relaterede hændelser, GDPR-underretning om brud på persondatasikkerheden, NIS2-rapportering af væsentlige hændelser, kundekontraktforpligtelser, underretning af cyberforsikring og rapportering til bestyrelsen.

Zenith Controls hjælper med at reducere denne kompleksitet ved at kortlægge ISO/IEC 27002:2022-kontroller på tværs af frameworks. For eksempel:

Fra et NIST-perspektiv understøtter den samme model resultater inden for Detect, Respond og Recover. Fra et COBIT 2019- og ISACA-revisionsperspektiv er fokus styring: om hændelsesstyring, kontinuitet, risiko, compliance, leverandøransvar og performanceovervågning er kontrolleret.

De mest modne organisationer opretter ikke særskilte arbejdsgange for hvert framework. De opretter én hændelsesstyringsproces med regulatoriske overlejringer. Ticketen registrerer de samme centrale fakta én gang og forgrener sig derefter til DORA, GDPR, NIS2, kontraktuel, forsikringsmæssig eller sektorspecifik rapportering, når det kræves.

Hvordan revisorer vil teste jeres DORA-hændelsesproces

En DORA-klar hændelsesrapporteringsproces skal kunne modstå forskellige revisionsvinkler.

En ISO/IEC 27001:2022-revisor vil undersøge, om ISMS’et har valgt og implementeret relevante Annex A-kontroller, om Anvendelseserklæringen understøtter disse kontroller, om der findes hændelsesregistreringer, og om intern revision og ledelsens gennemgang omfatter hændelsesperformance.

Zenith Controls henviser til ISO/IEC 19011:2018-revisionsmetodik for 5.24, 5.25 og 6.8. For 5.24 undersøger revisorer hændelseshåndteringsplanen for hændelsestyper, alvorlighedsklassificeringer, tildelte roller, kontaktlister, eskalationsveje, instruktioner for regulatorisk rapportering og kommunikationsansvar. For 5.25 undersøger de, om der findes dokumenterede klassificeringskriterier, f.eks. alvorlighedsmatricer eller beslutningstræer baseret på systempåvirkning, datafølsomhed og varighed. For 6.8 vurderer de rapporteringsmekanismer, time-to-report-metrikker og bevismateriale for, at rapporterede begivenheder logges, triageres og løses.

En DORA-tilsynsgennemgang vil fokusere på, om større IKT-relaterede hændelser detekteres, klassificeres, rapporteres, opdateres og lukkes i overensstemmelse med regulatoriske forventninger. Den gennemgangsansvarlige kan bede om en prøve på en hændelse og følge den fra første alarm til endelig rapport.

En databeskyttelsesrevisor vil fokusere på, om risikoen for brud på persondatasikkerheden blev vurderet, og om forpligtelserne i GDPR Article 33 og Article 34 blev udløst. BS EN 17926:2023 er relevant her, fordi den tilføjer ansvar for databeskyttelseshændelser, underretningskriterier, timing og tilpasning til tilsynsmæssige forventninger om offentliggørelse.

Det samme bevismateriale kan besvare flere revisionsspørgsmål, hvis det er struktureret korrekt fra begyndelsen.

Tjekliste for DORA-hændelsesrapporteringsberedskab i 2026

Før jeres næste tabletop-øvelse, interne revision eller tilsynsgennemgang bør I teste organisationen mod denne tjekliste:

• Ved medarbejderne, hvordan de rapporterer mistænkte IKT-hændelser?
• Findes der en særskilt kanal til hændelsesrapportering?
• Logges og triageres sikkerhedshændelser konsekvent?
• Findes der en dokumenteret matrix for alvorlighed og DORA-klassificering af større hændelser?
• Kræves klassificering inden for en defineret tid efter underretning?
• Er kritiske eller vigtige funktioner kortlagt til systemer og leverandører?
• Vurderes udløsere for DORA-, GDPR-, NIS2-, kontraktuel, forsikrings- og kundeunderretning i én arbejdsgang?
• Er hændelsesroller defineret på tværs af IT, sikkerhed, juridisk funktion, compliance, databeskyttelse, kommunikation og forretningsejere?
• Er logfiler tilstrækkelige til at rekonstruere hændelsestidslinjer?
• Bevares bevismateriale med chain of custody?
• Er leverandørers hændelsesforpligtelser og rettigheder til adgang til logfiler testet?
• Gennemføres tabletop-øvelser med realistiske DORA-scenarier?
• Spores læring til korrigerende handlinger?
• Gennemgås hændelsesmetrikker i ledelsens gennemgang?
• Er Anvendelseserklæringen kortlagt til DORA-relevante ISO/IEC 27001:2022-kontroller?

Hvis svaret på nogen af disse er “delvist”, er problemet ikke kun compliance. Det er operationel robusthed.

Opbyg en revisionsklar DORA-model for hændelsesrapportering

DORA-hændelsesrapportering i 2026 er en test af styring under pres. De organisationer, der klarer sig godt, er ikke dem med de længste hændelseshåndteringsdokumenter. Det er dem med klare rapporteringskanaler, hurtig klassificering, pålidelige logfiler, bevaret bevismateriale, uddannede medarbejdere, testet leverandøreskalering og sporbarhed på tværs af frameworks.

Clarysec kan hjælpe jer med at opbygge den driftsmodel.

Start med at kortlægge jeres hændelsesrisici og Anvendelseserklæring ved hjælp af Zenith Blueprint: En revisors 30-trins køreplan. Tilpas derefter jeres hændelseskontroller med Zenith Controls: Guide til tværgående compliance. Operationalisér processen med Clarysec’s Politik for hændelseshåndtering, Politik for hændelseshåndtering - SME, Lognings- og overvågningspolitik - SME, Politik for indsamling af bevismateriale og digital efterforskning og Politik for indsamling af bevismateriale og digital efterforskning - SME.

Hvis jeres ledelsesteam ønsker sikkerhed før den næste reelle hændelse, så gennemfør en DORA-tabletop for en større IKT-relateret hændelse med Clarysec’s værktøjssæt, og udarbejd den evidence pack, som en revisor eller tilsynsmyndighed forventer at se.