How Often Should You Do Penetration Testing?

Test at least once a year, and again after every significant change to your environment. That is the consensus floor across every major framework, and it is the right starting point for most companies. If you handle cardholder data, PCI DSS 4.0.1 goes further: annual internal and external tests are mandatory, and service providers must test segmentation every six months. And if you ship code weekly or hold data attackers actively want, annual is not enough; move to quarterly testing or a continuous program. The rest of this article is the framework-by-framework detail behind that answer, plus the part most guides skip: what "significant change" actually means.

Key takeaways

• At least once a year, and again after every significant change, is the consensus floor across every major framework.
• PCI DSS 4.0.1 is the only one that spells frequency out enforceably: annual internal and external tests, plus segmentation testing every 12 months, or every six months for service providers.
• The SOC 2 Trust Services Criteria name penetration testing only in a point of focus the AICPA says need not be addressed, but nearly every auditor expects an annual test, timed so the report lands inside the audit period.
• Write your definition of "significant change" down before the change happens. The test is security impact on attack surface and trust boundaries, not engineering effort.
• Move to quarterly or continuous testing if you deploy weekly, hold data with obvious resale or extortion value, or have had an incident in the past 18 months. Budget the retest as part of the cadence, not as an extra.

Why the frequency question matters more than it did

A penetration test is a snapshot. It tells you what an attacker could do to the environment that existed during the testing window. The moment you deploy a new service, open a firewall rule, or acquire a company, that snapshot starts to age.

The threat data says it ages fast. Vulnerability exploitation is now the number one initial access vector, present in 31% of breaches, according to the Verizon DBIR 2026. Not phishing. Not stolen credentials. Attackers scanning for and exploiting weaknesses in internet-facing systems, which is more or less what a penetration tester does, except the attacker runs continuously and your test ran last October.

That does not mean everyone needs monthly testing. It means your cadence should be driven by your rate of change and your exposure, with the compliance minimums treated as exactly that: minimums.

What each framework actually requires

PCI DSS 4.0.1: the most specific by far

PCI DSS is the only major framework that spells out penetration testing frequency in enforceable detail. Requirements 11.4.1 through 11.4.6 cover it:

• 11.4.1 requires a documented penetration testing methodology, including how you define a significant change (more on that below)
• 11.4.2 requires internal penetration testing at least every 12 months and after any significant infrastructure or application change
• 11.4.3 applies the same cadence to external penetration testing: annually and after significant changes
• 11.4.4 says exploitable vulnerabilities found during testing must be corrected and the fix verified by retesting
• 11.4.5 adds segmentation testing at least every 12 months if you use segmentation to reduce PCI scope
• 11.4.6 tightens that to every six months for service providers

Note the "internal AND external" language. We still see companies show up to a PCI DSS assessment with an external test only, assuming the internal requirement is optional. It is not, and a QSA will flag it. If you segment your cardholder data environment, budget for segmentation testing as its own recurring line item, because it is one.

SOC 2: an auditor expectation, not a literal mandate

Here is the honest version, which you will not always get from firms selling testing: the SOC 2 Trust Services Criteria name penetration testing only in a point of focus under CC4.1, one the AICPA says you are not required to address. Nothing in the TSC forces you to buy one.

In practice, though, nearly every auditor expects to see one. Criteria like CC4.1 (evaluating whether controls are functioning) and CC7.1 (monitoring for vulnerabilities and susceptibility to newly discovered ones) need supporting evidence, and an annual penetration test with a remediation trail is the cleanest evidence that exists. Skip it and you invite a longer conversation with your auditor about how else you validate your controls, and your enterprise customers' security questionnaires will ask for the report anyway.

So for SOC 2, the practical answer is annual, timed so the report lands inside your audit period. If your Type II window runs January through December, a test completed the previous November helps you less than you would hope.

HIPAA: an evaluation standard today, possibly an annual mandate soon

The HIPAA Security Rule, as it stands, requires a periodic "technical and nontechnical evaluation" under 45 CFR 164.308(a)(8) in response to environmental or operational changes. It never names penetration testing, and covered entities have historically satisfied the standard in a range of ways, some of them thin.

That may change. The proposed Security Rule update (NPRM published by HHS in January 2025) would require penetration testing at least once every 12 months, along with vulnerability scanning every six months. As of August 2026 this is still a proposed rule, not a final one, so treat annual testing as strongly advisable rather than legally required. If you handle ePHI and want to be positioned for the final rule instead of scrambling after it, start the annual cadence now.

CMMC: explicit only at Level 3

CMMC Levels 1 and 2 do not explicitly require penetration testing. Level 2 maps to NIST SP 800-171, which requires periodic security assessments (CA.L2-3.12.1), and a penetration test is excellent evidence for that practice, but an assessor cannot fail you for not having one.

The explicit requirement appears at Level 3: CA.L3-3.12.1e, drawn from NIST SP 800-172, requires penetration testing at least annually, using automated scanning tools and ad hoc tests by human experts. If you are a defense contractor targeting Level 3, annual human-led testing is a hard requirement. For the much larger population of Level 2 contractors, it is a judgment call, and we would usually still recommend it for anyone holding CUI, because the adversaries interested in CUI are not casual.

What counts as a significant change

Every framework that says "test after significant changes" leaves you to define significant. PCI DSS 4.0.1 makes that definition your explicit responsibility in requirement 11.4.1, and your QSA will read it. Here is the working definition we use with clients. A change is significant if it alters your attack surface or trust boundaries:

• A new internet-facing application, API, or service
• A major rewrite or re-architecture of an existing application, even if the URL never changes
• Infrastructure migration: on-prem to cloud, a change of cloud provider, a new production region
• Changes to network segmentation or firewall architecture, especially anything touching a PCI scope boundary
• A new or replaced authentication system (SSO rollout, IdP migration, MFA overhaul)
• A merger or acquisition that connects a new environment to yours
• A new third-party integration with access to sensitive data or production systems

The test is security impact, not engineering effort. A two-line firewall change that exposes an internal admin panel is significant. A six-month UI redesign that touches no auth logic and no data flows probably is not. Write your definition down before the change happens, because deciding after the fact is where motivated reasoning creeps in.

When annual is not enough

Annual testing assumes your environment changes slowly enough that a yearly snapshot stays roughly valid. For a lot of companies in 2026, it does not. Move to quarterly testing, or a continuous testing program, if any of these describe you:

• You deploy to production weekly or faster and those deployments regularly change attack surface
• You hold data with obvious resale or extortion value: cardholder data at scale, large ePHI sets, CUI
• You have had an incident in the past 18 months
• Your customer contracts or cyber insurance policy require more frequent testing, a clause we see in both with growing frequency as of August 2026

Full disclosure, since we sell this service: not everyone should buy more testing. If you run a small, stable environment, ship changes a few times a year, and have solid vulnerability scanning between tests, an annual test plus change-triggered retests is a defensible program, and a vendor pushing you to quarterly is optimizing for their revenue, not your risk. Continuous testing earns its cost when the environment changes faster than point-in-time tests can track. We covered how to scope engagements so each test actually earns its fee in Penetration Testing: Beyond Checkbox Compliance.

Retesting is part of the cadence, not an extra

One more piece that gets forgotten in budgeting: the retest. PCI DSS 11.4.4 requires that exploitable vulnerabilities be corrected and the correction verified by repeating the test, and every other framework's auditors expect the same closed loop. A finding report with no remediation verification is half a deliverable.

Retests are narrow. The tester revalidates the specific findings you fixed, not the whole scope, so they typically cost a fraction of the original engagement and take days, not weeks. Build one retest per major engagement into your annual plan and confirm your testing vendor includes it (or prices it) up front.

The cadence that works for most of our clients looks like this: one comprehensive annual test aligned to the audit calendar, change-triggered tests scoped to whatever changed, and a retest after each round of remediation. High-change environments layer quarterly or continuous testing on top. It is not complicated. It just has to actually happen, on schedule, with the evidence retained.

Frequently asked questions

Is an annual penetration test enough?

It is enough to satisfy PCI DSS, current HIPAA, CMMC Level 3, and virtually every SOC 2 auditor, provided you also test after significant changes and retest after remediation. Whether it is enough for your actual risk depends on your rate of change: with vulnerability exploitation now the leading breach entry point at 31% per the Verizon DBIR 2026, fast-shipping teams and holders of high-value data should test quarterly or continuously. For small, stable environments, annual plus change-triggered testing is a defensible program.

What triggers a retest?

Two things. First, remediation: after you fix exploitable findings from any test, the fix must be verified, and PCI DSS 11.4.4 makes that verification mandatory. Second, significant change: a new internet-facing system, an infrastructure migration, a segmentation or authentication change, or an acquisition all warrant a scoped test of what changed, without waiting for the next annual cycle. Define "significant change" in writing beforehand so the decision is not made under deadline pressure.