TL;DR — key takeaways
On 31 July 2026, the Reserve Bank of India issued the Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 — 233 paragraphs, effective immediately, replacing the 2016 Cyber Security Framework. It applies to commercial banks only (not Small Finance Banks, Payments Banks, Local Area Banks, or NBFCs). Banks must report cyber incidents on RBI's DAKSH platform within six hours of detection and also notify CERT-In. Governance is now mandatory and specific: a board-level IT Strategy Committee, an independent CISO outside the IT reporting line, and a 24×7 Cyber Security Operations Centre.
The biggest downstream impact falls on third-party vendors and fintech partners: the bank is held accountable for partner security (para 127), so those obligations flow into vendor contracts as right-to-audit, RBI inspection access, source-code escrow, and shareable VA/PT reports. For one vendor type — ATM Switch service providers — RBI wrote 24 specific controls to be embedded in the contract (para 138).
What is the RBI Cybersecurity Framework 2026?
The RBI Cybersecurity Framework 2026 is a master direction that consolidates how commercial banks in India must govern technology, manage cyber risk, and prove resilience. Issued on 31 July 2026 under the Banking Regulation Act, 1949 and the RBI Act, 1934, it took effect immediately and repealed the 2016 Cyber Security Framework. It spans 233 paragraphs across eight chapters, covering board oversight, IT governance, baseline security controls, a Cyber Security Operations Centre, and information systems audit.
On the first read it looks like an internal rulebook for banks. Its more consequential effect is on everyone connected to a bank: because the bank is made accountable for the security of its partners, the framework quietly resets the bar that every fintech, infrastructure provider, and service vendor must clear to keep doing business with a bank.
Who does the RBI 2026 framework apply to?
It applies to commercial banks — banking companies, the State Bank of India, and corresponding new banks. It explicitly excludes Small Finance Banks, Payments Banks, and Local Area Banks (para 3). NBFCs and co-operative banks fall under their own separate RBI regimes.
Foreign banks operating in India through branch mode get a "comply or explain" approach for several chapters, letting them deviate from specific requirements only where they can give RBI a justifiable explanation.
Although vendors are not directly regulated, they are the framework's de facto subject: banks push the requirements into partner contracts to satisfy their own accountability.
Key requirements at a glance
| Area | What the framework requires | Reference |
|---|---|---|
| Board oversight | Mandatory IT Strategy Committee (ITSC); board approves cyber strategy and is trained on cyber risk annually | Paras 7–19 |
| CISO | Independent senior executive (ideally GM rank), no reporting line to Head of IT, no business targets, quarterly board reporting | Paras 27–28 |
| Incident reporting | Report cyber incidents on RBI's DAKSH platform within 6 hours of detection; notify CERT-In | Para 182 |
| VA / PT | VA at least every 6 months and PT at least every 12 months for critical, internet-facing systems | Para 151 |
| Disaster recovery | DR drills at least half-yearly for critical systems; near-zero RPO and minimal RTO targets | Paras 165, 171 |
| Cyber SOC | 24×7 Cyber Security Operations Centre with SIEM, tiered L1/L2/L3 staffing | Chapter VI |
| Third parties | Bank accountable for partner security; right-to-audit, RBI inspection access, source-code escrow, background checks | Paras 126–139 |
| IS audit | Audit Committee of the Board oversees a risk-based information systems audit | Chapter VII |
The core mechanic: accountability vs control
The framework pivots on paragraph 127: "the bank shall be accountable for ensuring appropriate management and assurance on security risks in outsourced and partner arrangements."
RBI made the bank answerable for its partners' security but could not make the partners answerable to RBI, because a vendor is not the regulated entity. Accountability without control is unstable, so banks close the gap the only way they can — by writing the controls into vendor contracts and pushing them down the chain. RBI names the bank; enforcement reaches the vendor.
What banks must extract from their vendors
The Directions effectively supply banks with the contract clauses to demand from critical partners:
- Right to audit, plus RBI's right to inspect every critical-partner arrangement (para 132)
- Regulator access to all information resources the bank consumes, even where the infrastructure is not on bank premises (para 133)
- Source code or source-code escrow for critical applications, covering all updates and fixes (para 90)
- Background checks, NDAs, and security-policy agreements for all third-party personnel touching critical assets (para 135)
- Shareable VA/PT reports and evidence of remediation, on demand
The 24 ATM Switch (ASP) controls RBI wrote in full
For third-party ATM Switch Application Service Providers, paragraph 138 spells out 24 baseline controls to embed in the bank's contract. In full, grouped by theme:
Access and authentication
- Change default passwords of all network devices and systems after installation
- Never use trivial or default passwords
- Run centralised authentication and authorisation via an IAM solution, with a strong password policy, 2FA/MFA based on risk, least privilege, and separation of duties
- Route access to critical servers and network/security devices through Privileged User Management or IAM systems
Network security
- Design the infrastructure with adequate network segregation controls
- Set firewall rules to block unidentified outbound connections, reverse TCP shells, and backdoors
- Disable remote connections from outside machines to the ATM Switch network
- Enable IP tables restricting the SWIFT and ATM Switch environment to authorised systems only
Application integrity and change control
- Ensure the software integrity of ATM Switch applications
- Mask data used in development and testing
- Certify new products, updates, and upgrades as built on secure coding, with architecture tested for data confidentiality and integrity, and assurance shared with the bank or RBI on request
- Conduct source-code audits of critical applications by competent personnel, assuring the code is free of malicious or fraudulent content
- Run a robust change-management process logging every production change, with test cases, an approval chain, and a rollback plan
Logging and monitoring
- Monitor database security events and backend access, keeping access restricted and activity logged and reviewed
- Generate and capture logs from devices, applications, and databases
- Capture audit logs of user actions in a form that supports forensic auditing
- Alert on any change to log settings
Resilience, incident response, and assurance
- Meet incident-management and BCP/DR obligations even where sub-vendors run the ASP's IT, including timely incident notification to the bank
- Conduct periodic VA/PT of applications, servers, and network components
- Share VA/PT reports and remediation evidence with the bank or RBI on request
- Remediate detected vulnerabilities promptly via the risk-treatment framework
- Maintain resources and a written incident-response procedure (with defined roles) to act on any cyber incident
- Set up a Cyber Security Operations Centre that correlates logs through a SIEM for continuous surveillance
- Comply with PCI-DSS and PCI-SSF as applicable
What changes for each player in the ecosystem
| Player | What they now own |
|---|---|
| Board & IT Strategy Committee | Mandatory ITSC of ≥3 directors, chaired by an independent director with 7+ years of IT experience, meeting quarterly; annual cyber-strategy approval and board training (paras 16–18) |
| CISO | Independent role, no IT reporting line, no business targets, GM rank preferred; owns the SOC and vendor assurance; quarterly board/RMCB reporting (paras 27–28) |
| Head of IT & IT Steering Committee | First line of defence for IT controls; EOS/AMC tracking and a technology-refresh plan (paras 24–38) |
| Procurement & vendor management | Right-to-audit, RBI inspection access, background checks, VA/PT sharing, source code/escrow in every critical-partner contract (paras 126–135) |
| Fintechs & infrastructure partners | Must meet the switch-ASP style controls: IAM, network segregation, data masking, source-code audits, a SIEM-backed SOC, shareable VA/PT, incident runbook, PCI compliance |
Why this rewrites the competitive landscape for fintech vendors
For years, winning a bank's business meant a better product and a lighter integration. The 2026 framework adds a second gate that sits before the product conversation: before a bank can buy what you built, it must be able to answer to RBI for how you built it.
The advantage shifts from what a vendor can do to what it can prove — continuously and on demand. The requirements RBI imposes (six-monthly VA, source-code escrow, regulator access, defined incident timelines, half-yearly DR drills) describe a continuous operating posture, not a one-time certificate. That posture is buildable and productizable, which is why the vendors that treat assurance as a product feature will turn a compliance burden into a distribution advantage. This is the thinking behind how infrastructure players like FinBox approach embedded finance: assurance is part of the product the bank is buying, not an afterthought.
Frequently asked questions
When did the RBI Cybersecurity Framework 2026 come into effect?
It came into effect immediately on issuance, dated 31 July 2026, and repealed the earlier 2016 Cyber Security Framework for commercial banks.
Does the RBI 2026 framework apply to NBFCs?
No. It applies to commercial banks only and explicitly excludes Small Finance Banks, Payments Banks, and Local Area Banks. NBFCs are governed by RBI's separate directions for their category.
What is the RBI 6-hour incident reporting rule?
Banks must report cyber incidents on RBI's DAKSH supervisory platform within six hours of detection and must also proactively notify CERT-In (para 182).
What are the CISO requirements under the 2026 framework?
The CISO must be a senior executive (preferably GM rank), independent of the Head of IT, without business targets, appointed for a reasonable minimum term, and must place a review of cyber preparedness before the board or Risk Management Committee at least quarterly (paras 27–28).
How often must banks conduct VA and PT?
For critical and internet-facing systems, vulnerability assessment (VA) must be done at least every six months and penetration testing (PT) at least once every 12 months. Non-critical systems follow a risk-based schedule (para 151).
How does the framework affect third-party vendors and fintechs?
Although vendors are not directly regulated, banks are held accountable for partner security (para 127). Banks therefore impose the controls contractually: right-to-audit, RBI inspection access, source-code escrow, background checks, and shareable VA/PT reports. For ATM Switch providers, RBI specifies 24 controls to embed in the contract (para 138).
What is a "material change" to vendor code under the framework?
A material change alters an application's functionality, security, or performance. Each material change requires a fresh written confirmation that the code is free of known vulnerabilities, malware, and covert channels. Routine minor bug fixes and performance tweaks are excluded (para 92).
What is the DAKSH platform?
DAKSH is the Reserve Bank's Advanced Supervisory Monitoring System, used by banks to report cyber incidents and interact with RBI supervision.
