If you are an Indian fintech that touches money, RBI expects annual VAPT covering applications, infrastructure and APIs — repeated after any significant change, with remediation verified. This applies well beyond banks: NBFCs, payment aggregators, account aggregators, and fintechs partnered with regulated entities inherit the requirement by contract.
Most teams discover this the same way. A bank partnership closes, a payment aggregator licence comes through, or a customer's compliance checklist lands with a line item asking for a VAPT report. This guide covers what RBI actually requires, how CERT-In and the DPDP Act layer on top, and what evidence survives a supervisory review.
Three Regimes, None Substituting for Another
The most expensive misunderstanding in Indian fintech compliance is treating these as one obligation. They are independent, they are enforced by different bodies, and complying with one gives you nothing on the other two.
The useful convergence is that all three land on the same artefact — a manual penetration test with verified remediation. Scope it once properly and you satisfy the technical requirement across all three. What differs is the documentation and reporting wrapped around it.
What RBI Actually Requires
RBI's expectations are spread across several instruments rather than one circular:
- Cyber Security Framework for Banks (June 2016) — the original baseline
- Master Direction on IT Governance, Risk, Controls and Assurance Practices — in force for banks and NBFCs since April 2024
- Master Direction on Digital Payment Security Controls (2021)
- IT Framework for the NBFC Sector — tiers obligations by asset size, with a higher standard above ₹500 crore
- Directions for non-bank Payment System Operators (30 July 2024) — adds security audits and VAPT before deployment or redeployment, phased in for large PSOs from April 2025, medium from April 2026 and small from April 2028
On testing specifically, the consistent expectation is VAPT at least annually for internet-facing applications, and again after any significant change. Scope must cover applications, infrastructure and APIs, address the OWASP Top 10 plus business logic, and include remediation verification.
The supervisory bar has moved. Examinations no longer stop at "did you run a scan." The questions now are whether a manual penetration test was performed, whether findings were remediated, and whether closure was independently confirmed. A scanner report will not survive that line of questioning.
Who This Reaches
The common assumption — that small means exempt — does not hold.
- Banks and Payment System Operators face the deepest requirements
- Upper and Middle Layer NBFCs sit close to bank-level obligations
- Base Layer NBFCs have lighter requirements, but still need a board-approved policy, incident reporting capability and a VAPT programme
- Fintechs partnered with regulated entities inherit requirements contractually — your bank partner's compliance team will pass them straight through
And CERT-In's April 2022 Directions apply to every body corporate in India, with no exemption for size or sector. That is the floor beneath everything else.
CERT-In: The Six-Hour Clock
The obligation most often missed is incident reporting. Under the 2022 Directions, a covered cyber incident must be reported within six hours of noticing it.
RBI-regulated entities also report through CIMS, the Centralised Information Management System — an initial report within six hours, followed by detailed root cause analysis within 21 days.
The practical failure here is procedural, not technical. Registration on CIMS has to happen before an incident, and six hours is not enough time to work out who is authorised to file. Nominate the person, document the path, and rehearse it. An unreported incident becomes a supervisory finding, and that is a materially worse conversation than the incident itself.
On auditor selection: RBI does not strictly mandate CERT-In empanelled auditors for every entity type, but many banks and NBFCs require their partners to use empanelled or equivalently qualified firms. Check your partner agreement before assuming a general-purpose tester is acceptable.
ISO 27001 Does Not Equal RBI Compliance
This trips up teams that have already invested in certification. ISO 27001 covers many of the same control areas and genuinely reduces audit friction — it is a positive signal in a supervisory review.
But RBI-specific obligations sit outside it: the VAPT cadence and scope, CIMS registration and reporting, board-level governance structures, and the CISO role. Certification is a head start, not a substitute. The same applies to SOC 2 and ISO 27001 testing programmes more generally — useful groundwork, different evidence.
What a Compliant VAPT Programme Looks Like
- Annual manual testing of internet-facing applications, plus re-testing after significant change. Define "significant" in your own policy so the trigger is auditable.
- Scope covering applications, infrastructure and APIs. APIs are the most commonly under-scoped and, for a payments business, usually where the real exposure sits.
- OWASP Top 10 plus business logic. The current reference is OWASP Top 10:2025 — note that Broken Access Control remains number one, and it is exactly what automated tools cannot reason about.
- Authenticated testing. An unauthenticated test of a lending or payments application leaves the risk untested.
- Verified remediation. The retest report is the evidence that matters. See how a VAPT engagement runs for what each phase produces.
- CVE tagging against NVD entries with CVSS scoring, so vulnerability management is demonstrably systematic rather than ad hoc.
Where AWS Fits
Most Indian fintechs run on cloud, and a large share on AWS. Several RBI expectations translate directly into architecture decisions rather than paperwork: data localisation, encryption and key management, access control and privileged access review, logging with sufficient retention, and tested business continuity with defined RPO targets.
Getting these right in the account design makes the annual audit substantially cheaper, because the evidence is generated continuously rather than assembled under deadline. That is cloud security and DevSecOps work, and it is why teams with mature pipelines spend less on compliance year over year.
One practical note on tooling: AWS Security Agent is not available in an India region, which matters if you have data residency constraints. Our comparison of autonomous versus manual testing covers where each fits.
Budgeting
Compliance-grade manual testing for a fintech typically sits in the upper bands of the Indian market, because scope covers applications, APIs and infrastructure, and because documentation and retest cycles are mandatory rather than optional. Our breakdown of VAPT cost in India sets out the ranges.
The cost teams under-budget is not the test. It is remediation engineering time and the evidence trail — tickets, commits and closure records that demonstrate findings were actually fixed.
If you handle cardholder data, PCI-DSS runs alongside all of this and is more prescriptive still; our guide to PCI-DSS compliance for fintech startups covers that track.
Getting It Scoped
Start from your entity classification and partner obligations, because those determine scope. Then define what counts as a significant change, register on CIMS before you need it, and book testing with enough runway for remediation and retest.
If you are running a fintech platform on AWS and need testing scoped against RBI expectations — or your bank partner's checklist — explore our VAPT services and FinTech DevOps practice, or talk to our team. We will map the scope to the obligations that actually apply to your entity type rather than testing everything at once.
