How Often Should You Run a VAPT

The standard answer is annually. It is a floor set by audit convenience, and treating it as a plan leaves you with a system tested every January that changes every fortnight.

Four things set the interval.

1. What you are required to do

If you are regulated, the minimum is set for you, and more regulators now set separate intervals for the two halves of VAPT.

Under the RBI's 2026 cyber security Directions, for instance, vulnerability assessment and penetration testing carry different intervals: six months and twelve months respectively. That means "we do an annual VAPT" does not 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 goes through the Indian frameworks in detail: the RBI intervals and the SEBI CSCRF material. The regulatory number is a minimum, and it applies to 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. Act on this one first: mistakes here are the most consequential and the 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. Continuous scanning runs underneath a periodic test; it does not replace one. What each catches is in what a scanner finds, and what it cannot.

3. What the last test found

Several serious findings in one report say as much about how the system is built as about the flaws themselves. Go back sooner: 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 points the other way. Check what was in scope first: a clean report on a narrow scope, or from a test that was mostly automated, carries far less weight.

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 need the same interval, even under the same policy. Tier by consequence. A uniform annual cadence is 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. It costs a fraction of a full engagement, and it is the one most often skipped.
• Retest within the window after each round of fixes. That is where the closure evidence comes from.

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. It may only mean the tested part is fine and nobody has looked at the rest.

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. Keep the highest-consequence system in scope every time.

What to expect over successive tests is in what changes by your third VAPT.