Voorbereiding op de EU Cyber Solidarity Act met ISO 27001

Het incident van 03:17 dat EU-samenwerking tot uw auditvraagstuk maakt

Om 03:17 op een dinsdagochtend kijkt Maria, de CISO van InnovateCloud, naar een scherm vol waarschuwingen. Haar organisatie is een middelgrote Europese SaaS-aanbieder die logistieke klanten in Duitsland, Frankrijk en Polen bedient. De eerste waarschuwing wijst op verdachte geprivilegieerde toegang in een productietenant. Tien minuten later meldt de managed security service provider vergelijkbare activiteit bij twee andere klanten. Om 04:00 ziet het SOC API-aanroepen vanaf infrastructuur die eerder in verband is gebracht met ransomware-staging.

InnovateCloud was niet het oorspronkelijke doelwit. Een kernleverancier van infrastructuur lijkt binnen de blast radius te vallen. De impact is nu echter Maria’s probleem.

Eén getroffen klant is een Duitse bank die onder DORA om antwoorden vraagt. Een andere klant is een kritieke leverancier in de energiesector die al onder nationale NIS2-regels is geclassificeerd. De omgeving kan persoonsgegevens bevatten, maar exfiltratie is nog niet bevestigd. Het beveiligingsteam wil de dreiging onmiddellijk indammen. Juridische Zaken wil weten of de NIS2-termijn voor de vroege waarschuwing van 24 uur is gaan lopen. De privacyverantwoordelijke vraagt of een GDPR-melding van een inbreuk mogelijk is. Het bestuur wil weten of de uitval zich over lidstaten kan verspreiden.

In 2026 is dit niet langer alleen een interne crisis.

De EU Cyber Solidarity Act verandert de operationele realiteit voor grootschalige en grensoverschrijdende cyberincidenten. De verordening introduceert mechanismen voor detectie, paraatheid en respons op EU-niveau, waaronder het European Cybersecurity Alert System, het Cybersecurity Emergency Mechanism en de EU Cybersecurity Reserve. Zelfs wanneer een organisatie nooit rechtstreeks ondersteuning uit de reserve aanvraagt, kunnen haar bewijs, contactpersonen bij autoriteiten, leverancierscontracten, incidenttijdlijnen en klantcommunicatie onderdeel worden van een bredere Europese responsketen.

Het hiaat wordt snel zichtbaar. Veel organisaties hebben tools, tickets en beleid, maar geen bewijs dat toetsing door toezichthouders doorstaat. Zij kunnen zeggen: “wij hebben contact opgenomen met de toezichthouder”, maar niet aantonen wie daartoe bevoegd was, welke drempel het contact activeerde, wat is gecommuniceerd, of logboeken zijn veiliggesteld, of een leverancier contractueel verplicht was mee te werken, of dat een eindrapport kan worden gereconstrueerd op basis van gelijktijdig vastgelegde besluiten.

Het antwoord is niet nóg een afzonderlijke “Cyber Solidarity Act-map”. Het antwoord is een ISO/IEC 27001:2022-managementsysteem voor informatiebeveiliging (ISMS) dat bewijs één keer produceert en hergebruikt voor verwachtingen vanuit NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019.

Dat bewijs ontstaat vóór het incident.

Waarom de EU Cyber Solidarity Act de bewijsstandaard verhoogt

De Cyber Solidarity Act is ontworpen voor cyberdetectie, paraatheid en crisisrespons op EU-niveau. Het praktische effect voor CISO’s, auditors en compliance managers is duidelijk: coördinatie bij grootschalige incidenten vereist bewijs dat sneller, schoner, consistenter en eenvoudiger met vertrouwde stakeholders te delen is.

Wanneer grensoverschrijdende impact mogelijk is, moet een organisatie mogelijk afstemmen met nationale CSIRT’s, bevoegde autoriteiten, sectorale toezichthouders, gegevensbeschermingsautoriteiten, financiële toezichthouders, opsporingsinstanties, klanten, verwerkers, leveranciers en externe incidentresponders. De EU Cybersecurity Reserve voegt daar een extra dimensie aan toe, omdat vooraf beoordeelde private aanbieders ondersteuning kunnen leveren bij paraatheid, respons en herstel. Daardoor worden leveranciersgovernance, juridische bevoegdheid, gegevensverwerking en bewaring van bewijs nog belangrijker.

Private entiteiten staan midden in deze realiteit. Cloudproviders, datacenters, managed service providers, managed security service providers, exploitanten van digitale infrastructuur, fintechs en SaaS-platformen beschikken vaak over de telemetrie, logboeken, klantimpactgegevens en technische feiten die autoriteiten nodig hebben om een majeur incident te begrijpen.

NIS2 wijst al in deze richting. De richtlijn geldt voor veel middelgrote en grote entiteiten in de sectoren van Bijlage I en Bijlage II die diensten leveren of activiteiten uitvoeren in de EU. Daarnaast vallen bepaalde entiteiten er ongeacht omvang onder, waaronder vertrouwensdienstverleners, DNS-dienstverleners, registers voor topleveldomeinen en dienstverleners voor domeinnaamregistratie. Bijlage I omvat digitale infrastructuur zoals cloudcomputingdiensten, datacenterdiensten, content delivery networks, DNS-aanbieders, vertrouwensdienstverleners en TLD-registers. Ook ICT-servicemanagement B2B valt hieronder, inclusief managed service providers en managed security service providers. Bijlage II omvat digitale aanbieders zoals online marktplaatsen, online zoekmachines en platforms voor sociale netwerkdiensten.

DORA voegt een tweede laag toe voor de financiële sector. Sinds 17 januari 2025 is DORA van toepassing op een breed scala aan financiële entiteiten, waaronder kredietinstellingen, betalingsinstellingen, instellingen voor elektronisch geld, beleggingsondernemingen, aanbieders van cryptoactivadiensten, handelsplatformen, verzekerings- en herverzekeringsondernemingen, kredietbeoordelaars, crowdfundingdienstverleners en andere entiteiten. DORA creëert ook aanzienlijke verwachtingen voor derde aanbieders van ICT-diensten, omdat financiële entiteiten verantwoordelijk blijven voor uitbestede ICT-diensten.

Een fintech-incident in 2026 kan daarom via DORA-toezichtkanalen worden gecoördineerd, terwijl de SaaS-aanbieder of MSSP die deze fintech ondersteunt onder NIS2 kan vallen. Dezelfde technische gebeurtenis kan voor verschillende actoren verschillende rapportageplichten, bewijsverwachtingen en contractuele verplichtingen creëren.

ISO/IEC 27001:2022 geeft organisaties het besturingssysteem om deze complexiteit te beheersen. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie het ISMS in haar bedrijfscontext definieert, belanghebbenden en hun wettelijke, regelgevende en contractuele eisen identificeert, grenzen en afhankelijkheden vastlegt en het managementsysteem inricht. Clausules 5.1 tot en met 5.3 maken het leiderschap verantwoordelijk voor beleid, middelen, integratie en roltoewijzing. Clausules 6.1.1 tot en met 6.1.3 vereisen herhaalbare risicobeoordeling, risicobehandeling en een Verklaring van Toepasselijkheid. Clausule 8.1 vereist operationele beheersing, inclusief beheersing van extern geleverde processen, producten en diensten.

Dit is de kern van voorbereiding op de Cyber Solidarity Act: aantonen dat crisisrespons wordt beheerd, getest en auditeerbaar is, en niet wordt geïmproviseerd.

Het Clarysec-bewijsmodel: één incident, meerdere verplichtingen

Een grensoverschrijdend incident wacht niet totdat juridische teams het hebben geclassificeerd. Bewijs moet vanaf de eerste waarschuwing worden vastgelegd en vervolgens naar de juiste rapportage- en coördinatiepaden worden geleid.

De aanpak van Clarysec verbindt drie assets:

1. Zenith Blueprint: een 30-stappenroadmap voor auditors Zenith Blueprint, waarmee de implementatie van ISO/IEC 27001:2022 wordt omgezet in een gefaseerd traject dat klaar is voor audits.
2. Zenith Controls: de gids voor cross-compliance Zenith Controls, die ISO/IEC 27002:2022-beheersmaatregelen koppelt aan gerelateerde beheersmaatregelen, attributen, operationele capabilities, beveiligingsdomeinen en bewijsverwachtingen over raamwerken heen.
3. Clarysec-beleidssjablonen voor incidentrespons, bewijsverzameling, leveranciersbeveiliging, logging, monitoring en bedrijfscontinuïteit, aangepast voor enterprise- en mkb-omgevingen.

In de fase Controls in Action van de Zenith Blueprint behandelt stap 22 ISO/IEC 27002:2022-beheersmaatregel 5.5, contact met autoriteiten. Daarin staat:

Beheersmaatregel 5.5 zorgt ervoor dat een organisatie is voorbereid op interactie met externe autoriteiten wanneer dat nodig is, niet reactief of in paniek, maar via vooraf gedefinieerde, gestructureerde en goed begrepen kanalen.

Dezelfde sectie stelt de vraag die elke CISO vóór de crisis moet beantwoorden:

als uw organisatie doelwit zou zijn van een cyberaanval, betrokken zou zijn bij een datalek, of onderwerp van onderzoek zou zijn, wie zou dan contact opnemen met de autoriteiten? Hoe zouden zij weten wat zij moeten zeggen? Onder welke voorwaarden zou dergelijk contact worden gestart?

Dat is geen administratief papierwerk. In een Cyber Solidarity Act-omgeving is dit het verschil tussen een beheerste vroege waarschuwing en tegenstrijdige boodschappen over jurisdicties heen.

Zenith Controls behandelt ISO/IEC 27002:2022-beheersmaatregel 5.5, contact met autoriteiten, als preventief en corrigerend, gekoppeld aan vertrouwelijkheid, integriteit en beschikbaarheid, en afgestemd op de concepten Identify, Protect, Respond en Recover. De gids verbindt 5.5 met incidentbeheerplanning en voorbereiding, gebeurtenisrapportage, Threat Intelligence, special interest groups en respons op incidenten.

Dezelfde gids behandelt ISO/IEC 27002:2022-beheersmaatregel 5.24, planning en voorbereiding van informatiebeveiligingsincidentbeheer, als een corrigerende beheersmaatregel die is gekoppeld aan Respond en Recover. De relaties met gebeurtenisbeoordeling, incidentrespons, geleerde lessen, logging, monitoring, beveiliging tijdens verstoring en continuïteit laten zien wat auditors vaak toetsen: of uw plan detectie, classificatie, escalatie, bewijs, herstel en leren met elkaar verbindt.

Voor bewijsbehandeling is ISO/IEC 27002:2022-beheersmaatregel 5.28, verzameling van bewijsmateriaal, bijzonder belangrijk. Zenith Controls verbindt deze met incidentrespons, logging, monitoring en gebeurtenisrapportage. Bij een ernstig grensoverschrijdend incident wordt technisch onderzoek hiermee verdedigbaar.

Voorbereiding op de Cyber Solidarity Act mappen op ISO 27001-bewijs

De EU Cyber Solidarity Act creëert een omgeving voor paraatheid en coördinatie. ISO/IEC 27001:2022 levert de bewijsmotor. NIS2, DORA en GDPR definiëren veel specifieke verwachtingen voor rapportage, governance en bescherming.

Let op wat ontbreekt: een afzonderlijke nalevingssilo. Hetzelfde bewijs dat ISO/IEC 27001:2022-certificering ondersteunt, kan ook managementverantwoordelijkheid onder NIS2, ICT-risicomanagement onder DORA, verantwoordingsplicht voor beveiliging onder GDPR, communicatie-uitkomsten binnen NIST CSF en assuranceverwachtingen binnen COBIT 2019 ondersteunen.

NIS2: de rapportagetermijn start zodra bewustwording ontstaat

NIS2 staat centraal in voorbereiding op 2026, omdat de richtlijn een gefaseerde workflow voor incidentrapportage definieert.

Article 23 vereist dat essentiële en belangrijke entiteiten hun CSIRT of bevoegde autoriteit zonder onnodige vertraging in kennis stellen van significante incidenten die de dienstverlening beïnvloeden. De vroege waarschuwing moet zonder onnodige vertraging en uiterlijk 24 uur nadat men zich bewust is geworden van het significante incident worden ingediend. Waar van toepassing moet zij aangeven of kwaadwillige of onrechtmatige handelingen worden vermoed en of grensoverschrijdende impact mogelijk is.

Een incidentmelding volgt zonder onnodige vertraging en uiterlijk 72 uur na bewustwording, waarbij de vroege waarschuwing wordt bijgewerkt en een initiële beoordeling van ernst, impact en beschikbare indicatoren van compromittering wordt verstrekt. Een eindrapport is verschuldigd binnen één maand na de incidentmelding, met ernst, impact, waarschijnlijk dreigingstype of hoofdoorzaak, risicobeperkende maatregelen en grensoverschrijdende impact.

Daarom kan incidentrespons niet beginnen met een leeg document.

Het enterprise-Incidentresponsbeleid Incidentresponsbeleid stelt:

NIS2 Article 23 (melding binnen 24 uur nadat men zich bewust is geworden van het incident)

Het mkb-Incidentresponsbeleid - mkb Incidentresponsbeleid - mkb brengt dezelfde tijdlijnlogica in praktische governance:

“Responstermijnen, inclusief gegevensherstel en meldingsverplichtingen, moeten worden gedocumenteerd en afgestemd op wettelijke eisen, zoals de GDPR-verplichting om een inbreuk in verband met persoonsgegevens binnen 72 uur te melden.”

Uit Incidentresponsbeleid - mkb, sectie “Governancevereisten”, clausule 5.3.2.

Het dwingt ook de beoordeling over meerdere regimes heen af in het incidentproces:

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

Uit Incidentresponsbeleid - mkb, sectie “Risicobehandeling en uitzonderingen”, clausule 7.4.1.

In een Cyber Solidarity Act-scenario wordt “grensoverschrijdende impact is mogelijk” operationeel belangrijk. De vroege waarschuwing hoeft nog geen volledige feiten te bevatten, maar de organisatie moet kunnen aantonen waarom zij grensoverschrijdende impact op basis van beschikbaar bewijs wel of niet vermoedde.

De incidentregistratie moet vastleggen:

• Wanneer de organisatie zich bewust werd van het incident.
• Wie de gebeurtenis als potentieel incident heeft aangemerkt.
• Welke diensten, landen, klanten of sectoren mogelijk zijn getroffen.
• Of kwaadwillige of onrechtmatige activiteit werd vermoed.
• Welke indicatoren van compromittering beschikbaar waren.
• Welk contactpad naar de autoriteit is gebruikt.
• Of klantcommunicatie vereist was.
• Welk bewijs vóór majeure herstelmaatregelen is veiliggesteld.

Het beste moment om deze velden te ontwerpen is vóór 03:17.

DORA: wanneer de klant gereguleerd is, maar de leverancier de logboeken bezit

DORA verandert het leveranciersgesprek. Financiële entiteiten moeten ICT-risico’s van derden beheren als onderdeel van hun ICT-risicobeheerkader. Uitbesteding van ICT-diensten verplaatst de regelgevende verantwoordelijkheid niet weg van de financiële entiteit.

DORA vereist strategieën voor ICT-risico’s van derden, registers van ICT-dienstverleningscontracten, due diligence, audit- en inspectieplanning, beëindigingsrechten en geteste exitstrategieën voor kritieke of belangrijke ICT-diensten. Article 30 vereist contractuele duidelijkheid, inclusief dienstbeschrijvingen, locaties, gegevensverwerking, vertrouwelijkheid, integriteit, beschikbaarheid, serviceniveaus, ondersteuning tijdens ICT-incidenten, samenwerking met autoriteiten en beëindigingsrechten. Voor kritieke of belangrijke functies gelden strengere voorwaarden.

Keer terug naar Maria’s incident. De Duitse bank valt onder DORA. InnovateCloud levert SaaS-diensten. De MSSP detecteert verdachte activiteit. De cloudinfrastructuurprovider beschikt over enkele van de belangrijkste auditlogboeken. Een subcontractor beheert een deel van de telemetriepijplijn. De bank blijft verantwoordelijk, maar kan niet goed classificeren en rapporteren zonder leveranciersbewijs.

Clarysec adresseert dit via leveranciersclassificatie en contractueel bewijs. Het enterprise-beleid voor derde partijen en leveranciersbeveiliging beleid voor derde partijen en leveranciersbeveiliging vereist:

Contracten met leveranciers moeten bevatten:

Het mkb-beleid voor derde partijen en leveranciersbeveiliging - mkb beleid voor derde partijen en leveranciersbeveiliging - mkb gebruikt dezelfde nalevingslogica in een lichter operationeel model:

Contracten moeten verplichte clausules bevatten over:

De waarde zit in het schema achter die woorden: verplichtingen voor incidentmelding, toegang tot logboeken, auditrechten, vertrouwelijkheid, gegevenslocatie, beheersmaatregelen voor subcontractors, samenwerking met autoriteiten, herstelondersteuning en exitverplichtingen.

De fase Controls in Action van de Zenith Blueprint, stap 23, geeft de implementatieroute:

Stel een volledige lijst op van huidige leveranciers en dienstverleners (5.19), en classificeer deze op basis van toegang tot systemen, gegevens of operationele controle. Verifieer voor elke geclassificeerde leverancier dat beveiligings- verwachtingen duidelijk in contracten zijn opgenomen (5.20), inclusief vertrouwelijkheid, toegang, incidentrapportage en nalevingsverplichtingen.

De tekst gaat verder met downstreamrisico:

Identificeer voor elke kritieke leverancier of deze subcontractors (subverwerkers) gebruikt die toegang kunnen hebben tot uw gegevens of systemen. Documenteer hoe uw informatiebeveiligingseisen worden doorgelegd aan deze partijen, hetzij via de contractvoorwaarden van uw leverancier, hetzij via uw eigen rechtstreekse clausules.

Dit is ook voorbereiding op de Cybersecurity Reserve. Als een externe responsaanbieder tijdens een noodsituatie uw omgeving betreedt, moet u de rechtsgrondslag, toegangsreikwijdte, regels voor bewijs, verplichtingen inzake gegevensverwerking, het coördinatiepad met autoriteiten en exitvoorwaarden kennen. DORA maakt dit expliciet voor financiële entiteiten. NIS2 maakt het relevant voor essentiële en belangrijke entiteiten. ISO/IEC 27001:2022 maakt het auditeerbaar.

GDPR: de vraag naar een inbreuk binnen de cybercrisis

Niet elk cyberbeveiligingsincident is een inbreuk in verband met persoonsgegevens, maar elk ernstig incident moet op die mogelijkheid worden beoordeeld.

GDPR is van toepassing op verwerking in het kader van een vestiging in de EU, en ook op niet-EU-verwerkingsverantwoordelijken of verwerkers die goederen of diensten aanbieden aan personen in de EU of hun gedrag in de EU monitoren. GDPR definieert persoonsgegevens, verwerking, verwerkingsverantwoordelijke, verwerker en inbreuk in verband met persoonsgegevens. De beginselen omvatten integriteit, vertrouwelijkheid en verantwoordingsplicht, wat betekent dat verwerkingsverantwoordelijken naleving moeten kunnen aantonen.

Tijdens het incident van 03:17 moet Maria’s team vragen:

• Zijn persoonsgegevens geraadpleegd, verstrekt, gewijzigd, verloren gegaan of vernietigd?
• Is InnovateCloud verwerkingsverantwoordelijke, verwerker of beide voor de getroffen gegevens?
• Zijn bijzondere categorieën persoonsgegevens betrokken?
• Welke klanten of personen zijn getroffen?
• Zijn logboeken voldoende om de reikwijdte te beoordelen?
• Lopen GDPR-meldingsplichten parallel aan NIS2- of DORA-plichten?

Daarom hoort privacycoördinatie thuis in incidentescalatie, niet in een late juridische toets nadat systemen opnieuw zijn opgebouwd en logboeken zijn geroteerd.

Het mkb-Beleid voor logging en monitoring - mkb Beleid voor logging en monitoring - mkb stelt:

Waarschuwingen met hoge prioriteit moeten binnen 24 uur worden geëscaleerd naar de algemeen directeur en de privacycoördinator

Die clausule is eenvoudig, maar lost een reëel faalpatroon op. Privacyverantwoordelijken hebben bewijs nodig terwijl het nog vers genoeg is om te bepalen of een inbreuk in verband met persoonsgegevens heeft plaatsgevonden en of betrokkenen risico lopen.

Bouw een 24-uurs bewijspakket voor grensoverschrijdende incidenten

Een praktische voorbereidingsoefening moet de eerste 24 uur van een grensoverschrijdend incident simuleren. Het doel is niet om te veel te rapporteren. Het doel is aan te tonen dat de organisatie feiten kan verzamelen, verdedigbare besluiten kan nemen en communicatie consistent kan houden.

Scenario

Uw MSSP detecteert verdachte geprivilegieerde toegang vanuit een ongebruikelijke regio tot uw productietenant. Dezelfde broninfrastructuur verschijnt in waarschuwingen bij twee klanten in twee lidstaten. Eén klant is een financiële entiteit. De getroffen omgeving bevat persoonsgegevens, maar exfiltratie is niet bevestigd.

Stap 1: Open de incidentregistratie

Maak het incidentticket aan met goedgekeurde classificatievelden. Neem bewustwordingstijd, detectiebron, getroffen assets, getroffen diensten, mogelijk getroffen landen, vermoede kwaadwillige activiteit, initiële ernst en incident commander op.

Koppel dit aan ISO/IEC 27002:2022-beheersmaatregelen 5.24, 5.25 en 5.26, en aan ISO/IEC 27001:2022 Bijlage A-beheersmaatregelen A.5.24, A.5.25 en A.5.26.

Stap 2: Activeer de besluitvormingsworkflow voor autoriteiten

Gebruik de contactmatrix voor autoriteiten die door Zenith Blueprint stap 22 wordt vereist. Identificeer welke autoriteiten relevant kunnen zijn: nationale CSIRT, gegevensbeschermingsautoriteit, financiële toezichthouder, opsporingsinstanties en sectorale toezichthouder.

Leg het besluit en de onderbouwing vast. Als geen NIS2-vroege waarschuwing wordt gedaan, leg vast waarom. Als grensoverschrijdende impact mogelijk is, registreer het bewijs dat die conclusie ondersteunt.

Stap 3: Stel bewijs veilig vóór majeure herstelmaatregelen

Het enterprise-Beleid inzake bewijsverzameling en forensisch onderzoek Beleid inzake bewijsverzameling en forensisch onderzoek stelt:

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

Het mkb-Beleid inzake bewijsverzameling en forensisch onderzoek - mkb Beleid inzake bewijsverzameling en forensisch onderzoek - mkb geeft dezelfde discipline in eenvoudiger vorm:

“Elk item van digitaal bewijsmateriaal moet worden gelogd met:”

Uit Beleid inzake bewijsverzameling en forensisch onderzoek - mkb, sectie “Governancevereisten”, clausule 5.2.1.

Verzamel voor de tabletop-oefening voorbeelditems van bewijs: SIEM-waarschuwingsexport, logboeken van identity providers, registraties van geprivilegieerde sessies, endpointmomentopname, firewalllogboeken, cloudauditlogboeken, notities over klantimpact en communicatiegoedkeuringen.

Stap 4: Activeer leveranciersondersteuning

Controleer het leveranciersregister. Identificeer de MSSP, cloudprovider en kritieke subcontractors. Bevestig clausules voor incidentondersteuning, escalatiecontacten, logretentieperioden, bewijsformaat en verplichtingen tot samenwerking met autoriteiten.

Dit ondersteunt rechtstreeks de DORA-vereisten voor ICT-risico’s van derden en de NIS2-verwachtingen voor beveiliging van de toeleveringsketen.

Stap 5: Stel drie communicaties op

Stel drie communicaties op vanuit dezelfde feitenbasis:

Stap 6: Sluit af met geleerde lessen

Werk het risicoregister, de Verklaring van Toepasselijkheid, het leveranciersregister en het incidentresponsplan bij. Als de oefening ontbrekende logboeken, onduidelijke autoriteitscontacten of zwakke leveranciersclausules aan het licht brengt, registreer corrigerende maatregelen.

De fase Controls in Action van de Zenith Blueprint, stap 23, instrueert organisaties om incidentcapabilities als volgt te valideren:

Selecteer een recente gebeurtenis of voer een tabletop-oefening uit om uw plan te valideren. Leg alle besluiten, rollen en communicatie vast en log deze (5.26), en werk het plan bij met geleerde lessen (5.27). Bevestig dat procedures aanwezig zijn om forensisch bewijsmateriaal veilig te stellen (5.28), inclusief logmomentopnamen, back-ups, en veilige isolatie van getroffen systemen.

Die alinea is een auditklare oefenagenda.

Logging: het verschil tussen coördinatie en speculatie

Coördinatie van grensoverschrijdende incidenten faalt wanneer iedereen meningen heeft en niemand tijdstempels.

De fase Controls in Action van de Zenith Blueprint, stap 19, zegt het helder:

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

De tekst gaat verder:

In de kern gaat logging over traceerbaarheid. Wanneer er iets misgaat, of het nu een mislukte inlogpoging is, de verwijdering van kritieke bestanden, of een rogue script dat op een server draait, leveren logboeken de forensische draad die helpt te ontwarren wat er werkelijk is gebeurd.

Voor NIS2 ondersteunen logboeken de incidentmelding binnen 72 uur met initiële ernst, impact en indicatoren van compromittering. Voor DORA ondersteunen logboeken de classificatie van majeure ICT-gerelateerde incidenten, oorzaakanalyse, operationele impact en verantwoordingsplicht van derden. Voor GDPR ondersteunen logboeken de beoordeling of persoonsgegevens zijn geraadpleegd of verstrekt. In een Cyber Solidarity Act-context ondersteunen logboeken gedeeld situationeel inzicht zonder dat responders op speculatie hoeven te vertrouwen.

Als het antwoord op een vraag “niet zeker” is, hoort het punt thuis in het risicobehandelingsplan.

Bedrijfscontinuïteit en beveiligde crisisoperaties

Het gesprek over de Cyber Solidarity Act richt zich vanzelf op incidentrespons, maar weerbaarheid betekent ook dat kritieke diensten tijdens verstoring beveiligd blijven functioneren.

NIS2 Article 21 vereist een all-hazards-benadering die incidentenafhandeling, bedrijfscontinuïteit, back-upbeheer, herstel na verstoringen, crisismanagement, beveiliging van de toeleveringsketen, kwetsbaarhedenafhandeling, effectiviteitsbeoordeling, cyberhygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen, multifactorauthenticatie, beveiligde communicatie en waar passend beveiligde noodcommunicatie omvat.

DORA vereist op vergelijkbare wijze governance, ICT-risicomanagement, incidentbeheer, weerbaarheidstesten, risicobeheer van derden, continuïteit en herstel. Kleinere entiteiten kunnen vereenvoudigde eisen hebben, maar hebben nog steeds gedocumenteerd ICT-risicomanagement, monitoring, weerbare systemen, incidentenafhandeling, identificatie van afhankelijkheden van derden, back-ups, herstel, testen, leren na incidenten en training nodig.

Het enterprise-Bedrijfscontinuïteitsbeleid en beleid voor herstel na verstoringen Bedrijfscontinuïteitsbeleid en beleid voor herstel na verstoringen begint met een eenvoudige eis:

Plannen moeten omvatten:

Achter die zin staat het continuïteitsbewijs dat auditors verwachten: herstelprioriteiten, hersteltijddoelstellingen, herstelpuntdoelstellingen, back-upschema’s, hersteltests, crisisrollen, alternatieve communicatie, leveranciersafhankelijkheden en verbeteracties na oefeningen.

ISO/IEC 27002:2022-beheersmaatregelen 5.29 en 5.30 staan hierbij centraal. Beheersmaatregel 5.29 behandelt informatiebeveiliging tijdens verstoring. Beheersmaatregel 5.30 behandelt ICT-gereedheid voor bedrijfscontinuïteit. In Zenith Controls is incidentplanning onder 5.24 gekoppeld aan beveiliging tijdens verstoring en bredere continuïteitsplanning. Dit is vooral relevant wanneer normale kanalen niet beschikbaar zijn, identiteitssystemen gedegradeerd zijn of crisisteams via beveiligde noodcommunicatie met autoriteiten moeten coördineren.

Cross-compliancekaart: NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019

Een CISO heeft geen vijf afzonderlijke incidentprogramma’s nodig. Er is één bewijsmodel nodig dat door vijf lenzen kan worden bekeken.

De Current en Target Profile-methode van NIST CSF 2.0 is vooral nuttig voor organisaties die nog niet volwassen genoeg zijn voor een volledig geïntegreerd GRC-platform. De methode stimuleert organisaties om een profiel af te bakenen, input te verzamelen zoals beleid, prioriteiten uit enterprise risk, business impactanalyses, eisen, normen, procedures, beveiligingsmaatregelen en rollen, vervolgens hiaten te analyseren en een geprioriteerd actieplan op te stellen. Dat ligt dicht bij een praktische voorbereiding op de Cyber Solidarity Act: huidig bewijs, doelverplichtingen, hiatenplan, eigenaren, datums en audittrail.

COBIT 2019- en ISACA-achtige auditors vragen doorgaans of governancedoelstellingen zijn toegewezen, gemeten en bewaakt. Zij nemen geen genoegen met “het SOC handelt dit af”. Zij vragen hoe bestuursorganen risicomaatregelen goedkeuren, hoe prestaties worden gerapporteerd, hoe risico’s van derden worden bestuurd, hoe uitzonderingen worden geaccepteerd en hoe corrigerende maatregelen worden gevolgd.

Hoe auditors hetzelfde incident zullen toetsen

Hetzelfde incident van 03:17 levert verschillende auditvragen op, afhankelijk van de opdracht van de beoordelaar.

Een ISO/IEC 27001:2022-auditor begint bij het ISMS. Hij of zij vraagt of het incidentproces binnen het toepassingsgebied valt, of eisen van belanghebbenden NIS2, DORA, GDPR en contracten omvatten, of de risicobeoordeling grensoverschrijdende en leveranciersscenario’s heeft meegenomen, of Bijlage A-beheersmaatregelen zijn geselecteerd in de Verklaring van Toepasselijkheid, en of operationele registraties aantonen dat het proces is gevolgd.

Een op NIS2 gerichte autoriteit of beoordelaar richt zich op managementverantwoordelijkheid, risicobeheersmaatregelen onder Article 21 en rapportage onder Article 23. Zij kunnen vragen wanneer de organisatie zich bewust werd van het incident, waarom het incident wel of niet significant was, hoe grensoverschrijdende impact is beoordeeld, of klanten zijn geïnformeerd en of corrigerende maatregelen zonder onnodige vertraging zijn genomen.

Een DORA-toezichthouder of intern auditteam vraagt of het incident kritieke of belangrijke functies heeft geraakt, of derde ICT-aanbieders de respons hebben ondersteund, of de financiële entiteit verantwoordelijk bleef, of het informatieregister nauwkeurig was, of het incident correct is geclassificeerd en of geleerde lessen zijn teruggekoppeld naar weerbaarheidstesten en leverancierstoezicht.

Een GDPR-auditor of gegevensbeschermingsautoriteit vraagt of de organisatie voldoende bewijs had om te bepalen of persoonsgegevens zijn geschonden, of rollen van verwerkingsverantwoordelijke en verwerker duidelijk waren, of betrokkenen risico liepen, of vertrouwelijkheids- en integriteitsbeheersmaatregelen passend waren en of verantwoordingsregistraties zijn bijgehouden.

Een NIST CSF 2.0-beoordelaar vertaalt de gebeurtenis naar uitkomsten voor Govern, Identify, Protect, Detect, Respond en Recover. Deze beoordelaar zoekt naar stakeholderverwachtingen, wettelijke verplichtingen, risicobereidheid, leveranciersgovernance, logging, monitoring, uitvoering van respons, communicatie en herstelvalidatie.

Een COBIT 2019- of ISACA-auditor richt zich op de effectiviteit van governance en het managementsysteem: eigenaarschap, beslissingsrechten, metrieken, risicoacceptatie, procesprestaties, assurance en continue verbetering.

Hier is Zenith Controls nuttig als cross-compliancekompas. Het hernoemt officiële beheersmaatregelen niet en creëert geen parallel beheersraamwerk. Het laat zien hoe ISO/IEC 27002:2022-beheersmaatregelen zoals 5.5, 5.24 en 5.28 verbonden zijn met operationele capabilities, gerelateerde beheersmaatregelen en auditrelevant bewijs.

Wat CISO’s nu moeten doen voor voorbereiding in 2026

Als u zich voorbereidt op de operationele realiteit van de EU Cyber Solidarity Act, begin dan met bewijs, niet met slogans.

Werk eerst uw ISMS-context en analyse van belanghebbenden bij. Bepaal of uw organisatie, klanten of leveranciers onder NIS2, DORA of GDPR vallen. Neem de voetafdruk per lidstaat, sectorclassificatie, kritieke klanten, afhankelijkheden van ICT-diensten en contactpersonen bij autoriteiten op.

Voer ten tweede een tabletop-oefening voor een grensoverschrijdend incident uit. Gebruik een scenario met een leverancier, meer dan één lidstaat, mogelijke blootstelling van persoonsgegevens en een gereguleerde financiële klant. Begrens de eerste 24 uur in de tijd.

Beoordeel ten derde leverancierscontracten. Bevestig meldingsplichten, toegang tot logboeken, forensische ondersteuning, samenwerking met autoriteiten, doorlegverplichtingen naar subcontractors, gegevenslocatie, auditrechten, continuïteitsondersteuning en beëindigingsrechten.

Test ten vierde bewijsverzameling. Exporteer logboeken, bewaar momentopnamen, label bewijs, registreer chain-of-custody en valideer toegang tot de repository. Als uw beleid zegt dat bewijs uniek wordt geïdentificeerd en veilig wordt opgeslagen, toon dat dan aan.

Stem ten vijfde incidentcommunicatie op elkaar af. Uw NIS2-vroege waarschuwing, DORA-escalatie, GDPR-beoordeling van een inbreuk en klantmelding mogen elkaar niet tegenspreken. Zij kunnen verschillende juridische doelen hebben, maar moeten uit dezelfde feitenbasis voortkomen.

Maak ten zesde het bestuur onderdeel van de oefening. NIS2 en DORA verhogen beide de managementverantwoordelijkheid. De leiderschapsclausules van ISO/IEC 27001:2022 maken dit auditeerbaar. Een bestuur dat nog nooit een cybermeldingstermijn van 24 uur heeft gezien, is niet voorbereid op een grensoverschrijdende crisis.

Volgende stappen met Clarysec

De toekomst van EU-cyberbeveiliging draait om samenwerking en aantoonbaar vertrouwen. Organisaties die NIS2 en DORA als geïsoleerde checklists behandelen, zullen moeite hebben tijdens grensoverschrijdende incidenten. Organisaties die op bewijs gebaseerde ISO/IEC 27001:2022-besturingssystemen bouwen, kunnen toezichthouders, klanten, auditors en crisisresponders met vertrouwen antwoorden.

Clarysec helpt CISO’s, compliance managers, auditors en bedrijfseigenaren om EU-cyberregelgeving om te zetten in operationeel bewijs dat geschikt is voor audits via:

• Zenith Blueprint: een 30-stappenroadmap voor auditors voor gestructureerde ISO/IEC 27001:2022-implementatie en auditfasering.
• Zenith Controls: de gids voor cross-compliance voor het mappen van beheersmaatregelen voor incidenten, autoriteiten, leveranciers, bewijs, logging en continuïteit over raamwerken heen.
• Clarysec-beleidssjablonen, waaronder Incidentresponsbeleid, Beleid inzake bewijsverzameling en forensisch onderzoek, beleid voor derde partijen en leveranciersbeveiliging, Bedrijfscontinuïteitsbeleid en beleid voor herstel na verstoringen, plus mkb-versies waar proportionaliteit belangrijk is.

Het beste moment om u voor te bereiden op coördinatie van grensoverschrijdende incidenten is vóór de waarschuwing van 03:17. Het op één na beste moment is vandaag.

Begin met een Clarysec-gereedheidsbeoordeling, download de relevante beleidstoolkit of vraag een walkthrough aan van hoe Zenith Blueprint en Zenith Controls uw ISMS kunnen helpen het bewijs te produceren dat cyberweerbaarheid in 2026 zal vereisen.