Test at least once a year and after any significant change — that is the baseline nearly every framework adopts, including PCI DSS v4.0 (requirement 11.4). "Significant change" means a major release, new infrastructure, a cloud migration, an acquisition, or a new regulatory regime. Increase frequency with rate of change, risk and regulation: fast-shipping product teams and regulated financial entities often test every six months or continuously, pairing periodic deep penetration tests with continuous vulnerability scanning. Annual-only testing leaves long blind windows for anything that changes often.
// 01 The baseline: annually and after significant change
If you take one rule away, take this one: test at least every 12 months, and again whenever something significant changes. It is the cadence written into the major standards because it balances cost against the reality that risk drifts over time — new code ships, new services appear, dependencies age, and the test you ran last year slowly stops describing the system you run today. An annual test resets that picture; testing after change keeps it from going stale between annual cycles.
The trap is treating "annual" as the whole answer. Annual is a floor that suits a stable, lower-risk environment. For everyone else it is the starting point of a cadence, not the cadence itself.
// 02 What counts as a "significant change"?
This is where most programmes under-test. A significant change is any change large enough that your last test no longer reflects your attack surface. In practice that means:
- A major application release or a change to authentication, authorisation or payment flows
- New or substantially re-architected infrastructure, networks or segmentation
- A migration to (or between) cloud providers — see cloud penetration testing
- A merger or acquisition that brings in unfamiliar systems (M&A due diligence)
- Entering a new market or regulatory regime
- A security incident or breach — testing confirms the hole is closed and finds what else was missed
The underlying principle is simple: if the attack surface moved, the previous test is out of date.
// 03 Compliance-driven cadence
Where a framework applies, it usually sets the minimum for you. The most specific is PCI DSS.
| Framework | Minimum cadence |
|---|---|
| PCI DSS v4.0 (11.4) | External & internal pentest at least every 12 months and after significant change |
| PCI DSS segmentation (11.4.5) | Every 12 months (merchants); every 6 months (service providers) |
| SOC 2 | No fixed interval; annual testing is the norm auditors expect |
| ISO 27001 | Risk-based; typically annual, aligned to the ISMS cycle |
| Regional (CBB, SAMA, NCA) | Periodic to twice-yearly depending on the regulator and sector |
Use our requirements finder to see the exact obligation for your framework. Note the PCI distinction: service providers must test segmentation controls every six months, not annually.
// 04 Risk- and change-driven cadence
Beyond compliance, three factors push your cadence above the annual floor. Score yourself honestly on each:
Rate of change
Shipping weekly? An annual test covers 2% of your release history. Frequent change demands frequent testing, or continuous testing between annual deep-dives.
Risk & data sensitivity
Handling payment, health or large volumes of personal data raises both the likelihood you're targeted and the impact if breached. Higher stakes, shorter interval.
Threat exposure
Internet-facing, high-profile, or in a targeted sector (finance, government, critical infrastructure)? Assume more attention and test accordingly.
A useful rule of thumb: the more of these apply, the closer you should move from annual toward semi-annual or continuous.
// 05 Where continuous testing fits
The gap in an annual model is the eleven-and-a-half months between tests, during which new code and new services go unexamined. The modern answer is a layered cadence: continuous vulnerability scanning for constant hygiene, periodic human penetration tests for depth, and increasingly on-demand or continuous testing (PTaaS) triggered by releases. This is not "test more for its own sake" — it is matching examination frequency to change frequency, so nothing significant ships without being looked at. For lower-change environments, an annual test plus continuous scanning remains a perfectly defensible baseline.
// 06 Frequently asked questions
How often should you do a penetration test?
At least once a year and after any significant change (major release, new infrastructure, cloud migration, acquisition). This "annually and after significant change" baseline is the standard in most frameworks including PCI DSS. Higher-risk and fast-changing organisations test every six months or continuously.
Does PCI DSS require annual penetration testing?
Yes. PCI DSS v4.0 requirement 11.4 requires external and internal penetration testing at least every 12 months and after significant change. Segmentation testing (11.4.5) is every 12 months for merchants and every six months for service providers.
When should you test outside the annual cycle?
After any significant change: a major release or architectural change, new infrastructure, a cloud migration, an acquisition, entering a new regulatory regime, or after an incident. If the attack surface changed meaningfully, the previous test is out of date.
Is annual testing enough?
For low-change, lower-risk environments, an annual test plus continuous scanning is reasonable. For anything shipping frequently or handling sensitive data, annual leaves long blind windows — pair periodic deep tests with continuous scanning and on-demand testing.
// 07 References & standards
- PCI Security Standards Council, PCI DSS v4.0 — Requirement 11.4.1–11.4.7, including 11.4.5 segmentation testing intervals.
- NIST, SP 800-115 on testing frequency and post-change assessment.
- See our PCI DSS and requirements finder.