How Often Should You Run A Penetration Test? Frequency By Risk And Regulation

Most organizations should run a penetration test at least once a year and after any significant change to their systems, such as a new application, a major release, a cloud migration or a network redesign. That annual baseline is what PCI DSS, NYDFS Part 500, FedRAMP and CMMC Level 3 write into their rules. Higher-risk environments, such as internet-facing applications that change weekly, payment service providers and regulated financial entities, often test more frequently: twice a year, quarterly or continuously. Some well-known frameworks, including SOC 2 and ISO 27001, do not set a frequency at all, which leaves the decision to your risk assessment and your auditor.

This guide explains how to decide on a testing cadence, what each major regulation actually requires (with primary sources where available) and how to build a schedule that covers both compliance and real risk. For background, see our guide to what penetration testing is.

The Short Answer: Annual Plus Significant Change

Two triggers appear again and again in security standards:

• A time-based trigger, usually at least once every 12 months.
• An event-based trigger, after significant changes to infrastructure, applications or security controls.

The event-based trigger is the one teams most often skip. An annual test in January says little about the payment flow you rebuilt in June. If your environment changes often, the change trigger will drive your real testing frequency far more than the calendar.

Penetration Testing Frequency By Regulation

The table below summarizes what each framework requires as of October 2026. Requirements change, so confirm with your assessor and the current version of each standard before planning.

Framework	Is A Pentest Explicitly Required?	Minimum Frequency	Other Triggers And Notes
PCI DSS v4.0.1	Yes (Req. 11.4)	Internal and external: at least every 12 months	After significant change. Segmentation tests every 12 months, every 6 months for service providers
HIPAA Security Rule	No, under the current rule	None set. “Periodic” evaluation	2025 proposed rule would require pentests at least every 12 months. Not final as of Oct 2026
SOC 2	No	None set	Pentesting is named as one type of evaluation in CC4.1 points of focus. Auditors and customers often expect an annual test
ISO/IEC 27001:2022	No	None set	Driven by your risk assessment and technical vulnerability management controls. Annual is common practice
DORA (EU)	Yes, for selected entities (TLPT)	TLPT at least every 3 years. Basic testing of critical systems at least yearly	Authority can raise or lower TLPT frequency. Purple teaming in closure phase
NYDFS 23 NYCRR Part 500	Yes (500.5)	At least annually, from inside and outside system boundaries	Performed by a qualified internal or external party
FedRAMP	Yes (CA-8)	Before initial authorization, then at least every 12 months	Initial test no more than 6 months before SAR submission. Rules in transition under FedRAMP 20x
CMMC	Level 3 only (CA.L3-3.12.1e)	At least annually	Also when significant security changes are made. No explicit pentest at Levels 1 and 2

PCI DSS

PCI DSS v4.0.1 Requirement 11.4 is the most detailed pentest requirement among common frameworks. Internal (11.4.2) and external (11.4.3) penetration tests must be performed at least once every 12 months and after any significant infrastructure or application upgrade or change. Exploitable vulnerabilities must be corrected and the test repeated to verify the fixes (11.4.4). If you use segmentation to reduce PCI scope, segmentation controls must be tested at least every 12 months (11.4.5), and service providers must test them at least every six months (11.4.6), in both cases also after changes to segmentation controls. Vulnerability scanning is a separate requirement (11.3), with quarterly internal and external scans. The full standard is available from the PCI Security Standards Council document library. For providers, see our list of PCI penetration testing companies.

HIPAA

The current HIPAA Security Rule does not mention penetration testing. It requires covered entities and business associates to perform a periodic technical and nontechnical evaluation of their safeguards (45 CFR 164.308(a)(8)) and to respond to environmental or operational changes, without defining an interval. That changed on paper in January 2025, when HHS proposed updates to the Security Rule. The HHS fact sheet states the proposal would “require vulnerability scanning at least every six months and penetration testing at least once every 12 months.” As of October 2026 the rule has not been finalized, and HHS’s regulatory agenda has pushed the target date into 2027. Many healthcare organizations already test annually because their risk analysis, cyber insurers and enterprise customers expect it. See our list of HIPAA and healthcare penetration testing companies.

SOC 2

SOC 2 does not require a penetration test, and the AICPA Trust Services Criteria do not set a frequency. The criteria do name penetration testing as one example of the “ongoing and separate evaluations” management can use under CC4.1, and pentest results also support criteria around risk assessment and vulnerability management. In practice, most SOC 2 auditors and most enterprise buyers reviewing a SOC 2 report expect to see an annual test within the audit period. The Cloud Security Alliance summarizes this well: not explicitly required, but highly advisable. Our list of SOC 2 penetration testing companies covers firms that test for this purpose.

ISO 27001

ISO/IEC 27001:2022 does not use the phrase “penetration testing” as a mandatory requirement and does not set a frequency. Testing supports Annex A controls such as 8.8 (management of technical vulnerabilities) and the secure development and security testing controls, and your risk assessment decides how often. Certification auditors commonly accept an annual test plus testing after major changes, as long as the frequency is documented and justified.

DORA

The EU Digital Operational Resilience Act, applicable since 17 January 2025, has two tiers. All in-scope financial entities must run appropriate tests on ICT systems and applications supporting critical or important functions at least yearly. Entities selected by their competent authority must also carry out threat-led penetration testing (TLPT). Article 26(1) of Regulation (EU) 2022/2554 states they “shall carry out at least every 3 years advanced testing by means of TLPT,” and the authority can ask them to increase or reduce that frequency. The detailed TLPT method is set out in Delegated Regulation (EU) 2025/1190, which also requires a purple teaming exercise in the closure phase. Austria’s regulator, the FMA, notes that a first TLPT generally falls within a three-year window starting January 2025.

NYDFS Part 500

New York’s cybersecurity regulation for financial services companies, as amended in November 2023, requires covered entities to conduct penetration testing of their information systems from both inside and outside the system boundaries, by a qualified internal or external party, at least annually (23 NYCRR 500.5(a)(1)). The penetration testing provisions took effect on April 29, 2024. Automated vulnerability scans are a separate requirement, at a frequency set by the risk assessment and promptly after material system changes. Section 500.19 small-business and limited exemptions remove the vulnerability management requirements for some entities, so check your classification.

FedRAMP

Cloud service providers seeking FedRAMP authorization must have a penetration test performed by a third-party assessment organization as part of the initial assessment. The FedRAMP Penetration Test Guidance (v3.0) states the initial test must be performed no more than six months before submission of the Security Assessment Report, and that testing must occur “at least every 12 months” during continuous monitoring unless an authorizing body approves otherwise. It also defines six attack vectors to cover, from external-to-corporate through tenant-to-tenant. FedRAMP is moving its rules into a new structure under FedRAMP 20x, so confirm current requirements with your 3PAO.

CMMC

The Cybersecurity Maturity Model Certification sets out three levels in 32 CFR 170.14. Only Level 3, built on selected NIST SP 800-172 requirements, includes an explicit penetration testing requirement: CA.L3-3.12.1e, to “conduct penetration testing at least annually or when significant security changes are made to the system,” using automated scanning tools and ad hoc tests by subject matter experts. Levels 1 and 2 do not require a penetration test, although Level 2 includes vulnerability scanning.

[EXPERT QUOTE: White Knight Labs, John Stigerwalt, on why meeting the minimum annual compliance pentest rarely matches how often an environment actually changes]

How To Set Frequency By Risk

Regulations set a floor. Your real cadence should reflect how exposed and how changeable each system is. A practical way to set it is to rate each asset on three questions.

How Exposed Is It?

Internet-facing applications, APIs, VPN gateways and remote access services get attacked constantly. They warrant more frequent testing than internal systems behind several layers of control. External tests should usually run at least as often as internal ones.

How Often Does It Change?

An application deployed weekly drifts from its last test quickly. A stable internal network may change little year to year. Tie testing to release milestones for fast-changing systems instead of waiting for the calendar.

What Would A Breach Cost?

Systems handling payment data, health records, credentials or customer data at scale justify more testing than a marketing site. Critical operational systems, including OT and industrial control environments, deserve their own scoped tests.

Suggested Testing Cadence By Risk Level

Risk Profile	Example	Suggested Cadence
Low	Stable internal systems, brochure websites	Annually, plus after major change
Moderate	Business apps with customer data, standard corporate network	Annually for the full scope, plus targeted tests of major releases
High	Internet-facing SaaS with frequent releases, payment or health data	Twice a year or quarterly, plus release-driven tests
Very high	Payment service providers, large financial institutions, critical infrastructure	Continuous or quarterly testing, annual red team, scheduled TLPT where required

These are starting points, not rules. A high-risk company does not need to test every system quarterly. It needs to test its highest-risk systems often and the rest on a reasonable cycle.

What Counts As A Significant Change?

Most frameworks leave “significant change” to you to define, which means you should write it down. Common triggers include:

• Launching a new application, API or customer-facing feature that handles sensitive data.
• Major changes to authentication, authorization or payment flows.
• Migrating to a new cloud provider, data center or hosting model.
• Network redesigns, new segmentation or new remote access methods.
• Mergers, acquisitions or connecting a new subsidiary’s network.
• Upgrading core platforms, operating systems or frameworks across the estate.

Documenting these triggers in a policy, and recording when each one led to a test, gives auditors the evidence they ask for.

Filling The Gaps Between Tests

An annual pentest leaves eleven months of drift. Several approaches help cover that time without paying for a full engagement every month:

• Continuous or recurring pentesting. Subscription models keep human testers on your highest-risk applications.
• Pentest as a service. Platforms make it easier to book smaller, release-driven tests between full engagements.
• Automated testing between engagements. Automated pentesting tools are useful for checking infrastructure attack paths often. Read automated vs manual penetration testing for what each finds.
• Vulnerability scanning. Regular scanning catches known issues quickly but does not replace a pentest. See vulnerability scanning vs penetration testing.

Budgeting For More Frequent Tests

Testing more often does not have to mean paying full price each time. A large annual baseline test, followed by smaller scoped tests of changed components, usually costs less than repeating the full scope. Retests of fixed findings are often cheaper still. Our penetration testing cost guide explains what drives price and how scoping changes the quote.

Frequently Asked Questions

Is Annual Penetration Testing Enough?

For stable, lower-risk environments, often yes, provided you also test after significant changes. For internet-facing applications that change frequently, an annual test leaves long periods where new code is untested, so add release-driven or continuous testing.

Does HIPAA Require Annual Penetration Testing?

Not under the current Security Rule, which requires periodic evaluation without specifying pentests or an interval. The January 2025 proposed rule would require penetration testing at least every 12 months, but it had not been finalized as of October 2026.

How Often Does PCI DSS Require Penetration Testing?

At least every 12 months and after significant changes, for both internal and external testing. Segmentation controls must be tested at least every 12 months, or every six months for service providers.

How Often Should A Startup Run A Penetration Test?

Most startups test once a year, often timed to a SOC 2 audit or a major customer’s security review, plus after launching major new features. As release frequency and customer data grow, move to twice-yearly or release-driven testing.

Does A Vulnerability Scan Count As A Penetration Test?

No. Scans identify potential known weaknesses. A penetration test attempts to exploit and chain them to prove impact. Frameworks such as PCI DSS list them as separate requirements with separate frequencies.

Conclusion

The safe default is a penetration test at least once a year and after every significant change. PCI DSS, NYDFS, FedRAMP and CMMC Level 3 make that the rule, DORA adds threat-led testing every three years for selected financial entities, and HIPAA may soon follow with an annual requirement. SOC 2 and ISO 27001 leave the decision to your risk assessment, which in practice usually still means an annual test.

Beyond compliance, let exposure, change rate and impact set the cadence for each system. To find a tester, start with our list of top penetration testing companies and browse every guide in our penetration testing hub.