RBI Cyber Audit: Complete Guide for Banks, NBFCs & Payment Companies
Most banks and NBFCs do not fail an RBI cyber audit because their controls are weak. They fail because they cannot prove the controls were working on the day something went wrong. The firewall was configured correctly, the patch was applied, the privileged access review did happen. But there is no ticket, no timestamped log, no board minute to show for it. And in an RBI examination, if you cannot evidence it, it did not happen.
I have sat across the table from RBI examiners and led IT audits of regulated entities enough times to know how this plays out. The gap is almost never the control. It is the paper trail, the accountability, and the honesty of the CISO self-assessment that was filed months earlier. This guide is about what an RBI cyber audit actually examines, who is on the hook, and how to walk into the room with nothing to hide.
What an RBI cyber audit actually is
There is no single thing called the RBI cyber audit. It is a cluster of obligations that stack on top of each other depending on what kind of regulated entity you are. When someone says they need an RBI cyber audit, they usually mean one or more of the following: an independent assessment against the RBI Cyber Security Framework, a Digital Payment Security Controls audit, a System Audit Report (SAR) for a payment system operator, or the annual IS (Information Systems) audit that every RBI-regulated entity must file.
The Reserve Bank of India does not run all of these itself. It sets the expectation, mandates the frequency, and then either conducts its own thematic IT examination (a CSITE inspection, run by the Cyber Security and IT Examination cell) or requires you to appoint a CERT-In empanelled auditor to do it and submit the report. The distinction matters. A CSITE inspection is the regulator walking in. An IS audit or SAR is you proving your house is in order before they need to.
The frameworks you are actually being measured against
Four RBI instruments do most of the work here. Know which ones apply to you, because being audited against the wrong baseline is a fast way to spend money on a report that does not close your regulatory obligation.
| Framework | Who it applies to | What it covers |
|---|---|---|
| Cyber Security Framework in Banks (2016, DBS.CO/CSITE) | Scheduled commercial banks | Baseline controls, Cyber Security Operations Centre (C-SOC), incident reporting inside 2 to 6 hours, board-approved policy, Cyber Crisis Management Plan |
| Master Direction on Digital Payment Security Controls (2021) | Banks, NBFCs and card issuers offering digital payment products | App security, transaction monitoring, authentication, internet and mobile banking controls, card and UPI controls |
| Master Direction on IT Governance, Risk, Controls and Assurance (2023, effective Apr 2024) | All RBI-regulated entities including NBFCs, Payment Banks, credit info companies | IT governance, IT and information security policy, IS audit, business continuity, third-party risk |
| System Audit Report (SAR) under the PSS Act | Payment System Operators, PPI issuers, PA-PGs | Audit of the payment system against RBI-notified standards, submitted at least annually |
On top of these sit the sector overlays. If you process card data you are also inside PCI DSS scope. If you are a Payment Aggregator or Payment Gateway you carry the specific PA-PG guidelines (RBI, March 2020, updated 2021) which mandate a SAR by a CERT-In empanelled auditor before you even get authorisation. NBFCs used to get a lighter touch. That ended. The 2023 IT Governance Master Direction pulled NBFCs firmly into the same assurance regime as banks, scaled by their size tier.
Who actually needs one, and how often
The honest answer is that if you are regulated by RBI and you touch customer data or move money electronically, you need one. The frequency and depth is what changes.
| Entity type | Mandatory audit | Frequency |
|---|---|---|
| Scheduled commercial bank | IS audit plus Cyber Security Framework assessment | Annual, plus CSITE inspection on RBI's cycle |
| NBFC (Top / Upper / Middle layer) | IS audit under IT Governance MD | Annual |
| NBFC (Base layer) | IS audit, proportionate scope | Annual |
| Payment Aggregator / Gateway | System Audit Report by a CERT-In empanelled auditor | Annual, and pre-authorisation |
| PPI issuer (wallets) | SAR plus net-worth certification | Annual |
| UPI / card issuer | Digital Payment Security Controls audit | Annual |
One clarification that trips people up. The CERT-In empanelment requirement is real and non-negotiable for a SAR. RBI will not accept a payment-system audit from an auditor who is not on the CERT-In empanelled list. For a general IS audit RBI is less prescriptive, but any regulated entity that submits a report from an auditor without demonstrable security credentials is inviting a supervisory question it does not want.
What the examiner actually asks
Forget the framework text for a moment. Here is the kind of thing that actually gets asked when an RBI examiner or your appointed auditor sits down. If you can answer these with an artefact in hand, you are most of the way there.
- Show me the board minute where the cyber security policy was last approved, and the date. Not the policy. The minute.
- Your last VAPT flagged a critical on the internet banking portal. Show me the closure ticket and the retest evidence.
- Who approved the last three privileged access grants to the core banking system, and where is that approval recorded?
- You had an incident in Q2. Show me the report you filed with RBI and CERT-In, and the timestamp against the six-hour window.
- Your DR drill for the year. Show me the runbook, the actual switchover logs, and the RTO and RPO you achieved versus your policy.
- This third-party vendor holds customer PII. Show me their last security assessment and the clause in your contract that mandates it.
- Your SOC alerts. Pick a random day from three months ago and walk me through what fired and what your analyst did.
Notice the pattern. Almost none of it is about whether you have a control. It is about whether you can produce dated, attributable, tamper-evident evidence that the control operated. This is the single biggest reason audits go sideways.
Five gaps that sink RBI audits
Across the engagements I have led, the same handful of failures recur. None of them are exotic. All of them are avoidable with a quarter of lead time.
1. The self-assessment that does not match reality
RBI requires banks to submit a CISO self-assessment against the Cyber Security Framework. When the auditor's findings contradict a self-assessment the entity filed as green, that is no longer a technical finding. It is a governance and integrity finding, and it escalates. Never mark a control compliant in a self-assessment that you cannot defend in the room.
2. Incident reporting timelines missed
The Cyber Security Framework expects unusual cyber security incidents reported to RBI within two to six hours. CERT-In's April 2022 directions independently mandate reporting of listed incident types within six hours. Entities routinely discover an incident on Friday and report the following Tuesday. The delay itself becomes the finding, separate from the incident.
3. Log retention gaps
CERT-In directions require a rolling 180 days of logs, maintained within India. When the auditor asks for logs from four months ago and the SIEM rolled them off at 90 days, there is no recovering that. The finding writes itself.
4. Third-party and outsourcing blind spots
Your cloud provider, your KYC vendor, your business correspondents. The 2023 IT Governance Master Direction and the outsourcing guidelines make you accountable for their controls. Most entities have no evidence of vendor security assessments and no right-to-audit clause that they have actually exercised.
5. Unremediated VAPT findings carried year on year
A critical from last year's Vulnerability Assessment and Penetration Test that is still open this year is the worst possible finding. It proves the control exists, produced a result, and was ignored. Examiners treat repeat findings far more severely than fresh ones.
What actually happens in the room
A mid-sized NBFC I worked with had passed every prior IS audit. Confident team, decent tooling. The auditor asked for evidence that privileged access to the loan management system was reviewed quarterly, as their own policy stated. The IT head said, of course, we review it. The auditor asked to see the last four reviews. There was one, from fourteen months earlier, an Excel file with no sign-off and no evidence anyone had acted on it. The other three had simply not happened.
The control was not missing. The people knew who had access. But the review was a policy commitment they had made to RBI and then quietly dropped when the person who used to run it left. That became a repeat-risk observation, it dragged the IT governance rating down, and it forced a management response letter to RBI committing to a remediation timeline with named owners. All of it avoidable if someone had run a fifteen-minute quarterly review and saved the sign-off. The lesson every time: RBI audits do not test your intentions. They test your discipline over time.
The process and timeline, start to finish
A properly run RBI-aligned audit is not a two-day tick-box visit. Plan for six to ten weeks end to end for a mid-sized entity, longer if scope includes a full VAPT.
| Phase | What happens | Typical duration |
|---|---|---|
| Scoping and kick-off | Confirm applicable frameworks, asset inventory, system boundary, evidence list issued | 1 to 2 weeks |
| Documentation review | Policies, board minutes, prior audit and closure, risk register, BCP and DR plans | 1 to 2 weeks |
| Control testing | Config reviews, access recertification, log sampling, interviews with control owners | 2 to 3 weeks |
| VAPT (if in scope) | External and internal network, web and mobile app testing, retest of criticals | 2 to 4 weeks |
| Draft report and management response | Findings shared, entity responds with root cause and remediation commitments | 1 to 2 weeks |
| Final report and filing | Signed report, submission to board and to RBI as required | 1 week |
Build in the management-response phase deliberately. It is your chance to convert a finding into a credible, dated remediation plan before it goes to the board and the regulator, and it is where a good auditor helps you frame reality rather than just documenting it.
What it costs
Pricing in India varies enormously with scope, entity size and whether VAPT is bundled. The ranges below are indicative for the Indian market and should be treated as ballpark, not a quote.
| Engagement | Indicative cost range (INR) |
|---|---|
| IS audit for a Base-layer NBFC | 3,00,000 to 8,00,000 |
| IS audit plus Cyber Security Framework for a mid-sized bank or NBFC | 8,00,000 to 20,00,000 |
| System Audit Report for a PA or PG | 6,00,000 to 15,00,000 |
| Digital Payment Security Controls audit | 5,00,000 to 12,00,000 |
| Standalone VAPT (network, web and mobile) | 2,50,000 to 10,00,000 |
A word on cheap audits. The market has plenty of auditors who will sign a clean report for a low fee and a light look. That is the most expensive mistake you can make, because when the CSITE inspection later contradicts your clean IS audit, the integrity finding lands on you, not the auditor. Pay for an auditor who will actually challenge you before RBI does.
How to prepare — the fix-it checklist
If you do nothing else before your audit, work through this. It closes the gaps that produce the majority of findings.
- Pull the board minute approving your current cyber security and IT security policy, and confirm it is within the last twelve months. If not, schedule the approval now.
- Reconcile your CISO self-assessment line by line against actual evidence, and mark nothing green you cannot prove.
- Close every open critical and high from the last VAPT, and keep the retest evidence. Repeat findings hurt most.
- Verify SIEM log retention is at least 180 days and stored in India, and test that you can actually retrieve a log from four months ago.
- Run and sign off any overdue periodic reviews — privileged access, firewall rules, user recertification — before the auditor asks.
- Assemble your incident register with timestamps and proof of RBI and CERT-In reporting inside the mandated windows.
- Collect vendor security assessments for every third party holding customer data, and locate your right-to-audit contract clauses.
- Confirm your DR drill for the year is done, with switchover logs and achieved RTO and RPO documented against policy.
- Map each RBI framework clause to a named control owner so no question in the room lands on nobody.
- Prepare a clean, indexed evidence repository. It is the single biggest determinant of how smoothly the audit runs.
The point of all of it
An RBI cyber audit is not really testing whether you own the right technology. Any reasonably funded entity does. It is testing whether your controls hold up under the pressure of an ordinary Tuesday, and whether you can prove it months later without scrambling. The banks and NBFCs that sail through are not the ones with the biggest security budgets. They are the ones that treat evidence as a first-class deliverable, all year, not a fire drill in the fortnight before the auditor arrives.
At CyberSigma we are CERT-In empanelled auditors who do this hands-on, sitting in the room, testing the controls, and telling you the hard truths before the regulator finds them. If you would rather hear a difficult finding from us than from a CSITE inspection, that is exactly the work we do.
FAQs
Do we need a CERT-In empanelled auditor for every RBI audit?
For a System Audit Report on a payment system (PA, PG, PPI, payment operators) it is mandatory. RBI will not accept a SAR from a non-empanelled auditor. For a general IS audit RBI does not strictly require empanelment, but using a CERT-In empanelled firm gives your report far more credibility if a CSITE inspection later revisits the same ground.
How quickly must we report a cyber incident to RBI?
The Cyber Security Framework expects unusual incidents reported to RBI within two to six hours of detection. Separately, CERT-In's April 2022 directions require reporting of specified incident types within six hours. Treat six hours as your hard deadline and build a reporting runbook so the clock does not catch you unprepared.
We are an NBFC. Has anything changed recently?
Yes, materially. The RBI Master Direction on IT Governance, Risk, Controls and Assurance (2023, effective April 2024) pulled NBFCs into essentially the same IS audit and assurance regime as banks, scaled by your layer — Base, Middle, Upper or Top. The lighter-touch era for NBFCs is over.
How long does an RBI cyber audit take?
For a mid-sized entity, plan six to ten weeks end to end — scoping, documentation review, control testing, VAPT if in scope, a draft report with your management response, then the final signed report. A bundled VAPT can push the longer end of that range.
What is the difference between a CSITE inspection and an IS audit?
A CSITE (Cyber Security and IT Examination) inspection is RBI's own supervisory examination of your IT and cyber posture. An IS audit or SAR is an independent assessment you commission and file. The smart play is to make your own audit tougher than the CSITE inspection, so nothing new surfaces when RBI walks in.
What single thing most often causes findings?
Missing evidence for controls that actually exist — no dated sign-off on periodic reviews, logs rolled off before 180 days, incident-reporting timestamps that miss the window, and open VAPT criticals carried over from last year. Fix the evidence discipline and you eliminate the majority of findings before the auditor arrives.
Liked the post? Share on:
Leave A Comment