On July 31, 2026, a new regulatory document came into force that every commercial bank operating in India needed to have read by the time it woke up that morning.
The RBI (Commercial Banks) Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 is not a circular updating a previous position. It is not a thematic paper with recommendations. The RBI’s own framing of the document removes any ambiguity about what it is: a comprehensive, prescriptive framework that banks must review paragraph by paragraph and ensure compliance with all requirements.
The word prescriptive is doing a great deal of work in that sentence. Prescriptive means the framework does not tell banks what outcome to achieve and leave the method to them. It tells them what to do, how to govern it, who must be accountable, and with what frequency.
For CISOs, CTOs, and compliance heads at commercial banks in India, this document landed this week during one of the most active cybersecurity periods in the sector’s history. Bank of Baroda confirmed a customer data breach through a single compromised employee email on July 27. The Kudankulam contractor breach exposed nuclear infrastructure documentation on July 15. The week before, it was Bajaj Auto and Tata Electronics. The timing of this framework is not coincidental. The RBI has been watching the same events everyone else has, and it has responded with structure.
This blog is a plain-language breakdown of what the new framework requires, what is genuinely new compared to previous directions, and what every commercial bank CTO must do immediately.
What This Framework Replaces and Why It Matters
India’s commercial banks have been operating across a patchwork of cybersecurity guidance for a decade. The original Cyber Security Framework for Banks (2016) established the baseline. Subsequent circulars added requirements for specific areas: digital payments, IT outsourcing, cyber resilience, cloud adoption, and most recently the April 2024 ITGRCA Master Directions, which consolidated IT governance obligations.
The July 2026 framework does something different. It replaces the scattered circulars specifically on cybersecurity and technology risk with a single, consolidated, 8-chapter rulebook.
The RBI describes it as: a consolidated, structured rulebook replacing earlier scattered circulars on cybersecurity and IT governance, setting a comprehensive baseline for governance, controls, resilience and assurance.
For banks that have been managing compliance across multiple circulars with different effective dates, different applicability thresholds, and different interpretations of what was required, this consolidation is significant. There is now one document. That document requires comprehensive baseline compliance across all its provisions. The flexibility of interpretation that existed across a fragmented circular landscape has been significantly narrowed.
The key change in intent: the 2024 ITGRCA Directions told banks to have IT governance structures. The July 2026 framework tells them specifically what those structures must look like, who must sit on them, what authority they must have, and how they must report.
Who This Framework Applies To
The framework applies to all commercial banks. This includes Scheduled Commercial Banks, Small Finance Banks, Local Area Banks, Payment Banks, and Wholly Owned Subsidiaries and Joint Ventures of Banks.
This is notably broader in its articulation than some previous circulars that carried different thresholds for different categories of banks. The July 2026 framework applies a single comprehensive baseline across all of these entities.
Non-banking financial companies are not the primary subject of this framework. NBFCs remain under the April 2024 ITGRCA Master Directions for their IT governance and cybersecurity obligations. However, any NBFC whose leadership is reading this blog should understand that the RBI’s consistent pattern has been to extend commercial bank requirements to NBFCs within 12 to 18 months of their initial application to banks. What is mandatory for commercial banks as of July 31, 2026, is highly likely to be the roadmap for NBFCs within that window.
The Ten Mandatory Requirements Decoded
The framework identifies ten key mandatory requirements. Here is what each means in operational terms.
1. Board Oversight and Governance
The Board of Directors is responsible for IT and cybersecurity oversight. Board-approved policies are mandatory, not optional, not delegatable to management. The IT Strategy Committee of the Board is mandatory.
This requirement existed in the 2024 ITGRCA Directions. What the July 2026 framework does is make it the first and foundational requirement, establishing that everything else in the framework depends on the Board having genuine, documented, active oversight of cybersecurity, not nominal oversight through receiving a quarterly report.
2. IT Strategy Committee at Board Level
The IT Strategy Committee must be set up at Board level, not at management level. At least one member must have IT and technology expertise. Minimum 50% of committee members must have domain knowledge in IT or Information Security.
The 50% threshold is new and specific. It means that for a five-member IT Strategy Committee, at least three members must bring documented IT or information security knowledge to their role. This requirement has direct implications for board composition and for how banks recruit and assess non-executive director expertise.
3. Independent CISO
The Chief Information Security Officer cannot report to the Head of IT. The CISO must have direct access to the Board and to the IT Strategy Committee. The CISO must have adequate stature, authority, and resources.
This is one of the most operationally significant requirements in the framework for banks where the CISO currently sits within the IT function. Restructuring CISO reporting lines, with the Board access and authority that the framework requires, is not a change that happens through an email update. It requires a governance decision at Board level and is likely to have implications for compensation, grade structure, and the CISO’s practical authority over IT decisions that have cybersecurity implications.
4. Cyber Incident Reporting via DAKSH
All material cyber incidents must be reported to RBI on the DAKSH platform. The reporting timeline is within six hours of becoming aware of the incident.
The specific naming of DAKSH is new and important. DAKSH is the RBI’s Digital Advanced Knowledge Sharing Hub, its supervisory technology platform. The explicit requirement to use DAKSH for cyber incident reporting means banks must have active DAKSH access, configured and tested, with personnel who know how to file an incident report under time pressure. A bank that discovers a breach at 8 PM and has never used DAKSH has exactly six hours and a learning curve running simultaneously.
5. Baseline Cybersecurity Controls Across 19 Areas
The framework mandates comprehensive baseline controls across 19 specific areas including Access Control, Patch Management, Network Security, Data Loss Prevention, Logging, and Cryptography. Mandatory compliance with all baseline requirements is required.
The enumeration of 19 specific areas is new in its specificity. Previous frameworks described categories of controls. The July 2026 framework prescribes a baseline across a named list. This means banks can no longer rely on a general posture that addresses most areas. Each of the 19 must be addressed, documented, and demonstrably compliant.
6. Mandatory 24×7 CSOC
The framework mandates a 24×7 Cyber Security Operations Centre with integrated monitoring, detection, response, and threat intelligence capabilities. Defined roles, processes, and escalation paths are required.
A round-the-clock CSOC was not explicitly mandatory under previous frameworks in the way the July 2026 directions frame it. For smaller commercial banks and payment banks that have been relying on business-hours monitoring with on-call support outside those hours, this requirement represents a significant operational change. Building or sourcing a genuine 24×7 CSOC with the threat intelligence integration the framework requires is a months-long exercise, not a policy update.
7. Third-Party and ASP Obligations
The framework requires extensive due diligence before engaging any third party or Application Service Provider. Contractual requirements must cover security, data protection, audit rights, incident reporting obligations, and exit strategy. Continuous monitoring of third parties is required, with particular emphasis on critical services such as ATM switches.
The exit strategy requirement and the continuous monitoring requirement go meaningfully further than what most banks currently have in vendor contracts. A contract signed in 2022 that covered security and audit rights but not exit strategy and continuous monitoring obligations needs to be reviewed and, where necessary, renegotiated or supplemented.
8. IPv6 Readiness
Mandatory IPv6 readiness for all public-facing infrastructure and services is required, with a transition plan and timelines.
This is a genuinely new mandatory technical requirement that has not featured prominently in previous cybersecurity frameworks. Many commercial banks and their infrastructure partners are still primarily IPv4. The transition to IPv6 readiness for public-facing services requires infrastructure assessment, vendor engagement, and a documented transition plan. Banks that have not started this conversation need to start it now.
9. IT and Information Security Risk Management
The framework requires periodic review of IT risks, documented risk identification, assessment, evaluation, and documentation, with risk mitigation, monitoring, and reporting to the Board.
This requirement formalises what the CISO and IT head should already be doing but often are not doing with the Board-level reporting cadence and documentation discipline the framework requires.
10. IS Audit and Assurance
Independent IS audit is mandatory. The audit function must cover scope, frequency, reporting, and follow-up of findings. The Board must receive assurance on the adequacy of controls.
The independence requirement is clear. IS audit cannot be conducted by the team responsible for the systems being audited. The Board assurance requirement means the IS audit finding must reach the Board, not stop at management level.
What Is Genuinely New That Most Banks Have Not Built
Comparing the July 2026 framework with the April 2024 ITGRCA Directions, several requirements represent a step change rather than an incremental tightening.
- The 24×7 CSOC mandate. Previous frameworks encouraged continuous monitoring. The July 2026 framework mandates a structured CSOC with defined roles, processes, and escalation. That is the difference between a recommendation and a compliance requirement.
- The CISO reporting line restriction. The explicit prohibition on the CISO reporting to the Head of IT is new. Many Indian banks have their CISO within the IT function. This requires a structural change with governance implications at Board level.
- The DAKSH platform specificity. Naming the platform for incident reporting is more prescriptive than the generic six-hour notification requirement in the 2024 directions. Banks must be operationally ready to file a DAKSH report under time pressure.
- The 50% domain knowledge threshold for the IT Strategy Committee. A numerical threshold for the proportion of Board IT committee members who must have domain expertise is new and has direct implications for board composition.
- IPv6 readiness as a cybersecurity requirement. This is a first in RBI cybersecurity frameworks and requires technical preparation that previous compliance exercises did not address.
- 19 enumerated baseline control areas. The specificity of naming 19 areas that must all have mandatory baseline compliance is new. The previous frameworks described principles and categories. This one lists items.
What the Framework Also Requires Beyond the Ten Headlines
The infographic summary of the framework identifies several additional requirements under other important points that deserve attention from bank CTOs.
The Information Security Policy and the Cybersecurity Policy must both be Board-approved and reviewed periodically. These are two separate documents with separate governance requirements.
An inventory of information assets must be maintained and reviewed periodically. This is not a one-time exercise. An asset inventory that was accurate six months ago and has not been reviewed since the last infrastructure change is not a compliant asset inventory.
Strong access control, authentication, privileged access management, and segregation of duties are explicitly called out. Privileged access management, meaning controls specifically over accounts with elevated permissions to critical systems, is a frequent finding in security assessments and a documented entry vector in multiple breaches covered on this blog.
Secure development lifecycle requirements apply to all applications. Banks that have internal software development teams or that rely on vendor-supplied applications need to verify that those applications were built with documented secure development practices.
Robust business continuity and disaster recovery arrangements with regular testing are required. Testing is the critical word. A BCP that exists but has not been tested does not satisfy this requirement.
Retention and analysis of audit logs with real-time monitoring and alerting capabilities are required. Many banks retain logs but do not have the real-time alerting that the framework implies. The difference between retaining logs and having real-time alerting from those logs is significant in terms of the monitoring infrastructure required.
Data protection, encryption, and DLP controls are mandatory.
Training, awareness, and capacity building are required for both employees and Board members. The explicit inclusion of Board members in the training requirement ties back to the governance theme that runs throughout the entire framework.
Twelve Steps Every Commercial Bank CTO Must Take Now
These are ordered by urgency. The first three are time-critical. The remainder build the operational compliance posture the framework requires.
- Step 1: Obtain and read the official RBI circular. The full text of the framework is available on the RBI website. Read it. Not a summary of it. The RBI’s own language is that paragraph-by-paragraph compliance review is required. That review cannot be based on a summary.
- Step 2: Conduct an immediate gap assessment against the ten mandatory requirements. For each of the ten requirements, document your current state against the framework’s specific language. The CISO reporting line. The IT Strategy Committee composition. The DAKSH access and configuration. The CSOC structure. The third-party contracts. This gap assessment is the starting point for everything that follows.
- Step 3: Configure and test DAKSH access immediately. If your bank does not have active, configured DAKSH access with at least two authorised users who know how to file a report, fix this before any other step. A breach notification obligation that you cannot operationally execute is a compliance failure before an incident even happens.
- Step 4: Assess the CISO reporting structure against the framework’s requirements. If your CISO currently reports to the Head of IT, this needs to change. That change requires a Board decision, a governance document, and likely a change to the CISO’s terms of reference. Initiate this process immediately. Do not wait for the next Board meeting that happens to have availability.
- Step 5: Review IT Strategy Committee composition against the 50% domain knowledge threshold. If fewer than 50% of your IT Strategy Committee members have documented IT or information security domain expertise, the committee composition needs to change. This is a Board-level decision with director recruitment implications.
- Step 6: Audit your third-party contracts against the framework’s ASP obligations. For every critical vendor, including your core banking provider, your ATM switch vendor, your cloud infrastructure providers, and your payment processing partners, review the contract against the four required elements: security obligations, data protection requirements, audit rights, incident reporting obligations, and exit strategy. Where any element is missing, the contract needs amendment.
- Step 7: Build or source a 24×7 CSOC capability. If you do not have a genuine round-the-clock monitoring capability with the defined roles, processes, and escalation the framework requires, you need to build it or contract it. Document the capability, the roles, the escalation paths, and the technology feeding the monitoring function.
- Step 8: Begin IPv6 readiness assessment. Identify all public-facing infrastructure and services. Assess IPv6 readiness. Develop a transition plan with documented timelines. Even if full IPv6 transition will take months, the plan and timeline must exist.
- Step 9: Enumerate your baseline controls against all 19 mandated areas. Map your current controls against each named area. Identify gaps. Document them. Build a remediation plan with timelines.
- Step 10: Review and update the IS audit scope, frequency, and independence structure. Confirm that your IS audit function is genuinely independent of the IT operations function. Confirm that audit findings are reaching Board level, not stopping at management. Update the audit charter if necessary.
- Step 11: Ensure asset inventory is current and has a review schedule. Run an inventory of information assets now. Document the last review date. Set a calendar-based review frequency and assign ownership.
- Step 12: Plan Board and employee training on the new framework requirements. The training requirement specifically includes Board members. Build a training calendar for the coming quarter that covers the framework’s key requirements for IT committee members, relevant business unit heads, and frontline staff with access to customer data.
What This Means for NBFCs Watching From the Sideline
The July 2026 framework is addressed to commercial banks. NBFCs are not its primary subject. But every NBFC leadership team should be reading it carefully.
The April 2024 ITGRCA Master Directions that currently govern NBFC cybersecurity obligations were themselves a significant tightening from what NBFCs faced previously. The July 2026 commercial bank framework goes further again in specificity, in mandatory requirements, and in the operational depth it demands.
RBI’s regulatory pattern over the past eight years has been consistent: requirements introduced for scheduled commercial banks become the roadmap for NBFCs within 12 to 18 months, usually through an amendment to the applicable Master Directions or a new thematic circular.
The 24×7 CSOC requirement. The CISO independence structure. The third-party exit strategy and continuous monitoring obligations. The DAKSH incident reporting. All of these will come to NBFCs. The only question is when.
NBFCs that read this framework as a preview of their own compliance roadmap and begin building toward it now will be significantly better positioned than those that wait for the NBFC-specific circular.
The Broader Context That Makes This Framework Urgent
The RBI did not issue a 400-page prescriptive cybersecurity framework in a vacuum. It issued it during the most concentrated period of major Indian financial and critical infrastructure cyber incidents in recent memory.
Bank of Baroda confirmed a customer data breach on July 27. Bajaj Auto disclosed ransomware on June 23. Tata Electronics confirmed a 630GB theft on June 22. The Kudankulam nuclear contractor breach exposed critical infrastructure documentation on July 15. The OpenAI incident demonstrated for the first time that autonomous AI agents can conduct end-to-end network attacks without human direction.
The RBI is a sophisticated regulator that monitors the threat environment its supervised entities operate in. The July 2026 framework is the RBI’s formal response to the threat environment it has observed. It is telling commercial banks, with the specificity of a rulebook, that the posture they had before this circular is no longer adequate.
The key takeaway the framework itself provides is this: banks must review their existing policies, processes and controls paragraph by paragraph and ensure compliance with all requirements.
That sentence is not written in the language of guidance. It is written in the language of obligation.
Final Thought
India’s commercial banks have grown significantly in digital sophistication over the past decade. Mobile banking. UPI. Digital lending. Real-time payments processing. The surface that needed to be secured grew every year while the regulatory framework governing that security evolved in circulars, thematic papers, and directional guidance that often left implementation detail to interpretation.
The July 2026 framework is the RBI saying that period is over.
The prescriptive detail of the mandatory requirements, the CSOC specification, the CISO independence rule, the DAKSH platform specificity, the 50% domain knowledge threshold, the 19 named baseline control areas: all of these reflect a regulator that has decided that general principle without specific requirement has produced insufficient preparedness.
Every CTO and CISO at a commercial bank in India who has not yet read the full text of this framework should do so before their next leadership meeting. Not because a deadline is imminent on a specific provision, but because the framework describes what the RBI will now expect to find during supervisory examinations. And the gap between what many banks currently have and what the framework requires is one that takes months to close, not weeks.
The time to start is now, not when the inspection notice arrives.
Note: This blog is based on the official RBI (Commercial Banks) Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, effective July 31, 2026. For authoritative compliance guidance, refer directly to the official RBI circular available at rbi.org.in. This blog is for awareness and educational purposes. Consult your legal and compliance teams for entity-specific guidance.
