Ask ten security leads how often they pentest and most will say "once a year". Ask why, and the answer is usually that an auditor or a customer contract said so. An annual test is a reasonable minimum, but it was designed for systems that changed slowly. If your team deploys every week, a single yearly snapshot leaves long stretches where nobody is checking new code.
Why the calendar alone is not enough
Vulnerabilities arrive with change: new features, new integrations, new infrastructure, new people with new permissions. A test in January says little about the payment flow you rebuilt in July. The more often you change, the faster a report goes stale.
That does not mean testing everything constantly. It means matching effort to the rate and impact of change, system by system.
What standards and frameworks expect
Most formal frameworks set a floor rather than a target.
- PCI DSS v4.0.1 requirement 11.4 calls for penetration tests of both the internal and external environment at a minimum of every twelve months and after significant infrastructure or application changes, plus regular testing of segmentation controls where segmentation reduces scope.
- ISO/IEC 27001:2022 controls on technical vulnerability management and security testing in development (Annex A 8.8 and 8.29) do not set a fixed interval, but auditors look for testing that matches your risk assessment.
- SOC 2 reports commonly reference penetration testing as evidence for monitoring controls; annual testing is the usual expectation.
- Your regulator or sector rules may set their own interval. Check local requirements and contracts with major customers.
Treat these as the minimum. Our compliance pentesting service maps tests to the frameworks you report against.
A risk-based cadence
A simple way to set frequency is to place each system in a tier based on exposure, data sensitivity and change rate.
| Tier | Typical systems | Suggested cadence |
|---|---|---|
| Tier 1 | Internet-facing apps and APIs handling customer or payment data; fast release cycles | Continuous testing or quarterly focused tests, plus change-triggered tests |
| Tier 2 | Internal business apps, cloud platforms, Active Directory, partner integrations | Annually plus after significant change |
| Tier 3 | Low-sensitivity internal tools, stable legacy systems | Every one to two years, or folded into a wider internal test |
Adjust the tiers to your own risk appetite. The point is to make frequency a deliberate decision per system rather than one date for everything.
Define your change triggers
"After significant change" only works if people agree what significant means. Write a short list into your security policy so engineering teams know when to request a test. Common triggers include:
- A new internet-facing application, API or mobile app
- Changes to authentication, session handling or authorisation models
- New payment, billing or data-export features
- Migration to a new cloud provider, region or account structure
- Network redesigns, new sites or new segmentation boundaries
- Mergers, acquisitions or onboarding of a major new partner integration
- Adoption of AI features that can read user data or take actions
Not every trigger needs a full engagement. A focused test of the changed component, often a few tester-days, is usually enough.
Options for testing more often
Scheduled focused tests
Break your annual budget into smaller tests through the year, each aimed at what changed most recently. This keeps findings fresh without increasing total effort much.
Continuous pentesting
With continuous pentesting, a known team tests new features as they ship and reports findings as they are confirmed. It suits product teams that release weekly or faster.
Bug bounty alongside testing
A bounty can add outside eyes between tests once your baseline is clean. Our comparison of pentesting and bug bounties explains when that makes sense.
Vulnerability scanning in between
Automated scanning catches known weaknesses and missing patches quickly. It does not replace manual testing, but it narrows the gap between tests. A combined VAPT programme pairs both.
Planning a year of testing
An illustrative plan for a software company with one main product might be: a full grey box test of the application and API in the first quarter, a focused test of a major new feature mid-year, an internal network and Active Directory review in the third quarter, and a cloud configuration review before the annual audit. Retests follow each one. The total effort may be similar to a single large test, but the findings arrive closer to the changes that caused them.
Write the plan down, share it with engineering leads, and revisit it each quarter. Plans that only live in the security team's heads tend to slip. Linking each test to a product milestone or audit date also makes it easier to protect the time when other priorities press.
Signs your cadence is too slow
- The same classes of finding reappear every year in new features.
- Major releases go live without any security testing.
- Customers ask for a recent report and yours is close to a year old.
- An incident exposed a system that had not been tested for several years.
- Engineers do not know how to request a test when they change something.
If two or more of these sound familiar, start by testing your most exposed system now rather than waiting for the next scheduled date, then set the cadence from there.
Do not forget the retest
Frequency is only half the picture. A test whose findings stay open until the next annual cycle has not reduced risk. Build a retest into every engagement, and track time to fix as a metric alongside how often you test. The remediation and retesting guide explains how.
When planning the year, also budget calendar time. A single application test can take several weeks from first contact to clean retest; see how long a penetration test takes for typical timelines.
Frequently asked questions
Is an annual penetration test enough?
For a stable system with few changes, often yes. For products that ship weekly, an annual test leaves long gaps, so add change-triggered tests or a continuous programme.
What counts as a significant change?
Typical triggers are new internet-facing applications, major authentication or payment changes, cloud migrations, new network segments and mergers. Define the list in your own policy.
Want a testing plan that follows your release pace? Explore continuous pentesting, estimate effort with the cost calculator, or request a quote.