How Often Should Your Company Conduct Penetration Tests?

The short answer

The honest answer most teams need is: annually at minimum, plus before each audit, plus after every material change to the trust model. Continuous scanning fills the gap between pentests. Anything less leaves real surfaces uncovered for too long; anything more usually trades budget for scope you would have been better off spending elsewhere.

Compliance cadence — what each framework actually expects

Framework	Minimum cadence	What triggers extra
SOC 2 (Type II)	Annual penetration testing	Significant changes to in-scope systems
ISO 27001	Annual, aligned with surveillance audits	ISMS scope changes, major infrastructure changes
PCI DSS v4.0	External and internal annually (Req 11.4); segmentation testing per 11.4.5	Significant changes to the CDE
HIPAA	Risk-based; annual is the de facto industry baseline	New ePHI flows, new business associates
FedRAMP / StateRAMP	Annual for ATO maintenance	Significant changes per CCB review

Frameworks set the floor. The floor is rarely the right cadence on its own — most teams add tests for material change events on top.

Change-driven triggers

The other input to cadence is what changed. Six events that consistently warrant a fresh test, not just a scan:

• New product or major feature. Especially anything that changes the role matrix, the tenant model, or what data a user can access.
• New authentication system. SSO migration, MFA rollout, account-recovery overhaul, federation changes.
• New payment or money path. Anything that processes, holds, or routes money is in a higher-attention bucket.
• New partner integration. Especially when partners can call your APIs or you call theirs with elevated trust.
• New data class. First time you process ePHI, cardholder data, or sensitive PII.
• Infrastructure migration. Cloud provider, region, or major architecture refactor.

Building the calendar — a four-step process

A pentest calendar that actually gets followed has four anchors. Build them in this order:

Step 1. Identify your compliance baseline

List every framework you operate under and the testing cadence each expects. This sets the non-negotiable floor.

Step 2. Map your 12-month change calendar

From product, engineering, and platform: planned launches, migrations, partner integrations. The "anything that changes the trust model" filter is the right one.

Step 3. Place pentests on the calendar

Anchor an annual pentest at least four weeks before audit field work starts. Add targeted engagements scoped to each material change. Avoid stacking multiple engagements in the same month — your engineering team will be triaging findings.

Step 4. Add continuous scanning between

Continuous scanning paired with human triage lands findings in your tracker as they appear, not in batch. Coverage between pentests should be a real control, not a nominal one.

Example calendars

Three patterns we see work:

Early-stage SaaS, pre-Series A

• Web application + API pentest, scoped to the customer-facing product (annual)
• Continuous scanning across external surface and cloud configuration
• One additional pentest if a major feature ships mid-year

Mid-market SaaS, SOC 2 + ISO

• Web application + API + authenticated pentest, compliance-aligned (annual, before audit)
• Network and cloud pentest (annual, scheduled to alternate quarters from app pentest)
• Continuous scanning + triage
• Targeted engagements per material change

Regulated (fintech, healthtech)

• Compliance-aligned web/API pentest (annual)
• Network and cloud pentest including segmentation testing (annual or semi-annual)
• Red team operation every 18–24 months once a detection program is in place
• Continuous scanning + triage