If you ask five people in a bank to describe their information security program, you will probably get five different answers. Someone will point you to the policy folder on the intranet. Someone else will name the monitoring platform. The compliance lead will open a spreadsheet of controls with a lot of green cells. None of them are wrong but none of them are showing you the complete picture either.
That gap may stay hidden for years sometimes. And can show up on the day a supervisory team sits across the table and asks simple questions like: When did the board last approve this? or Who signed off on closing the last penetration test findings? At that moment, your information security program is no longer what you built. It is what you can produce.
This is what catches out teams that are otherwise doing fine. The controls and tools exist. What’s missing is the thread tying a control to an owner, an owner to a date and a date to a signature somebody can find.
RBI has rewritten its rulebook for regulated entities, and the rewrite pulled hard on exactly that thread. This guide walks through how to create an information security program that meets RBI standards: the order to build it in and the gaps that usually surface during review.
What is an information security program under RBI standards?
An information security program is the full operating structure for security inside a regulated entity. It is not a policy document, and it is not the security tool stack either.
Under the current framework, a compliant information security program has four working parts:
- A board-approved policy set that names owners, scope and consequences for non-compliance
- A governance structure with committees, defined roles and enforced reporting lines
- A control baseline covering assets, access, network, applications, data and vendors
- An assurance loop that tests the controls and reports the results upward
That last part is where most programs fall short. A policy binder proves intent. An information security program proves operation. Supervisors test the second.
What changed under the 2026 Directions
The Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026 are eight chapters and 233 paragraphs long. Three shifts matter most when you are designing the information security program:
- Accountability moved to the board. Strategies and policies for information technology, information assets, business continuity, information security and cybersecurity all need board approval and annual board review.
- Independence became structural. The Chief Information Security Officer (CISO) cannot report to the Head of IT, cannot carry business targets and reports instead to the executive overseeing risk management.
- Frequencies became explicit. Testing, drills, reviews and reporting now carry named intervals rather than a general expectation of regularity.
The companion Directions for Non-Banking Financial Companies (NBFCs) follow the same architecture, with obligations graded by scale-based regulation layer.
How to create an information security program that meets RBI standards
Build the information security program in the order the framework is written. Each layer supplies the evidence the next layer depends on.
1. Board ownership
Start with the policy set, because nothing below it is valid without approval on record. You need an information security policy covering objectives, scope, ownership, organisational structure, exceptions and penal measures for non-compliance. You also need a separate cybersecurity policy. The framework is explicit that the two must be distinct, so the cyber threat picture does not get buried inside a broader IT document. Both go to the board, and both come back for review at least annually.
2. Governance structure
The framework distributes information-security governance across these 4 bodies:
- IT Strategy Committee (ITSC) at board level, minimum three directors, chaired by an independent director with at least seven years of technology leadership experience, meeting quarterly
- IT Steering Committee at senior management level, drawn from IT and business, also quarterly
- Information Security Committee (ISC) under ITSC oversight, headed by someone from the risk management vertical
- Audit Committee of the Board (ACB) holding oversight of information systems audit
The CISO sits as a permanent invitee to the ITSC and the IT Steering Committee, and places a review of cyber risk and preparedness before the board or its risk committee every quarter.
3. Risk framework
Write the risk framework before selecting controls. Otherwise, you buy tools and reverse-engineer a justification. The framework needs to identify critical information systems, assign roles across stakeholders including third-party personnel, close accountability gaps and define how data is stored, transmitted and processed securely. Rate inherent risk as low, moderate, high or very high. The risk management committee, working with the ITSC, reviews it annually.
4. Control baseline
This is the largest chapter of the Directions and covers roughly thirty control domains. The ones that carry the heaviest evidence burden:
- Asset inventory with business criticality flagged, plus an enterprise data dictionary
- Data leak prevention across endpoints, transmission and storage, extended to vendor-managed facilities
- Access control with multi-factor authentication mandatory for privileged users of critical systems
- Application security including secure coding, threat modelling, segregated environments and source code escrow where source code cannot be obtained
- Audit logs detailed enough to serve as forensic evidence and support non-repudiation
- Third-party controls with vendor risk assessment, right-to-audit clauses and RBI inspection rights written into contracts
The framework also explicitly addresses IPv6 readiness and email-domain security controls such as DMARC.
5. Continuous surveillance
A Cyber Security Operations Centre (CSOC) is mandatory, and the framework now specifies what it must do rather than simply requiring one to exist.
Expect log collection and correlation through a Security Information and Event Management (SIEM) platform, root cause identification, indicator of compromise collection, dynamic behaviour analysis, honeypot services and deep packet inspection. Staffing runs across three tiers: round-the-clock Level 1 monitoring, Level 2 specialists for root cause work and Level 3 analysts covering forensics and malware reverse engineering.
6. Independent assurance
The loop closes with testing and audit. Vulnerability assessment runs at least once every six months for critical and demilitarised zone systems with customer interfaces. Penetration testing runs at least once every twelve months. Both must be conducted by independent, appropriately trained security experts, and where a Computer Emergency Response Team – India (CERT-In) empanelled auditor is engaged, the entity follows CERT-In’s audit policy guidelines. Closure status on findings goes to the ITSC and ISC quarterly.
Information systems audit sits separately, under an ACB-approved policy reviewed annually, using a risk-based audit plan.
Reporting cadences you must be able to evidence
Supervisory review tends to focus on dates. Build the calendar into the information security program rather than reconstructing it later.
| Activity | Required frequency |
| Board review of security policies | Annually |
| ITSC and IT Steering Committee meetings | Quarterly |
| CISO cyber risk review to board or risk committee | Quarterly |
| Vulnerability assessment, critical and DMZ systems | Every six months |
| Penetration testing, critical and DMZ systems | Every twelve months |
| Disaster recovery drills, critical systems | Half-yearly |
| VA and PT closure status to ITSC and ISC | Quarterly |
| Cyber incident reporting on the DAKSH platform | Within six hours of detection |
| Board and senior management security training | Annually |
Incident reporting deserves attention. Six hours is a detection-to-report window, not an investigation window. Entities also need to notify CERT-In proactively. If your escalation path runs through three approval layers before anyone files, the clock will beat you.
How proportionality works for NBFCs and smaller entities
NBFC requirements are tiered under the Scale Based Regulation framework. Base Layer NBFCs below ₹500 crore fall under Chapter III, while Base Layer NBFCs with assets of ₹500 crore and above fall under Chapter IV. Middle, Upper and Top Layer NBFCs fall under Chapter V, which contains the more extensive cybersecurity, resilience, VA/PT and assurance requirements.
Gaps that surface during supervisory review
An information security program rarely fails on missing controls. It fails on missing proof.
- Undated board minutes. Approval exists but the review date cannot be produced.
- A CISO who still reports to IT. Common in lean teams, and now a structural breach rather than a design preference.
- Testing without closure evidence. Reports are filed and findings are never tracked to remediation.
- DR drills that were not full switchovers. The Directions expect operations to run from the alternate site for a full working day.
- Vendor contracts signed before the audit clauses existed. Right-to-audit and RBI inspection access need to be in the agreement, not assumed.
Conclusion
The RBI cybersecurity framework issued in 2026 did not invent new security thinking. It removed ambiguity about ownership, independence and frequency, and it did so with immediate effect. An information security program built as a document set will read as compliant and fail under examination. One built as an operating rhythm, with owners, intervals and an evidence trail, will hold. Start with a gap assessment against the Directions that apply to your entity class. Map what exists, what is documented and what can actually be produced on request.
At CyberNX, our RBI Master Direction compliance services help banks, NBFCs and financial institutions work out how to create an information security program that meets RBI standards and keep it audit-ready every year. As a CERT-In empanelled auditor, we support the full path from gap assessment and policy design through VAPT, CSOC operations and IS audit readiness. Talk to our experts and find out where your information security program stands today.
How to create an information security program that meets RBI standards FAQs
What is an information security program under RBI rules?
It is the complete governance and control structure a regulated entity uses to protect its information assets. It brings together board-approved policies, committee oversight, a documented risk framework, baseline security controls, continuous monitoring and independent assurance. RBI assesses whether the program operates in practice, not merely whether the documents exist.
How long do banks have to comply with the 2026 Directions?
There is no transition period. The Directions issued on Jul 31, 2026 came into force immediately on issuance. Entities are expected to review the framework paragraph by paragraph and address gaps without waiting for a deadline.
Does an NBFC need the same information security program as a bank?
Not identically. NBFC obligations are graded by scale-based regulation layer, so a Base Layer company below ₹500 crore in assets carries lighter requirements than a Middle or Upper Layer entity. The governance logic is the same across both, and an NBFC may voluntarily adopt a higher standard than its layer requires.
Can the 24/7 CSOC requirement be outsourced?
Yes. The Directions permit continuous monitoring through managed service arrangements as well as in-house staffing. Accountability for the outcome stays with the regulated entity, so the arrangement needs defined metrics, escalation paths and assurance over the provider’s controls.
