“Hoe vaak moeten we eigenlijk een pentest laten doen?” is een van de meest gestelde vragen die we krijgen, en het eerlijke antwoord is: het hangt af van meer dan alleen de kalender. Een vast jaarlijks ritme is een goed startpunt, maar de juiste frequentie wordt bepaald door een combinatie van compliance-eisen, hoe vaak je systemen veranderen, en hoeveel risico een onopgemerkte kwetsbaarheid voor je organisatie betekent.

Het compliance-minimum: een vloer, geen plafond

Verschillende kaders stellen verschillende minimale frequenties:

PCI DSS 4.0: minimaal jaarlijks, plus een hertest na elke significante wijziging aan infrastructuur of applicaties binnen de kaartgegevensomgeving.
NIS2: schrijft geen exacte frequentie voor, maar verplicht organisaties om risicobeheersmaatregelen “passend” te houden bij het dreigingslandschap, wat in de praktijk neerkomt op minimaal jaarlijks testen voor de meeste middelgrote en grote organisaties.
ISO 27001: vereist periodieke technische beoordelingen; de meeste auditors verwachten een jaarlijkse pentest als onderdeel van het risicomanagementproces.
DORA (financiële sector): minimaal jaarlijkse basistesten, met voor significante instellingen een aanvullende driejaarlijkse TLPT-verplichting.

Deze minimumfrequenties zijn een compliance-ondergrens, geen beveiligingsadvies op maat. Voldoen aan de letter van de eis is niet hetzelfde als daadwerkelijk veilig blijven tussen de testmomenten in.

Wat je verandertempo zegt over hoe vaak je zou moeten testen

Een organisatie die een paar keer per jaar iets aan de infrastructuur wijzigt, heeft een andere realiteit dan een softwarebedrijf dat wekelijks naar productie deployt. Elke substantiële wijziging, een nieuwe feature, een nieuwe integratie, een migratie naar een andere cloudomgeving, kan nieuwe kwetsbaarheden introduceren die pas bij de volgende test aan het licht komen. Vuistregel: hoe sneller je verandert, hoe korter de afstand tussen “iets breekt” en “je weet dat het kapot is” zou moeten zijn.

Risicoprofiel weegt zwaarder dan sectorgemiddelde

Een organisatie die veel persoonsgegevens, financiële data of gezondheidsgegevens verwerkt, of die een aantrekkelijk doelwit is vanwege naamsbekendheid of maatschappelijke functie, doet er goed aan boven het compliance-minimum te gaan zitten. Dat betekent niet per se vaker een volledige pentest, maar vaak een combinatie: een jaarlijkse diepgaande test, aangevuld met continue of periodieke kwetsbaarhedenscans die nieuwe, bekende kwetsbaarheden sneller opsporen dan een jaarlijkse cyclus zou doen.

Een praktisch ritme dat voor de meeste MKB-organisaties werkt

Eén grondige externe pentest per jaar op de kernapplicaties en -infrastructuur.
Een gerichte hertest of deelscope na elke grote release of architecturale wijziging.
Doorlopende of maandelijkse kwetsbaarhedenscans tussen de pentests in, als vroege waarschuwing.
Een interne pentest (bijvoorbeeld op Active Directory) minimaal elke twee jaar, vaker als het interne netwerk sterk verandert.

Wat te vaak testen ook kan betekenen

Het omgekeerde komt ook voor: organisaties die jaarlijks een volledige, dure pentest laten uitvoeren op systemen die tussentijds nauwelijks veranderen, terwijl een groot deel van het budget beter besteed zou zijn aan het daadwerkelijk oplossen van eerdere bevindingen of aan continue monitoring. Testen om te testen, zonder dat de frequentie aansluit op verandertempo of risico, is zelden de beste besteding van een beveiligingsbudget. De vraag is dus niet alleen “hoe vaak”, maar ook “waar past welk type test het beste bij welk risico”.

Hoe MonkeysICT meedenkt over de juiste frequentie

We adviseren nooit standaard “zo vaak mogelijk”, maar kijken samen naar je compliance-verplichtingen, releasetempo en risicoprofiel om tot een realistisch en behapbaar testritme te komen. Dat voorkomt twee uitersten: te weinig testen en structureel risico lopen, of te veel testen zonder dat het extra inzicht oplevert.