Cybersecurity is voor veel organisaties geen vrijblijvend onderwerp meer. Niet alleen omdat digitale dreigingen toenemen, maar ook omdat wet- en regelgeving strenger wordt.
Met de komst van de Cyberbeveiligingswet, de Nederlandse implementatie van de Europese NIS2-richtlijn, krijgen meer organisaties te maken met verplichtingen rondom digitale weerbaarheid, risicobeheersing en incidentmelding.
Daarmee ontstaat bij veel organisaties dezelfde vraag:
Worden pentesten straks verplicht?
Het eerlijke antwoord is genuanceerd. De wet zegt niet voor iedere organisatie letterlijk dat er periodiek een pentest moet worden uitgevoerd. Maar de eisen rondom risicobeheersing, aantoonbaarheid en passende beveiligingsmaatregelen maken pentesten in de praktijk wel steeds relevanter.
Niet als vinkje.
Maar als manier om te onderbouwen dat digitale risico’s serieus worden onderzocht.
Wie eerst de basis wil begrijpen, kan lezen wat een pentest inhoudt en welke onderdelen daarbij worden onderzocht.
Waarom de Cyberbeveiligingswet relevant is
De Cyberbeveiligingswet is bedoeld om de digitale weerbaarheid van organisaties te verhogen. Dat is nodig omdat steeds meer processen afhankelijk zijn van digitale systemen, cloudomgevingen, API-koppelingen, leveranciers en externe diensten.
Wanneer zo’n omgeving kwetsbaar is, blijft de impact vaak niet beperkt tot één systeem. Een incident kan leiden tot datalekken, verstoring van dienstverlening, ketenproblemen of reputatieschade.
Juist daarom verschuift de aandacht van vrijblijvende beveiliging naar aantoonbare risicobeheersing.
Organisaties moeten niet alleen maatregelen nemen, maar ook kunnen uitleggen waarom die maatregelen passend zijn. Dat vraagt om inzicht in systemen, kwetsbaarheden, afhankelijkheden en mogelijke aanvalsscenario’s.
Daar komen pentesten in beeld.
Een pentest helpt niet alleen om kwetsbaarheden te vinden, maar vooral om te begrijpen wat een aanvaller in de praktijk kan bereiken.
Schrijft de Cyberbeveiligingswet een pentest letterlijk voor?
Niet altijd.
Wetgeving zoals NIS2 en de Cyberbeveiligingswet schrijft meestal geen vaste technische checklist voor die voor iedere organisatie hetzelfde is. De wetgeving draait vooral om passende maatregelen, risicobeheersing, incidentmelding en verantwoordelijkheid op bestuursniveau.
Dat betekent dat organisaties zelf moeten kunnen onderbouwen welke maatregelen nodig zijn in hun situatie.
Voor een eenvoudige omgeving kan dat anders zijn dan voor een organisatie met bedrijfskritische systemen, gevoelige data, API-koppelingen of complexe cloudinfrastructuur.
Een pentest is dus niet altijd letterlijk als losstaand verplicht middel benoemd. Maar als een organisatie moet aantonen dat zij risico’s kent en maatregelen effectief zijn, wordt het lastig om alleen te vertrouwen op beleid, documentatie of geautomatiseerde scans.
Dan is de vraag niet:
“Staat het woord pentest letterlijk in de wet?”
Maar:
“Kunnen we aantonen dat we onze belangrijkste digitale risico’s realistisch hebben onderzocht?”
Voor veel organisaties is een pentest daarvoor een logisch middel.
Waarom een vulnerability scan meestal niet genoeg is
Een vulnerability scan kan nuttig zijn. Dit soort scans helpen om bekende kwetsbaarheden, verouderde software en zichtbare configuratieproblemen te signaleren.
Maar zo’n scan beantwoordt maar een deel van de vraag.
Een vulnerability scan laat vooral zien welke kwetsbaarheden zichtbaar zijn. Een pentest onderzoekt wat iemand daar in de praktijk mee kan doen.
Dat verschil is belangrijk.
Een scanner kan bijvoorbeeld aangeven dat een systeem een zwakke configuratie heeft. Maar hij begrijpt niet altijd welke data toegankelijk is, welke rechten een gebruiker heeft of hoe meerdere kleine bevindingen samen een groter risico vormen.
Ook kwetsbaarheden in autorisatie, businesslogica, API-gedrag of laterale beweging worden vaak niet goed zichtbaar met alleen geautomatiseerde tooling.
Voor aantoonbare risicobeheersing is juist die context belangrijk.
Niet alleen:
“Zijn er kwetsbaarheden gevonden?”
Maar:
“Wat betekent dit voor onze organisatie als iemand dit misbruikt?”
Daarom is het verschil tussen een vulnerability scan en een pentest belangrijk om goed te begrijpen.
Wat een pentest toevoegt aan compliance
Compliance draait vaak om aantoonbaarheid. Er moet zichtbaar zijn dat maatregelen zijn genomen, risico’s zijn beoordeeld en bevindingen worden opgevolgd.
Een pentest kan daarbij helpen, omdat het concreet maakt waar risico’s zitten.
Maar de waarde van een pentest zit niet alleen in het rapport.
Een goed uitgevoerde pentest laat zien hoe een systeem zich gedraagt wanneer iemand actief probeert buiten de gebaande paden te gaan. Kan een gebruiker bij data van anderen? Zijn beheerinterfaces onnodig bereikbaar? Werken autorisatiecontroles consequent? Kan een eerste ingang worden gebruikt om verder te komen in het netwerk?
Dat soort vragen zijn belangrijk voor security, maar ook voor compliance.
Een rapport met alleen losse technische bevindingen is vaak beperkt bruikbaar. Daarom is het belangrijk om te begrijpen waarom pentesten niet bij compliance mogen eindigen.
Een rapport dat uitlegt welke scenario’s echt impact hebben, helpt organisaties veel beter om risico’s te prioriteren en maatregelen te onderbouwen.
Daarmee wordt een pentest meer dan bewijs voor een audit.
Het wordt input voor betere besluitvorming.
Welke systemen verdienen prioriteit?
Niet elk systeem hoeft tegelijk getest te worden. Dat is meestal niet realistisch en ook niet nodig.
De vraag is waar de grootste risico’s zitten.
Systemen die klantdata verwerken, bedrijfskritische processen ondersteunen of gekoppeld zijn aan externe omgevingen verdienen vaak prioriteit. Dat geldt ook voor applicaties waar gebruikersaccounts, rollen, betalingen, persoonsgegevens of API-koppelingen een belangrijke rol spelen.
Bij een webapplicatie kan de nadruk liggen op autorisatie, sessiebeheer en businesslogica. Bij API’s gaat het vaak om endpoints, datastromen en objectniveau-autorisatie. Bij cloudomgevingen draait het eerder om rechten, configuratie, blootstelling en koppelingen tussen resources. Bij netwerken gaat het om bereikbaarheid, segmentatie en wat er mogelijk wordt na een eerste ingang.
De juiste scope hangt dus af van de omgeving.
Een goede pentest begint daarom niet met testen, maar met afbakenen: welke systemen zijn belangrijk, waar zit de impact en welke scenario’s moeten worden onderzocht?
Wat auditors en klanten vaak willen zien
Auditors, klanten en toezichthouders kijken meestal niet alleen naar de vraag of er ooit een test is uitgevoerd.
Ze willen vooral zien dat security structureel wordt aangepakt.
In de praktijk betekent dat vaak dat organisaties moeten kunnen laten zien:
- welke systemen zijn getest;
- waarom die scope is gekozen;
- welke bevindingen zijn gedaan;
- hoe ernstig die bevindingen zijn;
- welke maatregelen zijn genomen;
- en of kwetsbaarheden daadwerkelijk zijn verholpen.
Het gaat dus niet alleen om het hebben van een rapport, maar om de opvolging.
Een pentest zonder opvolging heeft beperkte waarde. Als kritieke bevindingen blijven liggen, is er formeel misschien getest, maar is het risico niet beheerst.
Voor compliance is juist die keten belangrijk: testen, begrijpen, oplossen en opnieuw beoordelen.
Periodiek testen of alleen eenmalig?
Een eenmalige pentest kan waardevol zijn, vooral als startpunt. Maar voor veel organisaties is één test niet genoeg.
Digitale omgevingen veranderen continu. Er komen nieuwe releases, extra koppelingen, aangepaste rechten, nieuwe leveranciers en gewijzigde configuraties. Daardoor kunnen nieuwe risico’s ontstaan, ook als een eerdere pentest geen kritieke bevindingen opleverde.
Daarom kiezen veel organisaties voor periodiek pentesten.
Hoe vaak een pentest nodig is, hangt af van de omgeving. Een relatief stabiel systeem met beperkte impact vraagt om een andere aanpak dan een applicatie die continu wordt doorontwikkeld en gevoelige data verwerkt.
Ook grote wijzigingen zijn een logisch moment voor een nieuwe test. Denk aan een nieuwe klantomgeving, een belangrijke release, een aangepaste autorisatiestructuur of een migratie naar de cloud.
De frequentie moet dus niet alleen worden bepaald door de kalender, maar vooral door risico en verandering.
Veelgemaakte misvattingen
Een veelvoorkomende misvatting is dat een organisatie “klaar” is zodra er een vulnerability scan rapport ligt.
Dat is te kort door de bocht.
Een vulnerability scan kan onderdeel zijn van een securityproces, maar vervangt geen handmatig onderzoek naar impact, context en aanvalsscenario’s.
Een tweede misvatting is dat pentesten alleen relevant zijn voor grote organisaties. In de praktijk kunnen juist middelgrote organisaties kwetsbaar zijn, omdat zij wel complexe digitale processen hebben, maar niet altijd beschikken over volwassen securityteams.
Een derde misvatting is dat een pentest alleen nodig is als de wet dat letterlijk voorschrijft.
Dat is niet hoe risicobeheersing werkt. De wet vraagt om passende maatregelen. Als een organisatie gevoelige data verwerkt, afhankelijk is van digitale systemen of onderdeel is van een keten, kan een pentest een logische manier zijn om risico’s aantoonbaar te onderzoeken.
Niet omdat het woord verplicht in de wet staat, maar omdat de onderliggende verantwoordelijkheid daarom vraagt.
Hoe organisaties zich nu kunnen voorbereiden
Wachten tot alle details definitief zijn, is meestal niet verstandig.
Organisaties kunnen nu al beginnen met het in kaart brengen van hun belangrijkste digitale risico’s. Welke systemen zijn kritisch? Welke applicaties verwerken gevoelige gegevens? Welke API’s koppelen interne en externe systemen? Welke cloudresources zijn bereikbaar vanaf internet? Welke leveranciers hebben toegang?
Daarna kan worden bepaald welke systemen als eerste getest moeten worden.
Niet alles hoeft tegelijk. Begin bij de systemen waar de impact het grootst is. Voor planning en budgettering is het daarnaast nuttig om te begrijpen waar pentest kosten van afhangen.
Voor veel organisaties is het verstandig om eerst onderscheid te maken tussen basiscontrole en diepgaand onderzoek. Een vulnerability scan kan helpen om bekende kwetsbaarheden zichtbaar te maken. Een pentest is nodig wanneer je wilt weten wat iemand in de praktijk kan bereiken.
Documentatie is daarbij belangrijk. Niet alleen het rapport zelf, maar ook de opvolging: welke bevindingen zijn opgelost, welke risico’s zijn geaccepteerd en welke maatregelen zijn genomen?
Dat maakt security aantoonbaar.
Pentesten als onderdeel van aantoonbare weerbaarheid
De Cyberbeveiligingswet vraagt organisaties om serieuzer naar digitale risico’s te kijken. Niet alleen op papier, maar ook in de praktijk.
Een pentest helpt daarbij omdat het laat zien waar systemen, applicaties of infrastructuur daadwerkelijk kwetsbaar zijn. Niet alleen technisch, maar vooral in termen van impact.
Dat maakt pentesten relevant voor compliance, maar ook voor bestuur, IT en risicomanagement.
De beste vraag is daarom niet of een pentest verplicht is.
De betere vraag is:
“Kunnen wij uitleggen hoe we onze belangrijkste digitale risico’s hebben onderzocht?”
Als dat antwoord nog niet scherp is, kan een gerichte pentest helpen om risico’s binnen applicaties, API’s, cloudomgevingen of netwerken concreet in kaart te brengen.