RBI's Cybersecurity Directions 2026: The SOC Org Chart Is Now Regulated
RBI's Cybersecurity Directions 2026 took effect immediately on 31 July 2026. What Chapter VI requires on CSOC staffing, and the cadence your board must see.
The regulator has stopped describing outcomes and started specifying your operating model.
Executive Summary
On 31 July 2026 the Reserve Bank of India issued the Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, reference RBI/DoS/2026-27/410, circular number DoS.CO.CSITEG.4/31.01.015/2026-27, signed by Chief General Manager N. Suganandh. Paragraph 2 is one sentence long: "These Directions shall come into effect immediately upon issuance." There is no glide path in the commencement clause.
The framework was issued as a family of parallel instruments across regulated-entity classes on the same date. A companion Direction for NBFCs — RBI/DoS/2026-27/461, DoS.CO.CSITEG.55/31.01.015/2026-27 — carries the same title structure and comes "into force with immediate effect." Those two are the instruments we verified directly against RBI's own text for this article; if your entity class is not one of them, check RBI's Master Directions listing for the instrument that names it. MediaNama's summary of the commercial-banks instrument corroborates the same reading of its control set.
Paragraph 230 repeals the existing Directions, instructions and guidelines on Cybersecurity Framework and IT Governance applicable to commercial banks, as communicated by circular DoS.CO.PPG.66/11.01.005/2026-27 of the same date. The patchwork Indian banks have been mapping controls against for a decade is gone, replaced by a single 56-page instrument.
The substantive shift is not the control list — most of it will be familiar to any bank that has survived a CSITE inspection. The shift is that RBI has moved from specifying what your security programme must achieve to specifying how it must be staffed, who it must report to, and how often the board must see it. Chapter VI runs to three sections on the Cyber Security Operations Centre, one titled "Staff Capabilities," prescribing an L1/L2/L3 structure with named skills at each tier. Paragraph 28(6) fixes the CISO's reporting line. Paragraph 151 fixes VA and PT frequencies. Paragraph 165 fixes DR drill cadence, and paragraph 167 defines what a drill must actually consist of.
1. What Was Issued, and What It Replaced
| Instrument | Reference | Applies to | Commencement |
|---|---|---|---|
| Commercial Banks Directions, 2026 | RBI/DoS/2026-27/410 · DoS.CO.CSITEG.4/31.01.015/2026-27 | Banking companies other than Small Finance Banks, Payments Banks and Local Area Banks; corresponding new banks; State Bank of India (para 3) | "Immediately upon issuance" (para 2) |
| NBFC Directions, 2026 | RBI/DoS/2026-27/461 · DoS.CO.CSITEG.55/31.01.015/2026-27 | All NBFCs registered under the RBI Act 1934, Factoring Regulation Act 2011 and NHB Act 1987, in tiers | "With immediate effect" |
The exclusions in the Commercial Banks instrument matter. Small Finance Banks, Payments Banks and Local Area Banks are carved out of this Direction, which is not the same as being outside the framework — check RBI's Master Directions listing for the instrument that names your class before concluding anything.
The NBFC instrument is tiered by Scale Based Regulation layer, and the tiering is the first thing an NBFC compliance team should read:
| Chapter | Applies to |
|---|---|
| Chapter III | NBFCs-Base Layer with asset size below ₹500 crore, and Core Investment Companies |
| Chapter IV | NBFCs-Base Layer with asset size ₹500 crore and above |
| Chapter V | NBFCs-Top Layer, Upper Layer and Middle Layer, excluding CICs |
Layer definitions come from the Scale Based Regulation Directions, 2025, which the NBFC instrument cites directly. A ₹480 crore NBFC-BL and a ₹520 crore NBFC-BL now sit under materially different chapters, so the asset-size test is a compliance-scoping question, not an accounting footnote.
Foreign banks: comply or explain
Paragraph 4 gives foreign banks operating in India through branch mode a comply-or-explain treatment for Chapters II, III, IV and VII and for sixteen enumerated paragraph groups in Chapter V, spanning inventory management, data migration, physical controls, capacity, application security lifecycle, audit logs, patching, user access, teleworking, third parties, cryptographic controls, straight-through processing, VA/PT (151–155), BCP/DR (163–174), incident response and metrics. References to the Board are read as references to the controlling or head office overseeing the India branch.
Comply-or-explain is not an exemption. Each deviation must survive "examination and acceptance by RBI of a reasonably justifiable explanation … as part of the supervisory process" — in practice, a written position paper per deviation, refreshed each inspection cycle.
2. Governance: Three Committees and a Fixed Reporting Line
This is where most banks will find a genuine gap, because the requirements are structural rather than technical.
The board owns the policies. Paragraph 7 requires board approval of strategies and policies for IT, information assets, business continuity, information security and cybersecurity including incident response and cyber crisis management. Paragraph 8 requires them to go back to the board at least annually.
The cybersecurity policy must be a separate document. Paragraph 15 requires it to be "distinct and separate from the broader IT policy / Information Security policy so that it can highlight the risks from cyber threats." Banks that maintain one merged infosec policy are non-compliant on the face of it.
Three committees, with composition tests. The board-level IT Strategy Committee (ITSC) needs a minimum of three directors, and its chairperson must be an independent director with "substantial IT expertise" — which paragraph 17(2) defines as a minimum of seven years managing information systems or leading technology or cybersecurity initiatives. The ITSC meets at least quarterly (para 18). Below it, an IT Steering Committee at senior-management level meets at least quarterly (para 21), and an Information Security Committee sits under ITSC oversight — with a specific constraint: paragraph 23 says the head of the ISC shall be from the risk management vertical, not from IT.
The CISO reporting line is now prescriptive. Paragraph 27 asks for a senior executive "preferably in the rank of a General Manager or an equivalent position," with no direct reporting relationship to the Head of IT Function and no business targets. Paragraph 28(6) goes further: the CISO "shall directly report to the Executive Director or equivalent executive overseeing the risk management function." Paragraph 28(3) makes the CISO a permanent invitee to both the ITSC and the IT Steering Committee, and 28(7) requires a quarterly review of cyber risk and preparedness before the Board, RMCB or ITSC.
Paragraph 27(3) is the quiet one: the CISO's office "is adequately staffed with people having necessary technical expertise, commensurate with the business volume, extent of technology adoption and complexity." That is a staffing adequacy test a supervisor can examine, and it sits directly upstream of Chapter VI.
3. Chapter VI: RBI Has Specified Your SOC Org Chart
Chapter V paragraph 143 requires the bank to set up a Cyber Security Operations Centre for continuous surveillance. Chapter VI then spends three sections on what that means — and Section C, "Staff Capabilities," is the most operationally specific text in the entire instrument.
Paragraph 221 prescribes role-based responsibilities across levels:
| Tier | What paragraph 221 requires |
|---|---|
| Level 1 | "Round-the-clock" monitoring by adequately trained personnel with relevant product and vendor certifications |
| Level 2 | Personnel with specialised expertise in network, data and endpoint security, supporting root cause analysis and corrective action |
| Level 3 | SOC analysts with advanced expertise including deep packet analysis, IOC collection, forensic evidence collection, malware reverse engineering and development of custom scripts |
All CSOC personnel must "possess adequate knowledge of the bank's products, services, and deployed technology environment" — a direct constraint on how thinly a managed-service layer can be spread across clients.
Paragraph 222 then requires "a differentiated and structured approach to hiring, managing, and retaining personnel for the CSOC, recognising the specialised nature of the function." A regulator has written retention strategy into a cybersecurity direction, which tells you what RBI has been seeing in inspections.
Paragraph 223 is the one to read closely on build-versus-buy. The bank must determine staffing requirements for 24x7 monitoring and shall "adopt suitable sourcing and operating models including in-house staffing or managed service arrangements," ensure adequate training "whether internal or service provider-deployed," establish compensation and incentive structures to retain skilled staff, define metrics to assess SOC performance, and ensure continuity of personnel through capacity planning.
Managed SOC is explicitly permitted. It is not a way to move accountability — paragraph 127 makes the bank accountable for assurance on security risks in outsourced and partner arrangements.
The capability requirements underneath the org chart
Paragraph 215 requires log collection from deployed systems and network activities, correlation through appropriate SIEM tools, continuous monitoring of SIEM dashboards, and alert generation. Paragraph 216 adds root cause identification, attack classification, incident investigation, dynamic behaviour analysis, IOC collection, analytics with IP geo-location visibility, and honeypot services. Paragraph 218 requires a security analytics engine capable of "wire speed performance with on-the-fly deep packet inspection."
Paragraph 220(6) is the detection-engineering mandate: integration of "various log types and logging options into SIEM and related systems, including ticketing, workflow and case management, unstructured and big data platforms, and development of use cases and rules customised to the bank's risk and compliance requirements and drivers."
A default vendor content pack does not satisfy paragraph 220(6). Neither does a SIEM with 40% of your critical estate onboarded. If you are working through that gap, our SIEM and IAM integration playbook and the SOC-as-a-Service guide for India cover the architecture decisions in more depth.
4. The Cadence Table Your Board Secretariat Now Owns
Scattered across the instrument are sixteen fixed-frequency obligations. Collected in one place, they are the compliance calendar:
| Obligation | Frequency | Paragraph |
|---|---|---|
| Board review of IT / IS / cybersecurity / BCP policies | At least annually | 8 |
| IT Strategy Committee meetings | At least quarterly | 18 |
| IT Steering Committee meetings | At least quarterly | 21 |
| CISO review of cyber risk to Board / RMCB / ITSC | At least quarterly | 28(7) |
| ITSC review of IT architecture | At least annually | 33 |
| ITSC review of BCP and DR adequacy | At least annually | 19(7) |
| RMCB and ITSC review of IT risk policy | At least annually | 39 |
| Review of security infrastructure and policies | At least annually | 43 |
| IT capacity requirement assessment | Annual or more frequent | 65 |
| VA of critical / DMZ customer-facing systems | At least once every six months | 151 |
| PT of critical / DMZ customer-facing systems | At least once in 12 months | 151 |
| VA/PT closure status to ITSC and ISC | At least quarterly | 161 |
| DR drills for critical information systems | At least half-yearly | 165 |
| IS Audit Policy review by Audit Committee | At least annually | 225 |
| Cybersecurity training for Board and Senior Management | Annual | 204 |
| Cybersecurity awareness for new recruits | Mandatory at induction | 203 |
Three of these are more demanding than they look.
Paragraph 167 defines what a DR drill is. Testing "shall involve switching over to the DR / alternate site and thus using it as the primary site for sufficiently long period where usual business operations of at least a full working day (including Beginning of Day to End of Day operations) are covered." A failover-and-fail-back inside a maintenance window does not meet the text. Paragraph 171 asks for minimal RTO as approved by the ITSC and a near-zero RPO for critical systems; paragraph 173 requires DC and DR configurations and deployed patches to be identical; paragraph 174 extends resilience testing to critical interconnected vendor and partner systems.
Paragraph 158 creates auditor liability by implication. If a system that was subjected to VA/PT is later compromised "apparently due to vulnerabilities that were not observed or highlighted on timely basis in the VA / PT," that qualifies as a deficiency in the auditor's discharge of function and must be factored into contract renewal. That changes how you score VA/PT panels. Paragraph 155 requires "appropriately trained and independent" experts, and paragraph 154 requires a documented approach covering scope, coverage and a vulnerability scoring mechanism such as CVSS — applying equally to systems hosted in cloud environments.
Red teaming is the outlier. Paragraph 162 says the bank "may conduct red teaming exercises." It is the only major offensive-testing activity in Chapter V left to discretion, which makes it the obvious question at the next inspection for any bank with a large internet-facing footprint.
5. Incident Reporting: Two Filings, One Detection Event
Paragraph 182 is unambiguous: 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)" and "shall also pro-actively notify CERT-In regarding cyber incidents." The NBFC instrument carries the same six-hour DAKSH obligation, at paragraph 28 for the smaller-entity chapter and paragraph 141 for the larger-entity chapter.
That sits on top of an obligation Indian entities already carry. CERT-In's Directions of 28 April 2022 under section 70B(6) of the IT Act 2000 — announced by MeitY on the same date — require mandatory reporting of twenty listed incident categories "within 6 hours of noticing such incidents or being brought to notice about such incidents," require ICT system clocks to be synchronised to NIC or NPL NTP servers, and require logs of all ICT systems to be enabled and maintained securely "for a rolling period of 180 days" within Indian jurisdiction.
| RBI Directions 2026 | CERT-In Directions 2022 | |
|---|---|---|
| Recipient | DAKSH (daksh.rbi.org.in) | CERT-In (incident@cert-in.org.in) |
| Clock | 6 hours of detection | 6 hours of noticing |
| Scope trigger | "Cyber incident" per FSB Cyber Lexicon, adapted — includes IT incidents | Twenty enumerated categories in Annexure I |
| Log retention | Scope, frequency and storage set by the bank after consulting stakeholders (para 97) | Rolling 180 days, within Indian jurisdiction |
| Clock sync | Not specified | NIC or NPL NTP, or a traceable source that does not deviate |
The operational consequence is that your triage runbook needs a decision point at minute zero, not minute ninety — two filings, different formats, both inside six hours, initiated by a Level 1 analyst on a night shift. If the escalation path routes through a CISO who is asleep, you will miss one. We covered building that detection and escalation layer in the context of CERT-In's threat reporting for BFSI teams.
Paragraph 179 requires documented response strategies for ransomware and cyber extortion, data destruction and DDoS specifically. Paragraph 211 requires network forensics, forensic investigation and DDoS mitigation support to be on standby — a retainer, not a phone number found during an incident. Paragraphs 192–193 require a documented Cyber Crisis Management Plan covering detection, containment, response and recovery, as part of the board-approved cybersecurity framework. Paragraph 188 requires periodic participation in cyber drills run under CERT-In and IDRBT.
6. Identity, Privileged Access and Logging — Where Audits Actually Fail
Chapter V Section L is short and expensive.
Paragraph 109 requires a centralised authentication and authorisation system for accessing and administering applications, operating systems, databases, network and security devices and points of connectivity, enforcing strong password policy, least privilege and separation of duties. Paragraph 110 requires mandatory MFA for privileged users of critical information systems and critical activities, with risk-based two-factor or multi-factor authentication elsewhere. Paragraph 111 requires centralised systems to allow, manage, log and monitor privileged, superuser and administrative access to servers, operating systems, databases, applications, middleware and network devices. Paragraph 108 disallows administrative rights on end-user workstations; paragraph 112 requires dormant account deactivation; paragraph 105 requires elevated-entitlement personnel to be closely supervised with all activity logged and periodically reviewed.
That is a PAM and IAM programme written as five paragraphs. For most banks the honest gap is not the PAM vault — it is that privileged session logs never reach the SIEM, so paragraph 105's "periodically reviewed" has no evidence trail.
The logging section reinforces it. Paragraph 93 requires every IT application or system that can access or affect critical or sensitive information to have audit logging capability and provide audit trails. Paragraph 94 requires periodic validation of log settings, with minimum fields including date, timestamp and source and destination addresses. Paragraph 95 requires audit trails sufficiently detailed to serve as forensic evidence and support non-repudiation.
Note what paragraph 97 does not do: it leaves scope, frequency and storage of log collection to the bank, after consulting all stakeholders. RBI declines to set a retention number here — which means the binding retention floor for most banks comes from CERT-In's 180 days and, for personal data, from the DPDP Rules. Our DPDP Rule 4 and Data Fiduciary playbook works through how those retention obligations stack. Size storage against the longest applicable floor rather than against each obligation in isolation.
7. Third Parties, Source Code and the ATM Switch Baseline
Paragraphs 126 to 135 carry an explicit scoping note: they apply only to third-party arrangements in the IT and cybersecurity ecosystem that fall outside the Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025. Paragraph 126 requires a vendor risk assessment process addressing concentration risk, conflicts of interest, single points of failure, regulatory compliance for customer data, high availability and supply chain risk. Paragraph 132 requires an agreement providing for a right to audit by the bank and a right of inspection by RBI. Paragraph 135 mandates background checks, non-disclosure and security-policy compliance agreements for all third-party service provider personnel accessing or managing critical assets — a staffing-process requirement more than a security control, and the clause most likely to be tested when a bank scales up contract engineers quickly.
On the application side, paragraph 90 requires the bank to obtain source code for all critical applications from vendors, or put a source code escrow arrangement in place covering product updates and programme fixes. Paragraph 92 requires written confirmation from the developer or vendor that the application is free of known vulnerabilities, malware and covert channels, refreshed on every material change. Paragraphs 84–85 require OWASP-informed practice and state explicitly that application security assessment "shall not be restricted to testing solely against the OWASP top 10."
Paragraphs 136–138 impose a separate baseline on third-party ATM Switch Application Service Providers, enumerating twelve control families to be contractually mandated. Paragraph 138(3) requires the ASP to implement centralised authentication and authorisation through an Identity and Access Management solution, and 138(4) requires access to critical servers and network and security devices to be provided through Privileged User Management / IAM systems. RBI has named the control category in the contract text.
8. A Practical 90-Day Sequence
The Directions are in force now, so there is no build-then-comply phase. What there is, is a sensible order of operations.
Days 1–30 — establish the record. Confirm the CISO reporting line against paragraph 28(6) and fix it if it runs through IT; this is a board-resolution item with a long internal lead time. Confirm ITSC composition against paragraph 17, including the independent-director-with-seven-years test. Split the cybersecurity policy from the IT/IS policy per paragraph 15. Confirm the ISC head sits in risk management per paragraph 23. Map the repealed instructions to the new paragraph numbers so your control library keeps its audit lineage.
Days 31–60 — close the measurable gaps. Run a log-coverage assessment against paragraph 93's test — every system that can access or affect critical or sensitive information — and reconcile it against the CERT-In 180-day floor. Pull the last VA and PT dates for every critical and DMZ customer-facing system and identify anything outside the paragraph 151 windows. Check whether DC and DR patch levels are actually identical (para 173), which is usually where the honest answer is uncomfortable.
Days 61–90 — fix the operating model. Establish the CSOC staffing model against paragraph 221's three tiers and paragraph 223's 24x7 requirement, deciding in-house versus managed service on capacity and retention grounds rather than cost alone. Build the two-filing incident runbook with the six-hour clock owned at L1. Put forensics and DDoS mitigation on retainer per paragraph 211. Stand up the metrics set required by paragraphs 194–197, including RPO and RTO for all critical systems.
The constraint most banks will hit is not tooling. Paragraph 221 asks for round-the-clock L1 with product and vendor certifications, L2 specialists across network, data and endpoint, and L3 analysts who can do deep packet analysis and malware reverse engineering — for a single institution, sustained across shifts, with retention explicitly regulated. That is a hiring problem before it is a SIEM problem.
FAQ
Do the Directions apply to Regional Rural Banks?
The Commercial Banks instrument defines its scope by reference to clauses (c), (da) and (nc) of Section 5 of the Banking Regulation Act, 1949 — banking companies other than Small Finance Banks, Payments Banks and Local Area Banks, corresponding new banks, and the State Bank of India. RRBs are not named there. Since parallel Directions were issued the same day for other entity classes, identify which 31 July instrument names your class rather than assuming exclusion.
We already comply with SEBI CSCRF. Does that carry over?
Partially, and not automatically. Many underlying controls overlap — VA/PT discipline, SOC operation, incident reporting, board oversight — but the instruments differ on frequencies, reporting recipients and governance composition. A group with both a bank and a SEBI-regulated arm now maintains two evidence sets against two supervisors. Our SEBI CSCRF checklist covers what the securities-market side is examined on.
What counts as a "cyber incident" for the six-hour DAKSH clock?
Paragraph 5(7) defines it as "a cyber event that adversely affects the cybersecurity of an information asset whether resulting from malicious activity or not," with an explicit note that this "includes cybersecurity incidents as well as IT incidents." That is broader than a security-only reading — availability-affecting IT failures are inside the definition.
Does paragraph 223 let us run the SOC entirely from a service provider?
It permits managed service arrangements as a sourcing model, but not the transfer of the outcome. Paragraph 213 requires governance arrangements including board and ITSC briefing on threat intelligence, paragraph 28(4) puts SOC management and monitoring in the CISO's office, and paragraph 127 keeps assurance accountability with the bank. The workable pattern is a bank-owned CISO and metrics layer over a provider-operated tiered SOC — how our managed security operations engagements are structured.
Is there a penalty schedule in the Directions?
No monetary penalty schedule appears in the instrument. Chapter VIII preserves penalties and proceedings arising under the repealed instructions, and paragraph 232 states the Directions are in addition to and not in derogation of other laws. Enforcement runs through RBI's normal supervisory and penal machinery.
What is the single most under-resourced requirement?
In our experience of BFSI SOC engagements, paragraph 220(6) — custom detection use cases and rules aligned to the bank's own risk drivers. Log onboarding gets funded because it appears in a licence line; content engineering does not, because it looks like work the vendor already did.
Where Cyberaube Fits
The Directions convert several long-standing "should" items into examinable "shall" items with named frequencies and named skills. Most of them land on the same two teams: security engineering and the SOC.
Cyberaube works on that side of the problem. We run log-coverage and detection-engineering programmes on QRadar and Splunk, including the custom use-case development paragraph 220(6) asks for; IAM and PAM implementation across CyberArk, Okta and SailPoint against the centralised authentication, MFA and privileged-access requirements in paragraphs 109 to 111; and 24/7 managed security operations staffed on the L1/L2/L3 structure paragraph 221 describes. Where you would rather hold the capability in-house, we place certified specialists on contract and permanent terms — including the L3 forensics and reverse-engineering profiles that are hardest to hire directly. For the data-protection obligations that stack on top of this, our DPDP audit practice covers the retention and evidence side.
Book an RBI Directions 2026 readiness assessment
Conclusion
The 31 July Directions are not a new control catalogue. Nearly every technical requirement in Chapter V has appeared before in some RBI circular. What is new is the specificity of the operating model: who the CISO reports to, who chairs the ITSC and with what experience, which vertical the ISC head comes from, how many tiers the SOC has and what each tier must be able to do, how often the DR site has to run a full business day as primary, and how many hours you have before two separate regulators expect a filing.
That is a deliberate move. Outcome-based regulation assumes the regulated entity has the capacity to choose sensibly. Structure-based regulation is what a supervisor writes after several cycles of finding that capacity absent.
For most Indian banks and larger NBFCs, the binding constraint over the next two quarters will not be budget or tooling. It will be whether you can put certified, trained people on a 24x7 rota across three skill tiers, keep them, and evidence all of it — while the same scarce L3 profiles are being competed for by every other regulated entity reading the same paragraph 221.
The first question to answer is narrow and answerable this week: if a critical incident is detected at 02:40 on a Sunday, does the person on shift know they have until 08:40 to file twice?
Talk to our team about SOC staffing and RBI readiness
About the Author
Saurabh Pande is Co-Founder of Cyberaube Technologies with 13+ years of experience across enterprise security platforms including IBM Security, CyberArk, and QRadar. He has interviewed and placed 2,500+ cybersecurity professionals across SIEM, PAM, and IAM disciplines, and advises BFSI organizations on security operations strategy and compliance readiness.
About Cyberaube
Cyberaube provides cybersecurity staffing, 24/7 managed security services, and expert consulting for SIEM, IAM, and data protection platforms. Our certified specialists implement and operate QRadar, Splunk, ArcSight, CyberArk, Okta, SailPoint, and integrated security stacks for enterprises across India and globally.