How Often Should You Run a VAPT

The standard answer is annually. It is not wrong, but it is a floor derived from audit convenience rather than from risk, and treating it as a plan produces a predictable failure: a system tested every January that changes every fortnight.

Cadence follows four things.

1. What you are required to do

If you are regulated, the minimum is set for you, and it is worth knowing that requirements increasingly separate the two halves of VAPT rather than treating them as one activity.

Under the RBI's 2026 cyber security Directions, for instance, vulnerability assessment and penetration testing carry different intervals — six months and twelve months respectively — which means "we do an annual VAPT" does not straightforwardly satisfy both. Under PCI DSS v4.0, internal and external penetration testing are required at least once every twelve months and after any significant infrastructure or application change (requirements 11.4.2 and 11.4.3), with segmentation controls on their own schedule.

Security Brigade's blog carries the detailed reading of the Indian frameworks — the RBI intervals and the SEBI CSCRF material. The point here is narrower: the regulatory number is a minimum, and it is a minimum for a defined scope. A regulator requiring an annual test of a particular system says nothing about the application you shipped in March.

2. What changed

The strongest argument for testing is change, because a report describes the version that was tested.

Events that justify testing regardless of when the last one happened:

• A new application, or a substantial new module in an existing one.
• A change to authentication or authorisation — the highest-value trigger on this list, because it is the area where mistakes are most consequential and least visible.
• A migration: new cloud provider, new architecture, on-premises to hosted.
• A new integration handling sensitive data or holding credentials.
• An acquisition, which brings a codebase and an estate nobody in your team has examined.
• A change to what the system holds — payments, health data, personal data at a new scale.

Organisations shipping continuously cannot test every change, which is the argument for continuous scanning underneath a periodic test rather than instead of one. What each catches is in what a scanner finds, and what it cannot.

3. What the last test found

A report with several serious findings is evidence about more than those findings. It says something about how the system is built, and it argues for returning sooner — both to confirm the fixes and because where there were four authorisation flaws, there is usually a fifth.

A genuinely clean report on a mature scope is evidence in the other direction. Interpret it carefully, though: a clean report on a scope that was narrow, or from a test that was mostly automated, is not the same evidence at all.

4. What it would cost you to be wrong

A system holding payment data for a hundred thousand customers and an internal room-booking tool do not deserve the same interval, even under the same policy. Tiering by consequence is what stops a uniform annual cadence from being simultaneously too much for some systems and far too little for others.

A workable pattern

For most organisations with a customer-facing application:

• Continuous automated scanning, because new vulnerabilities in software you already run are published on the days you are not testing.
• Annually at minimum, a full-scope test with people.
• On significant change, a focused test of what changed — much smaller and cheaper than a full engagement, and the one most often skipped.
• Retest within the window after each round of fixes, which is what produces the closure evidence.

Rotate the scope

The failure mode of a fixed annual cadence is testing the same scope every year and reading a quiet report as improvement, when what it may mean is that the tested part is fine and the untested part has never been looked at.

If the estate is larger than one engagement, rotate: the customer application this year, the internal network next, the API and mobile clients the year after — with the highest-consequence system in scope every time.

What to expect as the arc develops is in what changes by your third VAPT.