NIS2 penetration testing is geen checkbox-oefening. Artikel 21 noemt niet één specifieke testing tool die elke entiteit moet gebruiken. Het artikel verplicht organisaties om kwetsbaarheden te behandelen en te beoordelen of hun cybersecurityrisicobeheersmaatregelen in de praktijk werken.
Dat onderscheid telt. Een vulnerability scan kan laten zien dat er een bekende zwakte bestaat. Een DAST scan kan een draaiende webapplicatie testen op veelvoorkomende issues. Een penetration test gaat verder: die controleert of zwaktes kunnen worden misbruikt, hoe ver een aanvaller kan komen en of bestaande controles de aanvalslijn stoppen.
Voor EU-bedrijven die zich voorbereiden op NIS2 is de praktische vraag: “Kunnen wij bewijzen wat is getest, wat faalde, wat is hersteld en welk bewijs de finding afsluit?”
Dit artikel legt uit wat NIS2 Artikel 21 betekent voor vulnerability testing, wanneer penetration testing het juiste bewijsmechanisme is, wat een NIS2-ready rapport moet bevatten en hoe Nederlandse organisaties MIAUW kunnen gebruiken als nuttige referentie voor testing met auditwaarde.
TL;DR
NIS2 Artikel 21 vereist vulnerability handling onder Artikel 21(2)(e) en beoordeling van controle-effectiviteit onder Artikel 21(2)(f). Geautomatiseerde scans helpen bekende kwetsbaarheden te vinden, maar bewijzen niet of controles exploitatie voorkomen. Voor systemen met hoog risico kan een scoped penetration test sterker Artikel 21-bewijs opleveren: scope, methodologie, gevalideerde findings, remediation actions en retest results. Nederlandse organisaties kunnen MIAUW gebruiken als praktische referentie voor penetration testing met auditwaarde.
Vereist NIS2 penetration testing?
NIS2 verplicht organisaties om cybersecurityrisico’s te beheersen met maatregelen die passend en proportioneel zijn ten opzichte van hun blootstelling. Artikel 21(2)(e) behandelt security bij aanschaf, ontwikkeling en onderhoud, inclusief vulnerability handling en disclosure. Artikel 21(2)(f) behandelt beleid en procedures om te beoordelen of cybersecurityrisicobeheersmaatregelen effectief zijn.
Dat betekent niet dat elk systeem in elke organisatie elk jaar dezelfde penetration test nodig heeft. Het betekent dat de organisatie moet kunnen aantonen dat kwetsbaarheden worden gevonden, beoordeeld en hersteld, en dat security controls werken.
Voor een intern low-risk tool kunnen vulnerability scanning en secure configuration review genoeg zijn. Voor een internet-facing application, betaalplatform, klantportal, operational technology gateway of API die gevoelige data verwerkt, is een handmatige penetration test vaak de sterkere bewijsroute.
Een goed NIS2 testing plan moet drie vragen beantwoorden:
- Welke systemen vallen binnen scope voor Artikel 21-risico?
- Welke testing method bewijst dat het risico wordt beheerst?
- Welk bewijs is voldoende voor management, auditors, klanten of toezichthouders?
Het antwoord kan vulnerability scanning, DAST, penetration testing, code review, configuration review of supplier testing evidence omvatten. Penetration testing wordt nodig wanneer de organisatie bewijs nodig heeft van exploitability en control effectiveness, niet alleen een lijst met bekende CVEs.
Welke NIS2 Artikel 21-verplichtingen vulnerability testing vereisen
Artikel 21(2)(e) en Artikel 21(2)(f) zijn de twee relevante verplichtingen voor vulnerability testing.
Artikel 21(2)(e): vulnerability handling and disclosure
Artikel 21(2)(e) vereist security bij de aanschaf, ontwikkeling en het onderhoud van netwerk- en informatiesystemen, inclusief vulnerability handling en disclosure.
In de praktijk betekent dit dat de organisatie een herhaalbaar proces nodig heeft om kwetsbaarheden te vinden, beoordelen, prioriteren, herstellen en documenteren. Vulnerability scans ondersteunen deze vereiste omdat ze bekende zwaktes identificeren in systemen, poorten, softwareversies, packages en configuraties.
Maar scanning alleen is niet het volledige proces. De organisatie heeft ook ownership, remediation tracking, exception handling, supplier coordination en bewijs nodig dat de finding is gesloten.
Artikel 21(2)(e) beantwoordt: “Hebben wij een proces om kwetsbaarheden te vinden en af te handelen?”
Artikel 21(2)(f): control effectiveness assessment
Artikel 21(2)(f) vereist beleid en procedures om de effectiviteit van cybersecurityrisicobeheersmaatregelen te beoordelen.
Hier wordt penetration testing relevanter. Een scan kan detecteren dat een zwakte bestaat. Een penetration test controleert of die zwakte kan worden misbruikt ondanks de controles die de aanval zouden moeten voorkomen of beperken.
Een access control-regel kan bijvoorbeeld in beleid bestaan. Een penetration test kan laten zien of privilege escalation nog steeds mogelijk is. Een web application firewall kan geconfigureerd zijn. Een penetration test kan laten zien of deze de relevante aanvalslijn blokkeert. Logging kan zijn ingeschakeld. Een penetration test kan laten zien of de incident trail de juiste events vastlegt.
Artikel 21(2)(f) beantwoordt: “Kunnen wij bewijzen dat onze controles werken onder realistische aanvalsomstandigheden?”
Als uw team nog alle 10 Artikel 21-maatregelen in kaart brengt, start dan met de bredere NIS2 Article 21 security requirements guide voordat u de testing scope vernauwt.
De drie NIS2 testing methods: wat elke methode dekt en wat niet
NIS2 specificeert de uitkomst: vulnerability handling en control effectiveness. Het schrijft niet één tool voor.
Daarom telt de testing method. Een vulnerability scan, DAST scan en penetration test hebben allemaal een rol, maar zijn niet onderling uitwisselbaar.
Een bruikbaar testing plan begint met het scheiden van drie taken:
● Bekende kwetsbaarheden vinden.
● Applicatiegedrag testen terwijl het systeem draait.
● Bewijzen of een aanvaller zwaktes kan misbruiken en controles kan omzeilen.
Wanneer die taken door elkaar lopen, overschatten bedrijven vaak wat hun scanrapport bewijst. Het rapport kan bruikbaar zijn voor Artikel 21(2)(e), maar zwak voor Artikel 21(2)(f).
Vulnerability scan vs DAST vs penetration test: NIS2 compliance comparison
| Testing type | Wat het is | Welke NIS2 Artikel 21-maatregel het ondersteunt | Beperking — wat het niet dekt |
|---|---|---|---|
| Vulnerability scan | Geautomatiseerde scan van bekende CVEs, exposed services, poorten, softwareversies en misconfiguraties. Veelgebruikte tools zijn Nessus, Qualys en OpenVAS. | Ondersteunt Artikel 21(2)(e) door bekende kwetsbaarheden te helpen identificeren. Ondersteunt ook risicoanalyse wanneer findings worden geprioriteerd. | Kan kwetsbaarheden niet combineren, business logic niet testen, attack paths niet valideren of bewijzen of controles exploitatie stoppen. |
| DAST | Dynamic Application Security Testing op een draaiende webapplicatie of API. Kan issues detecteren zoals XSS, SQL injection, weak authentication flows en API exposure. | Ondersteunt Artikel 21(2)(e) voor application vulnerability handling. Kan Artikel 21(2)(f) deels ondersteunen voor application control checks. | Dekt geen volledig infrastructuurrisico, supplier exposure, handmatige attack chains of complexe authorization flaws zonder menselijke validatie. |
| Penetration test | Human-led gesimuleerde aanval binnen een gedefinieerde scope. Test exploitability, attack paths en of controles werken onder realistische omstandigheden. | Sterke ondersteuning voor Artikel 21(2)(e) en Artikel 21(2)(f), vooral voor high-risk systems. | Is point-in-time, afhankelijk van scope en geen vervanging voor doorlopend vulnerability management. Een smalle scope laat out-of-scope systems ongetest. |
NIS2 testing methods vullen elkaar aan. Een vulnerability scan helpt bekende issues te vinden; een penetration test is sterker bewijs wanneer de organisatie control effectiveness moet aantonen.
Een veelgemaakte compliancefout is een scanresultaat behandelen als bewijs dat controles werken. Dat is het niet. Een scan kan laten zien dat een server een patch mist. De scan kan niet laten zien of een aanvaller dat issue kan combineren met zwak toegangsbeheer, slechte segmentatie en exposed credentials om gevoelige data te bereiken. Gebruik voor de technische fases van scoping, exploitation, reporting en retesting de volledige penetration testing methodology guide als verdiepende referentie.
Voor NIS2-bewijs moet de testmethode passen bij het risico van het systeem. Hoe meer blootgesteld of bedrijfskritisch het systeem is, hoe meer de organisatie moet verschuiven van geautomatiseerde detectie naar gevalideerd bewijs van exploitability.
Hoe vaak moeten NIS2-entiteiten penetration testing uitvoeren?
NIS2 legt geen vaste penetration testing cadence op voor elke entiteit. De veiligere formulering van de vereiste is: testing frequency moet risicogebaseerd, gedocumenteerd en bijgewerkt zijn wanneer de omgeving verandert.
Voor veel essential en important entities is een jaarlijkse penetration test voor high-risk systems een praktische bewijsbasislijn. Daarmee laat de organisatie zien dat zij niet alleen vertrouwt op historische scanresultaten. Het geeft management ook jaarlijks zicht op exploitability, remediation status en residual risk.
Jaarlijkse testing is niet genoeg wanneer er een grote wijziging plaatsvindt. Een gerichte test moet worden overwogen na wijzigingen zoals:
● een nieuwe internet-facing application,
● een grote cloud migration,
● een nieuw customer portal of API,
● een significante identity and access management-wijziging,
● onboarding van een critical supplier platform,
● grote architecture changes die segmentatie of data flow beïnvloeden.
Een praktische cadence kan er zo uitzien:
| Trigger of entity context | Praktische penetration testing cadence | Vulnerability scan cadence | Bewijs om te bewaren |
|---|---|---|---|
| High-risk internet-facing systems | Minimaal jaarlijks, op basis van risico en scope | Maandelijks of per kwartaal, afhankelijk van blootstelling | Scope, findings, remediation plan, retest evidence |
| Important business systems met gevoelige data | Jaarlijks of na grote wijziging | Per kwartaal of halfjaarlijks | Risk acceptance, scan results, remediation tracking |
| Nieuwe applicatie of major release | Gerichte test vóór of kort na release | Scan vóór release en na remediation | Test report, release decision, unresolved risk sign-off |
| Supplier-operated system binnen scope | Review supplier test evidence jaarlijks of bij verlenging | Vraag supplier scan of assurance evidence op waar relevant | Supplier report summary, exceptions, follow-up actions |
NIS2 testing cadence moet risicogebaseerd zijn. Jaarlijkse testing is een praktische basislijn voor high-risk systems, geen universeel juridisch minimum.
De cadence moet worden gedocumenteerd in een beleid of security testing plan. Het plan moet aangeven welke systemen worden getest, welke methode wordt gebruikt, wie eigenaar is van remediation en wanneer retesting plaatsvindt.
Als een toezichthouder, sectorauthoriteit, klantcontract of cyber insurance requirement een strengere cadence stelt, moet die vereiste de algemene basislijn overrulen.
MIAUW: de Nederlandse standaard voor NIS2-compliant pentests
Voor Nederlandse organisaties is MIAUW een nuttige methodologiereferentie wanneer penetration testing auditwaarde moet hebben. MIAUW staat voor Methodiek voor Informatiebeveiligingsonderzoek met Audit Waarde, of Methodology for Information Security Research with Audit Value.
De formulering telt. MIAUW moet niet worden gepresenteerd als NIS2-certificering. Het maakt een bedrijf niet vanzelf compliant. De waarde is dat het helpt om de test zo te structureren dat de uitkomst makkelijker te valideren, herhalen en presenteren is als bewijs.
Een MIAUW-style aanpak is nuttig voor NIS2 omdat Artikel 21(2)(f) niet alleen gaat over securitywerk uitvoeren. Het gaat om beoordelen of risicobeheersmaatregelen effectief zijn. Dat vereist traceability.
Een pentest met auditwaarde moet laten zien:
● wat is getest,
● wat is uitgesloten,
● welke methodologie is gebruikt,
● welke findings zijn gevalideerd,
● welk bewijs de finding ondersteunt,
● welke remediation vereist is,
● of de remediation opnieuw is getest.
Dat verschilt van een los “ethical hacker report” waarin de scope onduidelijk is, severity scoring subjectief is en de klant het bewijspad later niet kan reconstrueren.
Voor Nederlandse entiteiten die zich voorbereiden op de Cyberbeveiligingswet kan MIAUW procurement- en securityteams helpen om betere vragen te stellen voordat zij een test laten uitvoeren:
● Maakt het rapport scope en exclusions expliciet?
● Gebruiken findings een consistente scoringmethode zoals CVSS?
● Bevat het rapport exploit evidence waar exploitatie mogelijk was?
● Worden retest results gedocumenteerd?
● Is het rapport bruikbaar voor management en auditors, niet alleen voor engineers?
Download voor de volledige MIAUW-methodologiedetails onze checklist om te zorgen dat uw penetration tests voldoen aan het MIAUW framework, inconsistenties aanpakken en cybersecurity controls verbeteren.
Heeft u een security baseline nodig voordat u een volledige NIS2 penetration test laat uitvoeren? Start met CyberCheck als uw team nog niet zeker weet welke systemen het meeste risico dragen, welke gaps eerst moeten worden hersteld of welk bewijs al ontbreekt.
Wat een NIS2-compliant pentest report moet bevatten
Een NIS2-ready penetration test report moet meer doen dan kwetsbaarheden opsommen. Het moet bewijs opleveren dat Artikel 21-risk management, interne governance, customer due diligence en remediation planning ondersteunt.
Een sterk rapport bevat zeven onderdelen.
1. Scope statement
Het rapport moet aangeven wat wel en niet is getest. Dit omvat systemen, applicaties, APIs, IP ranges, user roles, environments, leveranciers en testbeperkingen.
Out-of-scope systems tellen. Als een kritieke payment API of identity provider is uitgesloten, moet het rapport dat benoemen. Anders kan management aannemen dat er dekking is die de test niet heeft geleverd.
2. Methodology used
Het rapport moet de testing methodology of het framework benoemen. Voor Nederlandse organisaties kan MIAUW worden gebruikt als referentie voor testing met auditwaarde. Voor application testing kunnen OWASP WSTG of OWASP API Security Testing guidance ook relevant zijn.
De methodology section mag niet decoratief zijn. Deze moet uitleggen hoe testing is gepland, uitgevoerd en gedocumenteerd.
3. Findings with severity scoring
Elke finding moet severity, affected asset, exploit conditions en business impact bevatten. CVSS kan helpen om technische severity te standaardiseren, maar het rapport moet ook business priority uitleggen.
Een medium technical finding kan high priority worden als deze een public system, critical supplier connection of sensitive data flow raakt.
4. Exploitation evidence
Voor Artikel 21(2)(f) is dit het belangrijkste deel van het rapport. De organisatie heeft bewijs nodig dat laat zien of controles werkten.
Bruikbaar bewijs kan bestaan uit screenshots, logs, request/response examples, proof-of-concept steps, affected user roles, access paths of attack chain diagrams. Gevoelig bewijs moet zorgvuldig worden behandeld en onder access control worden opgeslagen.
5. Remediation recommendations
Een goed rapport vertelt het team wat eerst moet worden hersteld. Findings moeten worden gegroepeerd op severity, exploitability en business impact.
Het remediation-overzicht moet specifiek genoeg zijn voor engineering-, infrastructure-, security- en managementteams om owners toe te wijzen. “Fix access control” is niet genoeg. “Restrict role X from endpoint Y and add server-side authorisation check before release Z” is actiegericht.
6. Retest results
Retesting sluit de bewijsloop. Zonder retest results kan de organisatie laten zien dat een finding is gerapporteerd, maar niet dat deze is hersteld.
Voor NIS2-bewijs bewaart u de oorspronkelijke finding, remediation action, owner, target date en retest result samen. Critical en high findings mogen niet open blijven staan als tickets zonder einddatum en zonder gedocumenteerd besluit.
7. Executive summary
Het rapport moet een management summary bevatten die risico uitlegt in zakelijke termen. Deze moet benoemen wat is getest, wat de belangrijkste findings waren, wat open blijft en welk besluit management moet nemen.
Deze summary kan ook Artikel 20 governance evidence ondersteunen, omdat management bodies genoeg informatie nodig hebben om toezicht te houden op cybersecurityrisico. Voor leiderschapsverantwoordelijkheden buiten het test report: zie hoe NIS2 Article 20 management accountability security evidence koppelt aan board-level oversight.
Deze records moeten in het bredere NIS2 evidence pack worden opgenomen, samen met risk decisions, remediation tracking en management approval records.
NCSC guidance voor Nederlandse NIS2-entiteiten
Voor Nederlandse organisaties is de Cyberbeveiligingswet de nationale implementatieroute voor NIS2. Op het moment van publicatie op 29 mei 2026 had de Tweede Kamer de Cyberbeveiligingswet goedgekeurd en zat het voorstel in het proces bij de Eerste Kamer. Nederlandse overheidsbronnen adviseerden organisaties om niet te wachten tot de wet in werking treedt voordat zij zich voorbereiden.
Die timing beïnvloedt hoe dit artikel gelezen moet worden. Nederlandse entiteiten moeten penetration testing niet behandelen als een last-minute auditactiviteit. Een praktische manier om die last-minute druk te vermijden is eerst een NIS2 gap analysis uitvoeren en de resultaten daarna gebruiken om te bepalen welke systemen scanning, DAST, penetration testing of supplier evidence nodig hebben. De test creëert alleen waarde als er genoeg tijd is om findings te herstellen en critical issues opnieuw te testen vóór customer due diligence, supervisory review of board reporting.
De expertblog van NCSC over penetration testing wijst ook op een praktisch probleem: penetration testing kan in verschillende contexten verschillende dingen betekenen. Zonder duidelijke scoping- en rapportageverwachtingen kan een test moeilijk vergelijkbaar, moeilijk te auditen en moeilijk bruikbaar worden voor managementbesluiten.
MIAUW is relevant in die Nederlandse context omdat het een meer gestructureerde manier biedt om penetration testing in te kopen en te documenteren. Voor NIS2-voorbereiding is die structuur het punt. De organisatie heeft bewijs nodig dat later kan worden gereviewd, niet alleen technische findings die in een PDF blijven staan.
Hoe Sunbytes NIS2-compliant vulnerability testing levert
Sunbytes helpt EU-bedrijven om van een onduidelijke security posture naar evidence-backed remediation te gaan. Voor NIS2 penetration testing is de eerste stap vaak geen full-scope test. Het is een baseline: welke systemen tellen, welke risico’s zijn al bekend, welk bewijs bestaat en welke gaps moeten eerst worden hersteld.
Daar past CyberCheck. CyberCheck is een baseline + gap + roadmap assessment. Het helpt teams hun huidige security posture te begrijpen, prioriteitsgaps te identificeren en te bepalen wat diepere testing nodig heeft. Het helpt te bepalen waar een penetration test zich op moet richten en welk bewijs de organisatie moet voorbereiden.
Why Sunbytes?
Sunbytes is een Nederlands technologiebedrijf met hoofdkantoor in Nederland en een delivery hub in Vietnam. Al 15 jaar helpen wij klanten wereldwijd met Transform · Secure · Accelerate — strategie omzetten in betrouwbare delivery, met security ingebouwd in de manier waarop systemen worden ontworpen, getest en onderhouden.
- CyberSecurity Solutions: Sunbytes helpt security- en compliancerisico’s te verlagen via praktische security services, CyberCheck baseline assessments en compliance readiness support. Voor NIS2 Artikel 21 geeft CyberCheck teams een duidelijk startpunt: huidige security baseline, prioriteitsgaps en een roadmap voor wat eerst moet worden hersteld vóór diepere testing of bewijsvoorbereiding.
- Digital Transformation Solutions: Sunbytes helpt bedrijven digitale producten te bouwen en moderniseren met senior engineering teams voor custom development, QA/testing, maintenance en support. Voor NIS2 readiness telt dit, omdat penetration testing findings vaak terugleiden naar deliverywerk: onveilige architecture decisions, zwak toegangsbeheer, ontbrekende testdekking, slechte logging of technical debt die in de product backlog moet worden opgelost.
- Accelerate Workforce Solutions: Sunbytes helpt bedrijven capability en capaciteit op te schalen via recruitment en workforce support wanneer groei dat vraagt. Wanneer penetration testing gaps blootlegt die extra engineering-, QA-, security- of documentatiecapaciteit vereisen, kan Accelerate Workforce Solutions teams helpen de juiste ondersteuning toe te voegen zonder remediation te vertragen.
Als uw team wil begrijpen waar uw NIS2 testing evidence vandaag staat, start dan met CyberCheck: baseline, gap en roadmap vóór diepere testing decisions.
FAQs
Nee, niet voor elk systeem. Een vulnerability scan ondersteunt Artikel 21(2)(e), omdat deze helpt bekende kwetsbaarheden te identificeren. De scan bewijst niet dat controles exploitatie voorkomen. Voor high-risk systems kan een penetration test sterker bewijs leveren voor Artikel 21(2)(f).
NIS2 stelt geen universele cadence vast. Een praktische basislijn is om high-risk systems minimaal jaarlijks en na grote wijzigingen te testen. De exacte cadence moet gebaseerd zijn op exposure, system criticality, sector guidance, customer requirements en de risk assessment van de organisatie.
MIAUW certificeert NIS2 compliance niet op zichzelf. Het helpt penetration testing zo te structureren dat scope, evidence, scoring en reporting makkelijker te valideren zijn. Voor Nederlandse organisaties kan dat het rapport bruikbaarder maken voor NIS2 evidence en supervisory discussions.
CyberCheck is een baseline + gap + roadmap assessment. Het helpt current posture, priority gaps en next actions te identificeren voordat een volledige penetration test wordt scoped. Een volledige penetration test gaat dieper in op exploitability binnen een gedefinieerde scope. Als uw team nog niet weet waar het eerst moet testen, is CyberCheck het praktische startpunt.
Bewaar het volledige rapport, scope, methodology, findings, exploit evidence, remediation tracking, risk acceptance decisions en retest results. Sla deze samen op als één evidence package. Alleen het rapport is zwakker dan een volledig spoor dat laat zien wat is gevonden, wat is hersteld en wat open blijft.
Nee. Testing moet risicogebaseerd zijn. Start met systemen die internet-facing, business-critical, gekoppeld aan gevoelige data of gebruikt door kritieke leveranciers zijn. Documenteer waarom lower-risk systems zijn behandeld met lichtere testing methods zoals scanning, configuration review of supplier evidence.
DAST kan application security testing ondersteunen, vooral voor web applications en APIs. Het vervangt handmatige penetration testing niet volledig wanneer de organisatie attack chains, business logic flaws, authorization issues of control effectiveness over meerdere systemen moet valideren.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
