What RBI actually expects from your VAPT programme — and where banks fall short

Most security and compliance teams at Indian banks and NBFCs can recite the basics of RBI's cybersecurity requirements. The problem isn't awareness — it's that the requirements have expanded faster than most VAPT programmes have kept up, and the gap between what a bank believes it's doing and what the regulator actually expects has grown wider than most compliance teams realise.

Here's what's actually in force right now, and where the common gaps are.

The framework has three layers, not one

RBI's Cyber Security Framework for Banks (June 2016) is still the foundation. It set the baseline: a board-approved cybersecurity policy, a Security Operations Centre for continuous monitoring, and — critically — a requirement that periodic Vulnerability Assessment and Penetration Testing be carried out by qualified, independent parties. It also established a CISO reporting line that sits outside the Head of IT, and incident-reporting timelines that were aggressive even in 2016.

The Master Direction on IT Governance, Risk, Controls and Assurance Practices (RBI/2023-24/107), effective April 2024, sits on top of that baseline. It formalises IT governance as a board-level responsibility, requires a documented IT and information-security risk management framework, and mandates periodic information-systems audits — not just penetration tests, but a broader assurance function that most banks' existing VAPT vendor relationships were never built to support.

The Master Direction on Cyber Resilience and Digital Payment Security Controls for non-bank PSOs (2024) goes further still. It extends VAPT obligations to a wider set of regulated entities and — this is the part most compliance calendars miss — introduces event-driven testing obligations that exist independently of the periodic schedule.

The frequency requirement is a floor, not a ceiling

The commonly cited numbers are Vulnerability Assessment every six months and Penetration Testing at least annually for critical and internet-facing systems, with some risk classifications pushing to quarterly for high-risk systems. These figures are accurate, but treating them as the whole obligation is the first common mistake.

The 2024 PSO direction adds a second, independent trigger: VAPT must be carried out before the deployment or redeployment of any service, regardless of when the last scheduled assessment happened. Launch a new customer-facing feature in month two of a twelve-month testing cycle, and that launch triggers its own VAPT obligation — it doesn't wait for month twelve. Most banks' compliance calendars are built around calendar dates, not deployment events, which means this obligation is often met late, met informally, or missed entirely.

Scope has quietly expanded beyond systems you own

Under the current Master Directions, VAPT scope is no longer limited to infrastructure the regulated entity directly owns and operates. Third-party and vendor-hosted systems that touch customer data or critical functions fall inside the same assurance expectation — which means a bank's actual testing surface is very often larger than what its existing VAPT contract covers. Vendor due diligence, security assessment of vendors, and continuous monitoring of third-party risk are explicit expectations, not implied ones.

Incident reporting has a hard clock attached

Cyber incidents must be reported through RBI's platform (referred to as CIMS/DAKSH depending on the direction) within a short window — commonly cited as two to six hours from detection, not from confirmation. That distinction matters: the clock starts when something looks like an incident, not once your team has finished investigating whether it actually is one. A VAPT programme that only produces a report weeks after a scan, with no mechanism for surfacing a live exploitable finding immediately, doesn't give an incident response team the head start this timeline assumes it has.

Where the gap actually lives

Put together, three patterns show up repeatedly in how banks fall short — not from ignorance of the rules, but from the shape of a traditional VAPT engagement:

Point-in-time evidence for a continuous obligation. A VAPT report is accurate for the day it was generated. Deployments, configuration changes, and new vendor integrations happen constantly between testing cycles, and the event-driven trigger under the 2024 direction means the gap between scheduled tests is exactly where new obligations are created.

Scope that stops at the network boundary the vendor was contracted to test. If third-party and cloud-hosted systems aren't included in the standing VAPT scope, the assurance function has a blind spot that the regulator's current expectations explicitly cover.

Findings without a resolution trail. A regulator, or an internal auditor, asking "what did you do about this finding" wants to see closure — a ticket, a fix, a re-test confirming the exploit no longer works. A stack of PDF reports with no linked remediation record answers "were you tested" but not "were you fixed," and increasingly, that second question is the one being asked.

What this means for how testing should actually run

The practical implication isn't "test more often" — it's that testing needs to be continuous enough to catch the gaps a fixed schedule misses, cover the full vendor and cloud surface the current Master Directions actually describe, and produce a resolution record that survives an audit, not just a scan report.

This is the exact shape of the gap Vishnora is built to close. Continuous discovery keeps the asset inventory current as vendors and cloud footprint change, so a deployment-triggered VAPT obligation isn't relying on someone remembering to schedule it. Validated findings — proven exploitable, not just flagged by a scanner — carry the evidence an auditor will actually ask for. And Finding Resolution Intelligence turns every validated finding into a tracked incident with a remediation record and a re-validation step, so the answer to "what did you do about this" is a closed ticket with proof, not a promise.

If you're mapping your current VAPT programme against these obligations and want a second opinion on where the gaps are, we're happy to walk through it — or start with a free external attack-surface report to see what an outside view of your footprint actually looks like today.