On this page
- The baseline: annual, plus change-driven
- What each framework requires
- Set the cadence by risk and rate of change
- Triggers for an off-cycle test
- Scans and penetration tests run on different clocks
- When annual is not enough: continuous testing
- Retesting is part of the cycle
- A sample annual testing calendar
- How Sumrite helps
- Frequently asked questions
Last test more than a year ago? Run the free scan at scan.sumrite.com for a first look at your external exposure, then read on to set a proper cadence.
“Once a year” is the most common answer, and for many systems it is correct. But it is a floor set by auditors, not a measure of risk. A team that ships major features every two weeks and tests in January has spent eleven months running code that nobody has attacked. The right frequency depends on three things: what your regulators and customers require, how much risk the system carries, and how fast it changes.
The baseline: annual, plus change-driven
Two rules cover most organisations:
- Test at least every 12 months. This is the minimum auditors expect for SOC 2, ISO 27001 and most customer security questionnaires, and the fixed rule in PCI DSS.
- Test after significant change. A new release, new API, cloud migration or authentication change creates attack surface that last year’s report does not cover.
The second rule is the one teams skip, and it is where most real findings come from. A test report describes the system as it was on the test dates. Once the system changes materially, the report stops describing it.
What each framework requires
Some frameworks set a fixed interval. Most require testing “regularly” or “periodically” and leave you to justify the cadence. Our framework guides cover each in detail.
| Framework | Penetration testing frequency | Guide |
|---|---|---|
| PCI DSS 4.0.1 | Internal and external tests every 12 months and after significant change; segmentation tests every 12 months (every six months for service providers) | PCI DSS |
| SOC 2 | No fixed interval; most organisations test annually, inside or near the observation period | SOC 2 |
| ISO 27001 | No fixed interval; annual testing of key systems plus testing after significant change is common practice | ISO 27001 A.8.8 |
| HIPAA | No fixed interval today; the January 2025 proposed rule would require a test every 12 months and scans every six months | HIPAA |
| GDPR | “Regularly testing, assessing and evaluating” security (Article 32), with no interval set | Frameworks guide |
| DORA | Yearly testing of systems supporting critical or important functions; threat-led testing (TLPT) at least every three years where required | DORA TLPT |
| NIS2 | No fixed interval; annual testing of systems behind essential services is a defensible baseline | NIS2 |
| RBI (India) | Penetration testing every 12 months and vulnerability assessment every six months for critical and DMZ systems | RBI |
| SEBI CSCRF (India) | Half-yearly for MIIs and qualified stock brokers; at least annually for most other regulated entities | SEBI CSCRF |
| CERT-In audits (India) | At least annually and after major changes, unless your regulator sets a stricter rule | CERT-In |
| SAMA CSF (Saudi Arabia) | Annual tests of customer and internet-facing services; twice a year under the CRFR for sandbox fintechs | SAMA CSF |
| NCA ECC and CSCC (Saudi Arabia) | ECC: periodic, with annual as the usual baseline; CSCC: every six months for critical systems | NCA ECC |
When more than one applies, follow the strictest. A payments company in India covered by PCI DSS and RBI rules, for example, ends up with annual penetration tests, half-yearly vulnerability assessments, and change-driven tests on top.
Set the cadence by risk and rate of change
Where a framework leaves the interval to you, base it on two questions: how bad would a breach of this system be, and how often does it change? Assessors accept a risk-based cadence when you can show the reasoning.
- High risk, changes often
- Customer-facing SaaS, payment flows, public APIs, mobile apps. Test every six months or per major release, or use continuous testing.
- High risk, changes rarely
- Core banking, EHR, identity providers, critical infrastructure. Test annually, and before any change to them goes live.
- Moderate risk
- Internal business applications, partner portals, corporate networks. Test annually.
- Low risk, stable
- Brochure sites, isolated internal tools. Test every one to two years, with regular scanning in between.
Write the tiers down, assign each asset a tier, and review the list once a year. That document is what an auditor will ask for when your cadence is not the one in their checklist.
Triggers for an off-cycle test
Plan an extra test, before go-live where possible, when any of these happen:
- A new application, product or major release reaches production
- A new authentication, authorisation or payment flow
- New public APIs or a major API version
- A cloud migration, new hosting region or new tenancy model
- Major network, firewall or segmentation changes
- A merger, acquisition or new third-party integration with data access
- A serious incident, or a new vulnerability class that affects your stack
A change-driven test can be smaller than the annual one. Scope it to what changed and the paths into it, and it often takes days rather than weeks. Our guide to how long a penetration test takes covers sizing.
Scans and penetration tests run on different clocks
Vulnerability scans and penetration tests do different jobs, so they run at different frequencies:
- Vulnerability scanning: automated and cheap. Run it at least quarterly, and monthly or continuously for internet-facing assets. PCI DSS requires quarterly internal and external scans.
- Penetration testing: manual, deeper and slower. Testers chain weaknesses and test business logic that scanners cannot reach. Run it annually and after significant change.
Scanning more often does not replace testing. Our guide to VAPT versus a vulnerability scan explains what each catches.
When annual is not enough: continuous testing
For teams that ship weekly, the gap between annual tests is the problem. Continuous penetration testing (often sold as PTaaS) keeps testers working on your application through the year, testing new features as they ship and retesting fixes as they land. You still get a point-in-time report for auditors, but the findings arrive while the code is fresh.
It is not for everyone. A stable internal system gets little from it. A fast-moving SaaS product with enterprise customers asking for recent evidence often gets more from continuous testing than from one large annual test.
Retesting is part of the cycle
Frequency is not only about new tests. Every test should end with a retest that confirms the fixes work, and the retest should happen within weeks, not at next year’s test. Many regulators expect it: SEBI, for example, sets three months to fix findings and requires the fixes to be revalidated. An open critical finding from last year’s report is the first thing an auditor will ask about.
A sample annual testing calendar
- Q1: annual test. Full-scope penetration test of the external perimeter, core applications and APIs, timed before audit fieldwork.
- Within six weeks: retest. Confirm high and critical fixes and record the results.
- Every quarter: scans. Internal and external vulnerability scans, with findings tracked to closure.
- Q3: half-year test. Focused test of high-risk, fast-changing systems, or the half-yearly cycle your regulator requires.
- Before every major release: change-driven test. Scoped to what changed.
- Year-end: review. Update the asset list and risk tiers, and plan next year’s calendar.
How Sumrite helps
Sumrite runs annual, change-driven and continuous penetration testing across web applications, APIs, networks and cloud environments, with findings mapped to each framework that applies to you and a retest included. We can also help you write the risk-based cadence document auditors ask for. Begin with the free check at scan.sumrite.com.
Build a testing calendar that fits your release cycle
Tell us your frameworks, your systems and how often you ship. We will propose a cadence that satisfies auditors without testing what has not changed. Get a quote or run the free scan first.
Related reading: Which compliance frameworks require penetration testing? · Types of penetration testing · VAPT cost and pricing guide
Frequently asked questions
How often should you run a penetration test?
At least once a year, and again after any significant change to the application, infrastructure or access model. Systems that are internet-facing, handle payments or sensitive data, or change often usually need testing more frequently, such as every six months or per major release.
Is an annual penetration test enough?
For a stable, low-risk system, often yes. For a product that ships major features every month, an annual test leaves most of the year's code untested. In that case, add change-driven tests or a continuous testing model on top of the annual test.
Which regulations set a fixed penetration testing frequency?
PCI DSS requires internal and external tests every 12 months and after significant changes. RBI requires penetration testing of critical systems every 12 months. SEBI CSCRF sets half-yearly VAPT for market infrastructure institutions and qualified stock brokers. SAMA CSF expects annual tests of customer and internet-facing services. DORA requires threat-led testing at least every three years for the firms it applies to.
What counts as a significant change that needs a new test?
Typical triggers are a new application or major release, a new payment or authentication flow, new public APIs, a cloud migration or new hosting region, major network or segmentation changes, and mergers or acquisitions. Define your own list in advance, because PCI DSS assessors check you followed it.
How often should you run vulnerability scans compared with penetration tests?
Scans are cheap and automated, so run them far more often: at least quarterly, and monthly or continuously for internet-facing assets. Penetration tests are manual and deeper, so they run annually and after significant changes.
How do we begin?
Run Sumrite's free scan at scan.sumrite.com for a first look at your external exposure, then list your systems by risk and how often they change, and set a testing calendar from that.
Faisal Khan is a Director at Sumrite, where he oversees penetration testing, risk assessment and compliance engagements for SaaS and enterprise clients. Case studies are anonymised and published with client permission.
