The appropriate frequency for penetration testing depends on your systems, the risks they face and any applicable compliance requirements. Annual testing is a common starting point, but it may not be sufficient on its own if your environment changes significantly during the year.
PCI DSS specifies penetration testing requirements, while ISO 27001 and SOC 2 leave more room for risk-based decisions and the expectations of auditors and customers. Understanding those differences helps you plan a testing schedule that meets your obligations without commissioning unnecessary assessments.
What the compliance frameworks require
The main difference between these frameworks is how specifically they address penetration testing frequency. PCI DSS sets explicit requirements. ISO 27001 does not prescribe a specific schedule, while SOC 2 requirements depend on the organisation's controls and the criteria being assessed.
| Framework | What it says about penetration testing | Frequency |
|---|---|---|
| PCI DSS | Requires internal and external penetration testing of the cardholder data environment, along with segmentation testing where this is used to reduce scope | At least every 12 months and after significant changes. |
| ISO 27001 | Does not explicitly mandate penetration testing. Testing can support technical vulnerability management under Annex A control 8.8 | No universal frequency is specified. The approach should reflect your risk assessment and security objectives |
| SOC 2 | Does not mandate penetration testing by name | Testing may be used to demonstrate that security controls operate as intended. Expectations depend on the scope of the examination and the controls being assessed |
Our guide to penetration testing for compliance covers the different frameworks in more detail. Healthcare organisations and suppliers should also consult our healthcare penetration testing page for relevant NHS requirements, if appropriate.
Compliance is only one consideration, and your auditor, assessor, or certification body can clarify what evidence they would expect and how frequently it should be provided. Confirm those expectations before agreeing your testing schedule.
When should you test before the next annual assessment?
A penetration test describes the systems and configuration assessed at a particular point in time. If those systems change afterwards, the original findings may not cover the new functionality, permissions or infrastructure.
An additional assessment may be appropriate after changes such as:
- A significant product release: new functionality, a major feature or a new application area that introduces additional attack paths.
- An infrastructure migration: moving to a new hosting provider, cloud environment or network architecture.
- Changes to authentication: introducing a new identity provider or substantially changing sign-in and access-control processes.
- A new third-party integration: connecting a service that handles production data or introduces new trust relationships.
- Changes to network segmentation or compliance scope: particularly where those changes affect the systems covered by a security assessment.
- A security incident: testing may help establish whether the exploited weakness has been addressed and whether related attack paths remain.
Not every change requires a full penetration test. Depending on the risk, a targeted assessment of the affected components may be sufficient. For PCI DSS, consult your Qualified Security Assessor (QSA) about whether a change is considered significant under the applicable requirements.
The aim is to assess material changes at an appropriate time, rather than automatically repeating a full engagement after every release.
Matching the cadence to your situation
These are suggestions rather than rules, and they reflect our judgement. The right answer for you depends on how your systems change.
Stable systems with a small scope. An annual test, plus another after any major change, is often enough. Examples are a brochure website or a small office network.
A product that releases often. Keep an annual full-scope test for depth, add targeted tests after significant releases, and consider Penetration Testing as a Service (PTaaS) if releases are frequent enough that point-in-time tests go stale quickly.
High-risk data or a regulated sector. Start with the applicable compliance requirements and your risk assessment. Annual testing may be a baseline, but significant changes, sensitive data and increased exposure can justify additional assessments.
An audit or customer review coming up. Count back from the deadline and leave room for the report, remediation and retesting, not just the days of testing. Our guide to penetration testing for customer security reviews covers the timing in more detail.
If you are unsure where you sit, the pricing guide shows what drives cost for each type of test, which helps when you are weighing a single test against a more frequent one.
Frequently asked questions
Is an annual penetration test enough?
For stable systems with a limited scope, annual testing may be appropriate. Systems that change frequently or face greater exposure may need additional assessments between annual tests. Our article on why a once-a-year penetration test is not enough explains when more frequent testing may be worthwhile.
How often does PCI DSS require penetration testing?
PCI DSS requires penetration testing at least every 12 months and after significant changes to the infrastructure or applications in scope. Additional requirements apply to segmentation testing where segmentation is used to reduce scope. See our guide to PCI DSS penetration testing.
Does ISO 27001 specify how often to run a penetration test?
ISO 27001 does not prescribe a frequency for penetration testing. An appropriate approach will depend on your risk assessment and security objectives. See ISO 27001 penetration testing.
Should I test after every release?
Not usually with a full penetration test. A targeted assessment of changed components may be more appropriate after a significant codebase change. If you release frequently, Penetration Testing as a Service (PTaaS) can help organise recurring assessments around your development cycle.
Is a vulnerability scan enough between penetration tests?
Vulnerability scanning provides repeatable checks for known weaknesses across your internal and external networks, and can provide static or dynamic analysis of your applications. It's generally recommended to run your own scans as part of a vulnerability management programme.
A penetration test can investigate business logic flaws, exploit chains and weaknesses that automated scans may not identify. See vulnerability scanning vs penetration testing.
What if I have never had a penetration test?
Start with the systems that are most exposed or handle the most sensitive data. You can expand the scope over time, rather than testing everything at once. Our guides to scoping a web app pentest and scoping a network assessment explain how to prepare.
