By Xhield Team · July 30, 2026 · 15 min read
The regulator has stopped hinting
India's banking and financial sector loses an estimated ₹50,000 crore annually to cyber attacks. UPI fraud alone accounted for ₹485 crore across 632,000 reported incidents in FY 2024-25. Transaction volumes are growing at 35% year-on-year. And the attack surface — open banking APIs, digital lending apps, account aggregators, third-party payment integrations — is expanding faster than most BFSI security programs can track.
The RBI has noticed. Its April 2024 Master Direction on IT Governance, Risk, Controls and Assurance Practices is not another advisory or a set of suggested best practices. It is a binding directive. It explicitly mandates Vulnerability Assessment and Penetration Testing for banks, NBFCs, and regulated entities — with specific frequency requirements, scope obligations, auditor qualification standards, and board reporting expectations.
The problem is not that BFSI organisations don't know they need to do VAPT for RBI compliance. Most do. The gap is in what their programs actually cover — whether the frequency, scope, documentation, and pre-engagement discovery match what the directives require, or whether the VAPT has become a compliance checkbox that satisfies the paperwork without meaningfully reducing risk.
This post maps the RBI's cybersecurity framework — four interlocking directives — to what each one specifically demands from a pentest program. Entity by entity. Directive by directive. And what a VAPT program that genuinely satisfies the RBI's intent, rather than just its letter, looks like.
1. The RBI cybersecurity framework — four directives that matter for VAPT
The common mistake in approaching RBI cybersecurity compliance is treating it as a single framework. In practice, it is four interlocking directives, each applying to different entity types with different obligations. Understanding which directive applies is the first question any BFSI organisation needs to answer.
Cybersecurity Framework for Banks (June 2016)
The foundational circular. Issued in response to the Bangladesh Bank heist and a wave of ATM skimming attacks, it established the baseline security controls for scheduled commercial banks, mandated periodic VAPT on critical systems, and introduced board-level cybersecurity accountability for the first time. Still in force and still directly applicable to scheduled commercial banks as the underlying governance framework.
Master Direction on IT Governance, Risk, Controls and Assurance Practices (April 2024)
The most significant update since 2016. This direction consolidated and updated earlier circulars, extended core principles to NBFCs, cooperative banks, and other regulated entities, and provided the most explicit VAPT frequency and scope requirements the RBI has ever published. Vulnerability assessments every six months. Penetration testing at minimum annually. Risk-based methodology. Qualified personnel. This is the current binding standard for most RBI-regulated entities.
Master Direction on Cyber Resilience and Digital Payment Security Controls for non-bank PSOs (July 2024)
Applies specifically to payment aggregators, card payment networks, and prepaid payment instrument issuers. Goes beyond the periodic testing cadence of the 2024 Master Direction by introducing event-triggered VAPT obligations — mandatory testing after major releases, significant infrastructure changes, and security incidents. A calendar-only testing program does not satisfy this direction.
Digital Lending Directions (2025)
Applies to digital lending apps and their NBFC partners. Mandates application security testing including VAPT as part of a secure software development lifecycle — testing must occur before new app releases and after significant updates, not just on an annual calendar. Treats security testing as a development process control, not a post-deployment compliance activity.
For many BFSI organisations, more than one of these directives applies simultaneously. A bank that operates a payment aggregator subsidiary and a digital lending app faces all four frameworks at once — with different frequency obligations, different trigger conditions, and different scope requirements for each.
2. Who the framework applies to — and how requirements differ by entity type
The RBI's framework is explicitly tiered. Obligations scale with entity size, systemic importance, and the nature of services offered. Getting this mapping right matters — both for understanding minimum obligations and for avoiding the assumption that a smaller entity is substantially exempt.
Scheduled Commercial Banks face the deepest obligations. The full 2016 framework plus the 2024 Master Direction applies in its entirety. Board-level CISO accountability, bi-annual vulnerability assessments, annual penetration testing, CERT-In empanelled auditor requirements for certain assessments, and board reporting of VAPT findings are all mandatory.
Upper and Middle Layer NBFCs face near-bank level obligations under the 2024 Master Direction. VAPT frequency and scope requirements closely mirror those of scheduled commercial banks. The tiered NBFC classification under the Scale-Based Regulation means Upper and Middle Layer NBFCs cannot treat themselves as having materially lighter obligations than banks on security testing.
Base Layer NBFCs have lighter but not trivial obligations. A board-approved IT security policy, basic security controls, incident reporting capability, and a baseline VAPT program are all mandatory. CERT-In's 2022 directions — 6-hour incident reporting, 180-day log retention — apply universally regardless of NBFC tier, layering on top of RBI-specific obligations.
Payment Aggregators and non-bank PSOs face the July 2024 Cyber Resilience Direction's additional event-triggered testing requirements on top of periodic obligations. Annual VAPT plus mandatory testing after major releases and significant changes. API security is explicitly in scope under this direction.
Fintech companies and Digital Lending App operators face the 2025 Digital Lending Directions, which embed security testing into the development lifecycle. VAPT before release, after significant updates, and as part of the broader secure SDLC framework. Security testing is not a post-deployment compliance activity under this direction — it is a release gate.
One point worth making explicitly for smaller entities: the assumption that "we're small, so the heavy requirements don't apply to us" is increasingly dangerous under the 2024 framework. RBI's supervisory reviews are specifically checking whether basic VAPT and IT governance obligations are being met, including at Base Layer NBFCs. The question is not whether VAPT is required — it is — but at what frequency and depth.
3. What the 2024 Master Direction specifically requires from VAPT
The 2024 Master Direction is the most explicit the RBI has ever been about security testing requirements. Translating its specific VAPT obligations from regulatory language into operational meaning reveals several obligations that many existing programs do not currently meet.
Frequency — bi-annual VA, annual PT
Vulnerability assessments every six months for critical systems. Penetration testing at minimum annually. This is the stated requirement in the 2024 direction — not a recommendation, not a guideline. A significant number of RBI-regulated entities still conduct VA once a year and believe they are compliant. Under the 2024 direction, they are not. The bi-annual VA requirement is one of the most commonly missed obligations in current BFSI VAPT programs, and one of the first things RBI supervisory reviews are now checking.
Scope — critical systems broadly defined
The direction specifies that testing must cover internet-facing applications, critical IT infrastructure, APIs, and payment processing systems. This is broader than most existing VAPT scope documents. A scope confined to the core banking system — tested once a year, produced as a VAPT report for the auditor — does not satisfy the direction's intent. Mobile app backends, internet banking portals, UPI stack components, API banking endpoints, and administrative interfaces are all within scope.
Auditor qualification
For certain assessments under the RBI framework, CERT-In empanelled security auditors are required — not any third-party vendor. Organisations must verify that their VAPT vendor holds current CERT-In empanelment and that the empanelment covers the categories of testing being conducted. An assessment conducted by a non-empanelled vendor may not be recognised in a supervisory review.
Board reporting
VAPT findings must be reported to the board or a board-level IT strategy or audit committee — not just the security team. This changes the documentation standard required from VAPT reports significantly. A technical report written for security engineers does not meet the board reporting obligation. Findings must be contextualised for board-level understanding — business impact, risk ratings in non-technical language, remediation status, and residual risk.
Remediation tracking and closure
The direction's intent is risk reduction, not report production. Documented remediation of findings — with timelines appropriate to severity, tracking of remediation progress, and evidence of closure — is part of the compliance requirement. A VAPT report filed and forgotten, with findings unaddressed, is not compliance. RBI supervisory reviews have specifically flagged BFSI organisations that had VAPT reports on file but no evidence of remediation.
4. Where most BFSI VAPT programs fall short of RBI's intent
Most RBI-regulated entities conduct VAPT. The compliance gap is not in having a program — it is in what that program actually covers and how its findings are used. Four shortfalls appear consistently.
Scope confined to core banking only
The RBI's directive covers critical IT infrastructure broadly. Mobile apps, internet banking portals, payment APIs, third-party integrations, and internal administrative systems all fall within scope. Many BFSI VAPT programs test the core banking system and the primary web portal, and stop there. Everything else — the expanding digital channel estate that is where most new risk sits — goes untested.
Annual VA instead of bi-annual
The 2024 direction is explicit: vulnerability assessments every six months for critical systems. Many programs still operate on an annual VA cycle, either because the 2024 direction's requirements have not been fully absorbed into the security program design, or because procurement and vendor engagement cycles make bi-annual testing operationally inconvenient. Inconvenience is not a defence in a supervisory review.
No event-triggered testing process
Payment aggregators and PSOs under the July 2024 Cyber Resilience Direction must test after major releases and significant infrastructure changes. Most run calendar-only programs with no formal trigger for out-of-cycle testing. A major payment platform release that goes live without a targeted security assessment is both a compliance gap and a concrete risk — the highest-risk moment for a production system is immediately after a significant change.
VAPT scope built without pre-engagement discovery
Critical systems change continuously — new APIs are added, third-party integrations introduced, cloud services provisioned, mobile app versions released. A scope document defined once at the start of an annual program and never revisited will miss every system added during the year. RBI's intent is continuous risk management, not an annual snapshot of last year's infrastructure. The scope should reflect what exists now, not what existed when the last engagement was scoped.
The supervisory review dimension makes each of these shortfalls concrete rather than theoretical. RBI has demonstrated willingness to act on cybersecurity compliance gaps — restricting new product launches, mandating corrective action plans, and in severe cases directing board-level changes at cooperative banks. A VAPT program that satisfies the letter of the directive on paper but not its substance is a supervisory risk with real operational consequences.
5. The BFSI attack surface problem — why pre-VAPT discovery matters in banking
The BFSI sector has one of the most complex and rapidly expanding attack surfaces of any industry in India. Three characteristics specific to banking make attack surface management significantly harder than in most other sectors.
Legacy core banking connected to modern digital channels
Most banks and large NBFCs run core banking platforms that are decades old, connected through integration layers to modern mobile apps, UPI transaction stacks, and API banking services. Each integration point — every middleware connector, every API gateway, every data synchronisation service — is a potential attack surface. Many of these integration layers were built incrementally over years and are not fully documented in any single asset inventory.
Third-party fintech integrations
The open banking and embedded finance era has dramatically expanded the BFSI attack surface through third-party connections — account aggregators operating under the AA framework, digital lending partners in co-lending arrangements, payment processors, insurance partners, investment platforms. Each integration endpoint is in scope under RBI's framework. Most are absent from VAPT scope documents because they were provisioned by a business team rather than IT, or because the integration was treated as the third party's responsibility rather than the bank's exposure.
Rapid digital channel expansion
UPI volumes growing at 35% year-on-year means new digital products and payment features are being released continuously. Each new release is an event-triggered testing obligation under the 2024 PSO direction. Each represents new attack surface that appears between annual VAPT cycles and may never appear in a scope document built from last year's infrastructure map.
Pre-VAPT discovery in the BFSI context means mapping the full attack surface — subdomains, API endpoints, third-party integration surfaces, mobile backend services, legacy system interfaces, cloud infrastructure — before scoping any VAPT engagement. This is not an optional refinement to the process. It is the only way to build a scope document that reflects current infrastructure rather than historical memory.
The same passive reconnaissance techniques that attackers use against BFSI targets — certificate transparency logs surfacing forgotten subdomains, Shodan revealing exposed services on banking IP ranges, passive DNS uncovering legacy integration endpoints — are the tools that should be used in pre-VAPT discovery before any RBI-compliant testing engagement begins.
6. What an RBI-compliant VAPT program actually looks like
Translating the directive requirements into a concrete program structure gives BFSI security teams a clear picture of what needs to be built and maintained.
Scope definition from a full asset map
Before any VAPT vendor is engaged, build a comprehensive map of critical systems. Core banking system interfaces. Internet banking portals and mobile app backends. UPI stack components and payment processing systems. API banking endpoints. Third-party integration surfaces. Administrative and operational interfaces. Cloud infrastructure across every business unit. This asset map — not a legacy spreadsheet, not a CMDB last updated eighteen months ago — is the authoritative source for scope definition. Every system on the map is a VAPT scope candidate. Every system off the map is a risk.
Bi-annual VA, annual PT as the baseline cadence
Vulnerability assessments against the full critical systems scope every six months. Penetration testing at minimum annually, conducted by CERT-In empanelled security professionals using a risk-based methodology that goes beyond a generic checklist. The bi-annual VA cadence is the minimum — high-risk systems or environments undergoing rapid change may warrant more frequent assessment.
Event-triggered testing workflow
For PSOs, payment aggregators, and digital lenders, establish a formal trigger process alongside the periodic cadence. Any major release — new mobile app version, new payment feature, new API integration — triggers a targeted security assessment before the change goes live. Any significant infrastructure change initiates a scoped review. Any security incident of material severity initiates a post-incident VAPT once the incident is contained. This is a process requirement that must be embedded in release management and incident response workflows, not just security policy.
Board-ready documentation standard
Every VAPT produced under the RBI framework must meet a board-presentable standard. Scope documentation showing what was tested, why it was included, and the basis for prioritisation. Methodology descriptions in language accessible to non-technical board members. Findings with severity ratings and business impact framing — not just CVSS scores. Remediation plans with timelines calibrated to severity. Evidence of remediation completion for closed findings. This is a different deliverable from a technical penetration test report, and the distinction matters in a supervisory review.
Remediation tracking as a program component
VAPT findings that are not remediated do not constitute compliance. Build formal remediation tracking into the program — severity-tiered timelines (critical findings within 24-48 hours, high within 30 days), assigned ownership for each finding, documented evidence of closure, and escalation paths for findings that cannot be remediated within the standard timeline. The board reporting obligation implies that remediation status is reported at the board level alongside the findings themselves.
7. RBI vs CERT-In vs DPDPA — the overlapping compliance picture for BFSI
BFSI organisations do not face a single compliance framework for cybersecurity. They face three simultaneously — each with distinct but overlapping security testing requirements. A well-designed VAPT program can address all three, but only if it is scoped and documented with all three in view from the start.
RBI mandates testing frequency (bi-annual VA, annual PT for critical systems), scope (broadly defined critical IT infrastructure), auditor qualification (CERT-In empanelled for certain assessments), and board reporting. The framework is focused on operational resilience, systemic risk, and the integrity of India's financial system.
CERT-In mandates 6-hour incident reporting, 180-day log retention, vulnerability disclosure, and security audits for certain categories. It is infrastructure-focused and applies to every corporate body, providing the baseline security hygiene obligations that underpin the more sector-specific RBI requirements. CERT-In compliance does not satisfy RBI's VAPT frequency and scope obligations — it establishes the floor, not the ceiling.
DPDPA mandates reasonable security safeguards for every system processing personal data — which in the BFSI context means almost every system the organisation operates. Customer account data, transaction records, KYC documents, loan application data — all personal data under the Act. DPDPA adds data flow mapping, explicit API testing obligations, third-party processor coverage, and regulatory documentation requirements that layer on top of RBI's testing frequency obligations.
The practical design implication: a BFSI organisation that scopes its VAPT program purely to RBI's critical systems definition may still carry DPDPA gaps — systems processing personal data that fall outside what RBI classifies as critical but that create significant DPDPA liability. And it may carry CERT-In gaps in infrastructure outside the banking application perimeter. A program designed to satisfy all three simultaneously — through comprehensive scope definition, appropriate testing frequency, and documentation built for regulatory review — is more efficient than three separate compliance exercises, and more defensible in any regulatory interaction.
8. Closing
The RBI's cybersecurity framework is the most explicit it has ever been about what security testing must look like for banks, NBFCs, and payment system operators. The 2024 Master Direction does not leave frequency or scope to interpretation. Bi-annual vulnerability assessments. Annual penetration testing. Risk-based methodology. Qualified personnel. Board reporting. Documented remediation.
What it leaves to each organisation is the quality of the program behind the compliance paperwork. A VAPT program that satisfies the letter of the directive through an annual checkbox exercise — testing a narrow scope, producing a report for the auditor's file, and leaving findings unaddressed — is increasingly a supervisory risk as RBI's examination function looks more closely at substance rather than just documentation.
The quality of a VAPT program begins with the quality of its scope. And the quality of scope begins with knowing what you have — every critical system, every API endpoint, every third-party integration surface, every digital channel asset — before any testing engagement begins.
The regulator's framework defines the minimum. The organisation's risk posture should define the program above it.
Build a VAPT program on a complete picture of your attack surface. Start with xhield's pre-VAPT discovery →
Related reading:
- DPDPA and Security Testing: What India's Data Protection Law Means for Your VAPT Program
- Why Your VAPT Scope Is Wrong Before the Engagement Even Starts
- What a Pentester Sees in the First 30 Minutes — And Why It Should Scare You
- Shadow IT and CERT-In: The Attack Surface Your Annual VAPT Is Missing
- How CERT-In Compliance is Reshaping Enterprise VAPT in India (2026)