Planning a pentest
How often should you pentest? Standards, triggers and a schedule
How often should you pentest? The PCI DSS 11.4 wording, SOC 2 and ISO 27001 position, ten changes that should trigger a test, and a schedule table by profile.
Short answer
PCI DSS v4.0.1 asks for internal and external penetration tests at least once every 12 months and after any significant change. SOC 2 and ISO 27001 set no fixed interval. For software teams the practical rule is: test before launch, after meaningful changes to authentication, authorization, data handling or architecture, and at least once a year.
Test at least once a year, and again after any significant change. That is the wording of PCI DSS, the one major standard that sets a frequency. For most software teams, "significant change" is the useful part, because a yearly test cannot protect code that shipped last week.
Below are the standards' wording and a way to decide your own schedule.
What does PCI DSS say about pentest frequency?#
PCI DSS v4.0.1 requires internal and external penetration tests at least once every 12 months, and after any significant infrastructure or application change. These are requirements 11.4.2 (internal) and 11.4.3 (external) in the standard's numbering.
As of November 2026, v4.0.1 is the published version. PCI SSC published it on 11 June 2024 as a limited revision and retired v4.0 on 31 December 2024. In June 2026 the council opened a request for comments on the next iteration, with no new version date stated.
The rest of requirement 11.4 matters for frequency too:
| Requirement | What it asks |
|---|---|
| 11.4.1 | A documented pentest methodology. Results kept at least 12 months. |
| 11.4.2 | Internal test: every 12 months and after significant change. |
| 11.4.3 | External test: every 12 months and after significant change. |
| 11.4.4 | Exploitable findings are corrected, and the test is repeated to verify the fix. |
| 11.4.5 | If segmentation isolates the card data environment: test segmentation every 12 months and after changes. |
| 11.4.6 | Service providers only: segmentation tests every six months. |
| 11.4.7 | Multi-tenant service providers support customers' external tests. |
PCI SSC's own summary of changes confirms 11.4.1, 11.4.4 and 11.4.7. The interval wording for 11.4.2, 11.4.3, 11.4.5 and 11.4.6 comes from vendor pages that quote the standard. The standard PDF is behind a click-through gate. Read the exact text, and ask your QSA which items apply. Our guide on PCI DSS penetration testing requirements goes deeper.
Requirement 11.4 has no merchant-level condition in the sources we read. Merchant level decides how you validate, not whether a requirement applies. Ask your QSA.
Do SOC 2 and ISO 27001 set a frequency?#
No fixed interval. SOC 2's Trust Services Criteria do not name penetration testing as a required activity. Auditors and customers often ask for a recent test, usually one from the last 12 months, but the criteria set no such rule. See does SOC 2 require penetration testing.
ISO/IEC 27001 asks you to manage technical vulnerabilities and test security. It leaves the method and the interval to your risk assessment.
When a customer contract names a frequency, that frequency is your requirement.
What should trigger a pentest between yearly tests?#
Test after a change that alters what an attacker can reach. The standard's phrase "significant change" is not defined in a way that fits every team, so write your own list. This starting set suits web apps, APIs and SaaS products.
| Trigger | Why it matters |
|---|---|
| New or rebuilt login, SSO, MFA or password reset | Authentication flaws give access to everything |
| New role, permission model or admin area | Access-control bugs follow permission changes |
| Multi-tenant change: new tenant model, sharing, invitations | Tenant leaks are costly |
| New public API or major API version | New endpoints bring new object-level checks |
| Payment, billing or entitlement logic | Business logic flaws turn into money loss |
| File upload, import, export or webhooks | Common source of injection and data exposure |
| Move of hosting, cloud account or framework | Defaults and settings change |
| Acquisition or new integration with partner data | New trust boundary |
| Major incident or a critical finding in a related system | Check for the same flaw elsewhere |
| Customer or auditor request | A contract or deadline is a trigger too |
Small UI changes, copy edits and most bug fixes rarely need a test. Group them into the next planned test.
How do you choose an interval? A decision table#
Start from your release pace and your data risk. The table gives a default for each profile. These are our suggestions, not standard requirements.
| Your profile | Suggested pattern |
|---|---|
| Pre-launch product, first public release | One test before launch. See pre-launch security testing. |
| Ships weekly, handles customer data | Full test yearly, plus a scoped test after each meaningful change set |
| Ships monthly, regulated or card data | Yearly test and tests after significant change, per the standard |
| Rarely changes, low-risk data | Yearly test, or after any change to login or data handling |
| Enterprise customers ask for reports | Test on a rhythm that keeps the report under 12 months old |
Teams that ship often get more from a recurring plan with scoped tests after releases than from one large test. Recurring penetration testing describes how that works at Excession Labs: we scope deltas, not constant testing.
How do you keep a schedule from slipping?#
Tie the test to events you already track. Put a "security test needed?" check in your release review, use the trigger list above as the questions, and name an owner.
Plan the fix time too, because a test helps only if the fixes land and are verified. PCI DSS 11.4.4 expects the test to be repeated to verify corrections, so leave time for fixes and a retest. See after the pentest: remediation and retest.
What about frequency surveys?#
Vendor surveys report how often their respondents test. The numbers differ by survey and by who was asked. For example, Cobalt's 2025 report with Cyentia lists 27% of respondents testing annually, 15% semi-annually and 30% quarterly. That is one vendor's sample of 450 respondents, not a norm for your company. Use your own release pace, data risk and contracts.
A short worked example#
Demonstration only
This is a demonstration. No real customer system was tested. Harbor Notes is a fictional SaaS app that ships twice a week and stores customer notes. A customer contract asks for a pentest "at least annually".
The team plans one full grey box test each year in March, and their release review asks the trigger questions. In June they rebuild their invitation flow, which changes who can join a tenant. That is a tenant-boundary change, so they book a scoped test of invitations and roles. In November they add a public API and test the new endpoints before the release. Over the year they run one full test and two scoped tests, and always hold a report under 12 months old.
Need a pentest you can act on?
Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.
Questions
Is once a year enough?
It meets the time interval in PCI DSS. It does not cover the weeks between tests: if you ship fast, a flaw can go live a week after the test ended. Add tests after significant changes.
Do I need a new pentest for every release?
No. Most releases are small. Test when a release changes something an attacker cares about: login, permissions, tenant boundaries, payments, file handling or new public endpoints. A scoped test of the changed area is often enough.
Does a vulnerability scan replace a pentest between tests?
A scan is a useful routine check, but it does not do the same job. It finds known patterns. It does not test business logic or chain issues. PCI DSS lists vulnerability scans and penetration tests as separate requirements.
What is an industry average for pentest frequency?
We do not quote one. Survey samples differ in size, buyer type and wording, and vendors run most of the surveys. Set your interval from your own release pace, risk and contracts.
Sources
- PCI SSC blog: Just Published: PCI DSS v4.0.1 (checked 9 November 2026)
- PCI DSS v3.2.1 to v4.0 Summary of Changes (r1, May 2022) (checked 9 November 2026)
- PCI SSC Information Supplement: Penetration Testing Guidance v1.1 (checked 9 November 2026)
- PCI SSC blog: Request for Comments PCI DSS v4.0.1 (3 June 2026) (checked 9 November 2026)