DORA-incidentrapportering och ISO 27001-kontroller 2026

Klockan är 08:17 en tisdagsmorgon 2026. Sarah, informationssäkerhetschef på ett europeiskt FinTech-bolag, ser att en kontrollpanel blinkar gult, inte rött. En kritisk plattform för betalningsavveckling börjar gå långsamt. Transaktionerna misslyckas inte helt, men de tar tre gånger längre tid än vad servicenivåavtalet tillåter. SOC ser ovanliga autentiseringsförsök mot ett administratörskonto. Molninfrastrukturleverantören rapporterar försämrad tjänst i en tillgänglighetszon. Kundsupport börjar få samtal från företagskunder som frågar varför betalningsfiler är försenade.

Ingen vet ännu om detta är en cyberattack, ett fel i den operativa resiliensen, ett leverantörsavbrott, en integritetsincident eller allt på en gång.

Sarah har ett DORA-problem innan de tekniska fakta är fullständiga. Är detta en större IKT-relaterad incident? Påverkas en kritisk eller viktig funktion? Har händelsen passerat organisationens interna allvarlighetströskel? Vem ska underrättas, när och med vilket underlag? Om personuppgifter berörs, har även tidsfristen för GDPR-anmälan börjat löpa? Om en IKT-tredjepartsleverantör ingår i incidentkedjan, vem ansvarar för fakta?

Det är här finansiella entiteter upptäcker gapet mellan att ha en incidenthanteringsplan och att ha en granskningsbar operativ modell för DORA-incidentrapportering.

DORA-incidentrapportering 2026 kräver mer än snabb eskalering. Den kräver en försvarbar kedja från detektering till klassificering, från klassificering till rapportering till behörig myndighet, från rapportering till åtgärdande och från åtgärdande till erfarenhetsåterföring. ISO/IEC 27001:2022 ger strukturen för ledningssystemet. ISO/IEC 27002:2022 ger den praktiska vägledningen för kontrollerna i bilaga A. Clarysecs policyer, 30-stegs färdplan och guide för samordnad regelefterlevnad omsätter dessa förväntningar i ett genomförande som är redo som revisionsunderlag.

Varför DORA-incidentrapportering brister under press

De flesta misslyckanden i DORA-incidentrapportering börjar inte med oaktsamhet. De börjar med otydlighet.

En säkerhetsanalytiker ser ett larm men vet inte om det kvalificerar som en IKT-relaterad incident enligt DORA. IT-tjänsteansvarig behandlar försämrad prestanda som ett tekniskt tjänsteproblem, medan regelefterlevnadsfunktionen ser det som en regulatorisk händelse. Juridik inväntar bekräftelse innan eskalering. Verksamhetsägaren kan ännu inte kvantifiera kundpåverkan. Informationssäkerhetschefen vill ha underlag, men de relevanta loggarna är spridda över molntjänster, slutpunkter, identitetssystem, SIEM och leverantörsplattformar.

När organisationen väl enas om klassificeringen är rapporteringsfönstret redan under press.

DORA Articles 17 till 21 skapar en strukturerad förväntan på hantering av IKT-relaterade incidenter, klassificering, rapportering, rapportinnehåll och tillsynshantering. För finansiella entiteter är det praktiska kravet tydligt: övervaka, hantera, logga, klassificera, rapportera, uppdatera och lära av IKT-relaterade incidenter på ett sätt som kan rekonstrueras i efterhand.

Clarysecs Policy för incidenthantering [IRP] bäddar in DORA direkt i referensramverket:

EU:s DORA-förordning (2022/2554): Article 17: krav på rapportering av IKT-incidenter från finansiella institut till behöriga myndigheter.

Samma policy kopplar incidenthantering till ISO/IEC 27002:2022-kontrollerna 5.25 till 5.27, som omfattar ansvar för incidentbedömning, respons, kommunikation och förbättring.

För mindre fintechbolag och resursbegränsade reglerade entiteter gör Clarysecs Policy för incidenthantering – SME [IRP-SME] skyldigheten praktiskt genom att betona att DORA kräver att finansiella entiteter klassificerar, rapporterar och följer upp IKT-relaterade incidenter och störningar.

Den formuleringen är viktig. DORA-efterlevnad är inte bara en rapportmall. Organisationen ska klassificera, rapportera och följa upp. Det innebär underlag för den initiala händelsen, beslutskriterier, allvarlighetsgrad, rapporteringsbeslut, kommunikation, återställningsåtgärder, leverantörsinvolvering och uppföljning.

ISO/IEC 27001:2022 som DORA:s ledningscentral för incidenter

Ett moget ledningssystem för informationssäkerhet enligt ISO/IEC 27001:2022 bör inte bli ännu en efterlevnadssilo bredvid DORA. Det bör vara ledningscentralen för DORA-incidentrapportering.

ISMS kräver redan riskägarskap, urval av kontroller, internrevision, ledningens genomgång, dokumenterad information, ständig förbättring och underlag för kontrollernas funktion. DORA tillför sektorsspecifik rapporteringspress, men ISO/IEC 27001:2022 ger styrningsstrukturen som gör processen repeterbar.

Clarysecs Zenith Blueprint: revisorns 30-stegs färdplan [ZB] förstärker denna integrering i steg 13, planering av riskbehandling och tillämpbarhetsförklaring. Blueprint rekommenderar att kontroller kopplas till risker och klausuler för spårbarhet, inklusive att lägga till en kontrollreferens till bilaga A för risker och ange när kontroller stödjer GDPR, NIS2 eller DORA.

För Sarahs incident i betalningsavvecklingen kan posten i riskregistret vara:

”Störning eller kompromettering av plattformen för betalningshantering.”

De mappade ISO/IEC 27001:2022-kontrollerna i bilaga A skulle omfatta 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 och 8.16, med en DORA-notering för klassificering och rapportering av större IKT-relaterade incidenter.

Clarysecs Zenith Controls: guide för samordnad regelefterlevnad [ZC] fungerar därefter som kompassen för tvärgående regelefterlevnad. I Zenith Controls mappar Clarysec ISO/IEC 27002:2022-kontroller till andra ISO/IEC 27001:2022-kontroller, relaterade standarder, revisionsförväntningar och regelverk som DORA, GDPR och NIS2. Den skapar inte separata ”Zenith-kontroller”. Den visar hur befintliga ISO-kontroller fungerar tillsammans och hur de testas.

DORA-rapporteringsarbetsflödet kan betraktas som en kontrollkedja:

Du kan inte rapportera det du inte har detekterat. Du kan inte klassificera det du inte har bedömt. Du kan inte motivera ett rapporteringsbeslut utan dokumentation. Du kan inte förbättra utan en granskning efter incident.

Kontroll 6.8: DORA-klockan startar med människor

I Sarahs scenario kanske den första användbara signalen inte kommer från SOC. Den kan komma från en kundansvarig som hör kundklagomål, en ekonomianvändare som ser misslyckade avvecklingsbatcher eller en ingenjör som noterar onormal latens.

Därför är ISO/IEC 27001:2022-kontroll 6.8 i bilaga A, rapportering av informationssäkerhetshändelser, avgörande för DORA. Den gör rapportering till ett ansvar för hela personalstyrkan, inte enbart för säkerhetsdriften.

I Zenith Blueprint, steg 16, personrelaterade kontroller II, anger Clarysec:

Ett effektivt incidenthanteringssystem börjar inte med verktyg, utan med människor.

Steg 16 rekommenderar tydliga rapporteringskanaler, medvetenhetsutbildning, en kultur utan skuldbeläggning, triagering, konfidentialitet och regelbundna simuleringar. Det mest användbara praktiska budskapet är enkelt:

”Rapportera vid tvekan.”

Det är en DORA-kontrollprincip. Om anställda väntar tills de är säkra förlorar organisationen tid. Om de rapporterar tidigt kan organisationen bedöma, klassificera och fatta beslut.

I Zenith Controls mappas 6.8 som en detekterande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den kopplar till 5.24 eftersom rapporteringskanaler ska ingå i incidentplanen. Den matar 5.25 eftersom händelser bara kan bedömas om de rapporteras. Den utlöser 5.26 eftersom formell respons börjar efter att rapporter har utvärderats.

För DORA stödjer detta Articles 17 och 18, där finansiella entiteter ska hantera, klassificera och rapportera större IKT-relaterade incidenter och betydande cyberhot. Det stödjer även GDPR Article 33 och Recital 85, eftersom intern rapportering avgör hur snabbt en personuppgiftsincident identifieras och eskaleras.

Ett praktiskt Clarysec-genomförande är en ensidig instruktion: ”Så rapporterar du en IKT-incident”. Den bör omfatta:

• Vad som ska rapporteras, inklusive avbrott, misstänkta e-postmeddelanden, förlorade enheter, ovanligt systembeteende, misstänkt leverantörskompromettering, obehörig åtkomst, dataläckage och tjänsteförsämring med kundpåverkan.
• Hur rapportering ska ske, med hjälp av en övervakad brevlåda, ärendekategori, hotline, samarbetskanal eller SOC-portal.
• Vad som ska ingå, såsom tid, system, användare, verksamhetsprocess, observerad påverkan, skärmdumpar om det är säkert och om kunder eller personuppgifter kan vara berörda.
• Vad som inte ska göras, inklusive att inte radera loggar, inte starta om kritiska system om det inte finns instruktion om det, inte kontakta kunder externt utan godkännande och inte utreda utanför den egna rollen.
• Vad som händer därefter, inklusive triagering, klassificering, eskalering, respons, bevarande av bevismaterial och eventuell regulatorisk bedömning.

Målet är inte att göra varje anställd till utredare. Målet är att göra varje anställd till en tillförlitlig signalkälla.

Kontroll 5.25: DORA:s beslutspunkt för klassificering

Rapportering av större IKT-relaterade incidenter enligt DORA hänger på klassificering. Det är här ISO/IEC 27001:2022-kontroll 5.25 i bilaga A, bedömning av och beslut om informationssäkerhetshändelser, blir central.

Zenith Blueprint, steg 23, förklarar den praktiska utmaningen:

Inte varje avvikelse är en katastrof. Inte varje larm signalerar kompromettering.

Därefter beskrivs syftet med 5.25 som att:

skilja det harmlösa från det skadliga och veta vad som kräver eskalering.

För DORA är detta den punkt där en säkerhetshändelse, tjänsteförsämring, leverantörsavbrott, dataexponering eller operativ störning bedöms mot kriterierna för större incident. Organisationen ska beakta operativ påverkan, berörda tjänster, kritiska eller viktiga funktioner, berörda kunder och transaktioner, varaktighet, geografisk spridning, datapåverkan, anseendekonsekvenser och ekonomisk påverkan.

I Zenith Controls mappas 5.25 direkt till DORA Article 18, klassificering av större IKT-incidenter. Det är den strukturerade utvärderingsprocessen för att fastställa om en observerad händelse kvalificerar som en säkerhetsincident. Den kopplar även till 8.16, övervakningsaktiviteter, eftersom larm och loggdata ska triageras, och till 5.26, eftersom klassificering utlöser respons.

Det är här många organisationer får revisionsavvikelser. De har ärenden, men inte klassificeringsunderlag. De har allvarlighetsetiketter, men inte kriterier. De har regulatoriska rapporter, men inte beslutskedjan som visar varför en incident ansågs eller inte ansågs vara större.

Clarysec hanterar detta genom att bädda in DORA-klassificering i incidenternas allvarlighetsmodell. I företagets Policy för incidenthantering innehåller klausul 5.3.1 ett tydligt exempel på nivå 1:

Nivå 1: Kritisk (t.ex. bekräftad personuppgiftsincident, ransomwareutbrott, kompromettering av produktionssystem)

För mindre organisationer lägger Policy för incidenthantering – SME till ett skarpt operativt krav:

Verkställande chef ska, med stöd från IT-leverantören, klassificera alla incidenter efter allvarlighetsgrad inom en timme från underrättelse.

Målet om klassificering inom en timme är kraftfullt eftersom det tvingar fram styrningsdisciplin. En mindre reglerad entitet kanske inte har en SOC dygnet runt, men kan ändå definiera vem som klassificerar, vem som ger råd och hur snabbt beslutet ska fattas.

Ett DORA-till-ISO-underlag för incidenttriage

För att göra klassificeringen försvarbar bör en DORA-incidenttriagepost skapas i ärendehanterings-, GRC- eller incidenthanteringssystemet. Posten bör skapas för varje potentiellt väsentlig IKT-händelse, även om den senare nedklassificeras.

Lägg till en beslutsnotering:

”Baserat på störning i betalningstjänst som påverkar en kritisk verksamhetsprocess, oklar rotorsak och potentiell kundpåverkan eskaleras händelsen som en potentiell större IKT-relaterad incident. Regelefterlevnad och juridik ska bedöma krav på regulatorisk rapportering. Bevarande av bevismaterial har initierats.”

Denna enda post stödjer DORA Article 17-uppföljning, Article 18-klassificering, Article 19-rapporteringsbeslut, ISO/IEC 27001:2022-kontroll 5.25 i bilaga A, 6.8-rapportering, 5.26-respons och 5.28-hantering av bevismaterial.

Kontrollerna 5.24 och 5.26: planering, roller och respons

När en DORA-incident inträffar måste responsplanen redan ha svar på obekväma frågor.

Vem har befogenhet att klassificera? Vem kontaktar den behöriga myndigheten? Vem godkänner den initiala underrättelsen? Vem kommunicerar med kunder? Vem kontaktar IKT-tredjepartsleverantören? Vem beslutar om incidenten även utlöser GDPR-anmälan? Vem bevarar bevismaterial? Vem äger slutrapporten?

ISO/IEC 27001:2022-kontroll 5.24 i bilaga A, planering och förberedelse för hantering av informationssäkerhetsincidenter, besvarar dessa frågor före krisen. Kontroll 5.26, respons på informationssäkerhetsincidenter, säkerställer att planen omsätts i kontrollerad handling under incidenten.

I Zenith Controls kopplas 5.24 till DORA Articles 17 till 21 eftersom den operationaliserar dokumenterad, testad och granskad incidentrespons, inklusive intern eskalering, extern regulatorisk underrättelse, intressentkommunikation och erfarenhetsåterföring.

ISO/IEC 27035-1:2023 stödjer detta genom att utvidga incidenthantering bortom responsrutiner till policy, planering, förmågor, relationer, stödmekanismer, medvetenhet, utbildning och regelbunden testning. ISO/IEC 27035-2:2023 beskriver incidenthanteringsprocessen ytterligare, från förberedelse till erfarenhetsåterföring.

Zenith Blueprint, steg 23, ger en direkt genomförandeinstruktion:

Säkerställ att ni har en uppdaterad incidenthanteringsplan (5.24) som omfattar förberedelse, eskalering, respons och kommunikation.

En DORA-redo incidenthanteringsplan bör definiera:

• IKT-incidenthanteringsteamet och ersättare.
• Befogenhet för allvarlighetsklassificering och DORA-rapporteringseskalering.
• Ansvar för juridik, regelefterlevnad, integritet, kommunikation, IT, säkerhet, leverantör och verksamhetsägare.
• Kriterier för klassificering av större IKT-relaterade incidenter.
• Rutiner för initial, mellanliggande och slutlig regulatorisk rapportering.
• Bedömning av underrättelsetriggers enligt GDPR, NIS2, avtal, cyberförsäkring och styrelse.
• Steg för begränsning, eliminering, återställning och validering.
• Krav på bevarande av bevismaterial.
• Rutiner för leverantörseskalering och åtkomst till loggar.
• Erfarenhetsåterföring och uppföljning av korrigerande åtgärder.

Policy för incidenthantering – SME kopplar även responstidslinjer till rättsliga krav:

Responstidslinjer, inklusive dataåterställning och underrättelseskyldigheter, ska dokumenteras och anpassas till rättsliga krav, såsom GDPR:s 72-timmarskrav för anmälan av personuppgiftsincident.

Detta är avgörande eftersom en enda IKT-incident kan bli en större DORA-incident, en personuppgiftsincident enligt GDPR, en betydande incident enligt NIS2, en avtalsenlig kundunderrättelsehändelse och en leverantörshanteringsfråga. Planen måste samordna dessa överlagringar i stället för att behandla dem som separata världar.

Kontrollerna 8.15 och 8.16: loggar gör rapporten försvarbar

DORA-incidentrapportering beror på fakta. Fakta beror på loggning och övervakning.

I betalningsavvecklingsscenariot behöver Sarah veta när försämringen började, vilka system som påverkades, om privilegierade konton användes, om data lämnade miljön, om molnleverantörens avbrott stämmer överens med intern telemetri och när återställningen var slutförd.

ISO/IEC 27001:2022-kontroll 8.15 i bilaga A, loggning, och 8.16, övervakningsaktiviteter, stödjer denna underlagsbas. I Zenith Controls kopplar båda till 5.24 eftersom incidentresponsplanering måste omfatta användbara loggdata och övervakningsförmåga. Kontroll 8.16 kopplar även till 5.25 eftersom larm måste triageras till beslut.

Clarysecs Loggnings- och övervakningspolicy – SME [LMP-SME] innehåller ett praktiskt eskaleringskrav:

Högprioriterade larm ska eskaleras till verkställande chef och integritetssamordnare inom 24 timmar

För DORA-reglerade entiteter kräver potentiellt större IKT-incidenter normalt en snabbare operativ eskaleringsmodell, särskilt när kritiska eller viktiga funktioner påverkas. Styrningsmönstret är ändå korrekt: högprioriterade larm får inte stanna inom IT. De måste nå verksamhets-, integritets- och ledningsroller.

En DORA-redo loggningsmodell bör omfatta:

• Centraliserad loggning för kritiska system, identitetsplattformar, slutpunkter, molntjänster, nätverkssäkerhetsverktyg och verksamhetsapplikationer.
• Tidssynkronisering mellan system så att incidenttidslinjer är tillförlitliga.
• Larmkategorisering anpassad till incidentens allvarlighetsgrad och DORA-klassificering.
• Logglagring anpassad till regulatoriska, avtalsenliga och forensiska behov.
• Åtkomstkontroller som skyddar loggintegritet.
• Rutiner för att fånga loggögonblicksbilder under större incidenter.
• Krav på leverantörers loggåtkomst för kritiska IKT-tjänster.

Revisorer kommer inte att godta ”det finns i SIEM” som tillräckligt underlag. De kommer att fråga om rätt loggar fanns, om larm granskades, om eskalering skedde i tid och om loggar bevarades när incidenten blev potentiellt rapporteringspliktig.

Kontroll 5.28: insamling av bevismaterial och beviskedja

Vid en större IKT-relaterad incident fyller bevismaterial tre syften: teknisk utredning, regulatorisk ansvarsskyldighet och rättslig försvarbarhet.

Om bevismaterial är ofullständigt, överskrivet, ändrat eller odokumenterat kan organisationen få svårt att visa vad som hände. Den kan också få svårt att motivera sitt klassificeringsbeslut.

Clarysecs Policy för bevisinsamling och forensik [ECF] anger:

En logg över beviskedjan ska följa allt fysiskt eller digitalt bevismaterial från tidpunkten för inhämtning till arkivering eller överföring och ska dokumentera:

Versionen för små och medelstora företag, Policy för bevisinsamling och forensik – SME [ECF-SME], håller kravet enkelt:

Varje digitalt bevisobjekt ska loggas med:

Den operativa lärdomen är direkt. Hantering av bevismaterial kan inte börja först när juridik begär det. Den måste vara inbyggd i incidentresponsen.

ISO/IEC 27006-1:2024 förstärker denna revisionsförväntan genom att betona rutiner för att identifiera, samla in och bevara bevismaterial från informationssäkerhetsincidenter. För DORA kan samma uppsättning bevismaterial stödja den initiala underrättelsen, mellanliggande uppdateringar, slutrapporten, granskningen efter incident och tillsynsmyndighetens frågor.

En praktisk checklista för bevismaterial vid DORA-relaterade incidenter bör omfatta:

• Incidentärende och triageringsanteckningar.
• Tidslinje för detektering, eskalering, klassificering, rapportering, begränsning, återställning och stängning.
• SIEM-larm och korrelerade loggar.
• Artefakter från slutpunkter och servrar.
• Identitetsloggar och loggar för privilegierad åtkomst.
• Sammanställningar av nätverkstrafik.
• Molnleverantörens status och revisionsloggar.
• Leverantörskommunikation och incidentuttalanden.
• Poster över verksamhetspåverkan, inklusive kunder, tjänster, transaktioner och avbrottstid.
• Utkast till och inlämningar av regulatoriska underrättelser.
• Ledningsbeslut och godkännanden.
• Rotorsaksanalys.
• Erfarenhetsåterföring och korrigerande åtgärder.

Bevismaterialet måste visa både tekniska fakta och styrningsbeslut. DORA-rapportering handlar inte bara om vad som hände med systemen. Den handlar också om hur ledningen identifierade, bedömde, eskalerade, kontrollerade och förbättrade efter incidenten.

Kontroll 5.27: erfarenhetsåterföring och ständig förbättring

En DORA-incident är inte avslutad när slutrapporten har skickats in. Den är avslutad när organisationen har lärt av den, tilldelat korrigerande åtgärder, uppdaterat kontroller och verifierat förbättring.

ISO/IEC 27001:2022-kontroll 5.27 i bilaga A, lärande av informationssäkerhetsincidenter, kopplar DORA-rapportering till ISO/IEC 27001:2022-cykeln för ständig förbättring. I Zenith Controls länkas 5.24 till 5.27 eftersom incidenthantering är ofullständig utan rotorsaksanalys, erfarenhetsåterföring och förbättring av kontroller.

Zenith Blueprint, steg 23, instruerar organisationer att uppdatera planen med erfarenhetsåterföring och tillhandahålla riktad utbildning i incidentrespons och hantering av bevismaterial. Detta är särskilt viktigt för DORA eftersom återkommande klassificeringsförseningar, saknat leverantörsunderlag, svaga loggar eller otydlig kommunikation kan bli tillsynsfrågor.

En mall för erfarenhetsåterföring bör fånga:

• Vad som hände och när.
• Vilka kritiska eller viktiga funktioner som påverkades.
• Om klassificeringen var tidsenlig och korrekt.
• Om DORA-rapporteringsbeslut fattades med tillräckligt underlag.
• Om underrättelsetriggers enligt GDPR, NIS2, avtal eller mot kund bedömdes.
• Om leverantörer svarade inom avtalade tidsramar.
• Om loggar och forensiskt bevismaterial bevarades.
• Vilka kontroller som brast eller saknades.
• Vilka policyer, åtgärdsplaner, utbildningar eller tekniska kontroller som måste förbättras.
• Vem som äger varje korrigerande åtgärd och när den ska vara genomförd.

Detta matar även ledningens genomgång enligt ISO/IEC 27001:2022. Incidenttrender bör granskas av ledningen, inte begravas i tekniska granskningar efter incident.

Tvärgående regelefterlevnad: DORA, GDPR, NIS2, NIST och COBIT 2019

DORA är huvudfrågan för finansiella entiteter, men incidentrapportering hör sällan till endast ett ramverk.

En enda IKT-incident kan omfatta rapportering av större IKT-relaterad incident enligt DORA, anmälan av personuppgiftsincident enligt GDPR, rapportering av betydande incident enligt NIS2, skyldigheter enligt kundavtal, underrättelse till cyberförsäkringsgivare och styrelserapportering.

Zenith Controls hjälper till att minska denna komplexitet genom att mappa ISO/IEC 27002:2022-kontroller över ramverk. Till exempel:

Ur ett NIST-perspektiv stödjer samma modell Detect-, Respond- och Recover-resultat. Ur ett COBIT 2019- och ISACA-revisionsperspektiv är frågan styrning: om incidenthantering, kontinuitet, risk, regelefterlevnad, leverantörsansvar och prestationsövervakning är kontrollerade.

De mest mogna organisationerna skapar inte separata arbetsflöden för varje ramverk. De skapar en incidenthanteringsprocess med regulatoriska överlagringar. Ärendet fångar samma kärnfakta en gång och förgrenas därefter till DORA, GDPR, NIS2, avtalsenlig, försäkringsrelaterad eller sektorsspecifik rapportering när det krävs.

Hur revisorer testar er DORA-incidentprocess

En DORA-redo incidentrapporteringsprocess måste hålla för olika revisionsperspektiv.

En ISO/IEC 27001:2022-revisor kommer att undersöka om ISMS har valt och infört relevanta kontroller i bilaga A, om tillämpbarhetsförklaringen stödjer dessa kontroller, om incidentposter finns och om internrevision och ledningens genomgång omfattar incidentprestanda.

Zenith Controls hänvisar till ISO/IEC 19011:2018-revisionsmetodik för 5.24, 5.25 och 6.8. För 5.24 granskar revisorer incidenthanteringsplanen avseende incidenttyper, allvarlighetsklassificeringar, tilldelade roller, kontaktlistor, eskaleringsvägar, instruktioner för regulatorisk rapportering och kommunikationsansvar. För 5.25 granskar de om dokumenterade klassificeringskriterier finns, såsom allvarlighetsmatriser eller beslutsträd baserade på systempåverkan, datakänslighet och varaktighet. För 6.8 bedömer de rapporteringsmekanismer, mätetal för rapporteringstid och underlag för att rapporterade händelser loggas, triageras och löses.

En DORA-tillsynsgranskning fokuserar på om större IKT-relaterade incidenter detekteras, klassificeras, rapporteras, uppdateras och stängs enligt regulatoriska förväntningar. Granskaren kan begära ett exempel på en incident och spåra den från första larm till slutrapport.

En integritetsrevisor fokuserar på om risken för personuppgiftsincident bedömdes och om skyldigheterna enligt GDPR Article 33 och Article 34 utlöstes. BS EN 17926:2023 är relevant här eftersom den tillför ansvar för integritetsincidenter, underrättelsekriterier, tidsfrister och anpassning till förväntningar på rapportering till tillsynsmyndighet.

Samma bevismaterial kan besvara flera revisionsfrågor om det struktureras korrekt från början.

Checklista för beredskap inför DORA-incidentrapportering 2026

Inför nästa skrivbordsövning, internrevision eller tillsynsgranskning bör ni testa organisationen mot denna checklista:

• Vet anställda hur misstänkta IKT-incidenter ska rapporteras?
• Finns det en dedikerad kanal för incidentrapportering?
• Loggas och triageras säkerhetshändelser konsekvent?
• Finns en dokumenterad matris för allvarlighetsgrad och DORA-klassificering av större incidenter?
• Krävs klassificering inom en definierad tid efter underrättelse?
• Är kritiska eller viktiga funktioner mappade till system och leverantörer?
• Bedöms triggers för DORA, GDPR, NIS2, avtal, försäkring och kundunderrättelse i ett och samma arbetsflöde?
• Är incidentroller definierade över IT, säkerhet, juridik, regelefterlevnad, integritet, kommunikation och verksamhetsägare?
• Är loggar tillräckliga för att rekonstruera incidenttidslinjer?
• Bevaras bevismaterial med beviskedja?
• Testas leverantörers incidentskyldigheter och rättigheter till loggåtkomst?
• Genomförs skrivbordsövningar med realistiska DORA-scenarier?
• Spåras erfarenhetsåterföring till korrigerande åtgärder?
• Granskas incidentmätetal i ledningens genomgång?
• Är tillämpbarhetsförklaringen mappad till DORA-relevanta ISO/IEC 27001:2022-kontroller?

Om svaret på någon av dessa frågor är ”delvis” är problemet inte bara efterlevnad. Det är operativ resiliens.

Bygg en DORA-incidentrapporteringsmodell redo som revisionsunderlag

DORA-incidentrapportering 2026 är ett test av styrning under press. De organisationer som lyckas bäst är inte de som har de längsta incidentresponsdokumenten. Det är de som har tydliga rapporteringskanaler, snabb klassificering, tillförlitliga loggar, bevarat bevismaterial, utbildad personal, testad leverantörseskalering och spårbarhet över ramverk.

Clarysec kan hjälpa er att bygga den operativa modellen.

Börja med att mappa era incidentrisker och er tillämpbarhetsförklaring med Zenith Blueprint: revisorns 30-stegs färdplan. Anpassa därefter era incidentkontroller med Zenith Controls: guide för samordnad regelefterlevnad. Operationalisera processen med Clarysecs Policy för incidenthantering, Policy för incidenthantering – SME, Loggnings- och övervakningspolicy – SME, Policy för bevisinsamling och forensik och Policy för bevisinsamling och forensik – SME.

Om ledningsgruppen vill ha trygghet före nästa verkliga incident, genomför en skrivbordsövning för en större IKT-relaterad incident enligt DORA med Clarysecs verktyg och ta fram det bevispaket som en revisor eller tillsynsmyndighet förväntar sig att se.