What frameworks actually say
PCI DSS is the most explicit: internal and external penetration testing at least once every 12 months, and also after any significant infrastructure or application upgrade or change. Two triggers, and the second is the one that binds a team that ships regularly.
SOC 2 and ISO 27001 set no frequency at all. They ask that vulnerabilities be identified and managed, and whatever cadence you choose must be documented and followed. Choosing annually and then skipping a year is worse than choosing eighteen months and keeping to it.
The change trigger is the real schedule
Significant change is the honest basis for a schedule, because it tracks when your attack surface actually moved rather than when the calendar turned over.
- A new authentication or authorization model, or a new identity provider
- A new tenant model, or a change to how tenants are isolated
- A new payment, billing or financial flow
- A new externally reachable service, API or integration
- A change to network segmentation
- Adding an AI agent or feature with access to tools or customer data
What to run between tests
Full tests are not the only instrument. Continuous scanning, dependency monitoring and your own regression tests for previously found issues fill the gap, and they are what make the next test productive.
Without them, each annual test rediscovers the same categories and you pay a specialist to tell you about missing patches. With them, the test spends its time on the things only a human finds.
A practical cadence
For most product companies: one scoped test a year as the baseline, plus a targeted test whenever something on the change list above ships, plus continuous scanning throughout.
The targeted tests are narrow and that is the point. Testing the new authorization model properly is worth more than re-testing the whole application superficially.