Ernstclassificatie van incidenten voor DORA, NIS2 en GDPR

De incidentoproep van 02:17 die een regelgevingsbesluit wordt

Om 02:17 op donderdagochtend ziet Sarah, de CISO van FinScale, de eerste waarschuwing: afwijkend API-verkeer, pieken in mislukte authenticatie en latentie op het betalingsdashboard boven 3000 ms. Binnen enkele minuten meldt de klantenservice fouten in de betalingsstatus. De cloudprovider geeft aan dat er geen platformbrede storing is. Het SOC ziet verdachte toegangstokens uit twee geografische regio’s. Product bevestigt dat het dashboard na 19 minuten weer online is, maar twaalf klanten hebben al supporttickets aangemaakt.

Om 03:05 zit Sarah in het crisisoverleg met de incidentleider, de juridisch adviseur, de privacycoördinator, de verantwoordelijke voor cloudoperaties en de directiesponsor. De technische vraag is duidelijk genoeg: wat is er gebeurd met de API-gateway? De regelgevingsvragen zijn lastiger:

1. Is dit een groot ICT-gerelateerd incident onder DORA?
2. Is dit een significant incident onder NIS2?
3. Is er sprake van een GDPR-datalek met persoonsgegevens waarvoor melding vereist is?
4. Kan de organisatie aantonen hoe zij tot die antwoorden is gekomen?

Het verkeerde antwoord kan leiden tot blootstelling aan toezichthouders. Een traag antwoord kan ertoe leiden dat een meldtermijn wordt gemist. Een ongedocumenteerd antwoord kan maanden later tekortschieten tijdens een ISO/IEC 27001:2022-audit.

Dit is de uitdaging voor incidentrespons in 2026. Veel organisaties hebben een incidentresponsplan (IRP), forensische procedures, privacydraaiboeken en sjablonen voor crisiscommunicatie. Minder organisaties beschikken over een verdedigbaar model voor incidenternst dat een rumoerige beveiligingsgebeurtenis omzet in een gedocumenteerd besluit over DORA, NIS2, GDPR en de bewijsmateriaalverwachtingen van ISO/IEC 27001:2022.

De oplossing bestaat niet uit drie afzonderlijke triageprocessen. Zij bestaat uit één beheerst ernstmodel met afzonderlijke regelgevingslagen, meetbare drempels, escalatieregels, besluitlogboeken en eisen voor bewijsverzameling. Praktisch betekent dit dat incidenternst geen label mag zijn dat onder druk wordt gekozen. Het moet een gecontroleerd bedrijfsbesluit zijn dat toetsing door toezichthouders, auditors, bestuurders, klanten en de functionaris voor gegevensbescherming kan doorstaan.

Waarom ernstclassificatie van incidenten nu een beheersmaatregel op bestuursniveau is

Incidentclassificatie was vroeger vooral technisch: ernst van malware, getroffen hosts, uitgebuite kwetsbaarheden en de vraag of gegevens waren geëxfiltreerd. In 2026 is zij ook juridisch, financieel, maatschappelijk en contractueel.

DORA maakt digitale operationele weerbaarheid tot een governanceverplichting voor financiële entiteiten. Van het leidinggevend orgaan wordt verwacht dat het het ICT-risicobeheerkader definieert, goedkeurt, daarop toezicht houdt en daarvoor verantwoordelijk blijft. Dat omvat ICT-bedrijfscontinuïteit, respons- en herstelplannen, meldkanalen voor grote incidenten, ICT-risico’s van derden en geleerde lessen.

NIS2 verhoogt de governance-inzet voor essentiële en belangrijke entiteiten. Article 20 vereist dat leidinggevende organen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie en training volgen. Het koppelt tekortkomingen in risicobeheer en incidentmelding ook aan ernstige toezichtgevolgen. Voor essentiële entiteiten kunnen maximale administratieve boetes oplopen tot ten minste EUR 10.000.000 of 2 procent van de totale wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Voor belangrijke entiteiten bedraagt de uitgangswaarde ten minste EUR 7.000.000 of 1,4 procent van de omzet, afhankelijk van welk bedrag hoger is.

GDPR voegt een andere invalshoek toe. Een datalek met persoonsgegevens is niet beperkt tot bevestigde publieke openbaarmaking of gestolen bestanden. Het omvat onopzettelijke of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of toegang tot persoonsgegevens. Verwerkingsverantwoordelijken moeten het risico voor betrokkenen beoordelen en de verantwoordingsplicht voor het besluit om wel of niet te melden kunnen aantonen.

ISO/IEC 27001:2022 geeft deze verplichtingen een bewijsmateriaalbasis. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context, eisen van belanghebbenden, toepassingsgebied, interfaces en afhankelijkheden begrijpt. Clausules 5.1 tot en met 5.3 vereisen leiderschapsbetrokkenheid, beleid, rollen, verantwoordelijkheden en rapportage. Clausules 6.1.1 tot en met 6.1.3 vereisen risicogebaseerde planning, risicobeoordeling, risicobehandeling en een Verklaring van toepasselijkheid. Clausules 8.1 tot en met 8.3 vereisen operationele beheersing, wijzigingsbeheer, bewaard bewijsmateriaal en herbeoordeling wanneer risicocondities veranderen. ISO/IEC 27001:2022

Wanneer de incidentoproep plaatsvindt, moet de vraag niet zijn: “Wie vindt dit kritiek?” De vraag moet zijn: “Wat vereisen onze goedgekeurde criteria, wettelijke triggers, bewijsmateriaal en escalatieregels dat wij nu doen?”

Eén gebeurtenis, drie regelgevende classificatiesystemen

DORA, NIS2 en GDPR gebruiken niet dezelfde taal voor incidenten. Dat is de kernreden waarom organisaties in het eerste uur moeite hebben.

DORA Article 17 vereist dat financiële entiteiten een beheerproces voor ICT-gerelateerde incidenten inrichten dat ICT-incidenten detecteert, beheert en meldt, ICT-gerelateerde incidenten en significante cyberdreigingen registreert, grondoorzaken aanpakt, indicatoren voor vroegtijdige waarschuwing gebruikt, incidenten categoriseert en classificeert, rollen toewijst, communicatie beheert, grote incidenten naar het hoger management escaleert en veilige operaties herstelt.

DORA Article 18 vereist classificatie aan de hand van criteria zoals getroffen cliënten, getroffen tegenpartijen, transacties, duur, downtime, geografische spreiding, gegevensverlies dat beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid raakt, het kritieke karakter van getroffen diensten en economische impact. DORA Article 19 vereist melding van grote ICT-gerelateerde incidenten en communicatie met cliënten wanneer financiële belangen worden geraakt.

NIS2 Article 23 definieert een significant incident als een incident dat ernstige operationele verstoring of financieel verlies heeft veroorzaakt of kan veroorzaken, of dat anderen heeft geraakt of kan raken door aanzienlijke materiële of immateriële schade te veroorzaken. Het vereist een vroegtijdige waarschuwing binnen 24 uur nadat men zich bewust is geworden van het significante incident, een incidentmelding binnen 72 uur, tussentijdse rapportages op verzoek en een eindrapport binnen één maand na de incidentmelding. Waar van toepassing moeten getroffen afnemers van diensten ook worden geïnformeerd over maatregelen of remedies die zij kunnen nemen.

GDPR stelt een privacyrisicovraag. Heeft een inbreuk op de beveiliging geleid tot vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of toegang tot persoonsgegevens? Zo ja, dan moet de verwerkingsverantwoordelijke het risico voor de rechten en vrijheden van natuurlijke personen beoordelen. Als het waarschijnlijk is dat de inbreuk een risico oplevert, moet de toezichthoudende autoriteit in het algemeen binnen 72 uur na bewustwording worden geïnformeerd. Als waarschijnlijk sprake is van een hoog risico, moeten getroffen betrokkenen mogelijk zonder onredelijke vertraging worden geïnformeerd.

Eén incident vereist daarom gelijktijdige classificatie.

Voor financiële entiteiten is DORA de sectorspecifieke Unierechtshandeling voor ICT-risicobeheer en incidentmeldingsverplichtingen die overlappen met NIS2. Dat maakt NIS2 niet irrelevant. NIS2 kan nog steeds relevant zijn voor samenwerking, informatiestromen, diensten buiten de DORA-perimeter, niet-financiële groepsentiteiten, clouddiensten, managed services en contractuele klantverplichtingen. Het ernstmodel moet niet alleen de uitkomst vastleggen, maar ook de toepasselijkheidslogica.

Clarysec’s model: classificeer de gebeurtenis, niet de emotie

Clarysec begint met ISO/IEC 27002:2022 beheersmaatregel 5.25, beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, als anker voor cross-compliance. In Zenith Controls: The Cross-Compliance Guide Zenith Controls is dit onderwerp gekoppeld via de vermelding “Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen” voor beheersmaatregel 5.25, ondersteund door “planning en voorbereiding van informatiebeveiligingsincidentbeheer” voor beheersmaatregel 5.24 en “verzameling van bewijsmateriaal” voor beheersmaatregel 5.28.

Het belangrijkste nalevingsmoment is vaak niet de indamming. Het is de splitsing waarbij een beveiligingsgebeurtenis een regelgevingsincident wordt, of verdedigbaar als gebeurtenis met lagere ernst wordt vastgelegd.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint beschrijft dit moment in de fase Controls in Action, stap 23:

“Niet elke anomalie is een ramp. Niet elke waarschuwing wijst op compromittering. In de praktijk worden beveiligingsteams en bedrijfseenheden overspoeld met ruis, aanmeldpogingen, logafwijkingen, kleine beleidsovertredingen en schaduw-IT-activiteit. De echte uitdaging zit niet alleen in detectie, maar in het onderscheiden van onschadelijk en schadelijk, en in weten wat escalatie vereist.”

Die zin vat het operationele probleem samen. Een SIEM-waarschuwing is niet automatisch een groot DORA-incident. Een tijdelijke storing is niet automatisch een significant NIS2-incident. Een verdachte databasequery is niet automatisch meldingsplichtig onder GDPR. Elk daarvan kan meldingsplichtig worden afhankelijk van impact, reikwijdte, gegevens, getroffen partijen en bewijsmateriaal.

De Zenith Blueprint, fase Risk Management, stap 10, beveelt ook aan om impactdefinities af te stemmen op bedrijfsschaal en blootstelling aan regelgeving:

“Bij het definiëren van impact is het verstandig om niveaus te relateren aan uw specifieke bedrijfsschaal. Bijvoorbeeld: ‘Grote financiële impact = verlies > $100k’ (pas dit aan uw context aan). Houd ook rekening met regelgevende impact: een datalek met persoonsgegevens kan bijvoorbeeld automatisch ‘Groot’ of ‘Ernstig’ zijn vanwege GDPR-boetes en meldingsvereisten, zelfs als het directe financiële verlies onduidelijk is.”

Dat is het ontwerpprincipe voor ernstclassificatie van incidenten in 2026: ernst is bedrijfsimpact plus juridische impact plus zekerheid van bewijsmateriaal.

Een praktische taxonomie voor incidenternst voor DORA, NIS2 en GDPR

Een verdedigbare taxonomie moet interne ernst scheiden van regelgevende classificatie. Interne ernst bepaalt de urgentie van respons, toewijzing van middelen en escalatie naar directieniveau. Regelgevende classificatie bepaalt melding, juridische toetsing en externe communicatie.

Het interne ernstniveau is niet het definitieve regelgevende antwoord. Het is de operationele modus. Een SEV 3-gebeurtenis kan na beoordeling van logboeken meldingsplichtig onder GDPR worden. Een SEV 2-storing hoeft geen groot DORA-incident te zijn als impactdrempels niet worden gehaald. Een SEV 1-ransomware-incident kan tegelijk DORA, NIS2, GDPR, klantcontracten en coördinatie met opsporingsinstanties activeren.

Een gedetailleerdere classificatiematrix helpt het team om van waarschuwing naar actie te gaan.

Het model moet in beleid zijn verankerd en niet worden overgelaten aan de luidste stem in het crisisoverleg. Het mkb-Incidentresponsbeleid-sme Incidentresponsbeleid-sme - SME, governancevereisten, clausule 5.3.1, bepaalt:

“De algemeen directeur moet, met input van de IT-dienstverlener, alle incidenten binnen één uur na melding naar ernst classificeren.”

Hetzelfde mkb-beleid, risicobehandeling en uitzonderingen, clausule 7.4.1, voegt toe:

“Wanneer klantgegevens betrokken zijn, moet de algemeen directeur de wettelijke meldingsverplichtingen beoordelen op basis van de toepasselijkheid van GDPR, NIS2 of DORA.”

Voor grotere organisaties formaliseert het enterprise-Incidentresponsbeleid Incidentresponsbeleid, governancevereisten, clausule 5.3, hetzelfde concept:

“Incidentclassificatie moet een gelaagd model volgen:”

De beleidstaal is van belang omdat toezichthouders en auditors zullen vragen of de classificatiecriteria al vóór het incident bestonden. Een matrix die achteraf is bedacht, is zwak bewijsmateriaal. Een matrix die is goedgekeurd, getraind, geoefend en consistent gebruikt, is verdedigbaar.

Het besluitlogboek: het belangrijkste bewijsmateriaal-artefact

Wanneer auditors, toezichthouders of bestuurders een incident beoordelen, vragen zij zelden alleen: “Wat is er gebeurd?” Zij vragen: “Wanneer wist u het, wie heeft besloten, op basis van welk bewijsmateriaal, en waarom hebt u niet eerder gemeld?”

Daarom adviseert Clarysec een besluitlogboek voor incidenternst voor elke SEV 3-gebeurtenis en hoger, en voor elke gebeurtenis waarbij persoonsgegevens, kritieke diensten, financiële klanten, managed services, cloudinfrastructuur of grensoverschrijdende impact betrokken zijn.

Dit sluit rechtstreeks aan op ISO/IEC 27001:2022. Clausule 8.1 vereist dat processen worden gepland, geïmplementeerd en beheerst, met voldoende gedocumenteerde informatie die wordt bewaard om aan te tonen dat zij volgens plan hebben gewerkt. Clausules 8.2 en 8.3 vereisen herbeoordeling wanneer significante wijzigingen optreden en bewaring van bewijsmateriaal voor risicobehandeling. Bijlage A-beheersmaatregelen A.5.24 tot en met A.5.28 vormen de ruggengraat voor incidentbeheer: planning en voorbereiding, beoordeling van en besluitvorming over gebeurtenissen, respons, leren van incidenten en bewijsverzameling.

Het mkb-Beleid inzake gegevensbescherming en privacy-sme Beleid inzake gegevensbescherming en privacy-sme - SME, handhaving en naleving, clausule 8.3.2, ondersteunt de GDPR-kant van het model:

“De privacycoördinator bepaalt de ernst, initieert indammingsmaatregelen en documenteert de casus”

Privacybeoordeling mag niet pas beginnen wanneer de regelgevende klok ongemakkelijk wordt. Zij hoort in de triageworkflow thuis.

Praktijkvoorbeeld: Sarah’s API-incident classificeren

Terug naar FinScale. Het is een B2B-fintechplatform dat gebruikmaakt van cloudinfrastructuur, een externe aanbieder van fraudeanalyse en een managed security provider. Voor sommige activiteiten is het een financiële entiteit die onder DORA valt. Het is ook een digitale dienstverlener met NIS2-relevante activiteiten in één lidstaat. Het verwerkt persoonsgegevens van klanten als verwerkingsverantwoordelijke voor accountdiensten en als verwerker voor sommige enterprise-klanten.

Om 02:17 wordt afwijkend API-verkeer gedetecteerd. Om 02:35 wordt het incidentticket geopend. Om 03:00 voltooit Sarah de initiële triage met de incidentleider.

Eerst wordt de interne ernst vastgesteld. Het incident beïnvloedde de beschikbaarheid van het klantdashboard gedurende 19 minuten, omvatte verdachte toegangstokens en raakte een kritieke klantgerichte functie. Het wordt geclassificeerd als SEV 3 Matig in afwachting van bevestiging, met escalatie naar de incidentleider, privacycoördinator, juridisch adviseur en service-eigenaar.

Vervolgens wordt de DORA-screening afgerond. Het team controleert getroffen cliënten, tegenpartijen, transacties, duur, downtime, geografische spreiding, gegevensverlies, kritiek belang en economische impact. Er zijn geen mislukte of gewijzigde transacties bevestigd. De downtime is beperkt. Gegevensverlies is niet aangetoond. Omdat echter een kritieke component van een financiële dienst en financiële belangen van klanten geraakt kunnen zijn, blijft het incident onder DORA-monitoring en kan het worden geherclassificeerd.

Ten derde wordt de NIS2-screening vastgelegd. Het team noteert dat DORA het primaire sectorspecifieke meldregime is voor de verplichtingen van de financiële entiteit binnen de reikwijdte. Het controleert ook of het incident diensten of klanten buiten de DORA-perimeter raakt. In dit stadium is geen ernstige operationele verstoring of aanzienlijke schade bevestigd.

Ten vierde wordt de GDPR-screening gestart. De verdachte tokens kunnen toegang tot klantdashboardgegevens hebben mogelijk gemaakt. De privacycoördinator documenteert gegevenscategorieën, getroffen gebruikers, tokenbereik, beoordeelde logboeken, of gegevens zijn bekeken of geëxporteerd, en waarborgen zoals tokenverval en toegangscontrole.

Om 04:20 toont loganalyse aan dat twee tokens zijn gebruikt om dashboardmetadata van 41 klanten te benaderen, waaronder namen, account-ID’s en transactiestatus, maar geen betalingsreferenties of identiteitsdocumenten. Het team verhoogt het incident naar SEV 2 Groot omdat de vertrouwelijkheid van persoonsgegevens is geraakt en klantcommunicatie mogelijk vereist is. De functionaris voor gegevensbescherming beoordeelt het GDPR-risico voor betrokkenen. Het DORA-besluit wordt opnieuw beoordeeld op basis van impact op cliënten, transacties en economische impact.

Dit is de praktische waarde van het model. Initiële classificatie is geen definitieve juridische conclusie. Het is een door bewijsmateriaal gedreven besluit dat kan worden bijgewerkt naarmate feiten zich ontwikkelen.

Logging, monitoring en forensisch bewijsmateriaal: de bewijslaag

Een ernstmodel zonder bewijsmateriaal is een vergaderopinie. De verwachting voor 2026 is dat classificatie wordt onderbouwd door logboeken, monitoring, veiliggestelde artefacten en chain-of-custody.

Het mkb-Beleid voor logging en monitoring-sme Beleid voor logging en bewaking-sme - SME, handhaving en naleving, clausule 8.3.4, bepaalt:

“Onderzoeken naar inbreuken moeten worden ondersteund door toereikende logboeken om te voldoen aan het verantwoordingsbeginsel onder GDPR en DORA”

Forensische behandeling is even belangrijk. Het mkb-Beleid inzake bewijsverzameling en forensisch onderzoek-sme Beleid inzake bewijsverzameling en forensisch onderzoek-sme - SME, governancevereisten, clausule 5.3.1, vereist:

“Voor elk incident moet een eenvoudig chain-of-custody-logboek worden bijgehouden (bijv. een Excel-bestand of sjabloondocument).”

Voor enterprise-omgevingen vereist het Beleid inzake bewijsverzameling en forensisch onderzoek Beleid inzake bewijsverzameling en forensisch onderzoek, governancevereisten, clausule 5.5:

“Al het verzamelde bewijsmateriaal moet uniek worden geïdentificeerd, gelabeld en opgeslagen in een beveiligde repository met:”

De Zenith Blueprint, fase Controls in Action, stap 23, legt uit waarom dit voor ISO/IEC 27002:2022 beheersmaatregel 5.28 van belang is:

“Wanneer zich een informatiebeveiligingsincident voordoet, is bewijsmateriaal een van de meest kritieke, maar vaak over het hoofd geziene elementen van de respons. Niet logboeken, niet screenshots, niet losse beschrijvingen, maar correct veiliggesteld, chain-of-custody-respecterend en manipulatiebestendig bewijsmateriaal.”

Een praktisch bewijspakket voor een groot of mogelijk meldingsplichtig incident moet het volgende bevatten:

• Incidentticket en tijdlijn
• Besluitlogboek voor incidenternst en herclassificatiehistorie
• SIEM-waarschuwingen, EDR-waarschuwingen, cloudlogboeken en identiteitslogboeken
• Logboeken van gegevenstoegang en exportlogboeken
• Inventarisvermeldingen van getroffen activa en diensten
• Impactbeoordeling voor klanten, transacties en geografie
• DORA-, NIS2- en GDPR-screeningwerkblad
• FG- of juridische beoordeling
• Communicatiegoedkeuringen en verzonden berichten
• Chain-of-custody-registratie
• Oorzaakanalyse
• Corrigerende maatregelen en geleerde lessen

Dit bewijspakket ondersteunt ook ISO/IEC 27001:2022 Bijlage A-beheersmaatregelen A.8.15 logging, A.8.16 monitoringactiviteiten, A.5.28 verzameling van bewijsmateriaal, A.5.27 leren van informatiebeveiligingsincidenten, A.5.31 wettelijke, statutaire, regelgevende en contractuele eisen, en A.5.34 privacy en bescherming van persoonlijk identificeerbare informatie.

Cross-compliance mapping: één keer bouwen, veel auditors beantwoorden

De sterkste modellen voor incidenternst worden één keer gebouwd en vele malen gekoppeld. Zenith Controls is ontworpen als cross-compliancekompas voor dit werk. Voor dit onderwerp zijn de kernvermeldingen in ISO/IEC 27002:2022 5.24 planning en voorbereiding van informatiebeveiligingsincidentbeheer, 5.25 beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, 5.26 respons op informatiebeveiligingsincidenten, 5.27 leren van informatiebeveiligingsincidenten en 5.28 verzameling van bewijsmateriaal.

Deze beheersmaatregelen sluiten natuurlijk aan op het managementsysteem van ISO/IEC 27001:2022. Clausules 4, 5, 6 en 8 definiëren toepassingsgebied, leiderschap, risicocriteria, behandeling en operationeel bewijsmateriaal. ISO/IEC 27002:2022 biedt de taal voor implementatie van beheersmaatregelen. Denken vanuit ISO 22301-achtige bedrijfscontinuïteit ondersteunt drempels voor verstoring, herstelprioriteiten en crisismanagement. Incidentbeheerpraktijken in de stijl van ISO/IEC 27035 ondersteunen gestructureerde detectie, rapportage, beoordeling, respons en leren. Privacygovernance in de stijl van ISO/IEC 27701 ondersteunt rollen bij datalekken met persoonsgegevens, overwegingen voor verwerkingsverantwoordelijke en verwerker, privacybewijsmateriaal en verantwoordingsplicht.

Hetzelfde model koppelt aan het NIST Cybersecurity Framework 2.0. De GOVERN-functie vereist dat wettelijke, regelgevende, contractuele, privacy- en burgerrechtenverplichtingen worden begrepen en beheerd. Ook verwacht zij dat risicobereidheid, rollen, bevoegdheden, beleid en toezicht worden gedefinieerd. De functies DETECT, RESPOND en RECOVER ondersteunen triage, analyse, escalatie, indamming, herstel, communicatie en verbetering.

Het voordeel is praktisch. Wanneer een DORA-toezichthouder vraagt om de onderbouwing voor een groot ICT-gerelateerd incident, een NIS2-autoriteit vraagt naar het besluit over de vroegtijdige waarschuwing binnen 24 uur, een gegevensbeschermingsautoriteit vraagt waarom een GDPR-melding wel of niet is gedaan, en een ISO-auditor vraagt of het ISMS volgens plan heeft gewerkt, kan de organisatie antwoorden vanuit dezelfde set bewijsmateriaal.

Hoe auditors en toezichthouders uw model zullen toetsen

Een ISO/IEC 27001:2022-auditor begint doorgaans met toepassingsgebied en wettelijke eisen. De auditor zal vragen of DORA, NIS2, GDPR, klantcontracten en ICT-verplichtingen van derden zijn geïdentificeerd als eisen van belanghebbenden. Vervolgens volgt de auditor het spoor naar risicocriteria, de Verklaring van toepasselijkheid, incidentprocedures, operationele registraties en bewaring van bewijsmateriaal. De auditor wil bewijs dat het classificatieproces niet tijdens het incident is bedacht.

Een DORA-toezichthouder of intern auditteam zoekt naar een levenscycluslus: incidentbeheerproces, indicatoren voor vroegtijdige waarschuwing, classificatiecriteria, escalatie van grote incidenten, communicatie met cliënten, grondoorzaak, definitieve impactcijfers, weerbaarheidstesten en toezicht door het leidinggevend orgaan. Zij zullen ook vragen of ICT-afhankelijkheden van derden zijn meegenomen, met name wanneer cloud, SaaS, managed security of outsourcingproviders betrokken waren.

Een NIS2-gerichte auditor of autoriteit zal toetsen of de entiteit significante incidenten kan identificeren, gefaseerde termijnen kan halen, kan communiceren met getroffen afnemers van diensten en bewijsmateriaal kan leveren voor de beoordeling van grensoverschrijdende impact. Zij zullen incidentafhandeling koppelen aan Article 21-risicobeheersmaatregelen, waaronder bedrijfscontinuïteit, crisismanagement, beveiliging van de toeleveringsketen, toegangscontrole, beleid inzake beheer van bedrijfsmiddelen en training.

Een GDPR-functionaris voor gegevensbescherming of toezichthoudende autoriteit zal onderzoeken of de organisatie persoonsgegevens, rollen, betrokkenen, categorieën, getroffen systemen, type inbreuk en risico voor betrokkenen heeft geïdentificeerd. Zij zullen toetsen of de verwerkingsverantwoordelijke verantwoordingsplicht kan aantonen en of meldingen van verwerkers aan verwerkingsverantwoordelijken tijdig en volledig waren.

Een auditor in ISACA- of COBIT 2019-stijl zal zich richten op governancebewijsmateriaal. Wie heeft de ernsttaxonomie goedgekeurd? Wie is eigenaar van het risico? Welke metrieken worden aan het management gerapporteerd? Hoe worden uitzonderingen afgehandeld? Hoe worden geleerde lessen omgezet in verbeteringen van beheersmaatregelen?

Veelvoorkomende faalpatronen bij incidentclassificatie

Het eerste faalpatroon is denken in één label. Teams classificeren een gebeurtenis als hoog, middel of laag, maar beoordelen DORA-, NIS2- en GDPR-triggers niet afzonderlijk. Het resultaat is een ernstlabel dat een meldingsbesluit niet kan verklaren.

Het tweede faalpatroon is bias richting bevestigde inbreuk. Teams wachten op absoluut bewijs van exfiltratie voordat zij privacy of juridisch betrekken. GDPR-beoordeling van een datalek begint vaak bij mogelijke ongeoorloofde toegang, verlies, wijziging of verstrekking, niet alleen bij bevestigde publicatie van gegevens.

Het derde faalpatroon is verwarring over de klok. Tijdlijnen onder NIS2 en GDPR hangen af van bewustwording en beoordeling. Als het incidentticket het bewustwordingsmoment, de classificatietijd en de escalatietijd niet vastlegt, kan de organisatie moeite hebben om tijdigheid aan te tonen.

Het vierde faalpatroon is forensisch onderzoek na opschoning. Engineers roteren sleutels, bouwen hosts opnieuw op en verwijderen tijdelijk bewijsmateriaal voordat een onderzoekspositie is geactiveerd. Dit kan bewijs vernietigen dat nodig is voor regelgevende, contractuele of juridische beoordeling.

Het vijfde faalpatroon is leveranciersblindheid. DORA, NIS2 en NIST CSF 2.0 benadrukken allemaal risico’s van derden en de toeleveringsketen. Als een cloudprovider, managed service provider, betalingsverwerker, identiteitsprovider of SaaS-leverancier deel uitmaakt van de incidentketen, moet het classificatiemodel leveranciersimpact en contractuele meldingsverplichtingen omvatten.

Een Clarysec-implementatiechecklist voor 2026

Om een verdedigbaar model voor incidenternst operationeel te maken, adviseert Clarysec de volgende volgorde:

1. Bevestig de toepasselijkheid van regelgeving voor DORA, NIS2, GDPR, klantcontracten en sectorregels.
2. Actualiseer het ISMS-toepassingsgebied en de eisen van belanghebbenden onder ISO/IEC 27001:2022.
3. Definieer interne ernstniveaus met meetbare drempels voor downtime, gegevens, klanten, geografie, financieel verlies en kritiek belang.
4. Voeg afzonderlijke DORA-, NIS2- en GDPR-screeningvragen toe aan de workflow voor incidenttickets.
5. Definieer escalatietriggers voor de incidentleider, functionaris voor gegevensbescherming, juridisch adviseur, hoger management en bestuur.
6. Maak een sjabloon voor het besluitlogboek voor incidenternst.
7. Koppel classificatie aan bewijsverzameling en chain-of-custodyprocedures.
8. Valideer logdekking voor identiteit, cloud, applicatie, databank, netwerk en leveranciersgebeurtenissen.
9. Voer tabletop-oefeningen uit voor scenario’s met een groot DORA-incident, significant NIS2-incident en GDPR-datalek.
10. Verwerk geleerde lessen in risicobehandeling, de Verklaring van toepasselijkheid, training en weerbaarheidstesten.

De Zenith Blueprint, fase Controls in Action, stap 16, versterkt de menselijke kant van dit model: meldingen moeten worden gelogd, getriageerd en via het incidentresponsplan worden geëscaleerd, en zelfs kleine gebeurtenissen moeten worden gevolgd omdat trends zwaktes in beheersmaatregelen blootleggen. Het bevordert een meldcultuur met lage drempel: “Bij twijfel: meld.”

Dat culturele punt is cruciaal. Een ernstmodel faalt als medewerkers melden uitstellen omdat zij bang zijn voor overreactie. Het doel is snelle melding, gedisciplineerde triage en verdedigbare classificatie.

Zet incidentonzekerheid om in auditgereed bewijsmateriaal

In 2026 is ernstclassificatie van incidenten niet langer uitsluitend een SOC-besluit. Het is een gereguleerd governanceproces dat criteria voor grote ICT-gerelateerde incidenten onder DORA, drempels voor significante incidenten onder NIS2, GDPR-risico bij datalekken en ISO/IEC 27001:2022-bewijsmateriaal met elkaar moet verbinden.

De organisaties die tijdens incidenten het beste presteren, zijn niet de organisaties met de dikste responsmap. Het zijn de organisaties die vier vragen snel kunnen beantwoorden en elk antwoord later kunnen bewijzen:

• Wat is er gebeurd?
• Hoe ernstig is het?
• Welke regelgevende verplichtingen kunnen van toepassing zijn?
• Welk bewijsmateriaal ondersteunt het besluit?

Clarysec helpt organisaties die brug te bouwen via beleidssjablonen, ernsttaxonomieën, besluitlogboeken, tabletopscenario’s en cross-compliance mappings. Begin met het incidentbeleid, valideer uw risicocriteria in Zenith Blueprint Zenith Blueprint, en gebruik Zenith Controls Zenith Controls om ISO/IEC 27002:2022-beheersmaatregelen 5.24, 5.25, 5.26, 5.27 en 5.28 te koppelen aan DORA, NIS2, GDPR, NIST CSF en auditverwachtingen.

Als uw team binnen het eerste uur geen antwoord kan geven op “Is dit DORA-groot, NIS2-significant of GDPR-meldingsplichtig?”, is de volgende stap niet nog een generiek incidentresponsplan. De volgende stap is een verdedigbaar operationeel model voor incidenternst, getest voordat de volgende oproep om 02:17 binnenkomt.

Klaar om paniek te vervangen door procesbeheersing? Download Clarysec’s sjablonen voor incidentresponsbeleid en bewijsverzameling, toets uw huidige ernsttaxonomie aan de Zenith Blueprint, of vraag een Clarysec-gereedheidsbeoordeling aan om een auditgereed classificatiemodel voor incidenten onder DORA, NIS2, GDPR en ISO/IEC 27001 te bouwen.