How Often Should VAPT Be Done? Annual Baseline, Change Triggers and Regulator Cadence in India

Most organisations should run a full VAPT at least once a year and again after any significant change to an in-scope system. Regulated entities in India often need more: RBI expects vulnerability assessment every six months of critical systems and DMZ systems that have a customer interface, SEBI requires two VAPT cycles a year from some entities, IRDAI asks for six-monthly external black-box testing of internet-facing assets, and PCI DSS adds quarterly scans. The right cadence is the strictest rule that applies, adjusted for each asset's exposure.

VAPT frequency at a glance

The table summarises the testing intervals in the primary texts. Each row is sourced in the sections that follow.

Why once a year is only the baseline

An annual test tells you what was exploitable on the days the testers were working. It says little about the release that went out the following month, the new cloud account someone created, or the vendor API added in the second quarter. The attack surface changes continuously; a yearly test samples it once.

That is why every framework below pairs a calendar interval with an event trigger. Treat the annual engagement as the full-depth review of the whole scope, then add two things around it: lighter, frequent vulnerability scanning to catch known issues between tests, and targeted penetration testing whenever a material change lands. If you are unsure which kind of test fits which asset, our guide to the types of penetration testing sets out the differences between network, web, API, cloud and red team work.

What counts as a significant change

No Indian regulator gives an exhaustive list, and PCI DSS does not define significant change in the requirement text reproduced in its SAQ D for merchants, so each entity must set its own definition. In practice, we treat these as triggers for a scoped retest:

• A new internet-facing application, API or domain going live.
• A major release that changes authentication, authorisation, payment flows or data handling.
• Infrastructure moves: a data centre migration, a new cloud account or region, or a change of hosting provider.
• Changes to network segmentation, firewall architecture or remote access.
• A new third-party integration that exchanges sensitive data.
• Remediation of critical findings, which needs a retest to prove the fix works.

The scope of a change-driven test should match the change. A new payments API needs an API test, not a repeat of the whole annual engagement.

RBI: six-monthly VA and annual PT for critical systems

The Reserve Bank's Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (RBI/2023-24/107, dated 7 November 2023) covers VA/PT in paragraph 26. For critical information systems and systems in the De-Militarized Zone (DMZ) that have a customer interface, vulnerability assessment must run at least once every six months and penetration testing at least once every 12 months. These systems must also be tested throughout their lifecycle: before implementation, after implementation and after major changes.

For non-critical systems, the Direction asks entities to decide both the need for testing and its frequency on a risk basis. Testing must be done by appropriately trained and independent information security experts or auditors. Post-implementation tests should run in production. If a penetration test has to run in a test environment, that environment must match production, and any deviation must be documented and approved by the Information Security Committee.

SEBI CSCRF: one or two cycles per financial year

SEBI's Cybersecurity and Cyber Resilience Framework (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, dated 20 August 2024) sets VAPT periodicity in Table 18.

• Protected systems or CII: regulated entities whose systems NCIIPC has identified as protected systems or critical information infrastructure must complete VAPT at least twice a year. That means one full cycle in each half of the financial year, April to September and October to March, including report submission, closure and revalidation.
• All other regulated entities: VAPT at least once a year, starting in the first quarter of the financial year.
• Qualified Stock Brokers: SEBI's CSCRF FAQs (FAQ 14) set VAPT and cyber audit periodicity at half-yearly, whatever their CSCRF category.

The same framework sets the timelines around each cycle in Table 19. The VAPT report is due within one month of completing the test, after IT Committee approval. Findings must be closed within three months of the report being submitted, using a graded approach based on criticality. Revalidation must be completed within five months of the VAPT itself. Standard DE.CM.S5 also requires VAPT before new systems are commissioned, especially critical systems or systems connected to them. Unless the framework says otherwise, CSCRF audits must be carried out by a CERT-In empanelled IS auditing organisation.

IRDAI: annual VAPT plus six-monthly external testing

The IRDAI Information and Cyber Security Guidelines, 2023 (version 1.0, April 2023) are more demanding for internet-facing assets than a single annual test suggests. The vulnerability assessment controls require:

• VAPT of internet-facing applications or infrastructure at least once a year.
• External black-box penetration testing of all internet-facing information assets and systems once every six months.
• Mandatory security testing for every change to internet-facing assets, with gaps closed before the change reaches production.
• VAPT, including secure code review, of business applications, APIs and web services periodically and before go-live.
• High-risk VAPT gaps closed within one month, followed by validation testing, and an outer limit of two months to close all audit gaps.

The information security team must also set standards for how often assessments run, based on how critical each application is.

PCI DSS: quarterly scans, annual penetration tests

PCI DSS Requirement 11 is the most granular cadence most Indian businesses will meet. The requirement text reproduced in the PCI SSC's SAQ D for merchants sets out:

• 11.3.1: internal vulnerability scans at least once every three months, with high-risk and critical vulnerabilities resolved and rescanned.
• 11.3.1.3: internal scans after any significant change.
• 11.3.2: external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor.
• 11.3.2.1: external scans after any significant change, resolving vulnerabilities scored 4.0 or higher by CVSS.
• 11.4.2 and 11.4.3: internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, by a qualified tester with organisational independence.
• 11.4.5: where segmentation isolates the cardholder data environment, penetration tests of segmentation controls at least once every 12 months and after any change to those controls.

Service providers carry additional requirements under 11.4.6. How much of this applies depends on your scope and validation type, which our PCI DSS scope reduction and SAQ guide explains. For assessment support, see our PCI DSS compliance service.

Where CERT-In fits

CERT-In's directions of 28 April 2022 (No. 20(3)/2022-CERT-In) do not set a VAPT interval. They require reporting of specified cyber incidents within 6 hours of noticing them, and logs of all ICT systems kept for a rolling 180 days within Indian jurisdiction. CERT-In matters to testing in a different way: frameworks such as SEBI CSCRF require audits by CERT-In empanelled organisations. Check that requirement against your own regulator's text before appointing a tester.

A risk-based cadence by asset type

Where no regulator sets the interval, or for assets outside regulated scope, set frequency by exposure and data sensitivity. The table below is a practitioner baseline, not a regulatory requirement.

Three adjustments move an asset up a row. If it holds personal data covered by the DPDP Act, card data or health records, test it more often. If it had critical findings last cycle, schedule a mid-year retest. And if it changes weekly, move from calendar testing to release-linked testing, with a deeper annual review on top. For web and cloud assets specifically, see our web application VAPT and cloud VAPT services.

Where SecureRoot fits

We help teams build one testing calendar that meets the strictest rule that applies to them, rather than running separate engagements for each framework. A typical plan pairs an annual full-scope test with change-driven retests and the six-monthly or quarterly cycles a regulator requires, all mapped to a single asset inventory. Our VAPT services cover networks, web applications, APIs and cloud environments, including retesting of fixed findings. Budget depends on scope and frequency; our penetration testing cost guide for India explains what drives it.

Frequently asked questions

How often should VAPT be done if no regulator applies to us?

At least once a year for the full scope, plus a targeted test after any significant change. That is the common baseline across frameworks, and many customers and auditors look for evidence of regular testing. Between annual tests, run automated vulnerability scans on internet-facing assets at least monthly, and on every release for applications that ship often. Raise the frequency for assets that hold sensitive personal data, process payments or had critical findings in the last cycle; for those, a six-monthly penetration test is reasonable. Keep a low-risk internal tool on a longer cycle unless it changes or becomes exposed to the internet. Write the cadence into your security policy and tie it to your asset inventory, so a missed test shows up as a gap rather than being forgotten. Auditors and enterprise customers usually care more about a documented schedule you actually follow than about any single interval.

Is quarterly vulnerability scanning the same as quarterly VAPT?

No. PCI DSS Requirements 11.3.1 and 11.3.2 require internal and external vulnerability scans at least once every three months, but penetration testing under 11.4.2 and 11.4.3 is required at least once every 12 months and after significant change. A scan is largely automated: it identifies known vulnerabilities and misconfigurations and produces a list to fix. A penetration test is a manual exercise in which a tester chains weaknesses, bypasses controls and shows real impact, such as reaching card data or taking over an account. The two catch different problems. Scans are cheap enough to run often and pick up newly disclosed issues between tests. Penetration tests find logic flaws, broken access control and attack paths that scanners miss. A compliant PCI DSS programme needs both, on separate calendars. External quarterly scans must also be run by a PCI SSC Approved Scanning Vendor, which internal scans do not require.

What counts as a significant change that needs a new penetration test?

PCI DSS does not define significant change in its requirement text, and RBI refers to major changes without listing them, so you need your own written definition. Sensible triggers include a new internet-facing application, API or domain; a release that changes authentication, authorisation, session handling or payment flows; migration to a new data centre, cloud account or region; changes to network segmentation or firewall architecture; and a new third-party integration that exchanges sensitive data. Routine patching, content updates and cosmetic front-end changes usually do not need a new penetration test, though they may still need a vulnerability scan. The scope of the retest should match the change. A redesigned login flow needs focused authentication testing, not a full repeat of the annual engagement. Record the decision for each material change in your change management tickets, because PCI DSS assessors will ask to see change control documentation alongside the test reports.

Does SEBI CSCRF require VAPT twice a year for every regulated entity?

No. Table 18 of SEBI's Cybersecurity and Cyber Resilience Framework requires two VAPT cycles a year only from regulated entities whose systems NCIIPC has identified as protected systems or critical information infrastructure. For them, one complete cycle, including report submission, closure and revalidation, must be finished in each half of the financial year. All other regulated entities must conduct VAPT at least once a year, starting in the first quarter of the financial year. SEBI's CSCRF FAQs add one exception: Qualified Stock Brokers must run VAPT and cyber audit half-yearly, whatever category they fall into. Whatever the frequency, the timelines are strict. The report is due within one month of the test, findings must be closed within three months of the report, and revalidation must be done within five months. Unless CSCRF specifies otherwise, the work must be done by a CERT-In empanelled IS auditing organisation.

How soon should we retest after fixing VAPT findings?

As soon as the fixes are deployed, and within the regulator's deadline if one applies. Retesting confirms that a fix actually closes the vulnerability rather than blocking one proof of concept. Under SEBI CSCRF, findings must be closed within three months of the VAPT report being submitted, and revalidation completed within five months of the test. IRDAI's 2023 guidelines require high-risk gaps to be closed within one month and followed by validation testing, with two months as the outer limit for closing all audit gaps. PCI DSS requires rescans until high-risk and critical vulnerabilities are resolved, and external scans must meet the ASV requirements for a passing scan. Where no rule applies, retest critical and high findings within 30 days and the rest before the next cycle. Keep the retest report with the original findings, because auditors will want to see that each issue was verified as closed, not just marked fixed.

Next step

If you need a testing calendar that satisfies RBI, SEBI, IRDAI or PCI DSS without paying for overlapping engagements, book a 30 to 45 minute scoping call. We will map your assets to the rules that apply and send a written scope, a timeline and a fixed price.