Most Indian businesses should run a full Vulnerability Assessment and Penetration Test (VAPT) at least once a year, plus after every major release, infrastructure change, or security incident — supplemented by continuous automated scanning in between. That baseline shifts upward for regulated or high-criticality systems: PCI DSS mandates annual testing plus testing after significant changes, while payment and fintech platforms under RBI oversight are expected to test more frequently given their risk profile. The right cadence for any given application depends on three factors — what compliance frameworks require, how often the codebase and infrastructure actually change, and how much damage a breach of that specific system would cause.
This guide breaks down the triggers that should drive your testing calendar, what the major frameworks actually say, and how to build a risk-based cadence instead of guessing.
Why "Once a Year" Is a Floor, Not a Strategy
Annual VAPT became the default because early compliance frameworks used it as a minimum bar, and it's easy to schedule. But an annual test only reflects the state of your application on the day it was tested. If your team ships weekly — new endpoints, new third-party integrations, new cloud config — the gap between test cycles is where most real-world exploitation happens. A vulnerability introduced in a release six months after your last VAPT sits unassessed until the next scheduled cycle, unless something else triggers a look sooner.
Treat the annual test as the baseline floor required for compliance and board-level assurance — then layer event-triggered and continuous testing on top for anything that actually changes your attack surface.
The Five Triggers That Should Drive Your VAPT Testing Calendar
1. Annual Baseline
A full-scope manual VAPT, at minimum once a year, covering every internet-facing application, API, and network segment in production. This is the assessment most compliance frameworks reference explicitly, and it's the one your board, investors, and enterprise customers will ask to see evidence of during due-diligence.
2. After Every Major Release
"Major" means anything that changes the attack surface: a new authentication flow, a new payment integration, a new public API, a significant architecture change (monolith to microservices, new cloud migration), or a new third-party dependency handling sensitive data. A retest scoped to the changed components — not necessarily a full-scope repeat — closes the gap between what shipped and what was last assessed.
3. Continuous Scanning in CI/CD
Automated DAST (Dynamic Application Security Testing) and SAST (Static Application Security Testing) tools integrated into the CI/CD pipeline catch the low-hanging fruit — outdated dependencies, missing security headers, common injection patterns, exposed secrets in code — on every build, not once a year. This doesn't replace manual penetration testing, which finds business-logic flaws and chained exploits that scanners miss, but it dramatically shrinks the window where known-class vulnerabilities go unnoticed.
4. Incident Triggered Testing
Any confirmed or suspected security incident — a breach, an unauthorized access attempt that succeeded even partially, a third-party vendor compromise that touched your systems, or a critical CVE disclosed in a dependency you run — should trigger a targeted retest of the affected systems before you consider the incident closed. This is also standard practice under most regulatory breach-response expectations, including DPDP Act due-diligence obligations.
5. Scheduled Cadence Review
At least annually, step back and ask whether the cadence itself still fits. An application that grew from an internal tool to a customer-facing payment system needs its testing frequency reassessed, not just its scope.
What Compliance Frameworks Actually Require
Frameworks differ in how prescriptive they are about frequency. Here's what the major ones relevant to Indian SMBs and fintechs actually say.
| Framework | Testing Frequency Requirement | Applies To |
|---|---|---|
| PCI DSS | Annual penetration test, plus after any significant change to the cardholder data environment; internal and external vulnerability scans quarterly | Anyone storing, processing, or transmitting card data |
| RBI cybersecurity framework | Periodic VAPT expected as part of ongoing risk management, with frequency scaled to criticality; frequent expectation for internet-facing and payment systems | Banks, NBFCs, payment aggregators |
| SEBI cybersecurity/CSCRF guidelines | Periodic VAPT for market infrastructure institutions and intermediaries, with defined cycles for critical systems | Stock exchanges, brokers, mutual funds, regulated intermediaries |
| ISO 27001 | No fixed number, but Annex A controls require regular technical vulnerability assessment as part of the ISMS; interval set by the organisation's own risk assessment | Any certified organisation |
| DPDP Act 2023 | No explicit testing calendar, but "reasonable security safeguards" and breach due-diligence expectations imply regular assessment, especially for significant data fiduciaries | Any entity processing personal data of Indian residents |
For the full picture on how DPDP obligations interact with security testing and breach response, see the blog or read the dedicated guide at DPDP compliance. The RBI publishes its cybersecurity and IT governance framework for regulated entities, and SEBI maintains its Cybersecurity and Cyber Resilience Framework circulars for market intermediaries — both are worth reading directly if your organisation falls under their regulatory scope.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanRisk-Based Cadence: Matching Frequency to Criticality
Not every application needs the same testing frequency. A marketing website and a UPI payment gateway carry entirely different consequences if compromised. Build your cadence around three tiers:
- Tier 1 — Critical (payment flows, PII/financial data stores, authentication systems): Full VAPT at least twice a year, retest after every release touching these systems, continuous automated scanning always on.
- Tier 2 — Important (customer-facing apps without direct payment handling, internal tools with sensitive data access): Annual full VAPT, retest after major releases, quarterly automated scans.
- Tier 3 — Lower risk (static marketing sites, internal tools with no sensitive data): Annual lightweight assessment, automated scanning on a lighter schedule.
Most SMBs default every application into Tier 2 by habit, without asking whether their payment or auth flow deserves Tier 1 treatment. That mismatch is where budget gets wasted on low-risk assets while the systems that would actually hurt the business in a breach get tested no more often than a brochure site.
Across a typical multi-application portfolio, testing activity is rarely spread evenly — most organisations run one scheduled baseline test a year, with the remaining testing activity split across release-triggered, incident-triggered, and periodic continuous-scan reviews.
Building a Cadence You Can Actually Sustain
The practical failure mode isn't picking the wrong frequency on paper — it's not having a process that actually fires the retest when a trigger event happens. Release management and security testing usually live in different teams, and "we'll test it next cycle" quietly becomes the default when there's no defined trigger-to-test workflow.
A sustainable program needs three things: a documented baseline schedule tied to compliance requirements, a lightweight trigger checklist that release managers actually check before shipping anything that touches auth, payments, or new external integrations, and a way to run scoped retests fast enough that they don't become a bottleneck teams route around. This is exactly the gap automated, continuously available VAPT platforms are built to close — turning "we should test after this release" into something that actually happens rather than something that gets deferred to the next annual cycle.
Getting Started
If you're not sure where your applications currently sit against this cadence, the fastest way to find out is to run an assessment now and use it as your new baseline. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated VAPT scans that plug into this kind of trigger-based cadence, with manual penetration testing available with a CERT-In empanelled partner for engagements that require it. You can start a free VAPT scan to see where your current attack surface stands before deciding on a testing calendar.