5 oktober 2026 · 8 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Hoe Vaak Moet U een Pentest Laten Uitvoeren? De Cadans Die Elk Kader Verwacht
Eén keer per jaar is het antwoord dat de meeste organisaties geven. Het is het minimum, niet het doel. Dit is wat elk kader werkelijk verwacht, wat een test tussen twee cycli uitlokt, en hoe u een cadans kiest die een auditor accepteert en een aanvaller niet voorbijrent.
Het korte antwoord
Minimaal eenmaal per twaalf maanden voor elk systeem dat ertoe doet, plus een test na elke significante wijziging, plus een hertest na elke herstelronde. Dat is de basis waar alle grote kaders op uitkomen. Organisaties met frequente releases, gereguleerde data of een actief dreigingsprofiel testen vaker, doorgaans met een volledige jaarlijkse test en lichtere applicatietests gekoppeld aan releases of kwartalen.
Waarom jaarlijks alleen de ondergrens is: de gemiddelde applicatie krijgt tientallen wijzigingen per jaar, de infrastructuur eronder verandert met elke cloudupdate, en de technieken van aanvallers bewegen sneller dan beide. Een test van elf maanden geleden beschrijft een systeem dat niet meer bestaat.
Wat elk kader verwacht
De expliciete of feitelijke cadans per kader, met de bepaling die hem bepaalt.
| Kader | Verwachte cadans | Bron |
|---|---|---|
| PCI DSS v4.0.1 | Interne en externe test elke 12 maanden en na significante wijziging; segmentatie elke 12 maanden (6 voor dienstverleners) | Requirements 11.4.2, 11.4.3, 11.4.5, 11.4.6 |
| DORA | Alle ICT-systemen achter kritieke of belangrijke functies minimaal jaarlijks getest; TLPT elke 3 jaar voor aangewezen entiteiten | Artikel 24, 26 |
| ISO 27001:2022 | Geen vaste frequentie; gedocumenteerde risicogebaseerde cadans, jaarlijks geaccepteerd door certificerende instellingen | A.8.8, A.8.29, hoofdstuk 9.1 |
| SOC 2 | Jaarlijks volgens praktijk; test, herstel en hertest binnen de Type II-observatieperiode | CC4.1, CC7.1 points of focus |
| NIS2 | Geen vaste frequentie; beleid om de effectiviteit van maatregelen te beoordelen, jaarlijks geaccepteerd | Artikel 21 lid 2 onder f |
| HIPAA | Periodieke evaluatie nu; voorgestelde Security Rule 2025 stelt 12 maanden voor testen en 6 voor scannen | 45 CFR 164.308(a)(8); NPRM 2025 |
| Cyberverzekering | Jaarlijkse test steeds vaker een dekkingsvoorwaarde | Polisvragenlijsten |
Wat telt als significante wijziging
Elk kader zegt: test na significante wijziging, en laat de definitie aan u. Leg hem vast. Dit zijn de triggers die wij het vaakst zien.
- Een nieuwe klantgerichte applicatie, portaal of API, of een grote release die authenticatie, autorisatie of betaalstromen wijzigt
- Cloudmigratie, nieuwe cloudaccounts of een wissel van hostingprovider
- Wijzigingen in netwerksegmentatie, VPN, remote access of identity provider
- Fusies, overnames of onboarding van een nieuwe derde met netwerk- of datatoegang
- Een beveiligingsincident of datalek, voordat het incident wordt gesloten
- Een nieuwe complianceverplichting (onder DORA of NIS2 vallen, een nieuw SOC 2-rapport, wijziging van PCI-scope)
- Twaalf maanden sinds de laatste test, ongeacht al het andere
Een testkalender die werkt
Drie niveaus, geschaald naar risico. De meeste organisaties passen in een ervan.
Niveau 1: één jaarlijkse cyclus
Past bij organisaties met een stabiele omgeving en weinig releases. Eén gecombineerde externe en interne test per jaar, gepland minimaal drie maanden voor de auditdatum zodat herstel en hertest binnen het venster passen. Voeg een gerichte test toe als een significante wijziging landt.
Niveau 2: jaarlijks plus releasegedreven
Past bij SaaS- en productbedrijven. De jaarlijkse infrastructuurtest blijft, en elke grote applicatierelease krijgt een gerichte applicatietest. Een kwartaalcadans is gangbaar. Dit is het patroon dat SOC 2 Type II- en PCI DSS-auditors graag zien.
Niveau 3: doorlopend programma
Past bij gereguleerde organisaties of organisaties met hoge blootstelling: banken en verzekeraars onder DORA, zorg, vitale infrastructuur onder NIS2. Jaarlijkse volledige test, applicatietests per kwartaal, doorlopend kwetsbaarhedenscannen, een red team of TLPT elke een tot drie jaar, en hertesten binnen dertig dagen na elke herstelronde.
De test plannen ten opzichte van de audit
De meest gemaakte planningsfout is testen in de maand voor de audit. Het rapport komt binnen met open bevindingen, de auditor noteert ze en het herstelbewijs ontbreekt. Plan de jaarlijkse test drie tot vier maanden voor de auditdatum, herstel in de maand erna, hertest, en ga de audit in met gesloten bevindingen. Zorg bij SOC 2 Type II dat test, herstel en hertest alle binnen de observatieperiode vallen.
Hoe HackersHub terugkerende programma's uitvoert
Wij spreken de kalender eenmalig af: de jaarlijkse volledige test, de releasegedreven applicatietests en een vast hertestvenster. De scope wordt elke cyclus herzien in plaats van gekopieerd, zodat nieuwe systemen in het programma komen zodra ze live gaan, en rapporten worden gekoppeld aan elk kader waarover u rapporteert. Eén lead tester beheert het account, en dat maakt vergelijking van jaar op jaar betekenisvol.
Veelgestelde vragen
Kies een cadans die uw auditor accepteert
Wij bouwen de testkalender met u, scopen elke cyclus opnieuw en houden één lead tester op uw account. Praat met een expert.