Voor veel organisaties begint een pentest niet vanuit nieuwsgierigheid, maar vanuit noodzaak.
Een audit komt eraan. Een klant stelt eisen. Er moet worden aangetoond dat beveiliging serieus wordt genomen. Nieuwe wetgeving en richtlijnen, zoals NIS2, maken die druk alleen maar groter.
De vraag is dan vaak niet:
“Hoe veilig zijn we echt?”
Maar eerder:
“Wat moeten we doen om te voldoen?”
Een pentest is in die context een logisch middel. Er wordt een scope afgesproken, er komt een rapport en bevindingen worden vastgelegd. Voor auditors, klanten en management geeft dat houvast.
Daar is op zichzelf niets mis mee.
Het probleem ontstaat pas wanneer een pentest alleen wordt gezien als bewijsstuk. Dan wordt de test een vinkje in een proces, terwijl de echte waarde ergens anders ligt: begrijpen wat er in de praktijk mis kan gaan.
Waarom compliance vaak het startpunt is
Compliance is voor veel organisaties de eerste aanleiding om security structureel op te pakken. Dat is begrijpelijk.
Zolang er geen externe druk is, blijft security vaak iets dat “belangrijk” wordt gevonden, maar niet altijd bovenaan de planning staat. Pas wanneer een klant vragen stelt, een audit nadert of wetgeving concreter wordt, ontstaat er beweging.
Een pentest past goed in dat plaatje. Het levert iets tastbaars op: een rapport, een overzicht van bevindingen en bewijs dat er getest is.
Voor organisaties die moeten aantonen dat zij passende beveiligingsmaatregelen nemen, is dat waardevol. Zeker bij systemen waarin persoonsgegevens, klantdata, financiële gegevens of bedrijfsgevoelige informatie worden verwerkt.
Maar compliance kijkt vooral naar aantoonbaarheid.
Een aanvaller kijkt naar iets anders.
Die vraagt zich niet af of een organisatie aan een norm voldoet, maar wat er mogelijk is. Welke toegang kan worden verkregen? Welke data is toegankelijk? Hoe kunnen lage kwetsbaarheden zich opstapelen tot een kritiek probleem?
Daar zit het verschil tussen voldoen en begrijpen.
Waar compliance vaak tekortschiet
Compliance werkt meestal met kaders. Er wordt een scope bepaald, er wordt gekeken naar eisen en er wordt beoordeeld of maatregelen aantoonbaar zijn genomen.
Dat is nuttig, maar ook beperkt.
Een compliance-gedreven pentest richt zich vaak op de vraag of er getest is en welke bevindingen daaruit zijn gekomen. Minder vaak draait het om de vraag hoe een aanvaller zich daadwerkelijk door een omgeving zou bewegen.
In de praktijk zie je dan rapporten die formeel kloppen, maar inhoudelijk weinig zeggen over het echte risico. Er staan kwetsbaarheden in, soms netjes geclassificeerd op ernst, maar de samenhang ontbreekt.
Een lage kwetsbaarheid blijft een lage kwetsbaarheid. Een middelhoge bevinding blijft middelhoog. Terwijl juist de combinatie van bevindingen in de praktijk de meeste impact kan hebben.
Een verkeerd ingestelde applicatie. Een account met te ruime rechten. Een API die net iets te veel data teruggeeft. Los van elkaar lijken dit misschien geen grote problemen. Samen kunnen ze alsnog leiden tot toegang die nooit bedoeld was.
Dat is precies wat je mist wanneer een pentest alleen wordt uitgevoerd om een verplichting af te vinken.
Een rapport is niet hetzelfde als inzicht
Een pentestrapport kan technisch correct zijn en toch weinig richting geven.
Dat gebeurt bijvoorbeeld wanneer bevindingen vooral worden beschreven als losse issues. Er staat wat er is gevonden, hoe ernstig het is en welke maatregel wordt geadviseerd. Dat is nuttig voor opvolging, maar het vertelt niet altijd wat het betekent voor de organisatie.
De belangrijkste vraag is niet alleen:
“Welke kwetsbaarheden zijn er gevonden?”
Maar ook:
“Wat kan iemand daarmee bereiken?”
Dat is een andere manier van kijken.
Een kwetsbaarheid in een loginflow is pas echt interessant als duidelijk wordt of hiermee accounts kunnen worden misbruikt. Een fout in autorisatie is pas goed te beoordelen als zichtbaar wordt welke data of functionaliteit daardoor bereikbaar wordt. Een configuratiefout wordt belangrijker wanneer die een opstap vormt naar verdere toegang.
Een sterke pentest geeft daarom niet alleen bevindingen, maar context.
Die context maakt duidelijk waarom iets prioriteit heeft.
Meer hierover lees je in het artikel over wat er tijdens een pentest gebeurt.
Aanvallers houden zich niet aan de scope van een audit
Een audit of compliance-traject werkt met afbakening. Dat moet ook, anders wordt het oncontroleerbaar.
Maar aanvallers denken niet in diezelfde grenzen.
Als een webapplicatie binnen scope valt, maar de achterliggende API niet goed wordt meegenomen, kan juist daar het risico zitten. Als alleen de buitenkant van een systeem wordt bekeken, blijft onduidelijk wat er gebeurt zodra iemand eenmaal toegang heeft. Een netwerksegment dat buiten scope valt, betekent niet dat een aanvaller daar stopt.
In de praktijk begint het vaak pas na de eerste ingang.
Een aanvaller probeert verder te komen. Rechten uitbreiden. Andere systemen bereiken. Data verzamelen. Kijken welke koppelingen bestaan en waar controles ontbreken.
Daarom is het belangrijk dat een pentest niet alleen kijkt naar losse kwetsbaarheden, maar ook naar realistische scenario’s.
Niet: “Welke issues staan er op de lijst?”
Maar: “Wat kan iemand hiermee doen?”
Een praktisch voorbeeld
Stel dat een organisatie een webapplicatie pentest laat uitvoeren op een klantportaal, met name omdat een grote klant daarom vraagt.
De scope is beperkt tot de webapplicatie. De test vindt geen kritieke kwetsbaarheden. Er zijn een paar middelhoge bevindingen, wat verbeterpunten in headers en een aantal aanbevelingen rondom sessiebeheer. Het rapport ziet er netjes uit en kan worden gedeeld met de klant.
Formeel is daarmee veel geregeld.
Maar tijdens een diepgaandere API pentest kan blijken dat de applicatie via een API meer data teruggeeft dan zichtbaar is in de interface. Een gebruiker ziet in het portaal alleen zijn eigen gegevens, maar de response bevat ook interne IDs en verwijzingen naar andere objecten.
Op zichzelf lijkt dat misschien beperkt.
Totdat blijkt dat één van die IDs kan worden gebruikt in een ander endpoint, waar de autorisatie minder strikt is. Dan ontstaat ineens een scenario waarin een normale gebruiker toegang krijgt tot data die niet voor hem bedoeld is.
Dat is het verschil tussen controleren of een applicatie aan de oppervlakte klopt en onderzoeken hoe het systeem zich gedraagt als iemand actief grenzen opzoekt.
Juist dat verschil bepaalt de waarde van een pentest.
Security begint bij de vraag wat er echt kan gebeuren
Een volwassen pentest kijkt niet alleen naar technische kwetsbaarheden, maar naar risico’s in context.
Dat betekent dat er wordt gekeken naar de manier waarop systemen samenwerken, hoe rechten zijn ingericht en welke aannames er in de applicatie zitten. Veel kwetsbaarheden ontstaan namelijk niet doordat één onderdeel volledig faalt, maar doordat meerdere onderdelen net niet goed op elkaar aansluiten.
Denk aan een gebruiker die meer rechten heeft dan nodig. Een API die data teruggeeft zonder voldoende filtering. Een configuratie die intern handig is, maar extern te veel blootstelt. Een beheerfunctie die niet zichtbaar is in de interface, maar technisch nog wel bereikbaar is.
Een goede pentest probeert dat soort situaties zichtbaar te maken.
Niet om een zo lang mogelijke lijst bevindingen te produceren, maar om duidelijk te maken waar de echte risico’s zitten.
Compliance en security hoeven elkaar niet tegen te spreken
Het is te makkelijk om compliance weg te zetten als nutteloos. Dat is het niet.
Compliance zorgt ervoor dat security aandacht krijgt. Het dwingt organisaties om maatregelen vast te leggen, verantwoordelijkheden te benoemen en risico’s bespreekbaar te maken. Zonder die druk zouden veel organisaties minder snel in beweging komen.
Maar compliance moet niet het eindpunt zijn.
Een pentest kan prima helpen om aan eisen te voldoen, zolang het niet alleen daarom wordt uitgevoerd. Het rapport is dan niet alleen bewijs voor een auditor, maar ook input voor betere beslissingen.
Welke risico’s moeten eerst worden opgelost? Welke bevindingen hebben echt impact? Waar is extra budget nodig? Welke systemen verdienen structureel meer aandacht?
Op die manier wordt een pentest meer dan een document in een auditmap.
Het wordt een manier om security concreet te maken.
Wat een sterke pentest oplevert
Een sterke pentest levert meer op dan een lijst kwetsbaarheden.
Het helpt technische teams begrijpen waarom iets misgaat. Niet alleen welke regel code of configuratie aangepast moet worden, maar ook welk risico daardoor ontstaat.
Voor management maakt een goede pentest zichtbaar welke scenario’s echt impact kunnen hebben. Dat is belangrijk, omdat securitybeslissingen vaak moeten concurreren met andere prioriteiten. Een abstracte kwetsbaarheid krijgt weinig aandacht. Een concreet scenario waarin klantdata toegankelijk wordt, doet dat wel.
Ook voor ontwikkelteams is die context waardevol. Een bevinding die goed wordt uitgelegd, voorkomt dat hetzelfde probleem later opnieuw ontstaat. Zeker bij fouten in autorisatie, businesslogica of API-ontwerp is dat belangrijk.
De waarde zit dus niet alleen in het vinden van kwetsbaarheden, maar in het verbeteren van hoe een organisatie naar risico kijkt.
Pentesten als onderdeel van risicobeheersing
Organisaties die pentesten alleen rond audits uitvoeren, lopen vaak achter de feiten aan.
Applicaties veranderen continu. Er komen nieuwe functionaliteiten bij, bestaande processen worden aangepast en systemen krijgen extra koppelingen. Ook configuraties veranderen, soms zonder dat dit direct als securityrisico wordt gezien.
Een pentest blijft daarom een momentopname.
Dat betekent niet dat je elke maand alles opnieuw moet testen. Wel betekent het dat pentesten beter werken wanneer ze worden gekoppeld aan logische momenten: grote releases, nieuwe koppelingen, wijzigingen in autorisatie of systemen waarin gevoelige data wordt verwerkt.
Voor sommige organisaties is één keer per jaar voldoende. Voor andere systemen is vaker testen logisch, bijvoorbeeld wanneer er veel wordt ontwikkeld of wanneer de impact van een kwetsbaarheid groot is.
De juiste frequentie hangt af van risico, niet van een vaste checklist.
Lees ook hoe vaak een pentest nodig is in verschillende situaties.
Van verplichting naar volwassen security
Compliance kan een prima aanleiding zijn om met pentesten te beginnen.
Maar als het daarbij blijft, wordt een pentest al snel een administratieve handeling. Er is getest, er is een rapport, en daarmee lijkt het onderwerp afgerond.
In werkelijkheid begint het daar pas.
De belangrijkste vraag is niet of er een pentest is uitgevoerd, maar wat de organisatie ervan heeft geleerd. Welke aannames bleken niet te kloppen? Welke risico’s waren groter dan verwacht? Zijn er systemen die meer aandacht verdienen? En welke bevindingen zeggen iets over structurele problemen in ontwerp, ontwikkeling of beheer?
Daar zit de echte waarde.
Een pentest moet niet alleen aantonen dat je iets hebt gedaan.
Een pentest moet laten zien waar je echt risico loopt.
Wil je weten of jouw pentest vooral compliance afdekt, of ook inzicht geeft in realistische aanvalsscenario’s? Dan kan een gerichte security check helpen om dat concreet te maken.