How Often Should You Do a Penetration Test? A Frequency Table by Framework

The honest answer to “how often should penetration testing be done” has two parts. The first is a floor set by whichever framework or contract you answer to, and for most companies that floor is once a year. The second is a set of triggers, changes to the systems that make last year’s report describe something that no longer exists. This guide gives you both, framework by framework, so you can put a date on the calendar rather than a hope.

The short version

• At least annually is the baseline every auditor, examiner, and insurer accepts, and the one most frameworks write down or imply.
• After any significant change is the second half of every requirement: a new application, a major release, a cloud migration, a merger, a change to segmentation or remote access.
• More often for high-change or high-risk systems. Products that ship weekly, environments handling cardholder data or ePHI, and service providers with contractual obligations usually test twice a year or run a continuous testing program.
• Vulnerability scanning fills the gaps between tests, and several frameworks require it on its own cadence, usually quarterly.

How often to do pen tests, by framework

Framework	Penetration testing frequency	Scanning frequency	Where it comes from
PCI DSS v4.0	Internal and external testing at least once every 12 months and after significant changes. Segmentation testing every 12 months, or every six months for service providers.	Internal and external scans at least every three months and after significant change.	Requirements 11.4.2, 11.4.3, 11.4.5, 11.4.6 and 11.3
SOC 2	No fixed interval in the criteria. Auditors expect a test inside each Type II observation window, which in practice means annually.	Evidence of an ongoing vulnerability management process, typically quarterly.	CC4.1, CC7.1 and auditor practice
HIPAA	The current Security Rule requires periodic evaluation with no interval named; annual testing is what OCR treats as reasonable. The proposed 2025 update would require testing at least every 12 months.	The proposed update would require vulnerability scans at least every six months.	45 CFR 164.308(a)(8) and the proposed rule
ISO 27001:2022	No fixed interval; the standard is risk-based. The baseline auditors accept is annually plus after significant change, matching the surveillance-audit rhythm.	Ongoing technical vulnerability management.	Annex A 8.8, A 8.29 and Clause 9
NYDFS 23 NYCRR 500	Penetration testing at least annually, from inside and outside the information systems’ boundaries, by a qualified party.	Automated scans at a frequency set by your risk assessment, plus manual review of systems not covered by scans, and after material changes.	Section 500.5(a)
CMMC Level 2	No fixed pentest interval in NIST SP 800-171; controls must be assessed periodically, and a penetration test is the accepted evidence for the boundary around CUI. Annual is the norm.	Scan periodically and when new vulnerabilities affecting the systems are identified.	CA.L2-3.12.1 and RA.L2-3.11.2
GDPR	“Regularly testing, assessing and evaluating” the effectiveness of security measures, with no interval named. Annual is the defensible reading.	Not specified.	Article 32(1)(d)
Cyber insurance	Most applications and renewals ask whether an independent test was performed in the last 12 months and whether critical findings were fixed.	Applications increasingly ask how often you scan and how fast critical findings close.	Underwriter questionnaires
Enterprise customers	Security questionnaires usually ask for a test within the last 12 months and a report or attestation letter they can read.	Often ask about scanning cadence too.	Vendor security reviews

Two things stand out in that table. Nobody accepts a test older than a year, and nearly everyone separates penetration testing from vulnerability scanning and expects both. If you only budget for one annual test and no scanning, you are meeting the letter of some frameworks and the spirit of none. Our guide to penetration testing vs vulnerability scanning explains what each one finds.

The changes that trigger a test, whatever the calendar says

Every framework above pairs its interval with “and after significant changes.” Frameworks leave the definition to you and your assessor, but in practice these always qualify:

• A new application, portal, or API goes live, or an existing one is re-platformed.
• A major release changes authentication, authorization, or the data model. New roles, SSO, an integration marketplace, a new tenant model.
• A cloud migration or a new cloud account, especially when identity and network rules are rebuilt.
• A merger or acquisition joins two networks, or a new office, plant, or partner connects to yours.
• Segmentation, firewall, VPN, or remote-access changes. PCI DSS names segmentation changes specifically.
• An incident. A phishing compromise or a breach at a peer raises the question of what that access could reach, and the answer is a test.

The practical rule: if the system description in your audit, your network diagram, or your data-flow document changed materially, the last report no longer describes your environment.

Picking the cadence that fits

Annual, plus scanning. The right answer for most companies with a stable estate: one penetration test of the systems in scope each year, timed ahead of the audit or renewal, with validated vulnerability scanning quarterly between tests. This satisfies every row in the table for a typical merchant, SaaS company, or professional-services firm.

Twice a year. Service providers under PCI DSS already carry a six-month segmentation cadence. Healthcare organizations preparing for the proposed HIPAA update, financial firms under NYDFS with active examiner attention, and companies with two release cycles a year often test twice, splitting the scope, for example the application in spring and the network in fall.

Continuous. Products that ship weekly change faster than an annual test can describe. A penetration testing as a service program schedules manual test windows through the year, runs validated scanning between them, and retests on demand, priced once so the cadence stops being a budget conversation every quarter.

How this fits with how long a test takes

Frequency and duration are separate questions that buyers often run together. A single web application or external network test typically takes about a week of testing, followed by the report and a free retest once the fixes ship. Planning backward from an audit date, that means starting scoping six to eight weeks ahead. Our guide to how long a penetration test takes walks through the timeline by test type, and what a penetration test costs covers the budget side, with our own fixed prices listed alongside the market ranges.

The short answer, again

Test at least once a year, again after any significant change, and scan between tests. Match the floor to the strictest framework you answer to: PCI DSS and NYDFS write the annual requirement down, SOC 2 and ISO 27001 auditors enforce it in practice, HIPAA is about to, and insurers and enterprise customers ask for it regardless. If you are not sure which cadence your environment needs, scope an assessment and we will recommend one, with a fixed price for the year rather than a quote per test.