Building a fintech in India means operating under more security and compliance obligations than almost any startup category in the world. RBI, SEBI, IRDAI, NPCI, CERT-In. Each has published cybersecurity frameworks that apply to different types of financial entities.
Some are legally mandatory. Some become mandatory the moment something goes wrong. Some are effectively mandatory the moment you try to partner with a bank or raise institutional capital.
Nobody hands you this map at the start. You usually find out what’s required the hard way — during your first RBI interaction, when a sponsor bank questionnaire arrives, or when CERT-In issues a notice about an incident you didn’t know you had to report.
What’s mandatory today and has real teeth
Applies to every organisation operating in India with an IT infrastructure. No exceptions for size, funding stage, or registration status.
Incident reporting window. Data breach, ransomware, unauthorised account access, phishing, supply chain compromise — all must be reported to CERT-In within six hours of detection. Not six hours after containment. Six hours after you first know something happened. Most companies are not ready for this.
Log retention. All system logs — servers, applications, network devices — must be maintained for 180 days and be available within India or accessible to CERT-In on request.
Meeting the six-hour window requires automated alerting so you know within minutes, a pre-written report template, and a named person who can file it. Companies that find out about a breach from a customer complaint on a Monday morning have already missed the window.
| RBI Master Direction | Who it applies to | Core requirement |
|---|---|---|
| IT Governance | NBFCs, payment aggregators, payment gateways, account aggregators, PPI issuers | Board-approved ISP, named security officer, annual VAPT, IR plan, BCP/DR tested annually |
| PCI DSS | Any product that touches payment card data | Annual penetration test — overlaps with RBI VAPT if scoped correctly |
What’s commercially mandatory — banks will block you otherwise
There’s a category of requirements that aren’t legally mandated but become prerequisites the moment you pursue the partnerships you need to operate.
Every serious sponsor bank in India — IDFC First, RBL, SBM India, Axis — has a vendor risk management programme. Before they approve you as a technology partner, they send a security questionnaire asking for: SOC 2 or ISO 27001 attestation, penetration test history and scope, data encryption standards, access control policies, and incident response procedures.
SOC 2 is not required by Indian law.
It is commercially required by the bank you need to operate. This distinction matters because it tells you when to prioritise it — not immediately, but before your first serious bank partnership conversation starts, because the process takes nine to twelve months.
Some banks will accept a VAPT report plus written policies for early-stage partners, with a committed SOC 2 timeline. Get this in writing if you go that route.
The DPDPA deadline that changes everything
For fintechs specifically, the financial data you process — bank account details, transaction histories, credit records, income information — is classified as sensitive personal data under the act, with stricter treatment than general personal data.
The obligations that require building infrastructure, not just policy: mandatory security safeguards proportionate to the risk, 72-hour breach notification to the Data Protection Board, explicit consent for non-transactional data processing, and erasure rights for users.
The good news: the security infrastructure that satisfies RBI’s requirements — WAF, endpoint protection, continuous monitoring, access controls — substantially overlaps with DPDPA’s security safeguard standard. One well-run security programme serves both. The new piece DPDPA adds is consent management and data rights infrastructure, which RBI compliance doesn’t address.
The practical priority order
If you’re a seed-stage Indian fintech figuring out where to start, this sequence minimises existential risk while building toward the complete picture.
The overlap between RBI requirements, CERT-In directions, PCI DSS, SOC 2, and DPDPA is significant. One comprehensive security programme satisfies the majority of all five simultaneously. You don’t need five separate compliance workstreams. You need one programme comprehensive enough to evidence across all five.
This is exactly the problem Osto is built for — one platform that runs the security infrastructure and generates the evidence across RBI, CERT-In, PCI DSS, and SOC 2 simultaneously, so Indian fintech teams aren’t managing five separate workstreams.