Hoe vaak moet u een penetratietest laten doen?
Het eerlijke antwoord begint met "dat hangt ervan af", maar daar koopt u niets voor. De werkbare vuistregel waar de meeste organisaties op uitkomen is simpel: minstens één keer per jaar, én na elke significante wijziging. Hieronder leest u waar die regel vandaan komt, wat als "significant" telt, wat compliance-kaders als PCI DSS en NIS2 precies vragen, en wanneer eens per jaar juist te weinig is.
Test minstens jaarlijks, plus na elke significante wijziging aan uw applicaties of infrastructuur. Verwerkt u gevoelige data, staan uw applicaties publiek online of brengt u vaak nieuwe releases uit, dan is vaker dan jaarlijks verstandig. En na het oplossen van bevindingen hoort altijd een hertest.
Waarom "jaarlijks" het uitgangspunt is
Een penetratietest is een momentopname. Hij laat zien hoe weerbaar uw systeem was op het moment van testen, met de code, de configuratie en de bekende kwetsbaarheden van dat moment. De dag erna kan dat beeld al schuiven: u brengt een nieuwe feature uit, een leverancier publiceert een patch, of er duikt een nieuwe kwetsbaarheid op in een component dat u gebruikt. Hoe verder u van de testdatum af raakt, hoe minder het rapport nog zegt over uw situatie van nu.
Daarom werkt vrijwel iedereen met een vaste ondergrens. Een jaar is geen magisch getal, maar een pragmatische balans: lang genoeg om betaalbaar te blijven, kort genoeg om niet jaren met onbekende gaten rond te lopen. De Britse NCSC verwoordt het kernpunt nuchter: als een test uw enige manier is om beveiliging te valideren, kunnen kwetsbaarheden lange tijd onopgemerkt blijven tussen twee tests in. Jaarlijks is dus een vloer, geen plafond.
De twee triggers: de kalender én de verandering
Frequentie zit niet in één getal, maar in twee onafhankelijke triggers die naast elkaar lopen. Eén op tijd, één op gebeurtenis.
De kalender
Een vaste, terugkerende test. Voor de meeste organisaties is dat één keer per jaar op de belangrijkste applicaties. Het vangt de sluipende veroudering op: nieuwe kwetsbaarheden in bestaande systemen die zonder code-wijziging toch zijn ontstaan.
De verandering
Een test na elke significante wijziging, ongeacht wanneer de vorige test was. Een grote release of migratie verandert het aanvalsoppervlak. Wachten op de jaarlijkse ronde betekent dat het nieuwe risico maanden ongetest blijft.
Wie alleen de kalender volgt, mist de risico's die ontstaan tussen twee jaarrondes in. Wie alleen op veranderingen test, mist de stille veroudering van systemen die níet zijn aangeraakt. De combinatie dekt allebei af.
Wat telt als een "significante wijziging"?
Dit is de term waar mensen over struikelen, want hij is bewust breed. Een goede toets: verandert deze aanpassing iets aan hoe een aanvaller binnen zou kunnen komen, of aan wat hij zou kunnen bereiken? Zo ja, dan is het significant. Concrete voorbeelden:
- Een nieuwe applicatie of een ingrijpend herbouwde bestaande applicatie
- Een migratie naar de cloud of een nieuwe hosting- of infrastructuuromgeving
- Wijzigingen in authenticatie of autorisatie (denk aan een nieuw inlogsysteem, SSO, of rollen en rechten)
- Aanpassingen aan netwerk- of segmentatie-instellingen, firewalls of toegangsregels
- Nieuwe betaal-, data- of integratiekoppelingen met externe partijen
- Een grote feature-release die nieuwe functionaliteit of nieuwe datastromen toevoegt
Kleine bugfixes en cosmetische aanpassingen vallen er niet onder. Het gaat om wijzigingen die het aanvalsoppervlak vergroten of verleggen. Twijfelt u of iets significant genoeg is? Dan is het dat meestal wel, of het is in elk geval het bespreken waard.
Niet zeker of een aanstaande wijziging een nieuwe test rechtvaardigt? Leg het kort voor in een gratis intake van 30 minuten. We bepalen samen wat wel en niet getest hoeft te worden, zonder verplichtingen.
Plan een gratis intake →Wat de compliance-kaders zeggen
Voor veel organisaties wordt de frequentie mede bepaald door een norm of wet waar ze aan moeten voldoen. De kaders verschillen, maar wijzen opvallend dezelfde kant op.
| Kader | Wat het vraagt over frequentie |
|---|---|
| PCI DSS (betaalkaartdata) | Een interne én externe penetratietest minstens elke 12 maanden en na elke significante wijziging. Voor service providers geldt daarnaast een segmentatietest elke 6 maanden. |
| NIS2 / Cyberbeveiligingswet | Geen vaste frequentie voorgeschreven, maar de zorgplicht verplicht u wel om de effectiviteit van uw maatregelen aantoonbaar te beoordelen. Een terugkerende pentest is daarvoor het gangbare bewijsinstrument. |
| ISO 27001 | Schrijft geen exact interval voor, maar verwacht regelmatige technische toetsing van kwetsbaarheden als onderdeel van het managementsysteem. In de praktijk vult men dit vaak jaarlijks in. |
De rode draad: zelfs waar geen exacte frequentie staat, verwacht elke norm dat u kunt aantonen dat uw beveiliging werkt en dat u dat met enige regelmaat opnieuw controleert. Meer over die NIS2-eis leest u in onze uitleg van de Cyberbeveiligingswet per 1 juli 2026.
Wanneer eens per jaar te weinig is
Jaarlijks is de ondergrens, niet het automatische antwoord. Een aantal factoren rechtvaardigt een hogere cadans:
- Gevoelige of gereguleerde data. Verwerkt u medische gegevens, betaaldata of grootschalige persoonsgegevens, dan is de impact van een lek groter en hoort de testfrequentie omhoog.
- Publiek bereikbare, kritieke applicaties. Alles wat permanent vanaf internet bereikbaar is, staat continu onder druk en verdient frequentere aandacht.
- Veel en snelle releases. Brengt u wekelijks of dagelijks nieuwe versies uit, dan veroudert een jaarlijkse test snel. Een combinatie van doorlopende controle en periodieke diepere tests past dan beter.
- Een eerder incident. Na een inbraak of bijna-incident is een gerichte test verstandig om te bevestigen dat het gat dicht is en dat er geen tweede route openstaat.
Organisaties in deze categorieën kiezen vaak voor doorlopende, geautomatiseerde monitoring of scanning tussen de handmatige tests door, met minimaal één grondige handmatige penetratietest per jaar op de belangrijkste systemen. Scanning vangt het bekende en het laaghangende fruit; de handmatige test vindt de logica- en ketenfouten die een scanner structureel mist.
De hertest hoort er standaard bij
Een vraag die in de frequentiediscussie vaak vergeten wordt: hoe vaak test u na het oplossen van bevindingen? Het antwoord is altijd. Een pentest die eindigt met een lijst kwetsbaarheden is pas half af. Pas een hertest bevestigt dat de doorgevoerde oplossingen de gaten echt dichten en er geen nieuwe bij introduceren. Dat is geen volledige nieuwe test, maar een gerichte verificatie van de eerdere bevindingen.
Bij Resync zit die hertest standaard bij de opdracht. U krijgt dus niet alleen een rapport, maar ook een hertest-verklaring waarmee u zwart op wit kunt laten zien dat de problemen zijn verholpen. Wilt u weten hoe zo'n rapport eruitziet? Bekijk het voorbeeld-pentestrapport.
Voor de meeste organisaties werkt dit ritme goed: één grondige handmatige pentest per jaar op de belangrijkste applicaties; een extra test na elke significante wijziging; doorlopende of periodieke scanning daartussen; en een hertest na elk hersteltraject. Heeft u te maken met PCI DSS, gevoelige data of veel releases, schroef de frequentie dan op vanaf die basis.
Conclusie
"Hoe vaak" is geen vraag met één getal als antwoord, maar de praktijk is goed te overzien. Minstens jaarlijks, plus na elke significante wijziging, plus een hertest na herstel. Verwerkt u gevoelige data of verandert er veel, dan gaat de frequentie omhoog. Het achterliggende doel is steeds hetzelfde: niet één keer bewijzen dat uw beveiliging werkt, maar dat met regelmaat opnieuw kunnen aantonen. Weet u niet zeker welk ritme bij uw situatie past? Een gratis intake geeft snel helderheid.
Bepaal samen de juiste testcadans.
In een gratis intake van 30 minuten bepalen we welke systemen wanneer getest moeten worden, afgestemd op uw risico en compliance. Vaste prijs, hertest inbegrepen.
Plan gratis intake →