RBI cyber security audit checklist

What RBI supervision is actually testing

Across banks, NBFCs, co-operative banks and payment operators, the pattern in supervisory findings has shifted in a way worth stating plainly. The questions are less about whether a control exists and more about whether the institution can show who owns it, who reviewed it, and what happened when it failed.

That is a governance test wearing technical clothing, and it is why technically strong institutions still collect findings. The Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices puts specific responsibilities on the board and on a board level IT strategy committee, and those responsibilities are evidenced in minutes.

An institution that can produce a risk register, dated board minutes showing it was discussed, decisions recorded against named owners, and evidence of what changed by the next meeting, is in a materially different position from one with the same controls and no paper trail.

The four areas where findings concentrate

Third party and concentration risk. Outsourcing does not move accountability, and supervision has become direct about testing this. Which critical functions run on a vendor, what happens if that vendor is unavailable for a week, when did you last test that, and what audit right do you hold. Most institutions can answer the first. Few can answer the second with anything beyond a contractual clause. Almost none have exercised the third.

Business continuity, which is now tested rather than documented. A BCP that has never been exercised counts for little, and a DR test where the application team knew the date and pre-warmed the environment counts for less than the institution thinks. A report recording a clean test with no issues attracts scepticism, correctly, because a real failover always surfaces something.

Privileged access. Standing administrative access in a regulated financial institution is the finding that turns into an enforcement conversation. Just in time elevation with an approval and a session recording turns a phishing email against an administrator from a domain compromise into a contained incident.

Incident reporting, where there are now multiple clocks. Reportable incidents go to CERT-In within six hours. RBI supervised entities have their own expectations on top. Where personal data is involved the DPDP Act adds a third obligation with different triggers.

How to run this checklist before an inspection

Do the governance section first, even though it is the least technical, because it is the cheapest gap to close and it colours how everything else is read. Named owners, dated decisions, recorded follow ups.

Then map critical services to their third parties and identify the concentration. If four of your critical services run in one cloud region operated by one provider, the fact that each contract is individually sound does not address the correlated failure.

Then run one unannounced failover of one critical service and write down honestly what broke. A test that surfaces nothing was not a test.

Then reconcile privileged access against your HR record. Exporting every account from every system and matching it against the joiners and leavers record is dull, takes about a fortnight for a mid sized estate, and reliably finds accounts belonging to people who left years ago.

What none of this requires

New technology, which is usually the uncomfortable part of the conversation. The institutions that come through inspection well are rarely the ones with the largest security budgets. They are the ones that can show their working.

Almost every item on this checklist is a process, an owner and a record. Where a technology gap does exist, it is most often in logging: whether your retention actually covers the systems that would matter in an intrusion, or whether you have 180 days of firewall logs and thirty days of the application logs anyone would need.

If the retention lives in a cloud region outside India, you are not compliant with the CERT-In requirement regardless of how good the logs are, and that is a configuration change rather than a purchase.

The evidence an inspection actually asks for

• IT strategy committee minutes recording decisions against named owners, with follow ups closed
• The risk register, with dates, owners and evidence of board level discussion
• Third party dependency map for critical functions, with concentration identified
• Results of the last continuity test, including what did not work
• Privileged access reconciliation against the HR record, with revocations traceable
• Incident records with timeline, decisions taken, and reporting evidence for each clock

Preparing without a fire drill

Institutions that prepare for inspection in the month before it produce documents. Institutions that come through well produce records that already existed, which is a different exercise entirely.

The practical approach is to run this checklist quarterly as a short internal review rather than annually as a project. Each pass takes a fraction of the effort because most items have not changed, and the gaps surface while there is time to close them properly.

Where a gap cannot be closed before the inspection, record it honestly with an owner and a dated plan. A known gap with a credible plan is a materially better position than a gap discovered by the examiner.