RBI cybersecurity requirements apply to any Indian fintech that touches money: payment aggregators, account aggregators, NBFCs, and fintech companies working with regulated entities like banks. The governing instrument since 31 July 2026 is the Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, issued in a separate version for each of seven entity classes and effective immediately upon issuance. It repealed the circulars most fintech checklists still name: the Cyber Security Framework in Banks (2016), the IT Framework for the NBFC Sector (2017), the Master Direction on Digital Payment Security Controls (2021), and the Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023). Still separate and still current: the Cyber Resilience and Digital Payment Security Controls Master Directions for non-bank payment system operators, and CSITE supervision. On testing, the Commercial Banks version requires vulnerability assessment at least once every six months and penetration testing at least once in 12 months for critical systems and those in the DMZ with a customer interface, with a risk-based approach elsewhere, conducted by trained and independent experts. Coverage must include applications, infrastructure, and APIs, address OWASP Top 10 plus business logic, and include remediation verification, and testing repeats after significant system changes. Non-compliance risks license action, partnership termination, and IT Act penalties.
You just closed a partnership with a bank or NBFC. Or maybe you’re a payment aggregator that just got your PA license. Somewhere in the compliance checklist your partner handed you, there’s a line item about “RBI cybersecurity framework compliance” and a requirement for a VAPT report.
If you’re a fintech startup in India that touches money in any form (payments, lending, insurance, wealth management), RBI’s cybersecurity requirements apply to you. Not just banks. NBFCs, payment aggregators, account aggregators, and even fintech companies working with regulated entities need to comply. The specifics vary by entity type, but the direction is clear: every player in the financial ecosystem is expected to have a baseline security posture.
Here’s what you actually need to know.
Which RBI Guidelines Apply to You?
RBI consolidated its supervisory instructions on 31 July 2026. Most fintech compliance checklists in circulation still name the circulars that consolidation replaced, so start by separating what is current from what is superseded.
Current:
| Instrument | Status | Applies To |
|---|---|---|
| Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 | Issued 31 July 2026, effective immediately upon issuance | Seven entity classes, one version each: Commercial Banks (RBI/DoS/2026-27/410, linked here), Small Finance Banks, Payments Banks, Urban Co-operative Banks, All India Financial Institutions, NBFCs, Credit Information Companies |
| Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators | Current, and not in the repeal Annex | Payment aggregators, payment gateways, PPI issuers |
| CSITE supervision and reporting | Ongoing | Entities directly supervised by RBI |
Repealed on 31 July 2026:
| Instrument | Annex Sr. | Was applied to |
|---|---|---|
| Cyber Security Framework in Banks (June 2016) | 54 | Scheduled commercial banks |
| Master Direction on IT Governance, Risk, Controls and Assurance Practices (November 2023) | 16 | Banks, NBFCs, UCBs |
| Master Direction on Digital Payment Security Controls (February 2021) | 29 | Payment system operators, banks, non-bank PSOs |
| Master Direction on the IT Framework for the NBFC Sector (June 2017) | 47 | NBFCs |
The Sr. numbers are positions in the Annex to circular DoS.CO.PPG.66/11.01.005/2026-27, dated 31 July 2026, by which RBI repealed 628 supervisory circulars with immediate effect. RBI’s own wording is that the Annex comprises circulars whose instructions have been consolidated into the new Directions, together with those that have become obsolete or redundant.
One practical warning. RBI still serves several of the repealed documents at their old URLs with no withdrawal banner, so a circular you find through a search engine can look live and not be. Check the circular number against the repeal Annex before you build audit evidence against it, and before you accept a vendor questionnaire that names it.
If you’re a payment aggregator, RBI’s Master Direction regulating payment aggregators also carries security requirements you need to meet for licensing and ongoing compliance. Confirm its current title and date on RBI’s Master Directions index before citing it in an audit response.
The key thing to understand: these aren’t suggestions. Non-compliance can result in regulatory action, fines, or your banking partner pulling the plug on your integration.
Key Requirements Breakdown
The exact requirements vary by entity type and scale, but here’s the practical summary of what RBI expects across its various frameworks.
1. Board-Approved Cybersecurity Policy
Every regulated entity needs a cybersecurity policy approved by the board (or equivalent governing body). This isn’t a 50-page document that sits in a drawer. RBI expects it to be reviewed and updated annually, covering emerging threats, incident learnings, and technology shifts.
For startups: if you don’t have a board yet, your founding team needs to formally approve and sign off on this policy. It should cover access control, data protection, incident response, vendor risk, and employee security awareness.
2. Cyber Security Operations Center (SOC)
Banks need a dedicated SOC. Smaller entities (NBFCs, payment aggregators) can outsource this to a managed SOC provider, but you still need continuous monitoring in place. “We check logs once a week” does not meet the requirement.
What this means practically: you need 24/7 monitoring of your critical systems, with alerting and escalation procedures documented.
3. Vulnerability Assessment and Penetration Testing (VAPT)
This is where most fintech startups first encounter RBI compliance. The cadence in the 2026 Directions is more specific than the “annual VAPT” shorthand most checklists use. Reading the Commercial Banks version (RBI/DoS/2026-27/410):
- Vulnerability assessment at least once in every six months, and penetration testing at least once in 12 months, for critical information systems and those in the DMZ having a customer interface (paragraph 151)
- A risk-based approach to deciding both the requirement and the periodicity for non-critical systems (paragraph 151). RBI does not set a fixed cadence for everything you run
- Testing across critical, internet-facing web and mobile applications, servers, and network components, at pre-implementation, post-implementation, and after changes (paragraph 150)
- A documented approach covering scope, coverage, and the vulnerability scoring mechanism, for example CVSS, which also applies to systems hosted in a cloud environment (paragraph 154)
- Conducted by appropriately trained and independent information security experts or auditors (paragraph 155)
- Closure status of VA and PT observations reported to the IT Strategy Committee and Information Security Committee at least quarterly (paragraph 161)
Those paragraph numbers are read from the Commercial Banks instrument. The Directions are issued in a separate version for each entity class, so an NBFC, UCB, Payments Bank, Small Finance Bank, AIFI, or Credit Information Company should quote the paragraph in its own version rather than these numbers.
On top of the regulator’s floor, your report should address OWASP Top 10, business logic vulnerabilities, and API security, and include remediation verification rather than a list of findings.
RBI does not mandate a CERT-In empanelled auditor in the Commercial Banks version. Paragraph 159 is conditional, applying “in case of CERT-In empanelled auditors”, which means RBI contemplates non-empanelled auditors doing this work. Paragraph 156 asks the bank to satisfy itself on the auditor’s requisite qualification, professional expertise, appropriate credentials, and suitable competency. That is a competence test, not a panel test. Many banks and NBFCs still require their partners to use empanelled firms as a matter of their own procurement policy, which is a contractual requirement rather than a regulatory one. If your banking partner requires CERT-In empanelment, confirm that upfront before engaging a vendor. We are not CERT-In empanelled and say so openly; see when you do not need a CERT-In empanelled vendor.
4. Incident Response and CSITE Reporting
RBI requires regulated entities to report cyber security incidents through the CSITE (Cyber Security Incident Reporting) framework. The key points:
- Incidents must be reported to RBI within 6 hours of detection. In the Commercial Banks version of the 2026 Directions, paragraph 182 requires the bank to report cyber incidents within six hours of detection on the DAKSH platform, RBI’s Advanced Supervisory Monitoring System, and to proactively notify CERT-In as well
- NBFCs and other entity classes have their own version of the Directions with their own reporting paragraph. Read yours rather than assuming the Commercial Banks numbering or window
- All Indian companies (not just banks and NBFCs) are also covered by CERT-In’s parallel 6-hour reporting rule for the same incidents
- You need a documented incident response plan that your team actually practices
- Post-incident root cause analysis is required
For startups: even if you’re not directly regulated, your banking/NBFC partner will contractually require you to report incidents to them within tight timelines. Build this into your incident response plan from day one.
5. Data Localization
This is non-negotiable for payment data:
- All payment system data must be stored only in India
- This includes transaction data, card data, and customer authentication data
- End-of-day processing data can be shared abroad for settlement purposes, but the primary copy stays in India
- RBI has conducted audits to verify compliance with this requirement
If you’re using AWS, GCP, or Azure, make sure your payment data workloads run exclusively in the Mumbai (or Hyderabad) region. No exceptions.
6. Multi-Factor Authentication
For digital payment transactions:
- MFA is required for customer-facing payment transactions
- The authentication factors must be from different categories (something you know, have, or are)
- SMS OTP alone may not be sufficient for high-value transactions going forward
- Device binding and biometric authentication are encouraged
7. Encryption Requirements
- Data at rest and in transit must be encrypted
- Encryption standards must align with current best practices (AES-256, TLS 1.2+)
- Key management procedures must be documented
- PCI DSS compliance is additionally required if you handle card data
VAPT Requirements: The Details
Since VAPT is the most common compliance requirement fintech startups face, here’s a deeper breakdown of what RBI expects from a VAPT engagement.
| Requirement | What It Means |
|---|---|
| Scope | All customer-facing applications, APIs, mobile apps, and supporting infrastructure |
| Methodology | OWASP Top 10 + business logic testing + API security testing |
| Authentication testing | Session management, MFA bypass attempts, privilege escalation |
| Report format | Executive summary + technical findings + remediation guidance + risk ratings |
| Remediation verification | Re-test after fixes to confirm vulnerabilities are resolved |
| Frequency | At least annually, plus after significant changes |
| Tester qualifications | Certified professionals (OSCP, CEH, CompTIA PenTest+, or equivalent) |
A common mistake: running an automated vulnerability scanner (Nessus, Qualys) and submitting that as your “VAPT report.” Regulators and banking partners know the difference. A proper pentest involves manual testing of business logic, authentication flows, and API endpoints that automated tools miss entirely.
How Cybersecify delivers pentest engagements for fintech
Cybersecify conducts penetration testing for Indian fintech startups, NBFCs, and payment aggregator partners. Scope covers OWASP Top 10 across the customer-facing portal and admin console in a web application pentest, business logic testing, API security testing of the endpoints your bank partner and payment gateway integrations sit behind, authentication and session management, and post-fix retest. Reports include executive summary, technical findings with reproduction steps, remediation guidance, CVSS risk ratings, and retest verification. Engagements are founder led by both co-founders (Rathnakara GN holds OSCP; Ashok Kamat handles compliance scoping). Startup Pentest INR 74,999 for 1 scope, Growth Pentest INR 1,79,999 for 2 scopes including SOC 2 and ISO 27001 audit prep and a Letter of Attestation. See pentest plans, view a sample report, or book a 30-min scoping call.
How This Affects Fintech Startups (Not Just Banks)
Even if you’re not directly regulated by RBI, here’s why this matters to you:
Payment aggregators (Razorpay, Cashfree partners): If you’re a merchant or platform using a payment aggregator, your PA will increasingly require you to demonstrate security compliance. If you’re applying for your own PA license, these requirements are mandatory.
NBFCs and lending platforms: All NBFCs are required to comply with the IT framework. If you’re a lending platform partnering with an NBFC, they will require VAPT reports and security policy documentation from you.
Account aggregators: The AA framework has its own security requirements, heavily influenced by RBI’s broader cybersecurity framework. Data security is central to the AA model.
Fintech-bank partnerships: When a bank evaluates you as a technology partner, they’ll assess your security posture against RBI’s framework. No VAPT report, no security policy, no partnership.
Compliance Roadmap for Startups
Here’s a practical sequence that works for early-stage fintech companies:
Phase 1: Assessment (Week 1-2)
Start with a security assessment to understand where you stand. Map your current controls against RBI requirements for your specific entity type. Most startups already meet some of the requirements without realizing it (you probably already have encryption in transit, cloud security groups, and some form of access control).
For a structured assessment with an actionable gap report, book a free 30-min discovery call with the founders.
Phase 2: VAPT (Week 2-4)
Get a proper penetration test done. Not just a scanner report. Manual testing of your application, APIs, and infrastructure by certified testers who understand fintech-specific risks (payment flows, transaction manipulation, authentication bypass).
Our Startup Pentest Plan (INR 74,999) covers one application scope in 5 business days, including remediation guidance and a re-test. The Growth Pentest Plan (INR 1,79,999) covers two scopes and includes SOC 2 + ISO 27001 audit prep if you’re on that path too.
Phase 3: Policy and Documentation (Week 3-5)
Document your cybersecurity policy, incident response plan, data classification, access control policy, and vendor risk management. These don’t need to be lengthy. They need to be accurate, followed, and board-approved.
Phase 4: Incident Response Setup (Week 4-6)
Build your incident response workflow with CSITE reporting built in. Define severity levels, escalation paths, communication templates, and reporting timelines for your banking/NBFC partners.
Phase 5: Data Localization Verification (Week 5-6)
Audit your infrastructure to confirm all payment data stays in India. Check your database hosting, backup locations, CDN caching, log storage, and any third-party integrations that might process payment data outside India.
Phase 6: Ongoing Compliance (Continuous)
Annual VAPT, quarterly vulnerability scans, regular policy reviews, and incident response drills. This isn’t a one-time checkbox. RBI expects continuous compliance, and your banking partners will ask for updated reports annually.
What This Costs
For context, here’s a realistic budget for a seed-to-Series A fintech startup:
| Item | Cost Range | Notes |
|---|---|---|
| Security assessment | INR 10,000 - 50,000 | Depends on scope and complexity |
| Penetration test (annual) | INR 75,000 - 1,80,000 | Manual testing, not just scanners. Our pricing |
| Policy documentation | INR 50,000 - 2,00,000 | Can be done in-house if you have security expertise |
| Managed SOC (if required) | Quoted per engagement by the SOC provider | Outsourced monitoring for smaller teams; providers price on log volume and coverage hours, and none we are aware of publishes a rate card |
| Data localization audit | INR 25,000 - 75,000 | Infrastructure review |
| Total first year | INR 3 - 10 lakh | Our own estimate from scoping this work for fintech startups, not a published market figure. Varies significantly by entity type and existing maturity |
That’s significantly less than what banks spend, and it’s achievable on a startup budget. The cost of non-compliance (failed partnerships, regulatory action, or a breach without proper controls) is far higher.
How We Help
We work with fintech startups at every stage of RBI compliance:
- Security assessment: identify gaps against RBI requirements for your specific entity type
- Penetration testing: annual VAPT with audit-grade reports your banking partners and regulators expect
- Remediation support: fix what the pentest finds, with verification retesting included
- Policy documentation: practical, followable policies that satisfy regulatory requirements
Not sure where to start? Book a free 30-min discovery call with the founders. We will map your compliance gaps and recommend a prioritized roadmap. No payment, no commitment.
Book a discovery call, check our pentest plans, or run a free external attack surface scan to see what’s publicly exposed today. For a broader view of how we support compliance readiness, see our audit and compliance services.
Corrections
-
2026-09-04: Rebuilt the “Which RBI Guidelines Apply to You?” table. All four rows named instruments that RBI repealed on 31 July 2026 vide circular DoS.CO.PPG.66/11.01.005/2026-27: “Cybersecurity Framework for Banks, June 2016” (Annex Sr. 54), “Guidelines on IT Governance, Risk, IT & IS Audit, January 2023 (updated)” (this is the Master Direction at Annex Sr. 16, whose own header row is dated 7 November 2023; no RBI instrument carrying a January 2023 date could be sourced), “Master Direction on Digital Payment Security Controls, 2021” (Annex Sr. 29), and “IT Framework for NBFCs, 2017” (Annex Sr. 47). Each row also linked to rbi.org.in’s homepage rather than to the instrument. The section now separates current instruments from repealed ones, names the repeal circular, and links the 2026 Directions to the Commercial Banks notification page.
-
2026-09-04: Replaced every citation of those four repealed instruments elsewhere in the post, including three FAQ answers that were shipping the stale versions as FAQPage structured data: the “Which RBI cybersecurity guidelines apply to fintech startups?” answer that opened “Five main directives stack depending on your entity type and partnerships”, the answer to “What are the Digital Payment Security Controls under the February 2021 Master Direction?” (the question itself is now about that Master Direction’s repeal), and the clause “Findings should map to RBI Master Direction Digital Payment Security Controls (where applicable)” inside the pentest-scope answer. The lead direct-answer paragraph carried the same list and was rewritten too.
-
2026-09-04: Removed “Annual VAPT is mandatory for all regulated entities under RBI guidelines” from the FAQ, and the matching “Annual VAPT is mandatory for all regulated entities” bullet from the VAPT section. It overstates coverage and understates cadence against what RBI actually wrote. The Commercial Banks version of the 2026 Directions sets vulnerability assessment at least once in every six months and penetration testing at least once in 12 months for critical information systems and those in the DMZ having a customer interface (paragraph 151), and a risk-based approach for everything else. Both passages now state that.
-
2026-09-04: Added the entity class to every quoted paragraph number. Paragraphs 150, 151, 154, 155, 156, 159, 161, 182 and 230 were read in the Commercial Banks instrument (RBI/DoS/2026-27/410). The Directions are issued in seven per-entity-class versions and the other six were not opened, so nothing is asserted about their numbering.
-
2026-09-04: Replaced “typically 2 to 6 hours for material incidents at directly-regulated entities” in the incident-timeline FAQ answer. No source was found for that range. The answer now cites paragraph 182 of the Commercial Banks instrument, which sets six hours from detection on RBI’s DAKSH platform, and says the window has to be read from the version for your own entity class.
-
2026-09-04: Removed the year claim “(2020, updated 2024)” attached to the Master Direction on Payment Aggregators and Payment Gateways, and the rbi.org.in homepage link on it. RBI’s current Master Directions index carries a differently titled instrument regulating payment aggregators, and the year pair could not be sourced against it. The sentence now tells the reader to confirm the current title and date on the index.
-
2026-09-04: Removed the “INR 1,50,000 - 5,00,000/year” managed SOC band. No managed SOC provider we are aware of publishes a rate card, so the row now says how the service is priced. The first-year total is now labelled as our own estimate rather than a market figure.
-
2026-08-09: Removed the claim that ISO 27001:2022 covers “approximately 70 to 80 percent” of RBI’s baseline cybersecurity expectations. No source supports a coverage percentage against a regulator’s expectations, and the claim sat in a FAQ answer aimed at RBI-regulated buyers. The named control areas ISO 27001 does cover, and the named gaps where RBI goes further, are unchanged.
-
2026-08-09: Removed the “most startups are 20-40% compliant” baseline, which had no source.