Alain Rees · 12-07-2026 · 11 min leestijd
Een penetratietest, in de praktijk meestal pentest genoemd, is een gecontroleerde aanval op je eigen systemen om kwetsbaarheden te vinden voordat een echte aanvaller dat doet. Een losse pentest levert een rapport op, maar pas een gestructureerde aanpak levert echte waarde. In dit artikel lees je waarom je pentest, hoe je een pentestbeleid en een pentestkalender opzet, wat er in een goed pentestrapport hoort en wat je daarna met de bevindingen doet.
In het kort
- Een pentest bootst een echte aanval na en laat zien welke kwetsbaarheden in jouw context daadwerkelijk uitbuitbaar zijn.
- Een pentestbeleid legt vast wat je test, hoe vaak, door wie en onder welke voorwaarden.
- Een pentestkalender plant de tests vooruit en koppelt ze aan wijzigingen en nieuwe systemen.
- Een pentestrapport is pas nuttig als je de bevindingen opvolgt, herstelt en laat hertesten.
- Je maakt het geheel aantoonbaar door de bevindingen te beheren in een register dat aansluit op je ISMS.
- Het pentestproces valt samen met de vier fasen van het Kantyra-model: signaleren, beoordelen, oplossen en aantonen.
Een pentest is een geautoriseerde, gecontroleerde poging om in je systemen binnen te dringen, uitgevoerd door een deskundige die denkt en handelt als een aanvaller. Het doel is niet om schade aan te richten, maar om te laten zien waar je zwak staat en wat de gevolgen zouden zijn als iemand die zwakte misbruikt.
Belangrijk is het verschil met een kwetsbaarhedenscan. Een scan is geautomatiseerd en vindt bekende kwetsbaarheden, maar zegt weinig over de werkelijke impact. Een pentest gaat verder. Een tester combineert losse zwakheden tot een echte aanvalsketen en laat zien hoe ver iemand kan komen. Zo weet je niet alleen dat er een kwetsbaarheid is, maar ook wat een aanvaller er in jouw omgeving mee kan bereiken.
Pentesten is om verschillende redenen verstandig, en soms zelfs noodzakelijk.
De belangrijkste reden is dat je kwetsbaarheden vindt voordat aanvallers dat doen. Je krijgt inzicht in echte, uitbuitbare zwakheden in plaats van een theoretische lijst, en je kunt die herstellen op een moment dat je zelf kiest.
Daarnaast is er de aantoonbaarheid. De norm ISO 27001 vraagt dat je technische kwetsbaarheden beheerst en je maatregelen periodiek toetst, en een pentest is de gangbare manier om dat te doen. Ook de zorgplicht uit de Cyberbeveiligingswet (Cbw) vraagt passende maatregelen, en die maatregelen moet je kunnen onderbouwen. Bovendien vragen klanten en opdrachtgevers steeds vaker om een recent testrapport voordat ze met je in zee gaan.
Ten slotte geeft een pentest je bestuur en je beveiligingsteam een realistisch beeld. Een geslaagde inbraak in een testomgeving maakt invoelbaar wat een lijst met risico's nooit overbrengt.
Niet elke pentest is hetzelfde. Voordat je test, bepaal je de reikwijdte, oftewel wat er precies wordt onderzocht en met hoeveel voorkennis.
Qua voorkennis zijn er drie varianten. Bij een test zonder voorkennis (blackbox) begint de tester met niets, net als een buitenstaander. Bij een test met volledige voorkennis (whitebox) krijgt de tester documentatie en toegang, waardoor die dieper kan graven. Een test met gedeeltelijke voorkennis (greybox) zit daartussenin en is in de praktijk het meest gebruikelijk.
Qua onderwerp kun je uiteenlopende zaken laten testen, zoals een webapplicatie, je externe of interne netwerk, een mobiele app, een cloudomgeving of het misleiden van medewerkers. Die laatste vorm, het testen of medewerkers gevoelig zijn voor misleiding, raakt aan je bewustwording en je beveiligingscultuur.
De keuze hangt af van wat je wilt weten en van je risico's. Een goede tester adviseert je hierin, maar de eindverantwoordelijkheid voor de reikwijdte ligt bij jou.
Een pentestbeleid maakt van losse tests een samenhangende aanpak. Het is het kader waarin je vastlegt hoe je organisatie met pentesten omgaat. Een goed pentestbeleid beschrijft in elk geval de volgende punten:
Dat laatste punt is cruciaal. Zonder afspraken over opvolging blijft een pentest een momentopname zonder gevolg.
Waar het beleid het kader vormt, plant de pentestkalender de tests concreet in. De kalender voorkomt dat pentesten ad hoc gebeuren en zorgt dat je kritieke systemen met een vaste regelmaat aan bod komen.
In de kalender leg je vast welk systeem wanneer wordt getest en door wie. Meestal test je je kritieke systemen ten minste jaarlijks, en daarnaast test je op vaste momenten, bijvoorbeeld voordat een nieuwe applicatie in productie gaat, na een ingrijpende wijziging of bij een grote nieuwe versie. Zo koppel je de kalender aan je wijzigingsbeheer en je planning van nieuwe versies, en test je op de momenten waarop het risico verandert.
Een kalender helpt ook bij de planning van je budget en van de beschikbaarheid van een geschikte partij, want goede testers zijn niet altijd op korte termijn beschikbaar.
Een pentest doorloopt doorgaans een vast aantal fasen. Als je weet hoe die eruitzien, kun je een test beter begeleiden.
De hertest wordt vaak vergeten, terwijl die je pas de zekerheid geeft dat een probleem echt is opgelost.
Het pentestrapport is het tastbare resultaat, maar de kwaliteit ervan bepaalt hoeveel je eraan hebt. Een goed rapport bevat de volgende onderdelen:
Een rapport dat alleen een lijst met kwetsbaarheden geeft, zonder impact en prioritering, dwingt je om zelf het echte werk te doen. Vraag daarom vooraf om deze onderdelen, zodat je het rapport meteen kunt gebruiken.
Hier zit de stap die het verschil maakt tussen afvinken en echt veiliger worden. Een rapport is pas waardevol als je de bevindingen opvolgt.
Per bevinding wijs je een eigenaar aan en bepaal je een hersteltermijn op basis van de ernst. Een kritieke bevinding pak je direct op, een lichte bevinding kan wachten tot een geschikt moment. Na het herstel laat je een hertest uitvoeren om te bevestigen dat het probleem echt weg is. De zwaarste bevindingen escaleer je naar je risicoregister, zodat ze op bestuurlijk niveau zichtbaar blijven tot ze zijn opgelost.
Je kunt pentestrapporten opslaan in een map, maar dan verlies je het overzicht zodra je meer dan een paar tests per jaar laat doen. De basis van een volwassen aanpak is daarom een bevindingenregister, oftewel een actueel overzicht van elke bevinding, met de ernst, de eigenaar, de hersteltermijn, de status en de hertestdatum.
In Kantyra registreer je elke bevinding uit een pentest met de bron pentest, of importeer je het hele rapport in één keer uit Excel, met het rapport zelf als bewijsstuk eraan vast. Vanuit dat register lopen de lijnen naar de rest van je beheersing. Je koppelt een bevinding aan de geraakte assets en aan de risico's die zij raakt, en bij een bevinding met ernst hoog of kritiek maakt Kantyra automatisch een herbeoordelingstaak voor het gekoppelde risico aan, net als bij een incident. Zo escaleert een zware kwetsbaarheid vanzelf naar je risicoregister in plaats van in een rapport te blijven liggen. De herstelactie leg je vast bij de bevinding zelf, met een eigenaar en een termijn, en na het herstel plan je de hertest met een eigen hertestdatum: nadert die, dan staat de hertest automatisch als taak klaar, zodat de vaakst vergeten stap niet meer wordt overgeslagen. De beveiligingsmaatregelen die uit een test volgen beheer je als maatregelen. Zo sluit pentesten direct aan op je informatiebeveiliging en risicomanagement (ISMS) in lijn met ISO 27001.
Van alle onderwerpen in deze reeks begint pentesten het duidelijkst onderaan het model, bij signaleren. Een pentest is namelijk in de eerste plaats een signaal: hij brengt aan het licht wat er werkelijk mis kan gaan.
Het begint bij signaleren: de kalender plant de test, die test vindt de kwetsbaarheden, en je registreert elke bevinding met de bron pentest. Daarna volgt beoordelen: je weegt elke bevinding op ernst, en de zwaarste escaleer je naar het risicoregister. In de fase oplossen zorgt het pentestbeleid voor de systematische aanpak, herstel je per ernst met een eigenaar en een termijn, en laat je hertesten; de hertestdatum wordt daarbij bewaakt. En in de fase aantonen vormen het bevindingenregister, het bewijs van de hertest en het rapport samen het dossier voor de auditor en de klant.
Precies daarom is een pentestrapport zo vaak een dood document: veel organisaties blijven steken in signaleren en laten het signaal nooit door de cyclus lopen. Een pentest levert pas waarde op als de bevinding doorwerkt naar een risico, een herstelactie en uiteindelijk het bewijs dat het probleem echt weg is. Het model dwingt die doorloop af, zodat de test geen eindpunt is maar een startpunt.
Je kunt je pentestbeleid, je kalender en je bevindingen in losse bestanden bijhouden, en als start is dat verdedigbaar. Maar naarmate je meer test en de toezichthouder of je klant om aantoonbaarheid vraagt, loop je tegen dezelfde grenzen aan als bij elk ander nalevingstraject. Losse bestanden raken uit de pas, en je mist het overzicht en de historie die je nodig hebt.
In een GRC-platform beheer je het pentestbeleid, de planning en het bevindingenregister binnen één omgeving. Elke bevinding heeft een eigenaar, een status, een hersteltermijn en een hertestdatum, en de koppeling met je risicoregister en je taken voorkomt dat een openstaand risico uit beeld raakt.
Met Kantyra beheer je je pentestproces in dezelfde omgeving als je ISMS. Het pentestbeleid leg je vast als beleidsdocument met versiebeheer en goedkeuring, de terugkerende test plan je als effectiviteitstest op de betrokken maatregel (de geplande testdatum met automatische herinnering vormt je kalender), en het rapport verwerk je in het bevindingenregister. Of je pentesten nu als losse activiteit ziet of als onderdeel van je bredere beveiliging, je bevindingen, je risico's en je herstelacties komen samen op één plek, in lijn met ISO 27001. Zo maak je je pentestproces net zo aantoonbaar als de rest van je beveiliging.
Wat is het verschil tussen een pentest en een kwetsbaarhedenscan? Een scan is geautomatiseerd en vindt bekende kwetsbaarheden. Een pentest gaat verder en laat zien of die kwetsbaarheden in jouw context echt uitbuitbaar zijn en wat de impact is. Een scan is breed en snel, een pentest is diep en gericht.
Hoe vaak moet je pentesten? Voor kritieke systemen is ten minste jaarlijks gebruikelijk. Daarnaast test je op vaste momenten, bijvoorbeeld voordat een nieuwe applicatie in productie gaat of na een ingrijpende wijziging. De juiste frequentie hangt af van je risico's.
Ben je verplicht om te pentesten? De wet schrijft niet letterlijk een pentest voor, maar ISO 27001 en de zorgplicht uit de Cbw vragen dat je je maatregelen toetst en technische kwetsbaarheden beheerst. Een pentest is daarvoor de gangbare manier, en klanten stellen het vaak contractueel verplicht.
Wie mag een pentest uitvoeren? Een interne ploeg kan testen, maar een onafhankelijke externe partij geeft een objectiever beeld en meer waarde tegenover klanten en toezichthouders. In alle gevallen zijn duidelijke autorisatie en afspraken vooraf noodzakelijk.
Wat doe je met de bevindingen? Je wijst per bevinding een eigenaar aan, herstelt op basis van de ernst binnen een termijn, en laat hertesten. De zwaarste bevindingen escaleer je naar je risicoregister, en je houdt alles bij in een bevindingenregister.
Wil je je pentestproces niet in losse bestanden beheren, maar in één omgeving die aansluit op je informatiebeveiliging? Met Kantyra leg je je pentestbeleid vast als beleidsdocument, plan je de terugkerende test als effectiviteitstest op de betrokken maatregel en verwerk je het rapport in het bevindingenregister, gekoppeld aan je risico's en je taken, in lijn met ISO 27001. Zo maak je je pentestproces aantoonbaar en overzichtelijk, en raakt geen enkele bevinding uit beeld. Vraag een demo aan en ontdek hoe je pentesten bovenop je bestaande ISMS inricht.
Kantyra is een Nederlands ISMS- en GRC-platform waarmee organisaties hun informatiebeveiliging, risicomanagement en naleving aantoonbaar beheren, in lijn met normen als ISO 27001 en ISO 22301 en met wetgeving als de AVG, de Cyberbeveiligingswet en de AI-verordening.
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demoDe AVG stelt regels aan het verwerken van persoonsgegevens en draait om één kerngedachte: de verantwoordingsplicht. Dit artikel behandelt de grondbeginselen, de zes grondslagen, de rechten van betrokkenen en de datalekmeldplicht, en laat zien hoe de naleving samenvalt met de vier fasen van het Kantyra-model.
De AI-verordening werkt risicogebaseerd: hoe groter het risico van een AI-systeem, hoe zwaarder de eisen. Dit artikel behandelt de vier risiconiveaus, je rol als aanbieder of gebruiksverantwoordelijke, de tijdlijn en de AI-geletterdheidsplicht, en laat zien hoe de naleving samenvalt met de vier fasen van het Kantyra-model.
Compliance-management heeft een stoffig imago van lijstjes afvinken, maar goed ingericht is het het proces dat eisen uit wetgeving, normen en contracten vertaalt naar één maatregelenset met bewijs. Dit artikel beschrijft de vijf stappen, de rolverdeling, en waar het proces in het Kantyra-model zit.