How Often Should You Perform Penetration Testing?
A risk question, not a calendar question.
“How often should we run a penetration test?” is one of the most frequently asked, and most poorly answered, questions in cyber security buying. The conventional answer — “once a year” — has the appeal of being simple and the drawback of being wrong for most organisations.
Annual testing became the default because PCI DSS happens to require it, and because annual cycles fit comfortably into audit calendars. Neither of those reasons has much to do with risk. The right testing frequency depends on what is changing in your environment, how exposed those changes are, what regulators expect, and what would actually happen if a finding sat unaddressed for nine months. This article explains how to think about cadence properly and how to build a testing programme rather than buying a series of unrelated annual tests.
Why “annual” is rarely the right answer on its own
An annual penetration test produces a snapshot of a moment in time. It tells you something useful about the environment as it existed during the testing window. It tells you almost nothing about the environment two, six or eleven months later — by which point the application has been redeployed dozens of times, the cloud configuration has drifted, three new internet-facing services have appeared, and an acquired business has brought its own infrastructure into scope.
Annual testing as a standalone control is best understood as a compliance artefact rather than an assurance mechanism. It produces a report you can hand to an auditor or a customer; it does not produce ongoing confidence that your environment is secure right now. For most modern organisations, that gap matters.
The factors that actually determine cadence
A defensible testing cadence is a function of several inputs working together rather than a single number applied uniformly across the estate.
- Change velocity. How often does the application or infrastructure change in ways that could introduce new exposure? A SaaS product deploying weekly has fundamentally different testing needs from a stable internal LOB application that changes twice a year.
- Exposure level. Internet-facing systems warrant more frequent assurance than internal ones. An exposed customer portal is a candidate for quarterly or per-release testing; a back-office application reachable only from the corporate network is not.
- Data sensitivity. Systems handling personal data, financial data, health data or other sensitive categories carry higher consequence on compromise. Higher consequence justifies higher frequency.
- Regulatory exposure. PCI DSS, ISO 27001, SOC 2, FCA/PRA operational resilience, DORA and the forthcoming Cyber Security and Resilience Bill all set expectations. Some are explicit about frequency; most expect testing proportionate to risk.
- Incident history. Past incidents — your own or your sector’s — are evidence that more frequent assurance is warranted on the affected attack surface.
- Contractual and insurance obligations. Enterprise customers, particularly in regulated sectors, frequently require evidence of regular testing as part of vendor due diligence. Cyber insurers increasingly do too.
- Material change events. Architectural changes, cloud migrations, identity provider changes, mergers and acquisitions, and major refactors all justify out-of-cycle testing regardless of the regular cadence.
A useful framing: testing frequency should be set so that the time between tests is shorter than the time it takes for material changes to accumulate in scope. If your environment moves faster than your testing cycle, your assurance is structurally out of date.
Industry benchmarks by maturity
In practice, organisations cluster around three broad cadence patterns:
Annual (baseline)
Appropriate for stable environments with low change velocity, limited internet exposure and modest regulatory load. Annual testing as a baseline is defensible when paired with continuous vulnerability scanning and external attack surface monitoring. As a standalone control it is increasingly insufficient.
Semi-annual (moderate maturity)
Common for SaaS providers, professional services firms, mid-market financial services and organisations with material online customer-facing operations. Two engagements per year, often split between application and infrastructure testing, with continuous monitoring filling the gap.
Quarterly or per-release (high assurance)
Appropriate where products release frequently, regulators expect ongoing assurance, or the consequence of compromise is severe enough that two snapshots per year leave too much risk uncovered. Common in regulated financial services, regulated healthcare, identity providers and material critical national infrastructure operators.
What the major regulatory frameworks actually require
Specific frameworks vary in how prescriptive they are. The summary below is for orientation — if you need to satisfy a regulator, take advice on the specifics that apply to you.
- PCI DSS 4.0. Penetration testing required annually and after any significant change. Segmentation testing required at least annually for service providers (every six months) and annually for merchants.
- ISO 27001 (Annex A 8.8). Vulnerabilities to be identified at planned intervals and after significant change. Frequency not prescribed but expected to be risk-justified.
- SOC 2. Testing frequency is driven by the chosen control set and the audit cycle. Most organisations test at least annually.
- FCA / PRA operational resilience. Important business services must be tested regularly and severely. Testing is expected to be threat-led where appropriate.
- DORA (financial services in scope). Threat-led penetration testing (TLPT) every three years for significant entities, plus regular testing of ICT systems and tools.
- NCSC Cyber Assessment Framework. Used for UK CNI operators; expects ongoing assurance of important systems, with penetration testing as one component.
- Cyber Essentials Plus. Annual reassessment with a technical audit of controls; not a full penetration test, but a recurring assurance touchpoint.
In all cases, the regulator is looking for evidence that testing frequency is proportionate to risk and that findings translate into action. A test report that sits unread is not assurance; it is a procurement event.
Building a programme rather than buying tests
A mature approach treats penetration testing as one component of an ongoing assurance programme, not as a standalone product purchased annually. The structure that works for most organisations:
- Tier your assets. Crown jewels (tier-0), production internet-facing (tier-1), production internal (tier-2), and non-production (tier-3). Different tiers warrant different cadences.
- Pair penetration testing with continuous controls. Vulnerability scanning, external attack surface management and configuration monitoring should run continuously between tests. These are not substitutes for testing — they tell you about a different set of risks.
- Schedule testing around material change. Plan an engagement before, or shortly after, any material architectural change, cloud migration, identity-provider change or acquisition. Do not wait for the next scheduled cycle.
- Maintain testing relationships. A tester who has seen your environment over multiple engagements brings context that a one-off provider cannot. There is real value in continuity, particularly for complex environments.
- Measure remediation, not findings. A backlog of unactioned findings is evidence that the testing cadence exceeds the remediation capacity. Either fix that gap or reduce the cadence to something the organisation can absorb.
The goal is a programme where testing produces actionable evidence at a rate the organisation can actually act on, with continuous controls covering the gaps between formal engagements.
Frequently asked questions
Is annual penetration testing enough?
For low-change, low-exposure environments paired with continuous scanning and EASM, annual testing can be defensible. For higher-change or higher-exposure environments, twice-yearly or quarterly testing is more common.
What does PCI DSS actually require?
Annual penetration testing and additional testing after any significant change. Service providers performing segmentation must test segmentation at least every six months.
How often should SaaS organisations test?
Most mature SaaS providers test the application quarterly or per major release, with annual reviews of cloud configuration, identity and external infrastructure.
Should we test after a cloud migration?
Yes — cloud migration changes the attack surface materially. Test after the migration is complete and the configuration is stable, not before.