VAPT Frequency in Practice: How Often Security Testing Actually Needs to Happen

 Most security teams can tell you when their last penetration test happened. Far fewer can explain why that date was chosen. The answer is usually some version of "it's been about a year" or "the auditor asked for one."

That is not a testing strategy. It is a renewal reminder.

Vulnerability Assessment and Penetration Testing exists to tell you whether your systems can be broken into as they are right now. The value of that answer decays every time something changes. So the real question is not how many tests you buy in a year. It is how long your environment can go untested before the last report stops describing reality.

This guide looks at how testing intervals work in practice, what should actually move them, and how to build a schedule your team can defend to a board, an auditor, or a customer.

Why annual testing became the default

The once-a-year habit came from compliance, not from security.

Frameworks such as ISO 27001, PCI DSS, SOC 2 and various regional data protection rules all expect regular technical testing. Most of them phrase it as "at least annually" or "after significant change." Organisations read the first half of that sentence and quietly skipped the second.

An annual test is a floor. It is the minimum evidence an assessor will accept that someone technically competent looked at your systems. It was never meant to describe the right interval for a company that ships code weekly or migrated half its estate to the cloud last quarter.

Treating the floor as the target is the single most common mistake in security testing programmes.

The gap between your audit calendar and your change calendar

Here is the practical problem. Audit cycles move once a year. Engineering does not.

A mid-sized company with a modest development team might push somewhere between fifty and two hundred production changes in a year. Add infrastructure updates, new SaaS integrations, firewall rule changes, staff joining and leaving with their access rights, and a fresh set of third-party libraries pulled in with every build.

By month four after a test, a meaningful share of what was tested no longer exists in the form it was tested in. By month nine, the report is a historical document. It still tells you something about how your team builds software, but it stops telling you whether you are exposed today.

The gap between those two calendars is where most real incidents live.

Six factors that should set your interval

Rather than picking a number first, work backwards from these.

• Change velocity. How often does code or infrastructure reach production? Weekly releases justify a very different rhythm to a system that changes twice a year.
• Exposure. Anything reachable from the public internet carries a different risk profile to an internal tool behind a VPN. External assets deserve the tightest schedule you can afford.
• Data sensitivity. Systems holding payment data, health records, identity documents or large volumes of personal data warrant more frequent and deeper testing, because the cost of a single failure is higher.
• Regulatory obligation. Some sectors set the interval for you. Financial services, healthcare and government suppliers often face explicit requirements, and regional rules across India, the Gulf and the United States continue to tighten.
• Threat exposure. If your sector is being actively targeted, or you have already been probed, the useful interval shortens. Ransomware crews work through industries in waves.
• Previous findings. A test that surfaced critical issues is a signal about your build process, not just about those specific bugs. Environments with a poor first result should be tested again sooner.

Score your environment honestly against those six. A company scoring high on four or more of them cannot responsibly run on an annual cycle.

A realistic cadence by asset type

Testing everything at the same rhythm wastes money on stable assets and underprotects volatile ones. Split the estate instead.

Asset	Typical interval	Why
External perimeter and public IPs	Quarterly	Directly reachable, changes quietly
Customer-facing web applications	Twice yearly, plus major releases	Where most exploitable logic lives
APIs	Twice yearly, plus schema changes	Often tested less than the apps using them
Internal network	Annually	Slower to change, high impact if reached
Cloud configuration	Quarterly review, annual deep test	Drift is constant and easy to miss
Mobile applications	Annually, plus significant releases	Tied to app store release cycles
Wireless and physical sites	Every one to two years	Low change rate in most offices

Treat these as starting points, not rules. A stable internal network in a low-risk sector can stretch. A payments platform shipping fortnightly cannot.

Events that should override the calendar

Some changes should trigger testing regardless of when the last one happened.

• A major application release or architectural rewrite
• Migration between hosting environments, including on-premise to cloud
• A new third-party integration handling customer or payment data
• Mergers and acquisitions, before the networks are joined
• Any security incident, including near misses and contained intrusions
• Entering a new regulated market or signing a customer with security obligations
• Significant changes to authentication, authorisation or session handling

This is where organisations most often get caught. The calendar test passed in March, the platform was rebuilt in July, and nobody reopened the question. Good providers of VAPT services will build retesting triggers into the engagement rather than waiting for a renewal date.

What happens between tests matters more than the tests

A point-in-time test is a snapshot. It cannot cover the weeks between snapshots, and buying more of them is an expensive way to try.

The teams that get this right run a layered model. Automated vulnerability scanning runs continuously and catches known issues fast. Attack surface monitoring watches for assets appearing outside the documented inventory, which happens more often than most inventories suggest. Patch management closes the gap on published vulnerabilities within a defined window. Manual testing then does what automation cannot: chaining findings together, abusing business logic, and proving that a theoretical issue is genuinely exploitable.

Scanning is not testing. A scanner will not notice that a low-severity information leak plus a weak password reset flow adds up to full account takeover. That reasoning is the part you are paying a human for.

Common mistakes worth avoiding

• Retesting never happens. Findings get fixed, but nobody verifies the fix. A remediation that introduces a new flaw is common enough that verification should be contracted from the start.
• Scope quietly shrinks. Each year the tested asset list gets trimmed to fit the budget. Three years later the test covers a fraction of the estate and the certificate looks identical.
• Testing is scheduled for the week before the audit. This produces a report that cannot be acted on. Test early enough to remediate, then retest.
• The report date is treated as the finish line. The report is the beginning of the work. A programme is measured by mean time to remediate, not by how many tests were commissioned.
• Nobody owns the schedule. Without a named owner, intervals stretch by default. Someone should be accountable for the testing calendar in the same way someone owns patching.

How to set your own interval

Start with four questions.

1. What is the longest period we could go undetected if something were exploitable today?
2. Which systems changed most in the last six months, and when were they last tested?
3. Which assets would trigger a regulatory notification if breached?
4. What did our last test find, and has any of it been independently verified as fixed?

If question two returns a system that has never been tested in its current form, that is your next engagement. If question four returns nothing verified, buy a retest before you buy a new test.

When you do go to market, compare providers on how they handle change rather than on the headline price. Ask whether retesting is included, how quickly they can mobilise for an unplanned trigger event, whether findings come with evidence of exploitation, and how the report will be understood by both engineers and executives. Firms such as Sattrix structure engagements around these questions, and any provider you shortlist should be able to answer them clearly.

The takeaway

The right testing interval is not a number you inherit from a framework. It is a function of how fast your environment changes, how exposed it is, and how much a breach would cost you.

Map your assets, score them against change and exposure, set a different rhythm for each tier, and define the events that override the schedule entirely. Then make sure someone owns it. Whether you run testing internally or buy VAPT services from a specialist, a defensible schedule beats an annual habit every time.