NIST-mapping voor incidentrespons bij audits in 2026

Het is 07:42 op een dinsdag. Anya, de CISO van een snelgroeiend fintechplatform, ziet de eerste waarschuwing: onmogelijke reisactiviteit op een beheerdersaccount. Daarna volgt een reeks mislukte aanmeldpogingen en vervolgens een geslaagde sessie vanaf een onbeheerd apparaat. Vijf minuten later meldt de klantenservice dat gebruikers geen toegang hebben tot een kernworkflow in SaaS. Om 08:10 toont het clouddashboard afwijkende API-aanroepen naar een opslagbucket die mogelijk persoonsgegevens bevat.

Het beveiligingsteam handelt snel. De SIEM slaat aan, de cloudengineer trekt een sessie in en de service-eigenaar start met het herstellen van toegang. Maar de echte crisis is niet alleen technisch. Het is governance.

Anya moet drie vragen beantwoorden voordat het eerste uur voorbij is.

Ten eerste: is dit een informatiebeveiligingsincident, een inbreuk in verband met persoonsgegevens, een significant NIS2-incident of een majeur ICT-gerelateerd incident onder DORA?

Ten tweede: wie moet worden geïnformeerd, wanneer en met welk bewijsmateriaal?

Ten derde: kan de organisatie aantonen dat haar incidentresponsproces daadwerkelijk heeft gewerkt zoals ontworpen?

Op dat moment ontdekken veel organisaties het verschil tussen een incidentresponsplan en een governancesysteem voor incidentrespons. Incidentrespons volgens NIST SP 800-61 en NIST CSF 2.0 is niet langer alleen een onderwerp voor SOC-draaiboeken. In 2026 is incidentrespons rechtstreeks verbonden met verantwoordingsplicht van het bestuur, audits volgens ISO/IEC 27001:2022, gefaseerde rapportage onder NIS2, operationele weerbaarheid onder DORA, besluiten over inbreuken in verband met persoonsgegevens onder GDPR en verantwoordingsplicht in de leveranciersketen.

De sterkste programma’s creëren geen afzonderlijke responspaden voor elk raamwerk. Zij gebruiken NIST CSF 2.0 als operationele kaart, ISO/IEC 27001:2022 als ruggengraat van het managementsysteem en één bewijsmodel dat NIS2, DORA en GDPR tegelijk kan ondersteunen. Dat is de Clarysec-aanpak: beleidsgestuurde besluitvorming, workflows die met tabletop-oefeningen zijn gevalideerd, bewijsdossiers die gereed zijn voor toezichthouders en cross-frameworkmapping via de Zenith Blueprint: 30-stappenroadmap voor auditors en Zenith Controls: gids voor cross-compliance.

Het probleem in 2026: één incident, meerdere verantwoordingsregimes

Het incident waarmee Anya te maken heeft, is niet één complianceprobleem. Het zijn meerdere overlappende besluitvormingspaden.

Als de organisatie cloudcomputingdiensten, SaaS, beheerde diensten, managed security services, DNS, datacenters, vertrouwensdiensten of andere digitale-infrastructuurdiensten levert, kan NIS2 van toepassing zijn. Classificatie als essentiële of belangrijke entiteit hangt af van sector, omvang en nationale implementatie, maar de richting is duidelijk: incidentafhandeling is nu een gereguleerde managementverantwoordelijkheid.

Als de organisatie een financiële entiteit is, kan DORA het primaire regelkader voor operationele weerbaarheid zijn. DORA is van toepassing vanaf 17 januari 2025 en bestrijkt ICT-risicomanagement, rapportage van majeure ICT-gerelateerde incidenten, testen van operationele weerbaarheid, informatie-uitwisseling, ICT-risico’s van derde partijen en toezicht op kritieke ICT-dienstverleners van derde partijen. Voor financiële entiteiten die onder DORA vallen en ook onder NIS2 vallen, fungeert DORA als sectorspecifiek raamwerk voor overlappende verplichtingen inzake ICT-risico en incidentrapportage.

Als persoonsgegevens zijn ingezien, gewijzigd, verloren gegaan, vernietigd of openbaar gemaakt, wordt GDPR onderdeel van de beslisboom voor incidentrespons. GDPR definieert een inbreuk in verband met persoonsgegevens als een beveiligingsinbreuk die leidt tot de accidentele of onrechtmatige vernietiging, het verlies, de wijziging, de ongeoorloofde verstrekking van of de ongeoorloofde toegang tot persoonsgegevens. GDPR vereist ook verantwoordingsplicht, wat betekent dat de verwerkingsverantwoordelijke moet kunnen aantonen dat de verwerkingsbeginselen worden nageleefd, waaronder integriteit en vertrouwelijkheid.

Als de onderneming is gecertificeerd volgens ISO/IEC 27001:2022, of zich voorbereidt op certificering, wordt het incident ISMS-bewijsmateriaal. Auditors onderzoeken scope, wettelijke verplichtingen, rollen, risicobehandeling, selectie van beheersmaatregelen, operationele uitvoering, gedocumenteerde informatie, geleerde lessen en voortdurende verbetering. ISO/IEC 27001:2022-clausules 4.1 tot en met 4.4 vereisen dat het ISMS de context, belanghebbenden, verplichtingen, scope en procesinteracties weerspiegelt. Clausules 5.1 tot en met 5.3 vereisen leiderschap, verantwoordingsplicht en toegewezen verantwoordelijkheden. Clausules 6.1.1 tot en met 6.1.3 vereisen een informatiebeveiligingsrisicobeoordeling, risicobehandeling en een Verklaring van Toepasselijkheid. Clausules 8.1 tot en met 8.3 vereisen beheerste uitvoering, bewijsmateriaal dat processen volgens plan zijn uitgevoerd, beheersing van uitbestede processen en implementatie van de risicobehandeling.

Het zakelijke probleem is niet een gebrek aan raamwerken. Het is het ontbreken van één operationeel model dat raamwerken omzet in tijdige besluiten en betrouwbaar bewijsmateriaal.

Gebruik NIST CSF 2.0 als gemeenschappelijke taal

NIST CSF 2.0 is nuttig omdat het leiderschap, security, juridische zaken, privacy, operations en leveranciers een gemeenschappelijke taal geeft voor cyberbeveiligingsresultaten. De GOVERN-functie is bijzonder belangrijk voor incidentrespons, omdat deze organisaties dwingt toezicht, beleid, risicostrategie, rollen en risico’s in de toeleveringsketen te adresseren voordat de crisis begint.

Voor incidentrespons verbindt CSF 2.0 governance met de operationele levenscyclus: IDENTIFY, PROTECT, DETECT, RESPOND en RECOVER. Die structuur helpt om een rumoerig incident te vertalen naar een beheerste stroom van bewijsmateriaal.

CSF 2.0 Organizational Profiles maken dit praktisch. Een Current Profile toont de werkelijke incidentresponscapaciteit van de organisatie, inclusief hiaten, onduidelijkheden en workarounds. Een Target Profile definieert de gewenste situatie, zoals ernstclassificatie binnen één uur, gedocumenteerde meldingsbesluiten, behoud van bewijsmateriaal, coördinatie met derde partijen en rapportagepakketten die gereed zijn voor toezichthouders.

Voor Anya’s fintech liet het Current Profile een bekend patroon zien: sterke tools, zwakke besluitvormingsgovernance. Het Target Profile richtte zich op concrete resultaten van CSF 2.0, waaronder:

• RS.MA-01: het incidentresponsplan wordt uitgevoerd in coördinatie met relevante derde partijen zodra een incident is verklaard.
• RS.MA-02: incidentmeldingen worden getriageerd en gevalideerd.
• RS.MA-03: incidenten worden gecategoriseerd en geprioriteerd.
• RS.MA-04: incidenten worden waar nodig geëscaleerd of opgeschaald.
• RS.AN-03: er wordt analyse uitgevoerd om vast te stellen wat tijdens een incident heeft plaatsgevonden en wat de grondoorzaak is.
• RS.AN-06: handelingen die tijdens een onderzoek zijn uitgevoerd, worden vastgelegd en de integriteit en herkomst van de registraties worden behouden.
• RS.AN-07: incidentgegevens en metadata worden verzameld en hun integriteit en herkomst worden behouden.
• RS.CO-02: interne en externe stakeholders worden over incidenten geïnformeerd.
• RS.MI-01: incidenten worden ingedamd.
• RS.MI-02: incidenten worden uitgeroeid.
• RC.RP-03: de integriteit van back-ups en andere herstelmiddelen wordt geverifieerd voordat zij voor herstel worden gebruikt.

Een raamwerk alleen is geen auditeerbaar programma. De resultaten moeten binnen een managementsysteem worden ingebed, en daar biedt ISO/IEC 27001:2022 de ruggengraat.

Veranker incidentrespons binnen ISO/IEC 27001:2022

NIST biedt een praktische taal voor incidentafhandeling. ISO/IEC 27001:2022 biedt de operationele discipline die auditors verwachten. Het ISMS verandert incidentrespons van een set draaiboeken in een bestuurd proces met scope, eigenaarschap, risicobehandeling, prestatie-evaluatie en verbetering.

De meest relevante cluster van beheersmaatregelen uit Annex A is:

De gids Zenith Controls van Clarysec koppelt deze beheersmaatregelreferenties uit ISO/IEC 27002:2022 aan andere normen, auditverwachtingen en gerelateerde complianceverplichtingen. Het is geen afzonderlijk beheersmaatregelenraamwerk. Het is een cross-compliancegids die organisaties helpt begrijpen hoe dezelfde beheersactiviteiten meerdere assurancebehoeften ondersteunen.

De Zenith Blueprint, fase Controls in Action, stap 23, maakt de ruggengraat voor incidentrespons operationeel:

Zorg dat u beschikt over een actueel incidentresponsplan (5.24) dat voorbereiding, escalatie, respons en communicatie omvat. Definieer wat een meldingsplichtige beveiligingsgebeurtenis (5.25) is en hoe het besluitvormingsproces wordt geactiveerd en gedocumenteerd. Selecteer een recente gebeurtenis of voer een tabletop-oefening uit om uw plan te valideren. Leg alle besluiten, rollen en communicatie vast in logboeken (5.26) en werk het plan bij met geleerde lessen (5.27). Bevestig dat procedures aanwezig zijn om forensisch bewijsmateriaal (5.28) te bewaren, waaronder snapshots van logboeken, back-ups en veilige isolatie van getroffen systemen.

Die alinea is de praktische brug van NIST-incidentafhandeling naar auditbewijsmateriaal. Bereid de capaciteit voor, classificeer de gebeurtenis, reageer op beheerste wijze, leer van de uitkomst en bewaar bewijsmateriaal.

Bouw meldbaarheid in het eerste uur in

Incidentresponsprogramma’s falen vaak in het eerste uur, niet omdat analisten vaardigheid missen, maar omdat de organisatie niet heeft gedefinieerd wie beslist, wanneer ernst wordt toegekend, welk bewijsmateriaal wordt bewaard en wanneer juridische triggers worden gecontroleerd.

Voor het mkb stelt Clarysec’s Incidentresponsbeleid voor het mkb een duidelijke governanceverwachting vast:

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

Dit is een krachtige eis. Het betekent niet dat alle feiten binnen één uur bekend zijn. Het betekent dat de organisatie een initiële ernst moet documenteren, onzekerheid moet vastleggen en escalatie moet activeren terwijl de feiten zich nog ontwikkelen.

Hetzelfde beleid vereist ook dat juridische termijnen in het proces worden ingebouwd:

Responstermijnen, waaronder gegevensherstel en meldingsverplichtingen, moeten worden gedocumenteerd en afgestemd op wettelijke vereisten, zoals de GDPR-vereiste om een inbreuk in verband met persoonsgegevens binnen 72 uur te melden.

Voor enterprise-omgevingen verankert Clarysec’s Incidentresponsbeleid een formeler responsmodel:

De organisatie moet een gecentraliseerd, gelaagd incidentresponskader onderhouden dat is afgestemd op ISO/IEC 27035 en bestaat uit de volgende gedefinieerde responsfasen:

Het enterprise-beleid neemt ook cross-regelgevende tijdsreferenties op in clausule 6.4.1:

GDPR Article 33 (melding aan de toezichthoudende autoriteit binnen 72 uur)

NIS2 Article 23 (melding binnen 24 uur nadat men kennis heeft gekregen van het incident)

DORA Article 17 (rapportage van ernstige ICT-gerelateerde incidenten)

Dat is het verschil tussen een technisch draaiboek en een governancegereed incidentresponskader. Juridische en regelgevende rapportagepaden worden niet tijdens een crisis geïmproviseerd. Zij worden geactiveerd door vooraf gedefinieerde classificatie- en beslispunten.

Breng NIS2-rapportage onder in de incidentworkflow

NIS2 vereist dat essentiële en belangrijke entiteiten het CSIRT of de bevoegde autoriteit zonder onnodige vertraging informeren over significante incidenten die de dienstverlening raken. Een significant incident omvat een incident dat ernstige operationele verstoring of financieel verlies heeft veroorzaakt of kan veroorzaken, of een incident dat anderen heeft geraakt of kan raken door aanzienlijke materiële of immateriële schade te veroorzaken.

Het rapportagemodel is gefaseerd.

NIS2 Article 21 vereist ook passende en evenredige technische, operationele en organisatorische maatregelen. De vereiste baseline omvat risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, kwetsbaarheidsafhandeling, effectiviteitsbeoordeling, cyberhygiëne en training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en, waar passend, multifactorauthenticatie en beveiligde communicatie.

NIS2 Article 20 brengt bestuursorganen in de verantwoordingsketen. Zij moeten maatregelen voor cyberbeveiligingsrisicomanagement goedkeuren en toezien op de implementatie. Voor incidentrespons betekent dit dat bestuursnotulen, managementgoedkeuringen, trainingsregistraties en escalatiebewijsmateriaal geen optionele administratieve artefacten zijn. Zij maken deel uit van de verdedigbaarheid richting toezichthouders.

Sancties verhogen de urgentie. Bij inbreuken op Article 21 of Article 23 moeten essentiële entiteiten maximale boetes kunnen krijgen van ten minste EUR 10 miljoen of 2 procent van de totale wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Belangrijke entiteiten moeten maximale boetes kunnen krijgen van ten minste EUR 7 miljoen of 1,4 procent van de totale wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is.

De praktische les is eenvoudig: als het moment van kennisname, ernstcriteria, escalatie en rapportagebesluiten niet worden vastgelegd, is het probleem niet langer alleen volwassenheid van incidentrespons. Het wordt een probleem rond regelgevend bewijsmateriaal.

Behandel DORA-incidentmanagement als operationele weerbaarheid

DORA verandert de discussie voor financiële entiteiten omdat incidentmanagement onderdeel is van digitale operationele weerbaarheid, niet alleen van security operations.

Article 5 vereist dat het bestuursorgaan het ICT-risicobeheerkader definieert, goedkeurt, bewaakt en daarvoor verantwoordelijk blijft. Article 6 breidt dat kader uit tot een gestructureerd ICT-risicobeheersysteem. Article 17 vereist dat financiële entiteiten een proces voor beheer van ICT-gerelateerde incidenten definiëren, vaststellen en implementeren om ICT-gerelateerde incidenten te detecteren, te beheren en te melden. Het proces moet ICT-gerelateerde incidenten en significante cyberdreigingen registreren, grondoorzaken identificeren en aanpakken, early-warningindicatoren gebruiken, incidenten classificeren op prioriteit, ernst en criticaliteit van getroffen diensten, rollen en verantwoordelijkheden toewijzen, communicatie en escalatie vaststellen, klanten en media informeren waar vereist, ten minste majeure incidenten rapporteren aan het hoger management, het bestuursorgaan informeren en responsprocedures onderhouden om impact te beperken en veilige operaties te herstellen.

Article 18 vereist classificatie op basis van criteria zoals getroffen klanten of tegenpartijen, transacties, reputatie-impact, duur en downtime, geografische spreiding, gegevensverlies dat beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid raakt, criticaliteit van getroffen diensten en economische impact. Article 19 vereist rapportage van majeure ICT-gerelateerde incidenten aan de bevoegde autoriteit, staat vrijwillige melding van significante cyberdreigingen toe en vereist onverwijlde klantmelding wanneer een majeur ICT-gerelateerd incident de financiële belangen van klanten raakt.

Voor Anya’s fintech betekent dit dat de incidentregistratie meer nodig heeft dan een SOC-tijdlijn. Nodig zijn:

• Getroffen dienst en criticaliteit.
• Getroffen klanten, tegenpartijen of transacties.
• Duur van downtime en geografische spreiding.
• Gegevensverlies of impact op integriteit.
• Economische impact.
• Zichtbaarheid voor het bestuursorgaan.
• Besluit over klantmelding.
• Afsluiting van de grondoorzaak.
• Herstel van veilige operaties.
• Betrokkenheid van leveranciers en contractueel bewijsmateriaal.

DORA breidt het incidentverhaal ook uit naar leveranciersmanagement. Articles 28 tot en met 30 vereisen dat financiële entiteiten ICT-risico’s van derde partijen beheren, een register bijhouden van contractuele afspraken voor ICT-diensten, concentratierisico beoordelen, due diligence uitvoeren, contractuele waarborgen borgen, audit- en inspectierechten definiëren, beëindigingsrechten onderhouden en exitstrategieën testen voor kritieke of belangrijke functies. Als het incident een cloudprovider, managed service provider of SaaS-integratie betreft, moet DORA-bewijsmateriaal leveranciersrollen, verplichtingen voor behoud van logboeken, incidentondersteuning, hersteltaken en samenwerking met toezichthouders aantonen.

Integreer GDPR-verantwoordingsplicht voor inbreuken in verband met persoonsgegevens vroegtijdig

GDPR is van toepassing op geautomatiseerde verwerking van persoonsgegevens en op niet-geautomatiseerde verwerking die deel uitmaakt van een bestand. Het kan van toepassing zijn op in de EU gevestigde organisaties en op niet-EU-verwerkingsverantwoordelijken of verwerkers die goederen of diensten aanbieden aan personen in de Unie of hun gedrag monitoren.

Tijdens incidentrespons moet GDPR-analyse beginnen zodra persoonsgegevens mogelijk betrokken zijn. Wachten op de technische grondoorzaak is te laat als de 72-uursklok al loopt.

Het responsteam moet de volgende vragen beantwoorden:

• Welke categorieën persoonsgegevens kunnen betrokken zijn?
• Welke systemen, toepassingen en verwerkingsactiviteiten zijn geraakt?
• Handelt de organisatie als verwerkingsverantwoordelijke, verwerker of beide?
• Zijn persoonsgegevens ingezien, gewijzigd, vernietigd, verloren gegaan of openbaar gemaakt?
• Waren encryptie, tokenisatie of pseudonimisering als waarborgen effectief?
• Wat is het waarschijnlijke risico voor betrokkenen?
• Wie heeft het meldingsbesluit genomen en wanneer?
• Welke communicatie is verstuurd naar verwerkingsverantwoordelijken, verwerkers, toezichthoudende autoriteiten of betrokkenen?
• Als geen melding is gedaan, wat was de gedocumenteerde motivering?

Verantwoordingsplicht onder GDPR Article 5 is de kern. De verwerkingsverantwoordelijke moet kunnen aantonen dat beginselen zoals rechtmatigheid, behoorlijkheid, transparantie, doelbinding, gegevensminimalisatie, opslagbeperking, integriteit en vertrouwelijkheid worden nageleefd. Dat betekent dat het inbreukenregister, het beslislogboek, technisch bewijsmateriaal en de communicatiehistorie onderdeel zijn van het privacybeheersingssysteem, niet van bijzaken na remediatie.

Bewaar bewijsmateriaal voordat herstel het vernietigt

Een terugkerend falen in incidentrespons is herstel dat bewijsmateriaal vernietigt. Systemen worden opnieuw opgestart. Malware wordt verwijderd. Logboeken roteren. Accounts worden gewijzigd voordat snapshots zijn gemaakt. Vanuit beschikbaarheidsperspectief kan het team succesvol lijken. Vanuit audit-, toezichthouder-, verzekeraar- of juridisch perspectief kan de organisatie het vermogen zijn kwijtgeraakt om aan te tonen wat er is gebeurd.

Clarysec’s Beleid inzake bewijsverzameling en forensisch onderzoek stelt:

Een chain-of-custody-logboek moet alle fysieke of digitale bewijsmaterialen begeleiden vanaf het moment van verwerving tot en met archivering of overdracht en moet documenteren:

Voor het mkb begint het Beleid inzake bewijsverzameling en forensisch onderzoek voor het mkb de eis voor het bewijslogboek duidelijk:

Elk item digitaal bewijsmateriaal moet worden gelogd met:

De Zenith Blueprint, fase Controls in Action, stap 23, licht het principe achter ISO/IEC 27002:2022-beheersmaatregel 5.28 toe:

Wanneer een informatiebeveiligingsincident plaatsvindt, is een van de meest kritieke, maar vaak over het hoofd geziene elementen van de respons bewijsmateriaal. Geen logboeken, geen schermafbeeldingen, geen losse verhalen, maar correct bewaard, chain-of-custody-respecterend en manipulatiebestendig bewijsmateriaal. Beheersmaatregel 5.28 erkent dat na een incident wat u kunt bewijzen net zo belangrijk is als wat er daadwerkelijk is gebeurd.

Een bewijsdossier dat gereed is voor toezichthouders voor Anya’s incident moet het volgende omvatten:

Bewaring van logboeken moet expliciet zijn. Clarysec’s Beleid voor logging en monitoring voor het mkb stelt:

Beveiligingslogboeken die betrekking hebben op incidenten moeten ten minste 3 jaar vanaf de datum van het incident worden bewaard

De Zenith Blueprint, fase Controls in Action, stap 19, voegt de operationele waarheid toe:

Logging is de levensader van elke veilige IT-omgeving. Zonder logging blijven incidenten onzichtbaar, vervaagt verantwoordingsplicht en verdwijnen oorzaak-gevolgrelaties in het niets.

Incidentrespons, logging, bewijsverzameling en rapportage moeten daarom als één verbonden beheersingssysteem worden ontworpen.

Voer de eerste 72 uur uit als een sprint voor bewijsmateriaal

Een praktische 72-uurssprint voor bewijsmateriaal helpt teams reageren zonder auditeerbaarheid te verliezen.

Uur 0 tot 1: verklaren, classificeren en bewaren

Open het incidentticket op basis van het Incidentresponsbeleid. Wijs een incident commander, technisch verantwoordelijke, communicatieverantwoordelijke, juridisch of privacyverantwoordelijke, leverancierscoördinator en eigenaar van bewijsmateriaal toe.

Gebruik de éénuursclassificatie-eis uit het Incidentresponsbeleid voor het mkb als controlepunt, ook in grotere organisaties. Pas het gelaagde raamwerk voor enterprise-respons toe en leg onzekerheid vast wanneer feiten onvolledig zijn.

Bewaar vluchtig bewijsmateriaal onmiddellijk: identiteitslogboeken, EDR-waarschuwingen, cloud-audittrails, registraties van geprivilegieerde toegang, logboeken van getroffen systemen, back-upstatus, configuratiewijzigingen en relevante tickethistorie. Start het chain-of-custody-logboek op basis van het Beleid inzake bewijsverzameling en forensisch onderzoek.

Besluitoutputs:

• Tijdstip van incidentverklaring.
• Initiële ernst.
• Vermoedelijk getroffen diensten.
• Vermoedelijk getroffen gegevens.
• Initiële regelgevende watchlist, inclusief GDPR, NIS2, DORA en contractuele verplichtingen.
• Hiaten in bewijsmateriaal en toegewezen eigenaren.

Uur 1 tot 24: impact- en early-warninganalyse

Stel het eerste impactbeeld op. Bepaal of de gebeurtenis de dienstverlening heeft geraakt, operationele verstoring of financieel verlies heeft veroorzaakt of kan veroorzaken, anderen heeft geraakt of materiële of immateriële schade heeft gecreëerd. Dit ondersteunt de analyse van een significant incident onder NIS2.

Classificeer voor financiële entiteiten aan de hand van DORA-criteria: getroffen klanten, transacties, reputatie, downtime, geografische spreiding, gegevensverlies, criticaliteit en economische impact.

Bepaal voor GDPR of persoonsgegevens betrokken waren en of er waarschijnlijk risico bestaat voor betrokkenen.

Besluitoutputs:

• Besluit over vroegtijdige waarschuwing onder NIS2.
• Watchstatus voor majeur incident onder DORA.
• Beoordelingsstatus van inbreuk in verband met persoonsgegevens onder GDPR.
• Watch voor melding aan klanten, cliënten of verwerkingsverantwoordelijken.
• Update aan het bestuursorgaan.
• Verzoeken om leveranciersbewijsmateriaal.

Uur 24 tot 72: bereid bewijsmateriaal voor meldingen op toezichthouderniveau voor

Als NIS2 van toepassing is, bereid dan de 72-uursupdate voor incidentmelding voor met voorlopige ernst, impact en indicatoren van compromittering indien beschikbaar. Als GDPR-melding vereist is, zorg dan dat het pakket voor de toezichthoudende autoriteit weergeeft wat bekend is, wat nog onbekend is, welke gevolgen waarschijnlijk zijn en welke maatregelen zijn genomen of voorgesteld. Als DORA van toepassing is, bereid dan de vereiste initiële of tussentijdse rapportage voor via het proces van de bevoegde autoriteit.

Besluitoutputs:

• Bijgewerkte incidenttijdlijn.
• Hypothese over de grondoorzaak.
• Indammings- en uitroeiingsacties.
• Bewijsmateriaal van herstel van dienstverlening.
• Meldingspakket voor toezichthouder.
• Communicatie met klanten of cliënten.
• Bijgewerkte inventaris van bewijsmateriaal.

Deze sprint is geen papierwerk omwille van papierwerk. Hij voorkomt dat het responsteam bewijsmateriaal opoffert terwijl operaties worden hersteld.

Cross-frameworkmapping: één workflow, meerdere afnemers van bewijsmateriaal

Een volwassen incidentresponsprogramma produceert bewijsmateriaal één keer en hergebruikt het in meerdere raamwerken.

De ISO-naar-NIST-responsmapping is bijzonder nuttig voor auditors.

Governance van de toeleveringsketen moet ook worden opgenomen. NIST CSF 2.0 GV.SC behandelt processen voor risico’s in de toeleveringsketen, leveranciersrollen, prioritering op basis van criticaliteit, contractuele eisen, due diligence, doorlopende monitoring, opname van leveranciers in incidentplanning en activiteiten bij beëindiging van de relatie. Dat sluit rechtstreeks aan op beveiliging van de toeleveringsketen onder NIS2, ICT-risicomanagement van derde partijen onder DORA en leveranciersmaatregelen uit ISO/IEC 27001:2022.

Hoe verschillende auditors hetzelfde incident toetsen

Een auditor voor ISO/IEC 27001:2022 begint bij het ISMS. Deze vraagt of incidentmanagement binnen de scope valt, of verplichtingen van belanghebbenden zijn gedocumenteerd, of incidentrisico’s zijn beoordeeld, of A.5.24 tot en met A.5.28 zijn opgenomen in de Verklaring van Toepasselijkheid, of het proces volgens plan is uitgevoerd en of het incident geleerde lessen, corrigerende maatregelen en voortdurende verbetering heeft opgeleverd.

Een NIST-georiënteerde beoordelaar richt zich op resultaten van CSF 2.0. Deze toetst governance, zichtbaarheid van bedrijfsmiddelen, monitoring, incidentverklaring, triage, escalatie, integriteit van bewijsmateriaal, communicatie met stakeholders, indamming, uitroeiing, herstel en updates van profielen.

Een toezichthoudende beoordeling onder NIS2 richt zich op managementverantwoordelijkheid, risicobeheersmaatregelen onder Article 21 en rapportage onder Article 23. Bewijsmateriaal van het besluit over vroegtijdige waarschuwing binnen 24 uur, inhoud van de 72-uursmelding, tussentijdse rapportages en het eindrapport staat centraal. De beoordelaar kan ook bedrijfscontinuïteit, beveiliging van de toeleveringsketen, toegangscontrole, training, cryptografie en effectiviteitsbeoordeling onderzoeken.

Een DORA-toezichthouder richt zich op operationele weerbaarheid. Deze verwacht criteria voor incidentclassificatie, registraties van ICT-gerelateerde incidenten en significante cyberdreigingen, early-warningindicatoren, escalatie naar hoger management, zichtbaarheid voor het bestuursorgaan, klantmelding waar financiële belangen zijn geraakt, afsluiting van de grondoorzaak, herstel van veilige operaties en leveranciersbewijsmateriaal.

Een toezichthoudende autoriteit onder GDPR richt zich op verantwoordingsplicht rond inbreuken in verband met persoonsgegevens. Deze vraagt wanneer de organisatie kennis kreeg, welke persoonsgegevens waren geraakt, of de organisatie verwerkingsverantwoordelijke of verwerker was, welk risico voor betrokkenen bestond, welke maatregelen zijn genomen, waarom wel of niet is gemeld en of het interne inbreukenregister volledig is.

Een auditor in COBIT- of ISACA-stijl toetst governancedoelstellingen, managementpraktijken, eigenaarschap, metrieken en assurancebewijsmateriaal. Deze wil weten of incidentrespons wordt bestuurd, gemeten, verbeterd en afgestemd op ondernemingsdoelstellingen.

Hetzelfde incident kan al deze beoordelingen ondersteunen als de workflow is ontworpen rond gedeeld bewijsmateriaal in plaats van gescheiden compliancemappen.

Test de mapping met een deadlinegedreven tabletop-oefening

De snelste manier om te leren of de mapping werkt, is een tabletop-oefening die is opgebouwd rond rapportagetermijnen.

Gebruik dit scenario: een geprivilegieerd account van een engineer is gecompromitteerd. De aanvaller opent een productiedatabase, exporteert een onbekende hoeveelheid registraties, wijzigt een configuratie-instelling die een gedeeltelijke uitval veroorzaakt voor EU-klanten en gebruikt een API-token dat via een integratie met een derde partij is uitgegeven.

Voer de oefening uit in vier rondes.

Ronde één: detectie en verklaring. Kan het team de bron van de waarschuwing identificeren, het incident verklaren, de ernst binnen één uur classificeren, logboeken bewaren en rollen toewijzen?

Ronde twee: impact. Kan het team getroffen diensten, getroffen gegevens, getroffen klanten, leveranciersbetrokkenheid, downtime, geografische spreiding en de vraag of het incident financiële belangen of persoonsgegevens raakt identificeren?

Ronde drie: rapportage. Worden de vroegtijdige waarschuwing onder NIS2, de 72-uursmelding onder NIS2, DORA-rapportage, GDPR-melding en contractuele klantmeldingen geactiveerd? Kan het team zowel meldings- als niet-meldingsbesluiten documenteren?

Ronde vier: herstel en afsluiting. Zijn indamming, uitroeiing, herstel, back-upvalidatie, communicatie, geleerde lessen en corrigerende maatregelen gedocumenteerd?

De output mag geen slidedeck zijn. Het moet een bewijsdossier zijn: ingevuld incidentticket, tijdlijn, beslislogboek, communicatielogboek, lijst met bewaard bewijsmateriaal, beslismatrix voor toezichthouders, registratie van leverancierscommunicatie, herstelvalidatieregistratie en plan voor corrigerende maatregelen.

De oefening is niet klaar wanneer mensen uitleggen wat zij zouden doen. Zij is klaar wanneer zij de registraties produceren waar een auditor om zou vragen.

Veelvoorkomende faalpatronen die vóór de volgende waarschuwing moeten worden verwijderd

Het eerste faalpatroon is een ongedefinieerd moment van kennisname. Als niemand vastlegt wanneer de organisatie kennis kreeg, wordt timinganalyse onder NIS2, DORA en GDPR risicovol.

Het tweede is ernst zonder criteria. Labels zoals medium of hoog zijn zwak tenzij zij zijn gekoppeld aan impact op dienstverlening, gegevensimpact, financiële impact, klantimpact of regelgevende drempels.

Het derde is privacy die te laat wordt toegevoegd. GDPR-beoordeling moet beginnen zodra persoonsgegevens mogelijk betrokken zijn, niet nadat de grondoorzaak volledig is vastgesteld.

Het vierde is onduidelijkheid over leveranciers. Als een cloudprovider, managed service provider of SaaS-integratie betrokken is, moeten contracten en draaiboeken definiëren wie logboeken bewaart, wie communiceert, wie forensisch onderzoek ondersteunt en wie helpt bij verzoeken van toezichthouders.

Het vijfde is vernietiging van bewijsmateriaal tijdens herstel. Herstarts, verwijderingen en configuratiewijzigingen kunnen noodzakelijk zijn, maar moeten waar haalbaar worden gecoördineerd met behoud van bewijsmateriaal.

Het zesde is geleerde lessen zonder risicobehandeling. ISO/IEC 27001:2022 verwacht verbetering waar passend. Een lessons-learnedbijeenkomst zonder wijziging van beheersmaatregelen, eigenaar, vervaldatum of herbeoordeling van risico levert zwak bewijsmateriaal op.

Verander incidentrespons in een cross-compliance bewijssysteem

Voorbereiding op verwachtingen voor incidentrespons volgens NIST SP 800-61 en audits in 2026 moet niet beginnen met nog een losstaand draaiboek. Zij moet beginnen met mapping van besluitvorming.

Clarysec kan uw team helpen om:

• Een Current Profile en Target Profile voor incidentrespons volgens NIST CSF 2.0 op te bouwen.
• Incidentrespons af te stemmen op clausules van ISO/IEC 27001:2022, risicobehandeling en beheersmaatregelen uit Annex A.
• Bewijsvereisten van NIS2 voor 24 uur, 72 uur en één maand in workflows in te bedden.
• Incidentclassificatie onder DORA, rapportage aan het bestuursorgaan, klantmelding en ICT-leveranciersbewijsmateriaal te mappen.
• Analyse van inbreuken in verband met persoonsgegevens onder GDPR en verantwoordingsregistraties te integreren.
• Clarysec’s Incidentresponsbeleid, Incidentresponsbeleid voor het mkb, Beleid inzake bewijsverzameling en forensisch onderzoek, Beleid inzake bewijsverzameling en forensisch onderzoek voor het mkb, Beleid voor logging en monitoring voor het mkb, Zenith Blueprint en Zenith Controls te implementeren in een operationeel model dat met tabletop-oefeningen is gevalideerd.

De vraag voor 2026 is niet of uw team een aanval kan indammen. De vraag is of uw team de respons kan classificeren, escaleren, rapporteren, herstellen en aantonen over NIST, ISO/IEC 27001:2022, NIS2, DORA en GDPR heen.

Clarysec’s 30-stappenimplementatiemodel en cross-compliance toolkit zijn gebouwd om dat mogelijk te maken vóór de volgende waarschuwing op dinsdagochtend. Download de relevante Clarysec-beleidsdocumenten, voer een deadlinegedreven tabletop-oefening uit en vraag een Clarysec-beoordeling aan om uw incidentresponsplan om te zetten in een auditgereed bewijssysteem.