How often should you run a penetration test?

Annual testing became the default largely because standards and contracts settled on it. The Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 requires internal and external penetration testing at least once every 12 months, auditors for other frameworks commonly look for a test within the last year, and enterprise security questionnaires usually ask for an annual third-party report.

Treat annual as the minimum for any system that holds customer data or is reachable from the internet, not as a target. A year is a long time in an environment that deploys every week.

PCI DSS requires testing after any significant infrastructure or application upgrade or change, and leaves the definition to the organization. A sensible working definition is any change that alters who can reach a system, how they prove who they are, or what data they can touch. Examples:

• A new public-facing application, major feature or API version.
• Changes to authentication, single sign-on, session handling or multi-factor authentication.
• A move to a new cloud provider, new network segmentation or a large firewall rule change.
• Mergers and acquisitions that connect new networks or identity systems.
• A new payment flow, or anything that brings new systems into compliance scope.

A change-triggered test can be narrow. Testing the new authentication flow is often more useful than re-running a full-scope test of everything.

The penetration testing for compliance guide explains what each framework says in more depth.

The faster you ship, the faster an annual report goes out of date. A rough way to think about it:

• Quarterly or slower releases: an annual test plus targeted tests for major releases usually covers it.
• Monthly releases: consider semi-annual testing, or an annual test with change-triggered tests for features touching authentication, authorization or sensitive data.
• Weekly or continuous deployment: periodic tests alone leave long gaps. Pair security checks in the pipeline (SAST, DAST, dependency scanning) with ongoing offensive testing. See continuous penetration testing.

1. Data sensitivity. Health, financial or large volumes of personal data justify more frequent testing.
2. Exposure. A large internet-facing footprint or many public APIs gives attackers more to probe.
3. History. If each test still finds serious issues, test more often until the trend improves.
4. Threat news. When a vulnerability in software you run appears in CISA's Known Exploited Vulnerabilities catalog, a targeted check is worth more than waiting for the next scheduled test.
5. Customer commitments. Contracts may set their own frequency, often annual with a summary letter.

The reverse also holds. A system that is internal only, holds no sensitive data, changes rarely and came back clean last time can reasonably sit at the bottom of the schedule. Spending testing time where risk is concentrated is better than testing everything at the same interval. Write the reasoning down: auditors and customers accept different frequencies for different systems far more readily when the decision is documented and tied to a risk assessment.

For a typical SaaS company handling customer data, a defensible schedule is: one full-scope test per year covering web applications, APIs and external infrastructure; targeted tests before or shortly after major changes; vulnerability scanning at least quarterly (monthly or more is common); and retests for every serious finding. Internal network and cloud configuration testing can run on their own annual cycle if they are not in the main test.

A smaller company with one web application and modest release cadence can scale this down: one annual test of the application, its API and the external perimeter, plus a short targeted test whenever authentication or payment flows change. The point is that each part of the attack surface has a known date it was last tested.

If that adds up to several tests a year, compare the cost and coordination against an ongoing model. A one-time vulnerability assessment suits a baseline or a specific change; ongoing coverage suits teams whose systems never stay still for long.

Vulnerability scanning and penetration testing answer different questions, so they are scheduled differently. A scan asks "is any known-vulnerable software or obvious misconfiguration exposed right now?" It is automated, cheap to repeat and should run often: PCI DSS requires it at least quarterly, and many teams run it weekly or on every deploy. A penetration test asks "what could an attacker actually achieve here?" It needs human time to chain weaknesses and judge impact, so it runs less often and goes deeper.

The two feed each other. Scans between tests catch newly disclosed CVEs in software you run, and a pentest shows which scan findings matter and finds the logic and access control flaws scanners cannot see. Prioritization data such as CISA's Known Exploited Vulnerabilities catalog and the EPSS score help decide which scan results deserve an out-of-cycle test. More on the difference: penetration testing vs vulnerability scanning.