Cybersecurity & Compliance for Indian Fintech Companies
Most Indian fintechs discover their compliance gaps the same way: an RBI inspection notice lands in the inbox, or a bank partner's vendor risk team asks for a System Audit Report before they will renew the API keys. Suddenly a thirty-page questionnaire is due in ten working days, and someone realises nobody ever documented who has production database access.
You are not being audited because a regulator dislikes you. You are being audited because you sit on other people's money and other people's Aadhaar-linked identities, and the moment your platform routes a rupee or stores a PAN, you inherit a stack of obligations that were written for banks and bolted onto you. The founders who sleep well are not the ones with the fanciest security tooling. They are the ones whose evidence is boring, dated and ready before anyone asks.
Which regulator actually owns you
The first mistake teams make is assuming one framework covers everything. It never does. Your obligations depend on what you actually do with money and data, and most fintechs trip more than one wire at once. A lending app that issues co-branded cards is simultaneously under RBI's digital lending rules, PCI DSS for the card data, and DPDP for the borrower's personal information. Map yourself honestly before you spend a rupee on controls.
| If you do this | You are pulled under | Core obligation |
|---|---|---|
| Store, process or transmit card data (PAN, CVV, track data) | PCI DSS (via your acquirer/card networks) | Annual SAQ or ROC, quarterly ASV scans, network segmentation |
| Operate a Payment Aggregator or Payment Gateway | RBI PA/PG Guidelines (CO.DPSS.POLC.No.S33/02-14-008) | Authorisation, escrow, annual System Audit by CERT-In empanelled auditor |
| Issue Prepaid Payment Instruments (wallets) | RBI Master Directions on PPIs | KYC, escrow, IT/IS audit, incident reporting |
| Digital lending via an app or LSP | RBI Digital Lending Guidelines 2022 | Data localisation, KDS, no biometric storage, grievance mechanism |
| Handle any personal data of Indian residents | DPDP Act 2023 + forthcoming Rules | Consent, breach notification to DPB, data principal rights |
| Run on NPCI rails (UPI, IMPS, NACH) | NPCI circulars + your sponsor bank's controls | Risk & Security Assessment, uptime, fraud monitoring |
| Suffer or suspect a cyber incident | CERT-In Directions of 28 April 2022 | Report within 6 hours, 180-day log retention, IST clock sync |
Notice how many of these you likely hit at once. That overlap is the point. You do not build seven security programmes. You build one control environment and map its evidence to each framework. Get the mapping wrong and you will pay for the same control three times, or worse, assume a bank partner's certification covers you when it does not.
The RBI System Audit: what the examiner actually asks
If you hold a Payment Aggregator authorisation, the annual System Audit Report is the single document that keeps your licence alive. It must be conducted by a CERT-In empanelled auditor, and RBI reads them. I have sat on both sides of that table. The findings that sink audits are rarely exotic. They are the same five gaps, year after year.
Five gaps that sink RBI audits
- Card data where it should not be. Your PA authorisation and RBI's tokenisation mandate mean you must not store actual card numbers or CVV. Auditors grep your logs, error dumps and analytics events, and they find full PANs sitting in an application log because a developer added a debug line during an incident and never removed it.
- Escrow reconciliation that does not tie out. The nodal or escrow account must reconcile to the paisa daily. When the audit trail shows T+2 settlements that do not match the escrow ledger, the examiner stops trusting every other number in the report.
- No documented merchant onboarding due diligence. RBI expects you to KYC your merchants, not just your customers. If you cannot produce the risk categorisation and periodic review for a sample of onboarded merchants, that is a finding.
- Privileged access nobody can explain. The auditor pulls the list of admins on your production database and payment switch, then asks who approved each one and when access was last reviewed. Silence is a finding.
- Incident response that exists only on paper. You have a policy. Good. Now the auditor asks for the last table-top test, the last real incident's timeline, and proof you reported it to CERT-In within six hours. Most teams cannot produce any of the three.
Here is what actually happens in the room. The auditor asks for read-only access to production for a two-hour window. Your engineer, nervous, provisions a shared admin account instead of a scoped read-only role because that is faster. The auditor notes the shared credential, the lack of MFA on it, and the fact that it was created that morning with no ticket. One rushed shortcut just generated three findings. The lesson is not that auditors are hostile. It is that your everyday hygiene is the audit. There is no separate audit-mode you can switch on.
PCI DSS 4.0: the part that changed while you were not looking
PCI DSS version 3.2.1 retired in 2024. You are now on 4.0, and its future-dated requirements became mandatory on 31 March 2025. If your last assessment used the old standard's language, your evidence is stale. Two changes catch fintechs off guard every time.
First, requirement 6.4.3 and 11.6.1 target your payment page directly. If you accept card data in the browser, you must inventory and justify every script on that page and detect unauthorised changes to it. This is the industry's answer to Magecart-style skimming, where attackers inject a few lines of JavaScript into a checkout page and quietly exfiltrate cards. A tag manager that lets marketing drop arbitrary scripts onto your payment page is now a direct compliance failure, not just a bad idea.
Second, requirement 8.3.6 raised password minimums to twelve characters and 8.4.2 pushes MFA for all access into the cardholder data environment, not just remote admin access. Teams that scraped by on eight-character passwords and MFA-only-for-VPN now have real remediation work.
| Your card handling model | Likely PCI scope | Typical validation |
|---|---|---|
| Full redirect to a PCI-compliant PSP, no card touches you | SAQ A | Self-assessment, minimal |
| Card fields hosted by PSP but embedded in your page (iframe) | SAQ A-EP | Self-assessment plus ASV scans, script controls |
| You capture card data on your own servers | SAQ D or full ROC | On-site QSA assessment, segmentation, pen test |
The cheapest compliance decision you will ever make is architectural. Push card capture to a compliant PSP and keep raw card data out of your environment entirely. An SAQ A programme costs a fraction of an SAQ D one, both in audit fees and in the controls you must maintain. Fintechs that let card data leak into their own systems for a minor UX gain spend the next three years paying for it.
DPDP: the obligation that has no grandfather clause
The Digital Personal Data Protection Act 2023 is the newest wire and the one most fintechs are least ready for. It applies to every scrap of personal data you hold on an Indian resident: PAN, Aadhaar, phone, transaction history, device fingerprints. Unlike a security standard you can technically ignore until an audit, DPDP creates individual rights your customers can exercise tomorrow and penalties that reach up to fifty crore rupees per instance for a security-safeguards failure.
For a fintech, three DPDP duties bite hardest. You need genuine, granular consent, not a pre-ticked box buried in onboarding. You need the ability to delete a data principal's data on request, which is brutal when that data is smeared across a data warehouse, three microservices and a marketing tool. And you must notify the Data Protection Board of a personal data breach, which means you finally need a breach definition, a detection capability and a clock that starts the moment you become aware.
- Build a data inventory first. You cannot honour a deletion request or scope a breach if you do not know where PAN and Aadhaar numbers live. Most fintechs are shocked to find them in log aggregators, support-ticket attachments and analytics exports.
- Separate the RBI data-localisation duty from DPDP. RBI's April 2018 directive already requires payment data to be stored only in India. DPDP adds consent and rights on top. Localisation alone does not make you DPDP-ready.
- Do not store biometrics from the lending flow. RBI's digital lending guidelines and DPDP both push you away from retaining Aadhaar biometrics. Use the offline or tokenised KYC path and hold nothing you do not need.
The security controls that actually earn their keep
Frameworks describe outcomes. Controls deliver them. If you are building from a blank slate, this is the order that gives you the most audit coverage per rupee, and it is roughly the order an examiner probes.
| Control | What it stops | Which frameworks it satisfies |
|---|---|---|
| MFA on all admin and CDE access | Credential-stuffing, insider account takeover | PCI 8.4/8.5, RBI IS audit, CERT-In |
| Network segmentation of the card environment | Blast radius of a breach, PCI scope creep | PCI 1.x, RBI PA guidelines |
| Centralised logging with 180-day retention, IST-synced | Undetectable intrusions, missed breach clock | CERT-In Directions, PCI 10.x, DPDP breach detection |
| Quarterly ASV scans and annual penetration test | Known-vulnerability exploitation | PCI 11.3/11.4, RBI System Audit |
| Encryption of data at rest and in transit (TLS 1.2+) | Data theft from a compromised host | PCI 3.x/4.x, DPDP safeguards, IT Act 43A |
| Change management with peer review on payment code | Skimming scripts, unreviewed prod changes | PCI 6.4, RBI SDLC expectations |
| Access reviews every quarter with sign-off | Orphaned privileged accounts | RBI IS audit, PCI 7.x, DPDP |
The CERT-In log-retention rule deserves its own line because teams miss it constantly. Since April 2022, you must retain logs within India for 180 days and synchronise all system clocks to NPL or NIC-served NTP running on Indian Standard Time. When a real incident hits and your servers are on UTC or drifting, your incident timeline becomes unusable and your six-hour reporting window is already a mess before you start.
What an audit-ready programme costs and how long it takes
Founders always ask for the number. There is no single number, but there are honest ranges. A first-time PCI SAQ A programme for a lean startup that already redirects card capture might run three to eight lakh rupees a year, mostly tooling and a light advisory engagement. A full SAQ D or ROC with segmentation, penetration testing and QSA fees climbs to fifteen to forty lakh rupees a year and more if remediation is heavy. An RBI System Audit by a CERT-In empanelled firm typically sits between five and fifteen lakh rupees depending on transaction volume and architecture.
| Phase | What happens | Realistic duration |
|---|---|---|
| Scoping and gap assessment | Data-flow mapping, control-gap findings, scope decisions | 2 to 4 weeks |
| Remediation | Fix findings: MFA, segmentation, logging, policies | 4 to 12 weeks |
| Evidence build-up | Run controls long enough to produce audit trail | 1 to 3 months |
| Formal audit | QSA assessment or CERT-In System Audit, report issued | 3 to 6 weeks |
The uncomfortable part is the evidence build-up phase. You cannot audit a control that started running last week. Access reviews, log retention and quarterly scans need history behind them. This is why the teams that treat compliance as a same-week scramble always fail their first cycle. Start the boring hygiene early and the audit becomes a formality.
The fix-it checklist before your next audit
- Draw the real data-flow diagram. Trace where card data and personal data enter, move and rest. Confirm no PAN or CVV lands in logs, error reports or analytics.
- Push card capture to a PCI-compliant PSP so you validate as SAQ A, not SAQ D, wherever the product allows it.
- Turn on MFA everywhere that touches production, the cardholder environment or admin consoles, with no shared accounts.
- Centralise logs in India, retain for 180 days, and sync every clock to Indian Standard Time via an NPL or NIC NTP source.
- Run a quarterly access review with a named approver signing off on every privileged account, and keep the sign-offs.
- Book your ASV scans quarterly and your penetration test annually, then actually remediate the highs and criticals before the next audit.
- Write an incident response runbook that names the six-hour CERT-In reporting step and the DPDP breach-notification step, then table-top test it once before you need it.
- Build a data inventory that lets you delete a data principal's records on request and scope a breach in hours, not weeks.
Come back to where we started. The founders who sleep well are not the ones who bought the most tools. They are the ones whose evidence is dated, dull and already sitting in a folder when the notice arrives. Compliance for a fintech is not a project you finish. It is a rhythm you keep, and the audit is just the day someone checks the metronome.
If you would rather have senior CERT-In empanelled auditors who have sat in the room walk your team through the mapping, the gaps and the evidence before RBI or your bank partner does, that is precisely the hands-on work we do at CyberSigma.
FAQs
Do I need a CERT-In empanelled auditor, or will any security firm do?
For an RBI System Audit as a Payment Aggregator or PPI issuer, the auditor must be CERT-In empanelled. RBI specifies this explicitly, and a report from a non-empanelled firm will not satisfy the requirement. For general PCI or DPDP advisory you have more choice, but empanelment signals the firm has been vetted for exactly this kind of regulated assurance work.
We use Razorpay or a similar PSP. Are we already PCI compliant?
No. Your PSP being compliant reduces your scope, often to SAQ A, but you still have your own validation to complete each year. If any card data touches your servers, or if you embed their card fields in your own page, your scope grows. Your PSP's certificate covers their systems, not your obligations.
How fast must we report a breach, and to whom?
Two clocks run. CERT-In requires you to report a cyber incident within six hours of noticing it. DPDP requires notification of a personal data breach to the Data Protection Board and affected data principals, with timelines set out in the Act and its Rules. Build detection that starts both clocks the moment you become aware, not the moment you finish investigating.
Does storing data in India make us DPDP compliant?
No. RBI's payment data localisation directive requires storage in India, but that is a separate duty. DPDP layers consent, data principal rights and breach notification on top. You can be perfectly localised and still fail DPDP because you never obtained granular consent or built a deletion capability.
What single finding causes the most trouble in RBI audits?
Card data or sensitive personal data turning up where it should not be, usually in application logs or error dumps. It is invisible day to day and it fails the audit instantly because it breaches tokenisation, PCI storage rules and DPDP minimisation at once. Grep your own logs before the auditor does.
When should a pre-revenue startup start on this?
Before you handle a single live transaction. The architectural decisions that keep you at SAQ A and out of biometric storage are almost free before launch and painfully expensive to retrofit. Get the data-flow right and the compliance cost stays small as you scale.
Liked the post? Share on:
Leave A Comment