Allvarlighetsklassificering av incidenter för DORA, NIS2 och GDPR

Incidentsamtalet 02:17 som blir ett regulatoriskt beslut

Klockan 02:17 en torsdagsmorgon ser Sarah, FinScales informationssäkerhetschef, det första larmet: avvikande API-trafik, kraftiga ökningar av misslyckade autentiseringar och latens i betalningspanelen över 3000 ms. Inom några minuter rapporterar kundsupport fel i betalningsstatus. Molnleverantören uppger att det inte finns någon plattformsövergripande incident. SOC ser misstänkta åtkomsttoken från två geografiska regioner. Produktteamet bekräftar att panelen är online igen efter 19 minuter, men tolv kunder har redan öppnat ärenden.

Klockan 03:05 deltar Sarah i krismötet tillsammans med incidentledaren, juridisk rådgivare, integritetssamordnaren, ansvarig för molndrift och en representant för högsta ledningen. Den tekniska frågan är tillräckligt tydlig: vad hände med API-gatewayen? De regulatoriska frågorna är svårare:

1. Är detta en allvarlig IKT-relaterad incident enligt DORA?
2. Är det en betydande incident enligt NIS2?
3. Finns det en personuppgiftsincident enligt GDPR som kräver anmälan?
4. Kan organisationen visa hur den kom fram till svaren?

Fel svar kan skapa regulatorisk exponering. Ett långsamt svar kan leda till att ett rapporteringsfönster missas. Ett odokumenterat svar kan underkännas vid en ISO/IEC 27001:2022-revision flera månader senare.

Detta är incidenthanteringsutmaningen 2026. Många organisationer har en incidenthanteringsplan, forensiska rutiner, dataskyddsrelaterade åtgärdsplaner och mallar för kriskommunikation. Färre har en försvarbar modell för allvarlighetsklassificering av incidenter som omvandlar en brusig säkerhetshändelse till ett dokumenterat beslut enligt DORA, NIS2, GDPR och förväntningarna på underlag i ISO/IEC 27001:2022.

Lösningen är inte tre separata triageprocesser. Den är en styrd modell för allvarlighetsgrad med separata regulatoriska prövningslager, mätbara tröskelvärden, eskaleringsregler, beslutsloggar och krav på bevisinsamling. I praktiken ska incidentens allvarlighetsgrad inte vara en etikett som väljs under press. Den ska vara ett kontrollerat verksamhetsbeslut som tål granskning från tillsynsmyndigheter, revisorer, styrelseledamöter, kunder och dataskyddsombudet (DPO).

Varför allvarlighetsklassificering av incidenter nu är en kontroll på styrelsenivå

Incidentklassificering var tidigare främst teknisk: allvarlighetsgrad för skadlig kod, berörda värdar, utnyttjade sårbarheter och om data hade exfiltrerats. År 2026 är den även rättslig, finansiell, samhällelig och avtalsmässig.

DORA gör digital operativ resiliens till en styrningsskyldighet för finansiella entiteter. Ledningsorganet förväntas definiera, godkänna, övervaka och fortsatt ansvara för ramverket för IKT-riskhantering. Det omfattar IKT-relaterad verksamhetskontinuitet, respons- och återställningsplaner, rapporteringskanaler för allvarliga incidenter, IKT-tredjepartsrisk och erfarenhetsåterföring.

NIS2 höjer styrningskraven för väsentliga och viktiga entiteter. Article 20 kräver att ledningsorgan godkänner riskhanteringsåtgärder för cybersäkerhet, övervakar genomförandet och genomgår utbildning. Den kopplar även brister i riskhantering och incidentrapportering till allvarliga tillsynskonsekvenser. För väsentliga entiteter kan basnivån för maximala administrativa sanktionsavgifter uppgå till minst 10 000 000 euro eller 2 procent av den totala globala årsomsättningen, beroende på vilket belopp som är högst. För viktiga entiteter är basnivån minst 7 000 000 euro eller 1,4 procent av omsättningen, beroende på vilket belopp som är högst.

GDPR tillför ett annat perspektiv. En personuppgiftsincident är inte begränsad till bekräftat offentligt röjande eller stulna filer. Den omfattar oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till personuppgifter. Personuppgiftsansvariga måste bedöma risken för enskilda och visa ansvarsskyldighet för beslutet att anmäla eller inte anmäla.

ISO/IEC 27001:2022 ger dessa skyldigheter en struktur för underlag. Klausulerna 4.1 till 4.4 kräver att organisationen förstår sitt sammanhang, intressentkrav, omfattning, gränssnitt och beroenden. Klausulerna 5.1 till 5.3 kräver ledningens åtagande, policy, roller, ansvar och rapportering. Klausulerna 6.1.1 till 6.1.3 kräver riskbaserad planering, riskbedömning, riskbehandling och en Statement of Applicability. Klausulerna 8.1 till 8.3 kräver operativ styrning, ändringsstyrning, bevarat underlag och omprövning när riskförutsättningar förändras. ISO/IEC 27001:2022

När incidentsamtalet äger rum ska frågan inte vara: ”Vem tycker att detta är kritiskt?” Den ska vara: ”Vad kräver våra godkända kriterier, rättsliga utlösare, underlag och eskaleringsregler att vi gör nu?”

En händelse, tre regulatoriska klassificeringssystem

DORA, NIS2 och GDPR använder inte samma språk för incidenter. Det är huvudorsaken till att organisationer får problem under den första timmen.

DORA Article 17 kräver att finansiella entiteter etablerar en process för hantering av IKT-relaterade incidenter som upptäcker, hanterar och anmäler IKT-incidenter, registrerar IKT-relaterade incidenter och betydande cyberhot, åtgärdar rotorsaker, använder indikatorer för tidig varning, kategoriserar och klassificerar incidenter, tilldelar roller, hanterar kommunikation, eskalerar allvarliga incidenter till högsta ledningen och återställer säker drift.

DORA Article 18 kräver klassificering utifrån kriterier som berörda kunder, berörda motparter, transaktioner, varaktighet, avbrottstid, geografisk spridning, dataförlust som påverkar tillgänglighet, autenticitet, riktighet eller konfidentialitet, de berörda tjänsternas kritikalitet och ekonomisk påverkan. DORA Article 19 kräver rapportering av allvarliga IKT-relaterade incidenter och kundkommunikation när finansiella intressen påverkas.

NIS2 Article 23 definierar en betydande incident som en incident som har orsakat eller kan orsaka en allvarlig driftstörning eller ekonomisk förlust, eller som har påverkat eller kan påverka andra genom att orsaka betydande materiell eller immateriell skada. Den kräver en tidig varning inom 24 timmar från det att organisationen fått kännedom om den betydande incidenten, en incidentanmälan inom 72 timmar, mellanrapporter på begäran och en slutrapport inom en månad från incidentanmälan. I förekommande fall ska berörda tjänstemottagare även informeras om åtgärder eller avhjälpande åtgärder de kan vidta.

GDPR ställer en dataskyddsriskfråga. Har en säkerhetsöverträdelse orsakat förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till personuppgifter? Om ja måste den personuppgiftsansvarige bedöma risken för fysiska personers rättigheter och friheter. Om incidenten sannolikt leder till en risk ska tillsynsmyndigheten normalt anmälas inom 72 timmar från kännedom. Om den sannolikt leder till en hög risk kan berörda personer behöva informeras utan onödigt dröjsmål.

En enskild incident behöver därför klassificeras samtidigt utifrån flera perspektiv.

För finansiella entiteter är DORA den sektorsspecifika unionsrättsakten för skyldigheter inom IKT-riskhantering och incidentrapportering som överlappar NIS2. Det gör inte NIS2 irrelevant. NIS2 kan fortfarande vara relevant för samarbete, informationsflöden, tjänster utanför DORA-perimetern, icke-finansiella koncernbolag, molntjänster, hanterade tjänster och kunders avtalsförpliktelser. Modellen för allvarlighetsgrad ska inte bara registrera utfallet, utan även tillämplighetslogiken.

Clarysecs modell: klassificera händelsen, inte känslan

Clarysec utgår från ISO/IEC 27002:2022 kontroll 5.25, bedömning och beslut avseende informationssäkerhetshändelser, som ankare för regelefterlevnad över flera regelverk. I Zenith Controls: The Cross-Compliance Guide Zenith Controls mappas detta område genom posten ”Bedömning och beslut avseende informationssäkerhetshändelser” för kontroll 5.25, med stöd av ”Planering och förberedelse för hantering av informationssäkerhetsincidenter” för kontroll 5.24 och ”Bevisinsamling” för kontroll 5.28.

Det viktigaste efterlevnadsögonblicket är ofta inte begränsning. Det är vägskälet där en säkerhetshändelse blir en regulatorisk incident, eller där den på ett försvarbart sätt registreras som en händelse med lägre allvarlighetsgrad.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint beskriver detta ögonblick i fasen Controls in Action, Step 23:

”Inte varje avvikelse är en katastrof. Inte varje larm signalerar kompromettering. I verkligheten översköljs säkerhetsteam och verksamhetsenheter av brus, inloggningsförsök, loggavvikelser, mindre policyöverträdelser och skugg-IT-aktivitet. Den verkliga utmaningen ligger inte bara i detektering, utan i att skilja det harmlösa från det skadliga och veta vad som kräver eskalering.”

Den meningen fångar det operativa problemet. Ett SIEM-larm innebär inte automatiskt en allvarlig incident enligt DORA. Ett tillfälligt avbrott innebär inte automatiskt en betydande incident enligt NIS2. En misstänkt databasfråga innebär inte automatiskt en anmälningspliktig GDPR-incident. Var och en kan bli rapporteringspliktig beroende på konsekvens, omfattning, data, berörda parter och underlag.

Zenith Blueprint, fasen Risk Management, Step 10, rekommenderar även att konsekvensdefinitioner anpassas till verksamhetens skala och regulatoriska exponering:

”När konsekvens definieras är det klokt att koppla nivåerna till den egna verksamhetens skala. Till exempel: ’Stor finansiell påverkan = förlust > 100 000 USD’ (anpassa till ert sammanhang). Beakta även regulatorisk påverkan: en personuppgiftsincident kan exempelvis automatiskt vara ’hög’ eller ’kritisk’ på grund av GDPR-sanktionsavgifter och anmälningskrav, även om den direkta ekonomiska förlusten är oklar.”

Det är designprincipen för allvarlighetsklassificering av incidenter 2026: allvarlighetsgrad är verksamhetskonsekvens plus rättslig påverkan plus tillförlitlighet i underlaget.

En praktisk taxonomi för incidenters allvarlighetsgrad enligt DORA, NIS2 och GDPR

En försvarbar taxonomi ska skilja intern allvarlighetsgrad från regulatorisk klassificering. Intern allvarlighetsgrad styr skyndsamhet i respons, resurstilldelning och eskalering till ledningen. Regulatorisk klassificering styr anmälan, juridisk granskning och extern kommunikation.

Den interna allvarlighetsnivån är inte det slutliga regulatoriska svaret. Den är driftsläget. En SEV 3-händelse kan bli anmälningspliktig enligt GDPR efter logggranskning. Ett SEV 2-avbrott behöver inte vara en allvarlig incident enligt DORA om konsekvenströsklarna inte är uppfyllda. En SEV 1-ransomwareincident kan utlösa DORA, NIS2, GDPR, kundavtal och samordning med brottsbekämpande myndigheter samtidigt.

En mer detaljerad klassificeringsmatris hjälper teamet att gå från larm till åtgärd.

Modellen ska vara inbyggd i policy och inte lämnas till den starkaste rösten i krismötet. SME Incident Response Policy-sme Incident Response Policy-sme - SME, Governance Requirements, punkt 5.3.1, anger:

”Den verkställande chefen ska, med input från IT-leverantören, klassificera alla incidenter efter allvarlighetsgrad inom en timme från underrättelse.”

Samma SME-policy, Risk Treatment and Exceptions, punkt 7.4.1, tillägger:

”När kunddata berörs ska den verkställande chefen bedöma rättsliga anmälningsskyldigheter baserat på tillämpligheten av GDPR, NIS2 eller DORA.”

För större organisationer formaliserar företagsversionen Incident Response Policy Incident Response Policy, Governance Requirements, punkt 5.3, samma princip:

”Incidentklassificering ska följa en nivåindelad modell:”

Policyspråket är viktigt eftersom tillsynsmyndigheter och revisorer kommer att fråga om klassificeringskriterier fanns före incidenten. En matris som skapas i efterhand är svagt underlag. En matris som är godkänd, utbildad, övad och konsekvent använd är försvarbar.

Beslutsloggen: det viktigaste revisionsunderlaget

När revisorer, tillsynsmyndigheter eller styrelseledamöter granskar en incident frågar de sällan bara: ”Vad hände?” De frågar: ”När visste ni, vem beslutade, på vilket underlag, och varför anmälde ni inte tidigare?”

Därför rekommenderar Clarysec en beslutslogg för allvarlighetsgrad för varje SEV 3-händelse och högre, samt för varje händelse som berör personuppgifter, kritiska tjänster, finansiella kunder, hanterade tjänster, molninfrastruktur eller gränsöverskridande påverkan.

Detta mappar direkt mot ISO/IEC 27001:2022. Klausul 8.1 kräver att processer planeras, genomförs och styrs, med tillräcklig dokumenterad information bevarad för att visa att de fungerade som planerat. Klausulerna 8.2 och 8.3 kräver omprövning när betydande förändringar inträffar och bevarande av underlag för riskbehandling. Annex A-kontrollerna A.5.24 till A.5.28 utgör ryggraden för incidenthantering: planering och förberedelse, bedömning och beslut avseende händelser, respons, lärande från incidenter och bevisinsamling.

SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Enforcement and Compliance, punkt 8.3.2, stödjer GDPR-sidan av modellen:

”Integritetssamordnaren ska fastställa allvarlighetsgraden, initiera begränsningsåtgärder och dokumentera ärendet”

Dataskyddsbedömningen ska inte börja först när den regulatoriska tidsfristen blir obekväm. Den hör hemma i triagearbetsflödet.

Praktiskt exempel: klassificering av Sarahs API-incident

Återvänd till FinScale. Det är en B2B-fintechplattform som använder molninfrastruktur, en extern leverantör av bedrägerianalys och en hanterad säkerhetsleverantör. Den är en DORA-omfattad finansiell entitet för vissa aktiviteter. Den är också en digital tjänsteleverantör med NIS2-relevant verksamhet i en medlemsstat. Den behandlar kunders personuppgifter som personuppgiftsansvarig för kontotjänster och som personuppgiftsbiträde för vissa företagskunder.

Klockan 02:17 detekteras avvikande API-trafik. Klockan 02:35 öppnas incidentärendet. Klockan 03:00 slutför Sarah initial triage med incidentledaren.

Först fastställs den interna allvarlighetsgraden. Incidenten påverkade tillgängligheten i kundpanelen i 19 minuter, involverade misstänkta åtkomsttoken och berörde en kritisk kundvänd funktion. Den klassificeras som SEV 3 Medel i avvaktan på bekräftelse, med eskalering till incidentledaren, integritetssamordnaren, juridisk rådgivare och tjänsteägaren.

Därefter slutförs DORA-prövningen. Teamet kontrollerar berörda kunder, motparter, transaktioner, varaktighet, avbrottstid, geografisk spridning, dataförlust, kritikalitet och ekonomisk påverkan. Inga misslyckade eller ändrade transaktioner bekräftas. Avbrottstiden är begränsad. Ingen dataförlust är bevisad. Eftersom en kritisk komponent i en finansiell tjänst och kunders finansiella intressen kan påverkas kvarstår incidenten dock under DORA-övervakning och kan omklassificeras.

För det tredje registreras NIS2-prövningen. Teamet noterar att DORA är den primära sektorsspecifika rapporteringsregimen för de skyldigheter som gäller den omfattade finansiella entiteten. Teamet kontrollerar också om incidenten påverkar tjänster eller kunder utanför DORA-perimetern. Ingen allvarlig driftstörning eller betydande skada bekräftas i detta skede.

För det fjärde inleds GDPR-prövningen. De misstänkta tokenen kan ha möjliggjort åtkomst till data i kundpanelen. Integritetssamordnaren dokumenterar datakategorier, berörda användare, tokenomfattning, granskade loggar, om data visades eller exporterades samt skyddsåtgärder såsom utgångstid för token och åtkomstkontroller.

Klockan 04:20 visar logganalys att två token användes för att få åtkomst till panelmetadata för 41 kunder, inklusive namn, konto-ID och transaktionsstatus, men inga betalningsuppgifter eller identitetshandlingar. Teamet uppdaterar incidenten till SEV 2 Allvarlig eftersom personuppgifters konfidentialitet påverkades och kundkommunikation kan krävas. DPO bedömer GDPR-risken för enskilda. DORA-beslutet granskas på nytt utifrån kundpåverkan, transaktionspåverkan och ekonomisk påverkan.

Detta är modellens praktiska värde. Initial klassificering är inte en slutlig rättslig slutsats. Den är ett evidensbaserat beslut som kan uppdateras när fakta utvecklas.

Loggning, övervakning och forensiskt bevismaterial: bevislagret

En modell för allvarlighetsgrad utan underlag är en mötesuppfattning. Förväntningen 2026 är att klassificeringen stöds av loggar, övervakning, bevarade artefakter och beviskedja.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Enforcement and Compliance, punkt 8.3.4, anger:

”Utredningar av incidenter ska stödjas av tillräckliga loggar för att uppfylla ansvarsskyldighetsprincipen enligt GDPR och DORA”

Forensisk hantering är lika viktig. SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Governance Requirements, punkt 5.3.1, kräver:

”En enkel logg över beviskedjan (t.ex. Excel-fil eller malldokument) ska upprätthållas för varje incident.”

För företagsmiljöer kräver Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Governance Requirements, punkt 5.5:

”All insamlad bevisning ska identifieras unikt, märkas och lagras i ett säkert dokumentarkiv med:”

Zenith Blueprint, fasen Controls in Action, Step 23, förklarar varför detta är viktigt för ISO/IEC 27002:2022 kontroll 5.28:

”När en informationssäkerhetsincident inträffar är ett av de mest kritiska, men ofta förbisedda, elementen i responsen bevisning. Inte loggar, inte skärmdumpar, inte lösa narrativ, utan korrekt bevarad, beviskedjerespekterande och manipulationsskyddad bevisning.”

Ett praktiskt underlagspaket för en allvarlig eller potentiellt rapporteringspliktig incident bör omfatta:

• Incidentärende och tidslinje
• Beslutslogg för allvarlighetsgrad och historik över omklassificering
• SIEM-larm, EDR-larm, molnloggar och identitetsloggar
• Loggar över dataåtkomst och exportloggar
• Berörda poster i tillgångs- och tjänsteförteckningar
• Konsekvensbedömning för kunder, transaktioner och geografi
• Arbetsblad för DORA-, NIS2- och GDPR-prövning
• DPO:s eller juridisk bedömning
• Kommunikationsgodkännanden och skickade meddelanden
• Beviskedjepost
• Rotorsaksanalys
• Korrigerande åtgärder och erfarenhetsåterföring

Detta underlagspaket stödjer även ISO/IEC 27001:2022 Annex A-kontrollerna A.8.15 loggning, A.8.16 övervakningsaktiviteter, A.5.28 bevisinsamling, A.5.27 lärande från informationssäkerhetsincidenter, A.5.31 rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav samt A.5.34 integritetsskydd och skydd av personligt identifierbar information.

Mappning över flera regelverk: bygg en gång, svara många revisorer

De starkaste modellerna för incidenters allvarlighetsgrad byggs en gång och mappas många gånger. Zenith Controls är utformad som en kompass för regelefterlevnad över flera regelverk i detta arbete. För detta ämne är de centrala ISO/IEC 27002:2022-posterna 5.24 planering och förberedelse för hantering av informationssäkerhetsincidenter, 5.25 bedömning och beslut avseende informationssäkerhetshändelser, 5.26 respons på informationssäkerhetsincidenter, 5.27 lärande från informationssäkerhetsincidenter och 5.28 bevisinsamling.

Dessa kontroller knyter naturligt an till ledningssystemet i ISO/IEC 27001:2022. Klausulerna 4, 5, 6 och 8 definierar omfattning, ledarskap, riskkriterier, behandling och operativt underlag. ISO/IEC 27002:2022 ger språket för genomförande av kontroller. Verksamhetskontinuitetstänkande i ISO 22301-stil stödjer störningströsklar, återställningsprioriteringar och krishantering. Incidenthanteringspraxis i ISO/IEC 27035-stil stödjer strukturerad detektering, rapportering, bedömning, respons och lärande. Integritetsstyrning i ISO/IEC 27701-stil stödjer roller vid personuppgiftsincidenter, överväganden om personuppgiftsansvarig och personuppgiftsbiträde, integritetsrelaterat underlag och ansvarsskyldighet.

Samma modell mappar mot NIST Cybersecurity Framework 2.0. Funktionen GOVERN kräver att rättsliga, regulatoriska, avtalsmässiga, integritetsrelaterade och civila fri- och rättighetsrelaterade skyldigheter förstås och hanteras. Den förväntar också att riskaptit, roller, befogenheter, policyer och tillsyn definieras. Funktionerna DETECT, RESPOND och RECOVER stödjer triage, analys, eskalering, begränsning, återställning, kommunikation och förbättring.

Nyttan är praktisk. När en DORA-tillsynsmyndighet efterfrågar motiveringen för en allvarlig IKT-relaterad incident, en NIS2-myndighet frågar om beslutet kring tidig varning inom 24 timmar, en dataskyddsmyndighet frågar varför en GDPR-anmälan gjordes eller inte gjordes, och en ISO-revisor frågar om ISMS fungerade som planerat, kan organisationen svara utifrån samma underlagsuppsättning.

Hur revisorer och tillsynsmyndigheter kommer att testa modellen

En ISO/IEC 27001:2022-revisor börjar normalt med omfattning och rättsliga krav. Revisorn frågar om DORA, NIS2, GDPR, kundavtal och IKT-tredjepartsförpliktelser har identifierats som intressentkrav. Därefter följer revisorn spåret till riskkriterier, Statement of Applicability, incidentrutiner, operativa underlag och bevarande av underlag. Revisorn vill se bevis för att klassificeringsprocessen inte uppfanns under incidenten.

En DORA-tillsynsmyndighet eller internrevision kommer att söka efter en livscykelloop: incidenthanteringsprocess, indikatorer för tidig varning, klassificeringskriterier, eskalering av allvarliga incidenter, kundkommunikation, rotorsak, slutliga konsekvenssiffror, resiliensprovning och ledningsorganets tillsyn. De kommer också att fråga om IKT-tredjepartsberoenden har beaktats, särskilt när moln, SaaS, hanterad säkerhet eller outsourcing-leverantörer varit inblandade.

En NIS2-inriktad revisor eller myndighet kommer att testa om entiteten kan identifiera betydande incidenter, uppfylla stegvisa tidslinjer, kommunicera med berörda tjänstemottagare och tillhandahålla underlag för bedömning av gränsöverskridande påverkan. De kommer att koppla incidenthantering till Article 21-riskhanteringsåtgärder, inklusive verksamhetskontinuitet, krishantering, leveranskedjesäkerhet, åtkomstkontroll, tillgångshantering och utbildning.

Ett GDPR-DPO eller en tillsynsmyndighet kommer att granska om organisationen identifierade personuppgifter, roller, registrerade, kategorier, berörda system, incidenttyp och risk för enskilda. De kommer att testa om den personuppgiftsansvarige kan visa ansvarsskyldighet och om personuppgiftsbiträdens underrättelser till personuppgiftsansvariga var snabba och fullständiga.

En ISACA- eller COBIT 2019-inriktad revisor kommer att fokusera på styrningsunderlag. Vem godkände taxonomin för allvarlighetsgrad? Vem äger risken? Vilka mätetal rapporteras till ledningen? Hur hanteras undantag? Hur omvandlas erfarenhetsåterföring till kontrollförbättringar?

Vanliga felmönster vid incidentklassificering

Det första felet är ett enetikettstänkande. Team klassificerar en händelse som hög, medel eller låg, men bedömer aldrig separat utlösare enligt DORA, NIS2 och GDPR. Resultatet blir en allvarlighetsnivå som inte kan förklara ett rapporteringsbeslut.

Det andra felet är bias mot bekräftad incident. Team väntar på absolut bevis för exfiltration innan dataskydd eller juridik involveras. GDPR-bedömning av personuppgiftsincidenter börjar ofta med möjlig obehörig åtkomst, förlust, ändring eller röjande, inte bara bekräftad publicering av data.

Det tredje felet är tidsförvirring. Tidslinjer enligt NIS2 och GDPR beror på kännedom och bedömning. Om incidentärendet inte fångar tidpunkt för kännedom, klassificeringstidpunkt och eskaleringstidpunkt kan organisationen få svårt att visa att den agerat i tid.

Det fjärde felet är forensik efter städning. Ingenjörer roterar nycklar, bygger om värdar och raderar tillfälligt underlag innan utredningsläge har aktiverats. Detta kan förstöra bevis som behövs för regulatorisk, avtalsmässig eller juridisk granskning.

Det femte felet är leverantörsblindhet. DORA, NIS2 och NIST CSF 2.0 betonar alla tredjeparts- och leveranskedjerisk. Om en molnleverantör, hanterad tjänsteleverantör, betalningsförmedlare, identitetsleverantör eller SaaS-leverantör ingår i incidentkedjan måste klassificeringsmodellen omfatta leverantörspåverkan och avtalsmässiga underrättelseskyldigheter.

Clarysecs checklista för genomförande 2026

För att operationalisera en försvarbar modell för allvarlighetsklassificering av incidenter rekommenderar Clarysec följande ordning:

1. Bekräfta regulatorisk tillämplighet för DORA, NIS2, GDPR, kundavtal och sektorsregler.
2. Uppdatera ISMS-omfattning och intressentkrav enligt ISO/IEC 27001:2022.
3. Definiera interna allvarlighetsnivåer med mätbara tröskelvärden för avbrottstid, data, kunder, geografi, ekonomisk förlust och kritikalitet.
4. Lägg till separata prövningsfrågor för DORA, NIS2 och GDPR i arbetsflödet för incidentärenden.
5. Definiera eskaleringsutlösare för incidentledare, DPO, juridik, högsta ledningen och styrelsen.
6. Skapa en mall för beslutslogg avseende allvarlighetsgrad.
7. Koppla klassificering till bevisinsamling och rutiner för beviskedja.
8. Validera loggtäckning för identitets-, moln-, applikations-, databas-, nätverks- och leverantörshändelser.
9. Genomför skrivbordsövningar för scenarier med allvarlig incident enligt DORA, betydande incident enligt NIS2 och personuppgiftsincident enligt GDPR.
10. För in erfarenhetsåterföring i riskbehandling, Statement of Applicability, utbildning och resiliensprovning.

Zenith Blueprint, fasen Controls in Action, Step 16, förstärker den mänskliga sidan av modellen: rapporter ska loggas, triageras, eskaleras genom incidenthanteringsplanen, och även mindre händelser ska följas upp eftersom trender avslöjar kontrollsvagheter. Den främjar ett rapporteringstänkande med låg tröskel: ”Rapportera vid osäkerhet.”

Den kulturella punkten är avgörande. En modell för allvarlighetsgrad fallerar om anställda dröjer med rapportering av rädsla för överreaktion. Målet är snabb rapportering, disciplinerad triage och försvarbar klassificering.

Omvandla incidentosäkerhet till underlag som håller vid revision

År 2026 är allvarlighetsklassificering av incidenter inte längre ett beslut endast för SOC. Det är en reglerad styrningsprocess som måste koppla samman DORA:s kriterier för allvarliga IKT-relaterade incidenter, NIS2:s trösklar för betydande incidenter, GDPR-risk vid personuppgiftsincidenter och ISO/IEC 27001:2022-underlag.

De organisationer som presterar bäst under incidenter är inte de som har den tjockaste incidentpärmen. Det är de som snabbt kan svara på fyra frågor och bevisa varje svar i efterhand:

• Vad hände?
• Hur allvarligt är det?
• Vilka regulatoriska skyldigheter kan vara tillämpliga?
• Vilket underlag stödjer beslutet?

Clarysec hjälper organisationer att bygga den bryggan genom policymallar, taxonomier för allvarlighetsgrad, beslutsloggar, skrivbordsövningar och mappningar över flera regelverk. Börja med incidentpolicyerna, validera era riskkriterier i Zenith Blueprint Zenith Blueprint, och använd Zenith Controls Zenith Controls för att mappa ISO/IEC 27002:2022-kontrollerna 5.24, 5.25, 5.26, 5.27 och 5.28 mot DORA, NIS2, GDPR, NIST CSF och revisionsförväntningar.

Om ert team inte kan svara på ”Är detta allvarligt enligt DORA, betydande enligt NIS2 eller anmälningspliktigt enligt GDPR?” inom den första timmen är nästa steg inte ännu en generisk incidenthanteringsplan. Nästa steg är en försvarbar operativ modell för allvarlighetsklassificering av incidenter, testad innan nästa 02:17-samtal kommer.

Redo att ersätta panik med process? Ladda ner Clarysecs policymallar för incidenthantering och bevisinsamling, granska er nuvarande taxonomi för allvarlighetsgrad mot Zenith Blueprint, eller begär en Clarysec-beredskapsbedömning för att bygga en revisionsklar incidentklassificeringsmodell för DORA, NIS2, GDPR och ISO/IEC 27001.