How often should you get a penetration test?
Short answer: at least once every 12 months, and again after any significant change to the systems in scope. That two-part rule, calendar plus change, is the practical floor across every framework a buyer runs into. Only PCI DSS writes it down as a hard requirement. SOC 2 and ISO 27001 do not name a frequency at all; they are risk-based, and annual has simply become the cadence auditors expect. If your environment ships code every week or handles high-value data, once a year is a floor to clear, not a target to aim at.
The question gets asked because "annual" sounds like a rule handed down from somewhere official. For one standard it is. For the others it is a convention that grew up around risk-based language, and knowing which is which stops you from either over-buying or getting caught short in an audit. Here is what each one actually says.
The short version, by framework
Four things drive most buyers to a test: a card processor, a SOC 2 report, an ISO certificate, or an insurance form. Only one of them prescribes a number.
| Driver | Names a frequency? | Cadence buyers land on |
|---|---|---|
| PCI DSS v4.0 | Yes, prescriptive | At least every 12 months and after significant change |
| SOC 2 (AICPA) | No, risk-based | Annual, inside the Type 2 window, by auditor convention |
| ISO/IEC 27001 | No, risk-based | Annual is common; frequency set by your risk assessment |
| Cyber insurance | Varies by carrier | Often annual attestation; read the specific policy |
| No mandate at all | N/A | Annual floor, more if you change fast or hold high-value data |
The two-part rule: calendar plus change
Every credible frequency answer is really two rules stacked together, and skipping either one leaves a hole.
The calendar half exists because a penetration test is a point-in-time exercise. It describes the systems in scope, during the testing window, against the techniques in the rules of engagement. New vulnerability classes get discovered, new exploits get published, and your team keeps shipping. A yearly test resets that clock before the picture goes too stale.
The change half exists because the calendar does not know when you rebuilt your auth flow or exposed a new API. A test from March tells you nothing about the service you launched in June. This is why every serious framework pairs "at least every 12 months" with "and after any significant change," and it is the half that buyers most often drop.
What counts as a significant change
PCI DSS leaves "significant" for each organization to define and defend, but the industry examples are consistent. Treat any of these as a trigger to test the affected scope, regardless of when the last annual test ran:
- A major application release or a rewrite of a security-relevant component.
- A new internet-facing service, subdomain, or API that widens what an attacker can reach.
- A cloud migration, or a material change to cloud architecture or IAM.
- A change to authentication, single sign-on, or session handling.
- A change to network segmentation, firewall rules, or how environments are isolated.
- An acquisition or a new third-party integration that folds someone else's surface into yours.
The common thread is exposure. If the change alters what is reachable from outside, how identity is proven, or where a trust boundary sits, the last test no longer describes reality.
What each framework actually says
PCI DSS v4.0 is the prescriptive one. Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, following a documented methodology based on an industry-accepted approach such as NIST SP 800-115. Where segmentation is used to keep systems out of the cardholder data environment, that segmentation is tested at least every 12 months for merchants and at least every 6 months for service providers, and findings are re-tested after remediation. This is the clearest "how often" any of the frameworks give you.
SOC 2 names no frequency. The AICPA Trust Services Criteria are written as objectives, not schedules, so there is no line requiring a yearly test. In practice auditors expect one at least annually, timed to fall inside a Type 2 observation window. We wrote the detail of which criteria point at testing in does SOC 2 require a penetration test?
ISO/IEC 27001 is explicitly risk-based. It calls for technical vulnerabilities to be managed and controls to be verified, and it ties the how-often to your own risk assessment and treatment plan rather than a fixed calendar. Certified organizations converge on annual testing as the defensible baseline, with higher-risk assets tested more often. The number is yours to justify, not a constant handed to you.
Cyber insurance depends on the carrier. Some policies ask whether you test regularly and treat "annually" as the expected answer; others do not ask at all. The honest move is to read the specific application rather than assume, which is the theme of do I need a pentest for cyber insurance?
When once a year is not enough
Annual is a floor, and some environments outgrow it fast. Test more often when:
- You ship continuously. If production changes weekly, a yearly test is stale for eleven months of the year. Teams in this position move to per-release testing on critical paths, or to a continuous testing model, and keep the full annual test as the anchor.
- You hold high-value data. Payments, health records, and large volumes of personal data raise the cost of being wrong, which justifies more frequent testing of the systems that touch them.
- You just had a scare. After an incident, a near-miss, or a critical vulnerability in a component you rely on, re-testing the affected area is cheaper than assuming the patch was clean.
None of this replaces the annual test. It layers on top of it, because a full, scoped engagement by senior people is a different depth of work than a targeted re-test of one change.
The mistake: treating the date as the deliverable
The most common way to get frequency wrong is to treat the pentest as a certificate with an expiry date, run it on the last valid day, and change nothing you learned. A test you commission to tick a box tends to be scoped narrowly enough to pass and shallow enough to miss the way an attacker actually gets in. The date on the report satisfies the auditor; it does not make you harder to breach.
Between scheduled tests, your exposure keeps moving whether you look or not: a forgotten subdomain, a service that should never have been public, a credential in a leak. Knowing your external attack surface continuously is the cheap complement to periodic depth, and it is not the same purchase as a pentest. If you are still untangling which service you actually need in the first place, check, scan, or full pentest? draws the lines.
How often should you get a penetration test? Quick answers
How often should you get a penetration test?
At least once every 12 months, and again after any significant change to the systems in scope. That two-part rule is the practical floor across the standards buyers care about. Fast-moving or high-value environments should test more often, up to per-release or continuous.
Does PCI DSS require annual penetration testing?
Yes. PCI DSS v4.0 Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change. Where segmentation isolates the cardholder data environment, segmentation is tested at least every 12 months for merchants and at least every 6 months for service providers.
How often do SOC 2 and ISO 27001 require a pentest?
Neither names a fixed frequency. Both are risk-based: SOC 2 leaves the evidence to your auditor, and ISO 27001 ties testing to your risk assessment. In practice annual has become the accepted cadence auditors expect, timed to fall inside a SOC 2 Type 2 observation window.
When should you test outside the annual cycle?
After any significant change: a major release, a new internet-facing service or subdomain, a cloud migration, an authentication or SSO change, a network or segmentation change, or an acquisition. The last test only described the environment as it was on that day.
Sources
- PCI Security Standards Council, PCI DSS v4.0 Requirement 11.4 (penetration testing methodology, frequency, and segmentation testing).
- AICPA Trust Services Criteria (SOC 2), written as risk-based objectives with no fixed testing frequency.
- ISO/IEC 27001, risk-based technical vulnerability management and control verification.
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, cited as an accepted methodology.
Related reading
- Does SOC 2 require a penetration test?
- Do I need a pentest for cyber insurance?
- How much does a penetration test cost?
Do not let the annual date be the only look.
Our $100 check shows what an attacker sees from the outside today, with a senior operator on the readout. It is the cheap complement to a periodic pentest, not a replacement, and we will tell you which you need.
Book a $100 check