Bewijsmapping voor NIS2 met ISO 27001:2022 in 2026

Het NIS2-probleem van 2026 is geen bewustwording, maar bewijs
Het is maandagochtend, 08:35. Maria, de onlangs aangestelde CISO van een snelgroeiende B2B-aanbieder van cloud- en managed services, neemt deel aan de kwartaalvergadering van het bestuur over risico’s. Op haar laptop staat een omvangrijke NIS2-gap-analyse open. De eerste dia oogt geruststellend. Er is beleid. Er is een risicobeoordeling. Incidentrespons is gedocumenteerd. Leveranciers zijn vastgelegd. Kwetsbaarheidsscans draaien maandelijks.
Dan stelt de voorzitter de vraag die de vergadering kantelt:
“Kunnen we aantonen dat deze maatregelen vorig kwartaal hebben gewerkt, en kunnen we laten zien welke ISO 27001:2022-beheersmaatregelen, eigenaren en registraties elke NIS2-verplichting ondersteunen?”
Het wordt stil in de zaal.
Juridische Zaken weet dat het bedrijf binnen de reikwijdte van NIS2 valt omdat het beheerde ICT- en clouddiensten aan EU-klanten levert. Compliance weet dat Article 21 technische, operationele en organisatorische maatregelen voor cyberbeveiligingsrisicobeheer vereist. Operations weet dat het team systemen patcht, leveranciers beoordeelt en logboeken monitort. Maar het bewijsmateriaal is verspreid over ticketsystemen, SIEM-exporten, beleidsmappen, spreadsheets, cloudconsoles, leveranciersportalen en vergadernotities.
Niemand kan snel een verdedigbare keten tonen van NIS2 Article 21 naar ISO 27001:2022-toepassingsgebied, risico, beheersmaatregel, beleid, eigenaar, procedure, operationele registratie en auditbevinding.
Dat is de echte uitdaging voor 2026.
Veel organisaties vragen niet langer: “Vallen wij binnen de NIS2-reikwijdte?” Ze stellen een moeilijkere vraag: “Kunnen we aantonen dat onze technische NIS2-maatregelen daadwerkelijk werken?” Het antwoord kan geen eenmalige mapping in een spreadsheet zijn. Het moet een levend operationeel model binnen het Informatiebeveiligingsmanagementsysteem zijn, waarin wettelijke verplichtingen worden vertaald naar risico’s, beleid, beheersmaatregelen, eigenaren, bewijsmateriaal en voortdurende verbetering.
Het model van Clarysec gebruikt ISO/IEC 27001:2022 als ruggengraat van het managementsysteem, NIS2 Article 21 als set van wettelijke verplichtingen, beleidsclausules als operationeel regelboek, Zenith Blueprint: een 30-stappenroadmap voor auditors als implementatieroute en Zenith Controls: de integrale compliancegids als mapping voor geïntegreerde compliance met ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF en assurance in COBIT-stijl.
Begin met het toepassingsgebied, want NIS2-bewijsmateriaal begint vóór beheersmaatregelen
Een veelvoorkomende NIS2-fout is direct beginnen met MFA, logging, incidentrespons en kwetsbaarhedenbeheer voordat het toepassingsgebied van de entiteit, de dienstverlening en de jurisdictie is bevestigd.
NIS2 geldt voor aangewezen publieke en private entiteiten in gereguleerde sectoren die aan omvangs- en activiteitencriteria voldoen, waarbij bepaalde typen entiteiten ongeacht omvang binnen de reikwijdte vallen. Relevante digitale en ICT-categorieën zijn onder meer cloudcomputingdienstverleners, datacentrumdienstverleners, aanbieders van content delivery networks, vertrouwensdienstverleners, aanbieders van openbare elektronische communicatiediensten, aanbieders van beheerde diensten, aanbieders van beheerde beveiligingsdiensten, online marktplaatsen, online zoekmachines en socialenetwerkplatforms.
Voor cloudproviders, SaaS-platformen, MSP’s, MSSP’s en aanbieders van digitale infrastructuur is dit scopingwerk niet theoretisch. Article 3 verplicht lidstaten onderscheid te maken tussen essentiële en belangrijke entiteiten. Article 27 verplicht ENISA een register bij te houden voor verschillende digitale en ICT-aanbieders, waaronder DNS-dienstverleners, TLD-naamregisters, domeinnaamregistratiedienstverleners, cloudcomputingdienstverleners, datacentrumdienstverleners, aanbieders van content delivery networks, aanbieders van beheerde diensten, aanbieders van beheerde beveiligingsdiensten, online marktplaatsen, online zoekmachines en socialenetwerkplatforms.
ISO 27001:2022 biedt de juiste structuur. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie externe en interne onderwerpen, belanghebbenden, eisen, interfaces en afhankelijkheden begrijpt en vervolgens het ISMS-toepassingsgebied definieert. NIS2 moet hier worden vastgelegd en mag niet in een juridische memo blijven staan.
Een praktische NIS2-scopingregistratie moet het volgende bevatten:
- Analyse van juridische entiteit en EU-vestiging
- NIS2-sector en dienstencategorie
- Status als essentiële of belangrijke entiteit, waar bevestigd door nationale wetgeving of aanwijzing door een autoriteit
- Relevantie voor het ENISA-register, waar van toepassing
- Kritieke diensten die aan klanten worden geleverd
- Netwerk- en informatiesystemen die deze diensten ondersteunen
- Afhankelijkheden van cloud-, datacentrum-, telecom-, beveiligingsmonitoring-, identiteits- en softwareleveranciers
- Koppelingen met DORA, GDPR, klantcontracten en sectorspecifieke verplichtingen
- Bewaarlocaties voor bewijsmateriaal, systeemeigenaren en beoordelingsfrequentie
Hier moet DORA ook correct worden onderscheiden. NIS2 erkent dat wanneer een sectorspecifieke EU-rechtshandeling gelijkwaardige verplichtingen voor cyberbeveiligingsrisicobeheer of incidentmelding oplegt, dat sectorspecifieke regime van toepassing is in plaats van de overeenkomstige NIS2-bepalingen. Voor onder DORA vallende financiële entiteiten is DORA doorgaans het leidende regime voor cyberbeveiliging en ICT-incidentrapportage. DORA is van toepassing sinds 17 januari 2025 en omvat ICT-risicobeheer, incidentmelding, testen van digitale operationele weerbaarheid, ICT-risico’s van derde partijen en toezicht op kritieke ICT-dienstverleners van derde partijen.
Een fintechgroep kan daardoor binnen één concernstructuur verschillende compliancebehandelingen hebben. De betalingsentiteit kan primair onder DORA vallen. De MSP-dochter kan rechtstreeks onder NIS2 vallen. Een gedeeld cloudplatform kan beide ondersteunen. Het volwassen antwoord is niet het dupliceren van beheersmaatregelen. Het is één ISMS-bewijsmodel dat meerdere regelgevende invalshoeken kan bedienen.
ISO 27001:2022 als operationeel systeem voor NIS2-naleving
NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen om risico’s voor netwerk- en informatiesystemen te beheren en de impact van incidenten op afnemers van diensten en andere diensten te voorkomen of te minimaliseren.
ISO 27001:2022 is zeer geschikt om die eis te operationaliseren, omdat de norm drie disciplines afdwingt.
Ten eerste governance. Clausules 5.1 tot en met 5.3 vereisen betrokkenheid van topmanagement, afstemming op de strategische richting, middelen, communicatie, toewijzing van verantwoordelijkheden en een gedocumenteerd informatiebeveiligingsbeleid. Dit sluit rechtstreeks aan op NIS2 Article 20, dat bestuursorganen verplicht maatregelen voor cyberbeveiligingsrisicobeheer goed te keuren, toe te zien op de implementatie en training te ontvangen.
Ten tweede risicobehandeling. Clausules 6.1.1 tot en met 6.1.3 vereisen een herhaalbaar risicobeoordelingsproces, risico-eigenaren, risico-evaluatie, behandelopties, selectie van beheersmaatregelen, een Verklaring van Toepasselijkheid, een risicobehandelingsplan en goedkeuring van restrisico.
Ten derde operationele beheersing. Clausule 8.1 vereist dat de organisatie ISMS-processen plant, implementeert en beheerst, gedocumenteerde informatie onderhoudt, wijzigingen beheerst en extern geleverde processen, producten en diensten beheert die relevant zijn voor het ISMS.
Dit verandert NIS2 van een juridische checklist in een operationeel model voor beheersmaatregelen.
| Maatregelgebied van NIS2 Article 21 | Operationeel mechanisme in ISO 27001:2022 | Belangrijke ISO 27001:2022 Annex A-beheersmaatregelen | Bewijsmateriaal dat werking aantoont |
|---|---|---|---|
| Risicoanalyse en beveiligingsbeleid | ISMS-toepassingsgebied, risicobeoordeling, risicobehandelingsplan, Verklaring van Toepasselijkheid, beleidskader | 5.1 Policies for information security, 5.31 Legal, statutory, regulatory and contractual requirements, 5.36 Compliance with policies, rules and standards for information security | Risicoregister, SoA, beleidsgoedkeuringen, complianceverplichtingenregister, notulen van directiebeoordelingen |
| Incidentafhandeling | Incidentresponsproces, triage, escalatie, communicatie, geleerde lessen | 5.24 Incident management planning and preparation, 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents, 5.27 Learning from information security incidents, 5.28 Collection of evidence | Incidentregister, tijdlijnen, besluiten, meldingen, oorzaakanalyse, corrigerende maatregelen |
| Bedrijfscontinuïteit en crisismanagement | Bedrijfsimpactanalyse, back-upbeheer, herstel na verstoringen, crisisdraaiboeken, oefeningen | 5.29 Information security during disruption, 5.30 ICT readiness for business continuity, 8.13 Information backup | Resultaten van back-uptests, rapportages van hersteltests, registraties van crisisoefeningen, BIA-goedkeuringen |
| Beveiliging van de toeleveringsketen | Due diligence van leveranciers, beveiligingsclausules, monitoring, cloudgovernance, exitplanning | 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.22 Monitoring, review and change management of supplier services, 5.23 Information security for use of cloud services | Leveranciersregister, due-diligenceregistraties, contractuele clausules, monitoringbeoordelingen, exitplannen |
| Veilige verwerving, ontwikkeling en kwetsbaarheidsafhandeling | Veilige SDLC, kwetsbaarheidsscans, patch-SLA’s, workflow voor openbaarmaking | 8.8 Management of technical vulnerabilities, 8.25 Secure development life cycle, 8.26 Application security requirements, 8.28 Secure coding | Scanresultaten, tickets, releasegoedkeuringen, validatiescans, goedkeuringen van uitzonderingen |
| Cyberhygiëne en training | Bewustwordingsprogramma, rolgebaseerde training, regels voor endpoints, beveiligde configuratie, patching | 6.3 Information security awareness, education and training, 8.1 User endpoint devices, 8.5 Secure authentication, 8.8 Management of technical vulnerabilities, 8.9 Configuration management | Trainingsregistraties, phishingresultaten, rapportages over endpointnaleving, patchdashboards |
| Cryptografie, toegangscontrole, MFA en beveiligde communicatie | Cryptografiestandaard, IAM-levenscyclus, geprivilegieerde toegang, veilige authenticatie, netwerkbeveiliging | 5.17 Authentication information, 8.2 Privileged access rights, 8.3 Information access restriction, 8.5 Secure authentication, 8.20 Networks security, 8.24 Use of cryptography | Toegangsrechtenbeoordelingen, MFA-rapportages, encryptie-instellingen, logboeken van geprivilegieerde toegang, netwerkconfiguratieregistraties |
| Beoordeling van doeltreffendheid van beheersmaatregelen | Interne audit, toetsing van beheersmaatregelen, metrieken, directiebeoordeling, corrigerende maatregelen | 5.35 Independent review of information security, 5.36 Compliance with policies, rules and standards for information security | Interne-auditrapporten, steekproeven van beheersmaatregelen, non-conformiteiten, opvolging van corrigerende maatregelen |
Elke rij heeft een eigenaar, een registratiebron en een steekproefmethode nodig. Als die ontbreken, heeft de organisatie een ambitie voor een beheersmaatregel, geen beheersmaatregel.
Beleid is waar NIS2 operationeel gedrag wordt
Beleid wordt vaak behandeld als sjabloonmateriaal. Voor NIS2 is dat riskant. Een toezichthouder of auditor raakt niet overtuigd door een beleidsmap als het beleid geen eigenaarschap toewijst, registraties definieert, aan risico’s koppelt en bewijsmateriaal oplevert.
Het enterprise Beleid inzake juridische en regelgevende naleving legt de basis in clausule 6.2.1:
Alle wettelijke en regelgevende verplichtingen moeten binnen het Informatiebeveiligingsmanagementsysteem (ISMS) worden gekoppeld aan specifieke beleidsregels, beheersmaatregelen en eigenaren.
Die clausule vormt de brug tussen NIS2 en ISO 27001:2022. NIS2 Article 21 wordt niet alleen als externe eis opgenomen. Het wordt ontleed in beleidsverplichtingen, gekoppeld aan beheersmaatregelen, toegewezen aan eigenaren en getoetst met bewijsmateriaal.
Voor kleinere organisaties houdt het mkb Beleid inzake juridische en regelgevende naleving hetzelfde concept lichtgewicht. Clausule 5.1.1 vereist:
De algemeen directeur moet een eenvoudig, gestructureerd complianceverplichtingenregister bijhouden met daarin:
De zin is bewust praktisch. Mkb-organisaties hebben geen complexe GRC-implementatie nodig om te beginnen. Ze hebben een complianceverplichtingenregister nodig dat verplichting, toepasselijkheid, eigenaar, beleid, bewijsmateriaal en beoordelingsfrequentie vastlegt.
Risicobehandeling zet de verplichting vervolgens om in actie. Het enterprise Beleid inzake risicobeheer, clausule 6.4.2, bepaalt:
De Risicofunctionaris moet ervoor zorgen dat behandelingen realistisch en tijdgebonden zijn en zijn gekoppeld aan beheersmaatregelen uit ISO/IEC 27001 Annex A.
Voor mkb-organisaties geeft het Beleid inzake risicobeheer - mkb, clausule 5.1.2, de minimaal werkbare risicoregistratie:
Elke risicovermelding moet bevatten: beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan.
Deze clausules zijn belangrijk omdat NIS2 expliciet risicogebaseerd en evenredig is. Article 21 verwacht dat maatregelen aansluiten bij de stand van de techniek, relevante normen, implementatiekosten, risicoblootstelling, omvang, waarschijnlijkheid en ernst van incidenten, inclusief maatschappelijke en economische impact. Een risicoregister zonder eigenaren en behandelplannen kan evenredigheid niet aantonen.
Het enterprise Informatiebeveiligingsbeleid voltooit het bewijsprincipe in clausule 6.6.1:
Alle geïmplementeerde beheersmaatregelen moeten auditeerbaar zijn en worden ondersteund door gedocumenteerde procedures en bewaard bewijsmateriaal van werking.
Dat is het verschil tussen een NIS2-programma hebben en een NIS2-bewijsprogramma hebben.
De Clarysec-route van mapping naar werking
De Zenith Blueprint is waardevol omdat deze weerspiegelt hoe auditors denken. Zij vragen niet alleen of een beheersmaatregel bestaat. Zij vragen waarom deze is geselecteerd, waar deze is gedocumenteerd, hoe deze werkt, wie eigenaar is, welk bewijsmateriaal de werking aantoont en hoe de organisatie verbetert.
In de fase Risicobeheer vraagt stap 13 teams om traceerbaarheid tussen risico’s, beheersmaatregelen en clausules toe te voegen:
✓ Koppel beheersmaatregelen aan risico’s: in het behandelplan van uw risicoregister hebt u voor elk risico bepaalde beheersmaatregelen opgenomen. U kunt aan elk risico een kolom “Annex A Control Reference” toevoegen en daarin de nummers van de beheersmaatregelen opnemen.
Voor NIS2 betekent dit dat het risicoregister en de Verklaring van Toepasselijkheid moeten laten zien waarom beheersmaatregelen zoals 8.8 Management of technical vulnerabilities, 5.19 Information security in supplier relationships en 5.24 Incident management planning and preparation van toepassing zijn.
Stap 14 van de Zenith Blueprint maakt de wettelijke mapping expliciet:
Voor elke regelgeving kunt u, indien van toepassing, een eenvoudige mappingtabel maken, bijvoorbeeld als bijlage bij een rapport, waarin de belangrijkste beveiligingseisen van de regelgeving en de bijbehorende beheersmaatregelen/beleidsregels in uw ISMS staan.
Dit voorkomt versnippering. GDPR-beveiliging van persoonsgegevens, NIS2-incidentmelding, DORA-testen van ICT-weerbaarheid en beveiligingstoezeggingen aan klanten kunnen allemaal steunen op hetzelfde bewijsmateriaal: toegangsrechtenbeoordelingen, herstel van kwetsbaarheden, logregistraties, back-uptests, leveranciersbeoordelingen en incidentrapportages.
Stap 19 verplaatst de aandacht van ontwerp naar werking:
Koppel elk van deze documenten aan de passende beheersmaatregel in uw SoA of ISMS-handboek. Deze documenten dienen als bewijs van implementatie en als interne referentie.
De documentatieset van stap 19 omvat endpointbeveiliging, toegangsbeheer, authenticatie, baselineconfiguraties voor veilige configuratie, logging en monitoring, patchbeheer, kwetsbaarhedenbeheer, capaciteitsplanning en rapportage over IT-operaties. Dit zijn precies de operationele documenten die nodig zijn om technische NIS2-maatregelen auditeerbaar te maken.
Stap 26 legt uit hoe auditbewijsmateriaal moet worden verzameld:
Terwijl u bewijsmateriaal verzamelt, legt u uw bevindingen vast. Noteer waar zaken voldoen aan de eis (positieve bevindingen) en waar dat niet het geval is (mogelijke non-conformiteiten of observaties).
Voor NIS2 betekent dit dat bewijsmateriaal steekproefsgewijs wordt beoordeeld voordat een toezichthouder, klantbeoordelaar of certificeringsauditor erom vraagt.
De rol van Zenith Controls in geïntegreerde compliance
Zenith Controls is geen afzonderlijk beheersmaatregelenkader. Het is de gids van Clarysec voor geïntegreerde compliance waarmee ISO/IEC 27001:2022- en ISO/IEC 27002:2022-beheersmaatregelen worden gekoppeld aan gerelateerde beheersmaatregelen, auditverwachtingen en externe kaders. Het helpt teams begrijpen hoe één ISO 27001:2022-beheersmaatregel NIS2, DORA, GDPR, NIST CSF 2.0 en assurance in COBIT-stijl kan ondersteunen.
Drie ISO 27001:2022-beheersmaatregelen zijn bijzonder belangrijk voor NIS2-bewijsmapping.
Beheersmaatregel 5.1 Policies for information security is het startpunt, omdat NIS2 Article 21 risicoanalyse en beleid voor de beveiliging van informatiesystemen omvat. Als een technische NIS2-maatregel niet in beleid is verwerkt, is deze moeilijk te besturen en lastig consequent te auditen.
Beheersmaatregel 5.36 Compliance with policies, rules and standards for information security is de realiteitstoets. Deze verbindt beleidseisen met daadwerkelijke conformiteit aan interne regels, normen en externe verplichtingen. In NIS2-termen is dit de plek waar een organisatie vraagt of zij doet wat haar Article 21-mapping zegt dat zij doet.
Beheersmaatregel 8.8 Management of technical vulnerabilities is een van de moeilijkste testgebieden voor 2026. Kwetsbaarhedenbeheer is rechtstreeks relevant voor veilige verwerving, ontwikkeling, onderhoud, kwetsbaarheidsafhandeling en openbaarmaking. Het ondersteunt ook DORA-testen en herstelmaatregelen, GDPR-verantwoordingsplicht voor beveiliging, NIST CSF Identify- en Protect-resultaten en ISO 27001-auditsteekproeven.
Ondersteunende normen kunnen het ontwerp aanscherpen zonder aanvullende certificeringen te vereisen. ISO/IEC 27002:2022 biedt implementatierichtsnoeren voor Annex A-beheersmaatregelen. ISO/IEC 27005 ondersteunt informatiebeveiligingsrisicomanagement. ISO/IEC 27017 ondersteunt cloudbeveiliging. ISO/IEC 27018 ondersteunt de bescherming van persoonlijk identificeerbare informatie in scenario’s met publieke cloudverwerkers. ISO 22301 ondersteunt bedrijfscontinuïteit. ISO/IEC 27035 ondersteunt incidentbeheer. ISO/IEC 27036 ondersteunt beveiliging van leveranciersrelaties.
Het doel is niet meer normen om de normen zelf. Het doel is beter bewijsontwerp.
Praktijkvoorbeeld: bouw een NIS2-bewijspakket voor kwetsbaarheden
Neem Maria’s SaaS-platform. Het bedient EU-productiebedrijven en is afhankelijk van in de cloud gehoste diensten, open-sourcecomponenten, CI/CD-pijplijnen en beheerde monitoring. Haar gaprapport vermeldt “kwetsbaarhedenbeheer geïmplementeerd”, maar het bewijsmateriaal is verspreid over scanners, Jira, GitHub, tools voor cloudconfiguratie en wijzigingstickets.
Een NIS2-gereed bewijspakket kan in één gerichte sprint worden opgebouwd.
Stap 1: Definieer het risicoscenario
Risico: een exploiteerbare kwetsbaarheid in een vanaf internet bereikbare toepassing, afhankelijkheid of cloudcomponent veroorzaakt een verstoring van dienstverlening, ongeautoriseerde toegang of blootstelling van klantgegevens.
Het risicoregister moet beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan bevatten. Het behandelplan moet verwijzen naar ISO 27001:2022-beheersmaatregel 8.8 Management of technical vulnerabilities, plus gerelateerde beheersmaatregelen voor inventaris van bedrijfsmiddelen, veilige ontwikkeling, logging, toegangscontrole, leveranciersmanagement en incidentrespons.
Stap 2: Koppel het risico aan NIS2 Article 21
Het risico ondersteunt Article 21-eisen voor veilige verwerving, ontwikkeling en onderhoud, kwetsbaarheidsafhandeling en openbaarmaking, risicoanalyse, incidentafhandeling, beveiliging van de toeleveringsketen en beoordeling van doeltreffendheid van beheersmaatregelen.
Stap 3: Veranker de operationele regels in beleid
Gebruik een procedure voor kwetsbaarhedenbeheer, een standaard voor veilige ontwikkeling, eisen voor patchbeheer, een beleid voor beveiligingstesten en regels voor auditbewijsmateriaal.
Het enterprise Beleid voor beveiligingstesten en red teaming, clausule 6.1, bepaalt:
Typen tests: het programma voor beveiligingstesten moet minimaal omvatten: (a) kwetsbaarheidsscans, bestaande uit geautomatiseerde wekelijkse of maandelijkse scans van netwerken en toepassingen om bekende kwetsbaarheden te identificeren; (b) penetratietesten, bestaande uit handmatige diepgaande tests van specifieke systemen of toepassingen door deskundige testers om complexe zwaktes te identificeren; en (c) red-teamoefeningen, bestaande uit scenariogebaseerde simulaties van echte aanvallen, inclusief social engineering en andere tactieken, om de detectie- en responscapaciteiten van de organisatie als geheel te testen.
Die clausule creëert een verdedigbare testbaseline. Zij sluit ook aan bij de DORA-verwachting voor terugkerende, risicogebaseerde tests van digitale operationele weerbaarheid voor onder DORA vallende financiële entiteiten.
Stap 4: Definieer metadata voor bewijsmateriaal
Het Beleid voor audit en toezicht op naleving - mkb, clausule 6.2.3, bepaalt:
Metadata (bijv. wie het heeft verzameld, wanneer en uit welk systeem) moeten worden gedocumenteerd.
Voor kwetsbaarheidsbewijsmateriaal moet het pakket vastleggen:
- Naam en configuratie van de scanner
- Scandatum en -tijd
- Assetscope en uitsluitingen
- Kritieke en hoge bevindingen
- Ticketnummer en eigenaar
- Patch- of mitigatiebesluit
- Besluit tot risicoacceptatie, waar van toepassing
- Hersteldatum
- Validatiescan
- Koppeling naar wijzigingsregistratie
- Eigenaar van de uitzondering en vervaldatum
Stap 5: Voeg loggingbewijsmateriaal toe
Het Beleid voor logging en monitoring - mkb, clausule 5.4.4, omvat systeemlogboeken zoals:
Systeemlogboeken: configuratiewijzigingen, beheerdershandelingen, software-installaties, patchactiviteiten
Een patchticket alleen toont mogelijk niet aan dat de wijziging daadwerkelijk heeft plaatsgevonden. Configuratielogboeken, beheerdershandelingen en software-installatieregistraties versterken de bewijsketen.
Stap 6: Voer een steekproefaudit uit
Selecteer vijf kritieke of hoge kwetsbaarheden uit het vorige kwartaal. Verifieer voor elk item dat het bedrijfsmiddel in de inventaris stond, de scanner de bevinding detecteerde, binnen de SLA een ticket werd geopend, een eigenaar werd toegewezen, herstel aansloot op ernst en exploiteerbaarheid, logboeken de wijziging tonen, validatie afsluiting bevestigt en elke uitzondering is goedgekeurd door de risico-eigenaar met een vervaldatum.
Die sprint levert een NIS2-gereed bewijspakket voor kwetsbaarheden en een ISO 27001:2022-interne-auditsteekproef op.
Leveranciersbeveiliging is ecosysteemgovernance
NIS2 Article 21 vereist beveiliging van de toeleveringsketen, inclusief beveiligingsaspecten van relaties met directe leveranciers en dienstverleners. Ook verwacht NIS2 dat organisaties rekening houden met kwetsbaarheden van leveranciers, productkwaliteit, cyberbeveiligingspraktijken van leveranciers en veilige ontwikkelpraktijken.
Hier was de eerste versie van Maria’s gaprapport het zwakst. Het vermeldde leveranciers, maar toonde geen due diligence, contractuele beveiligingsclausules, monitoring of exitgereedheid aan.
Het Beleid voor derde partijen en leveranciersbeveiliging biedt de beleidsverankering. Gerelateerde implementatie kan worden ondersteund door het Beleid inzake veilige ontwikkeling, Informatiebeveiligingsbewustzijns- en opleidingsbeleid, Beleid inzake kwetsbaarheden- en patchbeheer, Beleid inzake cryptografische beheersmaatregelen, Beleid inzake toegangscontrole en Beleid inzake werken op afstand.
Eén register voor leveranciersbewijsmateriaal kan NIS2, DORA en ISO 27001:2022 ondersteunen.
| Leveranciersbewijsmateriaal | Relevantie voor NIS2 | Relevantie voor DORA | Relevantie voor ISO 27001:2022 |
|---|---|---|---|
| Criticaliteitsclassificatie van leverancier | Identificeert risico’s van dienstverleners en mogelijke maatschappelijke of economische impact | Ondersteunt analyse van kritieke of belangrijke functies | Ondersteunt risicobehandeling voor leveranciers en selectie van beheersmaatregelen |
| Beveiligings-due diligence | Beoordeelt cyberbeveiligingspraktijken van leveranciers en productrisico | Ondersteunt precontractuele en levenscyclusbeoordeling | Ondersteunt 5.19 Information security in supplier relationships |
| Contractuele beveiligingsclausules | Definieert incidentondersteuning, beveiligingsverplichtingen en meldplichten | Ondersteunt contractuele eisen voor ICT-dienstverleners van derde partijen | Ondersteunt 5.20 Addressing information security within supplier agreements |
| Beoordeling van de ICT-toeleveringsketen | Adresseert afhankelijkheden, software, cloud en onderaannemersrisico | Ondersteunt toezicht op concentratie en uitbesteding | Ondersteunt 5.21 Managing information security in the ICT supply chain |
| Monitoringbeoordeling | Toont doorlopende beoordeling van leveranciersprestaties en beveiliging | Ondersteunt toezicht gedurende de levenscyclus en nauwkeurigheid van het register | Ondersteunt 5.22 Monitoring, review and change management of supplier services |
| Beoordeling van clouddiensten | Adresseert cloudconfiguratie, gedeelde verantwoordelijkheid en weerbaarheid | Ondersteunt toezicht op cloudgerelateerde ICT-diensten | Ondersteunt 5.23 Information security for use of cloud services |
| Exitplan | Vermindert verstoring, lock-in en continuïteitsrisico | Ondersteunt eisen voor exitstrategieën | Ondersteunt exitbeheer voor leveranciers en cloud |
Deze tabel voorkomt dubbele vragenlijsten, dubbele registers en tegenstrijdig eigenaarschap van beheersmaatregelen.
Eén incidentworkflow voor NIS2, DORA en GDPR
NIS2 Article 23 vereist dat significante incidenten zonder onnodige vertraging worden gemeld. Het artikel stelt een gefaseerde tijdlijn vast: een vroege waarschuwing binnen 24 uur na bekendwording, een incidentmelding binnen 72 uur met initiële ernst- of impactbeoordeling en beschikbare indicatoren van compromittering, tussentijdse updates indien gevraagd, en een eindrapport uiterlijk één maand na de incidentmelding.
DORA kent een vergelijkbare levenscyclus voor financiële entiteiten: detectie, classificatie, logging, ernstbeoordeling, escalatie, klantcommunicatie, rapportage aan autoriteiten, oorzaakanalyse en herstelmaatregelen. GDPR voegt analyse van datalekken met persoonsgegevens toe, inclusief rollen van verwerkingsverantwoordelijke en verwerker, impact op betrokkenen en de 72-uurs meldtermijn waar van toepassing.
Het juiste ontwerp bestaat niet uit drie incidentprocessen. Het is één incidentworkflow met beslispaden voor regelgeving.
Het Incidentresponsbeleid - mkb, clausule 5.4.1, bepaalt:
Alle incidentonderzoeken, bevindingen en corrigerende maatregelen moeten worden vastgelegd in een incidentregister dat wordt beheerd door de algemeen directeur.
Een sterk incidentregister moet bevatten:
| Veld | Waarom dit belangrijk is voor NIS2, DORA en GDPR |
|---|---|
| Tijdstempel van bekendwording | Start de analyse voor de vroege waarschuwing en incidentmelding onder NIS2 |
| Impact op dienstverlening | Ondersteunt NIS2-significantie en DORA-criticaliteitsclassificatie |
| Impact op gegevens | Ondersteunt GDPR-analyse van datalekken met persoonsgegevens |
| Getroffen landen en klanten | Ondersteunt grensoverschrijdende beslissingen en besluiten over meldingen aan afnemers |
| Indicatoren van compromittering | Ondersteunt de inhoud van de NIS2-melding binnen 72 uur |
| Oorzaak | Ondersteunt eindrapportage en corrigerende maatregelen |
| Mitigatie- en herstelmaatregelen | Toont operationele beheersing en herstel van dienstverlening |
| Meldingen aan autoriteiten en klanten | Toont meldingsbesluiten en timing aan |
| Geleerde lessen | Voedt voortdurende verbetering volgens ISO 27001:2022 |
De GDPR-koppeling mag niet worden onderschat. NIS2-bevoegde autoriteiten kunnen GDPR-toezichthoudende autoriteiten informeren wanneer tekortkomingen in cyberbeveiligingsrisicobeheer of rapportage kunnen leiden tot een datalek met persoonsgegevens. Het ISMS moet privacybeoordeling daarom onderdeel maken van incidenttriage, niet een latere bijzaak.
Hoe auditors en toezichthouders uw NIS2-bewijsmateriaal toetsen
Een organisatie die klaar is voor 2026 moet verwachten dat dezelfde beheersmaatregel vanuit verschillende invalshoeken wordt getoetst.
Een ISO 27001:2022-auditor begint bij het ISMS. De auditor vraagt of NIS2-verplichtingen zijn geïdentificeerd als eisen van belanghebbenden, of het ISMS-toepassingsgebied relevante diensten en afhankelijkheden omvat, of risico’s zijn beoordeeld en behandeld, of de Verklaring van Toepasselijkheid toepasselijke beheersmaatregelen onderbouwt en of registraties de werking aantonen.
Een NIS2-bevoegde autoriteit richt zich op juridische uitkomsten. Zij kan vragen of alle maatregelen uit Article 21 zijn geadresseerd, of beheersmaatregelen passend en evenredig zijn, of het management de maatregelen heeft goedgekeurd en er toezicht op houdt, en of incidentmelding binnen de vereiste termijnen kan plaatsvinden.
Een DORA-toezichthouder zal bij onder DORA vallende financiële entiteiten ICT-risicobeheer, incidentclassificatie, weerbaarheidstesten, risico’s van derde partijen, contractuele afspraken, concentratierisico en exitstrategieën toetsen.
Een GDPR-beoordelaar toetst of technische en organisatorische maatregelen persoonsgegevens beschermen, of beoordeling van datalekken is ingebed in incidentafhandeling, of rollen van verwerkingsverantwoordelijke en verwerker duidelijk zijn, en of registraties voor verantwoordingsplicht bestaan.
Een beoordelaar in NIST CSF 2.0- of COBIT 2019-stijl richt zich op governance, risico-eigenaarschap, prestatiemetrieken, huidige en beoogde resultaten, procescapaciteit en afstemming op de risicobereidheid van de onderneming.
Het enterprise Beleid voor audit en toezicht op naleving, clausule 3.4, vat het doel van bewijsmateriaal samen:
Het genereren van verdedigbaar bewijsmateriaal en een audittrail ter ondersteuning van verzoeken van toezichthouders, juridische procedures of klantassuranceverzoeken.
Dat is de operationele standaard waar NIS2-teams naartoe moeten werken.
Managementverantwoordelijkheid: het bestuur kan NIS2 niet wegdelegeren
NIS2 Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie en training ontvangen. Leden van bestuursorganen kunnen aansprakelijk worden gehouden voor inbreuken, met inachtneming van nationale aansprakelijkheidsregels.
Dit sluit aan bij de leiderschapseisen van ISO 27001:2022. Topmanagement moet ervoor zorgen dat het informatiebeveiligingsbeleid en de doelstellingen zijn afgestemd op de strategische richting, ISMS-eisen worden geïntegreerd in bedrijfsprocessen, middelen worden verstrekt, het belang wordt gecommuniceerd, verantwoordelijkheden worden toegewezen en voortdurende verbetering wordt bevorderd.
Een bestuur heeft geen ruwe scannerexporten of volledige SIEM-logboeken nodig. Het heeft assurance nodig op besluitvormingsniveau.
Een kwartaalpakket met NIS2-bewijsmateriaal voor het bestuur moet bevatten:
- Wijzigingen in toepassingsgebied en regelgevende status
- Belangrijkste NIS2-risico’s en behandelstatus
- Dashboard voor doeltreffendheid van beheersmaatregelen onder Article 21
- Significante incidenten, bijna-incidenten en meldingsbesluiten
- Leveranciers- en cloudrisico-uitzonderingen
- Interne-auditbevindingen, corrigerende maatregelen en achterstallig bewijsmateriaal
Dit pakket geeft het management de informatie die nodig is om maatregelen goed te keuren, uitzonderingen kritisch te bevragen en restrisico te accepteren.
Het operationele model van Clarysec voor 2026
Het operationaliseren van technische NIS2-maatregelen met ISO 27001:2022 vereist een eenvoudig maar gedisciplineerd model:
- Breng NIS2-, DORA-, GDPR- en contractuele verplichtingen binnen het ISMS-toepassingsgebied
- Koppel verplichtingen aan risico’s, beleid, beheersmaatregelen, eigenaren en bewijsmateriaal
- Gebruik de Verklaring van Toepasselijkheid als gezaghebbende bron voor beheersmaatregelen
- Bouw bewijspakketten voor Article 21-gebieden met hoog risico
- Integreer incidentmelding in één regelgevende workflow
- Behandel leveranciersbeveiliging als een levenscyclus, niet als een vragenlijst
- Voer interne audits uit met echte steekproeven
- Rapporteer de doeltreffendheid van beheersmaatregelen aan bestuursorganen
- Verbeter op basis van incidenten, auditbevindingen, tests en wijzigingen in regelgeving
Voor Maria was het kantelpunt het inzicht dat zij geen afzonderlijk NIS2-project nodig had. Zij had een sterkere ISMS-bewijsmachine nodig.
Het beleid van Clarysec, Zenith Blueprint en Zenith Controls zijn ontworpen om samen te werken. Beleid definieert verwacht gedrag en registraties. De Zenith Blueprint geeft de implementatie- en auditroute in 30 stappen. Zenith Controls biedt de mapping voor geïntegreerde compliance zodat NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF en assurance in COBIT-stijl als één coherent programma kunnen worden beheerd.
Volgende stap: bouw uw NIS2-naar-ISO 27001:2022-bewijsmapping
Als uw NIS2-werk nog steeds in een gapspreadsheet staat, is 2026 het jaar om het te operationaliseren.
Begin met één technische maatregel met hoog risico, zoals kwetsbaarhedenbeheer, incidentafhandeling of leveranciersbeveiliging. Koppel deze aan ISO 27001:2022-risico’s, beleid, Annex A-beheersmaatregelen, eigenaren, procedures en bewijsmateriaal. Neem vervolgens een steekproef van de registraties van het vorige kwartaal en stel een scherpe vraag: zou dit voldoen voor een toezichthouder, een klantbeoordelaar en een ISO 27001:2022-auditor?
Clarysec kan u helpen dat antwoord op te bouwen met de beleidsbibliotheek, Zenith Blueprint en Zenith Controls.
Het doel is niet meer documentatie. Het doel is verdedigbaar, herhaalbaar bewijsmateriaal dat uw technische NIS2-maatregelen daadwerkelijk werken.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


