2026-07-21 · GIDS · Het Offensive Technology-team

Hoe vaak moet u een penetratietest laten uitvoeren?

Kort antwoord: ten minste eenmaal per 12 maanden, en opnieuw na elke significante wijziging aan de systemen binnen de scope. Die regel uit twee delen, kalender plus wijziging, is de praktische ondergrens binnen elk framework waar een koper mee te maken krijgt. Alleen PCI DSS schrijft dit voor als een harde eis. SOC 2 en ISO 27001 noemen helemaal geen frequentie; ze zijn risicogebaseerd, en jaarlijks is simpelweg de frequentie geworden die auditors verwachten. Als uw omgeving wekelijks code oplevert of hoogwaardige gegevens verwerkt, is eenmaal per jaar een ondergrens om te behalen, geen doel om naar te streven.

De vraag wordt gesteld omdat "jaarlijks" klinkt als een regel die van hogerhand is opgelegd. Voor één standaard is dat zo. Voor de andere is het een conventie die is ontstaan rond risicogebaseerde formuleringen, en weten welke wat is voorkomt dat u te veel inkoopt of tekortschiet bij een audit. Dit is wat elke standaard daadwerkelijk zegt.

De korte versie, per framework

Vier dingen drijven de meeste kopers tot een test: een verwerker van creditcardgegevens, een SOC 2-rapport, een ISO-certificaat of een verzekeringsformulier. Slechts één daarvan schrijft een aantal voor.

De regel uit twee delen: kalender plus wijziging

Elk geloofwaardig antwoord over frequentie bestaat in feite uit twee gestapelde regels, en het overslaan van een van beide laat een gat achter.

Het kalenderdeel bestaat omdat een penetratietest een momentopname is. Het beschrijft de systemen binnen de scope, tijdens de testperiode, tegen de technieken in de rules of engagement. Er worden nieuwe categorieën kwetsbaarheden ontdekt, nieuwe exploits gepubliceerd, en uw team blijft opleveren. Een jaarlijkse test zet die klok terug voordat het beeld te verouderd raakt.

Het wijzigingsdeel bestaat omdat de kalender niet weet wanneer u uw authenticatieproces hebt herbouwd of een nieuwe API hebt blootgesteld. Een test uit maart zegt niets over de dienst die u in juni hebt gelanceerd. Dit is waarom elk serieus framework "ten minste elke 12 maanden" combineert met "en na elke significante wijziging", en het is het deel dat kopers het vaakst laten vallen.

Wat telt als een significante wijziging

PCI DSS laat "significant" over aan elke organisatie om te definiëren en te verdedigen, maar de voorbeelden uit de sector zijn consistent. Beschouw elk van deze punten als een aanleiding om de getroffen scope te testen, ongeacht wanneer de laatste jaarlijkse test heeft plaatsgevonden:

• Een grote applicatierelease of een herschrijving van een beveiligingsrelevant onderdeel.
• Een nieuwe internet-facing dienst, subdomein of API die het bereik van een aanvaller vergroot.
• Een cloudmigratie, of een materiële wijziging in de cloudarchitectuur of IAM.
• Een wijziging in authenticatie, single sign-on of sessieafhandeling.
• Een wijziging in netwerksegmentatie, firewallregels of de manier waarop omgevingen zijn geïsoleerd.
• Een overname of een nieuwe integratie van derden die het aanvalsoppervlak van een ander samenvoegt met het uwe.

De rode draad is blootstelling. Als de wijziging verandert wat van buitenaf bereikbaar is, hoe identiteit wordt bewezen, of waar een vertrouwensgrens ligt, beschrijft de laatste test niet langer de realiteit.

Wat elk framework daadwerkelijk zegt

PCI DSS v4.0 is degene die dit voorschrijft. Requirement 11.4 vereist interne en externe penetratietesten ten minste eenmaal per 12 maanden en na elke significante infrastructuur- of applicatie-upgrade of -wijziging, volgens een gedocumenteerde methodologie gebaseerd op een door de sector geaccepteerde aanpak zoals NIST SP 800-115. Waar segmentatie wordt gebruikt om systemen buiten de cardholder data environment te houden, wordt die segmentatie ten minste elke 12 maanden getest voor merchants en ten minste elke 6 maanden voor service providers, en worden bevindingen na herstel opnieuw getest. Dit is de duidelijkste "hoe vaak" die een van de frameworks u geeft.

SOC 2 noemt geen frequentie. De AICPA Trust Services Criteria zijn geschreven als doelstellingen, niet als schema's, dus er is geen regel die een jaarlijkse test vereist. In de praktijk verwachten auditors er ten minste jaarlijks een, getimed om binnen een Type 2-observatieperiode te vallen. We hebben in detail beschreven welke criteria naar testen verwijzen in vereist SOC 2 een penetratietest?

ISO/IEC 27001 is expliciet risicogebaseerd. Het vereist dat technische kwetsbaarheden worden beheerd en beheersmaatregelen worden geverifieerd, en het koppelt de frequentie aan uw eigen risicobeoordeling en behandelplan in plaats van aan een vaste kalender. Gecertificeerde organisaties komen uit op jaarlijks testen als verdedigbare basismethode, waarbij assets met een hoger risico vaker worden getest. Het aantal dient u zelf te verantwoorden, het is geen vaste waarde die u wordt aangereikt.

Cyberverzekering hangt af van de verzekeraar. Sommige polissen vragen of u regelmatig test en beschouwen "jaarlijks" als het verwachte antwoord; andere vragen er helemaal niet naar. De eerlijkste aanpak is om de specifieke aanvraag te lezen in plaats van aannames te doen, wat het thema is van heb ik een pentest nodig voor een cyberverzekering?

Wanneer eenmaal per jaar niet genoeg is

Jaarlijks is een ondergrens, en sommige omgevingen ontgroeien die snel. Test vaker wanneer:

• U continu software oplevert. Als de productieomgeving wekelijks verandert, is een jaarlijkse test elf maanden van het jaar verouderd. Teams in deze positie stappen over op testen per release voor kritieke paden, of op een continu testmodel, en behouden de volledige jaarlijkse test als ankerpunt.
• U hoogwaardige gegevens beheert. Betalingen, medische dossiers en grote hoeveelheden persoonsgegevens verhogen de kosten van fouten, wat frequentere testen rechtvaardigt van de systemen die hiermee in aanraking komen.
• U net bent geschrokken. Na een incident, een near-miss of een kritieke kwetsbaarheid in een onderdeel waarvan u afhankelijk bent, is het opnieuw testen van het getroffen gebied goedkoper dan aannemen dat de patch schoon was.

Niets van dit alles vervangt de jaarlijkse test. Het komt er bovenop, omdat een volledige, afgebakende opdracht door ervaren specialisten een andere diepgang heeft dan een gerichte her-test van één wijziging.

De fout: de datum behandelen als het opleverproduct

De meest voorkomende manier om de frequentie verkeerd aan te pakken, is door de pentest te behandelen als een certificaat met een vervaldatum, deze uit te voeren op de laatst mogelijke dag en niets te veranderen aan wat u hebt geleerd. Een test die u laat uitvoeren om een vinkje te zetten, wordt meestal zo nauw afgebakend dat u slaagt, en zo oppervlakkig dat de manier waarop een aanvaller echt binnenkomt wordt gemist. De datum op het rapport stelt de auditor tevreden; het maakt u niet moeilijker te hacken.

Tussen geplande testen door blijft uw blootstelling veranderen, of u nu kijkt of niet: een vergeten subdomein, een dienst die nooit openbaar had mogen zijn, inloggegevens in een datalek. Het continu kennen van uw extern aanvalsoppervlak is de voordelige aanvulling op periodieke diepgang, en het is niet dezelfde aankoop als een pentest. Als u nog aan het uitzoeken bent welke dienst u in de eerste plaats daadwerkelijk nodig hebt, check, scan of volledige pentest? geeft de verhoudingen aan.

Hoe vaak moet u een penetratietest laten uitvoeren? Snelle antwoorden

Hoe vaak moet u een penetratietest laten uitvoeren?

Ten minste eenmaal per 12 maanden, en opnieuw na elke significante wijziging aan de systemen binnen de scope. Die regel uit twee delen is de praktische ondergrens binnen de standaarden die voor kopers van belang zijn. Snel veranderende of hoogwaardige omgevingen moeten vaker testen, tot aan testen per release of continu.

Vereist PCI DSS een jaarlijkse penetratietest?

Ja. PCI DSS v4.0 Requirement 11.4 vereist interne en externe penetratietesten ten minste eenmaal per 12 maanden en na elke significante infrastructuur- of applicatiewijziging. Waar segmentatie de cardholder data environment isoleert, wordt segmentatie ten minste elke 12 maanden getest voor merchants en ten minste elke 6 maanden voor service providers.

Hoe vaak vereisen SOC 2 en ISO 27001 een pentest?

Geen van beide noemt een vaste frequentie. Beide zijn risicogebaseerd: SOC 2 laat het bewijs over aan uw auditor, en ISO 27001 koppelt testen aan uw risicobeoordeling. In de praktijk is jaarlijks de geaccepteerde frequentie geworden die auditors verwachten, getimed om binnen een SOC 2 Type 2-observatieperiode te vallen.

Wanneer moet u buiten de jaarlijkse cyclus testen?

Na elke significante wijziging: een grote release, een nieuwe internet-facing dienst of subdomein, een cloudmigratie, een wijziging in authenticatie of SSO, een netwerk- of segmentatiewijziging, of een overname. De laatste test beschreef de omgeving alleen zoals deze op die dag was.

Bronnen

• PCI Security Standards Council, PCI DSS v4.0 Requirement 11.4 (methodologie voor penetratietesten, frequentie en segmentatietesten).
• AICPA Trust Services Criteria (SOC 2), geschreven als risicogebaseerde doelstellingen zonder vaste testfrequentie.
• ISO/IEC 27001, risicogebaseerd beheer van technische kwetsbaarheden en verificatie van beheersmaatregelen.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, geciteerd als een geaccepteerde methodologie.

Gerelateerde artikelen

• Vereist SOC 2 een penetratietest?
• Heb ik een pentest nodig voor een cyberverzekering?
• Hoeveel kost een penetratietest?