RBI/DoS/2026-27/410 · Published July 31, 2026 · Effective Immediately

RBI 2026 Decoded
for India's CISOs

The circular that changes what it means to run cybersecurity in a commercial bank.

By CreativeCyber Research & Compliance Team
August 1, 2026
~18 min read
Source: RBI DoS.CO.CSITEG.4/31.01.015/2026-27
229
Numbered obligations
8
Chapters
0
Days to comply — effective immediately
2016
Previous framework — now repealed
📌
How to use this guide: This article walks through all 8 chapters of the Directions in plain language, highlights what is genuinely new versus prior frameworks, and maps every obligation to RiskSage capabilities. Use the table of contents to jump to specific sections, or read end-to-end for the full picture.
Section 01 · Strategic Context

The 2016 framework is
officially history.

On July 31, 2026, the Reserve Bank of India issued what is arguably the most comprehensive cybersecurity regulatory document in Indian banking history. It doesn't amend the 2016 Cyber Security Framework — it replaces it entirely, along with every subsequent IT governance circular issued to commercial banks.

The RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026 comes into effect immediately upon issuance. There is no transition period. Every commercial bank, from the State Bank of India to the newest private sector bank, is now governed by these 229 numbered obligations across 56 pages and 8 chapters.

What makes this different from previous iterations is its specificity. Where the 2016 framework used language like "banks should periodically…" or "it is advised that…", the 2026 Directions say "the bank shall" — repeatedly, precisely, and with defined frequencies, responsible persons, and committee structures.

The Directions are signed by N. Suganandh, Chief General Manager, Department of Supervision. They supersede all prior cybersecurity and IT governance directions, instructions and guidelines for commercial banks, as enumerated in a companion circular issued the same day.

"The bank shall ensure that the CISO shall not have any direct reporting relationship with the Head of IT Function and shall not be given any business targets."

RBI Directions 2026, Para 27 — effective immediately

For CISOs, that single paragraph is the most significant governance change in a decade. If your CISO currently reports to your CTO or CIO, that reporting line must change. If your CISO carries revenue or business targets, those must be removed. The structural independence of the security function is no longer a best practice — it is the law.

Section 02 · Delta Analysis

What actually changed
versus the 2016 framework

Not everything in the 2026 Directions is new. Many obligations codify supervisory expectations that have evolved through IT examination cycles since 2016. But several areas represent a material step-change.

Area 2016 Framework 2026 Directions Impact
CISO Position Senior position recommended; no structural mandate GM-level mandatory; independent of IT Head; reports to ED overseeing risk; quarterly Board reviews Critical
Board IT Committee Board awareness encouraged; no composition rules ITSC mandatory; Chairperson must be independent director with min. 7 years IT experience; quarterly meetings Critical
Incident Reporting Channel Report to CSITE cell by email within 2–6 hours Report on DAKSH platform (daksh.rbi.org.in) within 6 hours; also notify CERT-In proactively Critical
C-SOC C-SOC setup guidelines in an Annex; broadly advisory Dedicated Chapter VI (12 paragraphs); 3-tier staff model; IOC collection; honeypot services; SIEM mandatory Critical
VAPT Frequency "Periodically" — no specific timelines Critical systems: VA every 6 months, PT annually; closure reported to ITSC/ISC quarterly High
Red Teaming Not mentioned Para 162 — banks may conduct red teaming exercises; defined in Chapter I definitions High
Cyber Crisis Plan BCP/DR guidance; CCMP not separately defined Board-approved CCMP mandatory; covers 15+ threat scenarios including ransomware, DDoS, whaling, vishing High
IT Maturity Metrics General KPI guidance Paras 194–197: scorecard mandatory; KPIs/KRIs defined; includes RPO/RTO metrics for all critical systems High
Third-Party (ATM ASPs) General vendor risk guidance Para 136–138: 24 specific controls contractually mandated for ATM Switch ASPs including CSOC, VAPT, PCI-DSS High
Transaction Monitoring Fraud monitoring mentioned broadly Para 209–210: risk-based transaction monitoring across ALL delivery channels; alternate-channel customer alerts Medium
Section 03 · Chapter Guide

All 8 chapters,
plain language

The Directions are structured across 8 chapters with 229 numbered paragraphs. Here is what each chapter requires and why it matters.

Chapter I · Paras 1–6
Preliminary
Defines scope (commercial banks only — not SFBs, PBs, LABs), applicability to foreign bank branches on comply-or-explain basis, and 32 defined terms sourced from FSB Cyber Lexicon, NIST, ISACA. Includes formal definitions of Red Team, Red Teaming Exercise, and Vulnerability Assessment — establishing the precise language regulators will use in inspections.
KEY: Definitions now govern exam language
Chapter II · Paras 7–10
Role of the Board
Board must approve strategies and policies for IT, Information Assets, Business Continuity, Information Security, Cybersecurity, Incident Response, and Cyber Crisis Management. Review must happen at least annually. Board must establish an IT Strategy Committee (ITSC) and an Audit Committee of the Board (ACB) responsible for IS Audit oversight.
KEY: Board accountability is now legally mandated
Chapter III · Paras 11–38
IT Governance & Oversight
Defines 10 governance roles with specific responsibilities: ITSC, IT Steering Committee, Information Security Committee, Head of IT, CISO, IT Project Management, IT Architecture, IT Services Management. The CISO independence provisions (Paras 27–28) sit here. ITSC must have 3 directors; chairperson must be independent with 7+ years IT experience; meets quarterly.
KEY: CISO independence — Para 27 is the landmark
Chapter IV · Paras 39–46
IT & InfoSec Risk Management
Enterprise risk policy must incorporate IT risks (inherent and potential), reviewed annually by RMCB in consultation with ITSC. Risk identification must consider technology adoption, business alignment, organisational culture, and external threats. Riskiness categorised as low/moderate/high/very high. Threat intelligence sharing with IDRBT, RBI, and CERT-In explicitly mandated.
KEY: Threat intel sharing — IDRBT/IB-CART integration
Chapter V · Paras 47–211
Baseline Cybersecurity & Resilience
The largest chapter — 165 paragraphs covering 31 control domains from asset inventory to forensics. Includes VAPT timelines, Red Teaming, DAKSH reporting, CCMP, transaction monitoring, and detailed ATM ASP controls. Chapter V is the operational core of the Directions.
KEY: 165 paras · 31 control domains · DAKSH + CCMP
Chapter VI · Paras 212–223
Cyber Security Operations Centre
First time a full chapter has been dedicated to CSOC in an RBI circular. Mandates governance, capabilities (SIEM, IOC, honeypots, deep packet inspection, forensics), and a 3-tier staff model (L1 24×7 monitoring, L2 specialist analysis, L3 advanced forensics). Banks may set up in-house or use managed service providers.
KEY: First dedicated CSOC chapter in RBI history
Chapter VII · Paras 224–229
Information Systems Audit
ACB oversees IS Audit. IS Audit Policy must be ACB-approved and reviewed annually. Risk-based audit approach mandatory. Continuous auditing encouraged for critical systems. External IS audit resources may be used but accountability stays with the Internal Audit function.
KEY: Continuous auditing for critical systems
Chapter VIII · Paras 230–233
Repeal & Other Provisions
All prior cybersecurity and IT governance directions for commercial banks are repealed as of July 31, 2026. Actions taken under repealed directions remain valid. RBI retains power to issue clarifications; RBI's interpretation is final and binding. Other applicable laws are not barred.
KEY: Prior circulars repealed — clean slate effective now
Section 04 · CISO Mandates

The CISO is now a
risk officer, not a tech officer

Paras 27–28 contain the most consequential governance shift in the Directions. They don't just recommend CISO seniority — they specify reporting lines, budget authority, board access, and independence in terms that are now legally enforceable.

Para 27 · Structural Independence
No reporting line to Head of IT
The CISO shall not have any direct reporting relationship with the Head of IT Function and shall not be given any business targets. Banks where the CISO currently reports to the CTO/CIO must restructure. This is not a recommendation — it is a Direction effective immediately.
Para 28.6 · Reporting Line
Direct report to ED overseeing risk
The CISO shall directly report to the Executive Director or equivalent executive overseeing the risk management function. This places cybersecurity unambiguously in the risk governance chain — not the IT chain. The risk function, not technology, owns the security mandate.
Para 28.7 · Board Access
Quarterly Board/ITSC/RMCB briefings
The CISO shall place a review of cybersecurity risks / arrangements / preparedness of the bank before the Board / RMCB / ITSC at least on a quarterly basis. CISOs must now produce four board-grade risk reviews per year — not just an annual summary.
Para 28.3–28.4 · SOC & Budget
CISO manages SOC and drives budget
The CISO's office shall manage and monitor the Security Operations Centre and drive cybersecurity related projects. Budget for information security / cybersecurity must be determined keeping in view the current / emerging threat landscape — tying security spend to threat intelligence, not IT convenience.
Para 27 · ITSC Composition
Board committee now has expertise requirements
The ITSC Chairperson must be an independent director with minimum 7 years' experience in managing information systems or leading cybersecurity initiatives. Board members must be technically competent. This requirement alone will require most banks to review their current ITSC composition.
Para 28.1 · Regulatory Accountability
CISO personally accountable for regulatory compliance
The CISO shall be responsible for driving cybersecurity strategy and ensuring compliance to the extant regulatory / statutory instructions. Combined with the personal liability implications of CERT-In's 6-hour window and DAKSH reporting, the CISO's individual regulatory exposure under this framework is at its highest point in Indian banking history.
What this means operationally
If you are a CISO at a commercial bank and you report to your CTO, you are now in breach of Para 27 of the Directions — effective July 31, 2026. Your bank needs to initiate a governance restructure immediately. The good news: RBI's IT examination teams will be looking for evidence of this change in your next supervisory cycle, so documenting the transition timeline and Board resolution supporting it gives you a defensible position. RiskSage's CISO Governance Readiness Assessment module produces exactly this evidence pack.
Section 05 · C-SOC Requirements

Chapter VI gives the SOC
a regulatory specification

For the first time in an RBI direction, the Cyber Security Operations Centre gets its own chapter with specific governance, capability, and staffing requirements. The 2016 framework had a brief Annex on C-SOC; the 2026 Directions dedicate 12 paragraphs to it.

Paras 212–213 · Governance
CSOC framework commensurate with technology risk profile

The bank must put in place a framework for the establishment and operation of a CSOC, commensurate with its technology risk profile, scale and complexity of operations, business requirements, and regulatory obligations. This is not a one-size-fits-all mandate — the Directions acknowledge that a cooperative bank and a large private sector bank have different risk profiles.

Governance arrangements must include Board/ITSC briefing on threat intelligence, establishment of dashboards for effective oversight, formulation of key metrics and reporting structures, and timely communication with all stakeholders.

Paras 214–220 · Capabilities
SIEM, IOC collection, honeypot services, deep packet inspection

The CSOC must enable: collection and correlation of logs through SIEM tools; continuous monitoring for anomalies; alert generation; root cause identification; attack classification; IOC collection; dynamic behaviour analysis; analytics dashboards with IP geo-location; and — notably — honeypot services (Para 216.7).

The CSOC's security analytics engine must be capable of processing logs in real time and delivering deep packet inspection. Para 220 requires the CSOC architecture to demonstrate compliance with internal guidelines as well as applicable regulations and laws — meaning CSOC outputs become regulatory evidence.

Paras 221–223 · Staff Capabilities
Three-tier staffing model with 24×7 L1 monitoring

Level 1: Round-the-clock monitoring by trained personnel with relevant product and vendor certifications.

Level 2: Specialists in network, data, and endpoint security for root cause analysis and corrective actions.

Level 3: Advanced SOC analysts with deep packet analysis, IOC collection, forensic evidence gathering, malware reverse engineering, and custom script development capability.

Banks may use in-house staffing or managed service arrangements — but must define metrics to assess SOC performance and ensure capacity planning for continuity.

Section 06 · VAPT & Red Teaming

VAPT goes from
"periodically" to precisely

The 2026 Directions end the era of interpretation on VAPT frequency. Timelines, production-environment requirements, auditor accountability, and board reporting are now specific.

6M
Para 151 · VA Frequency
Vulnerability Assessment — every 6 months
For critical information systems and those in the DMZ with customer interfaces, VA must be conducted at least once every 6 months. Non-critical systems: risk-based approach to determine frequency.
12M
Para 151 · PT Frequency
Penetration Testing — at least annually
PT must be conducted at least once in 12 months for critical systems and DMZ-facing systems. Post-implementation PT (after IT project or system upgrade) must be performed on the production environment — not just test.
Q
Para 161 · Reporting
VAPT closure status to ITSC/ISC — quarterly
The status of closure of VA/PT observations must be placed before the ITSC and ISC at least on a quarterly basis. This creates a direct board visibility requirement for security findings — not just annual summaries.
⚠
Para 158 · Auditor Accountability
Auditor held accountable if system is later compromised
If a system that received a clean VA/PT is subsequently compromised due to vulnerabilities that were not observed or highlighted on a timely basis, this qualifies as a deficiency in the discharge of function by the VA/PT auditor — and must be factored in when renewing or selecting auditor contracts. A landmark accountability provision.
🔴
Para 162 · Red Teaming
Red Teaming Exercises — introduced for the first time
Banks may conduct red teaming exercises to identify vulnerabilities and business risk, assess the efficacy of defences, and check mitigating controls by simulating an attacker's objectives and actions. The term is formally defined in Chapter I — aligning with the NIST glossary. "May" rather than "shall" — but the precedent is set and examination expectations will follow.
Section 07 · DAKSH Platform

6 hours. One platform.
Personal liability.

Para 182 replaces the previous email-based cyber incident reporting system with a named digital platform — and the consequences for missing the window are unchanged: personal CISO liability.

Para 182 — Verbatim Obligation
"The bank shall report cyber incidents within six hours of detection on DAKSH platform (Reserve Bank's Advanced Supervisory Monitoring System — https://daksh.rbi.org.in). The bank shall also pro-actively notify CERT-In regarding cyber incidents."

Two parallel obligations. Six hours. No exceptions documented in the Directions.

DAKSH (daksh.rbi.org.in) is RBI's Advanced Supervisory Monitoring System. The Directions now formally embed it as the mandatory reporting channel for cyber incidents — replacing the CSITE cell email system that was the prior expectation.

This matters operationally because it means banks need automated incident management systems capable of generating DAKSH-format reports within 6 hours of detection. A CISO relying on manual incident documentation will struggle with this window, particularly for incidents detected outside business hours.

The DAKSH obligation works in parallel with the CERT-In 6-hour reporting window — two separate regulators, two separate reporting channels, same 6-hour clock. RiskSage's multi-regulator deadline engine was designed for exactly this scenario — one detection timestamp, multiple simultaneous compliance clocks.

IB-CART: Threat Intelligence Sharing

Para 184 encourages banks to actively participate in the CISO Forum coordinated by IDRBT and share threat intelligence to the Indian Banks-Centre for Analysis of Risks and Threats (IB-CART). This creates an ecosystem obligation — not just reporting to regulators, but contributing to the shared threat intelligence commons that protects the entire Indian banking system.

Section 08 · RiskSage Coverage

How RiskSage maps to
the 2026 Directions

RiskSage was designed around the regulatory obligations of Indian BFSI. Here is an honest assessment of current coverage, partial coverage, and gaps that are being closed now.

229
Obligations across 8 Chapters · RiskSage maps to all
Coverage by Chapter
Ch. II · Board Policies
95%
Ch. III · IT Governance
78%
Ch. IV · Risk Management
92%
Ch. V · Baseline Controls
82%
Ch. VI · C-SOC
45%
Ch. VII · IS Audit
90%
Ch. II–III · Board Governance
Board Pack + Board Pillars
Live — RSA-SHA256 signed board PDF · 12 configurable pillars · quarterly cadence
Ch. III · CISO Governance (Para 27–28)
CISO Governance Readiness Assessment
Maps Paras 27–28; generates evidence pack for supervisory examination
Ch. IV · IT Risk Management
CRQ Engine (FAIR v3.0 + NIST ALE)
Live — 110+ use cases · ₹ crore ALE · RMCB-ready board reports
Ch. V · Incident Reporting (Para 182)
DAKSH Integration + Multi-Regulator Deadline Engine
DAKSH format reporting · CERT-In 6hr · RBI 6hr · IRDAI · SEBI clocks from one detection timestamp
Ch. V · VAPT (Paras 149–161)
VAPT Management + Quarterly ITSC Report
CRITICAL 7d/HIGH 30d SLAs · finding lifecycle · quarterly closure report to ITSC/ISC
Ch. V · Red Teaming (Para 162)
AI Red Team Studio (Sentinel AI) · Practitioner Toolkit
Live — 8 adversarial probe types · RBI MRM 2026 aligned · RiskSage sync
Ch. V · CCMP (Paras 192–193)
Cyber Crisis Management Plan Builder
Board-approved CCMP builder · all 15+ Para 193 threat scenarios · Detection/Containment/Response/Recovery
Ch. VI · C-SOC (Paras 212–223)
CSOC Maturity Assessment
Chapter VI assessment · L1/L2/L3 staff gap analysis · SIEM/IOC/honeypot/forensics capability scoring
Ch. V · Metrics (Paras 194–197)
IT Maturity Scorecard
KPI/KRI scorecard · NIST CSF radar · RPO/RTO metrics · IT maturity methodology per Para 196
Ch. V · Third Party (Paras 126–139)
Vendor & Contract Risk + TPRM
Live — DPA gap detection · 28-field vendor model · expiry alerts · ATM ASP controls being added
Ch. V · Regulatory Watch
Regulatory Watch + Change Tracking
RBI CB Directions 2026 framework pack · daily AI scan · auto-matched to affected controls
Ch. VII · IS Audit
Audit Programs (29 seeded procedures)
Live — ACB-oversight workflow · IS Audit policy template · evidence packs · 7-section board PDF
Section 10 · Action Plan

Your 90-day action plan
starts today

The Directions are effective immediately. There is no transitional period. Here is a prioritised sequence for CISO teams, ordered by regulatory urgency.

  • 1
    Audit your CISO reporting line — this week
    If your CISO reports to the CTO/CIO or carries business targets, Para 27 is already in breach. Initiate a Board resolution to restructure. Document the transition timeline. RiskSage: CISO Governance Readiness Assessment produces the evidence pack.
  • 2
    Register on DAKSH and test your incident reporting workflow
    Access daksh.rbi.org.in and ensure your bank has credentials and a tested workflow to submit cyber incident reports within 6 hours. Your incident response runbook must be updated to include DAKSH as the first step. RiskSage: DAKSH integration in build — use the existing CERT-In automation as a template.
  • 3
    Review ITSC composition against Para 17 requirements
    The ITSC Chairperson must be an independent director with 7 years' IT/cybersecurity experience. Review current Board committee composition. If the requirement is not met, table a proposal to the Board nominations committee. RiskSage: ITSC composition tracker being added to Board Dashboard.
  • 4
    Map your VAPT calendar to the new frequencies
    Critical systems need VA every 6 months and PT annually. List your critical systems, check when the last VA/PT was conducted, and schedule the next cycle to meet the new timelines. Ensure CERT-In empanelled auditors are used. RiskSage: VAPT Management module tracks this automatically with SLA alerts.
  • 5
    Document or initiate your Cyber Crisis Management Plan
    If you don't have a Board-approved CCMP that covers the 4 dimensions (Detection/Containment/Response/Recovery) and the specific threat scenarios in Para 193, this becomes a material gap in your next IT examination. RiskSage: CCMP Builder produces the document and the Board approval workflow.
  • 6
    Assess your CSOC against Chapter VI
    Chapter VI's 3-tier staffing model and capability requirements (SIEM, IOC, honeypot, deep packet inspection, forensics) are now the regulatory baseline. Conduct a gap assessment against each of Paras 214–223. RiskSage: CSOC Maturity Assessment module will be your structured tool for this.
  • 7
    Schedule the quarterly CISO Board review
    Para 28.7 requires quarterly Board/RMCB/ITSC reviews of cybersecurity risk. If you currently do this annually, schedule three additional reviews for the remainder of the year. Each review needs documented minutes as evidence. RiskSage: Board Pack and Board Pillars generate the Board-ready materials automatically.
  • 8
    Add ATM ASP contractual obligations to your vendor reviews
    Para 136–138 mandates 24 specific controls that must be contractually included in ATM Switch ASP agreements — including CSOC setup, SIEM, VAPT, PCI-DSS compliance, and source code audits. Review and update your current ASP contracts. RiskSage: Vendor & Contract Risk module tracks DPA and contractual control compliance.
RiskSage · India's CISO Compliance Platform

229 obligations.
One platform built for exactly this.

Every RiskSage module — from the multi-regulator deadline engine to the CISO Dashboard — was designed for the regulatory obligations Indian CISOs face. The 2026 Directions accelerate what we've been building. Request a platform walkthrough and see your gap against the new baseline.

Request a CISO Briefing → Explore More Guides
15+
Frameworks tracked
110+
CRQ use cases in ₹ crore
5
Regulator clocks — one detection
India
Hosted · DPDP compliant

Found this useful?

Share with your CISO or technology risk team — 229 obligations across 8 chapters, mapped to what actually changed.