RBI Cybersecurity Directions for Urban Co-operative Banks: Finding Your Level

The RBI cybersecurity framework for urban co-operative banks has been replaced. The Directions that replace it came into force on the day they were issued, 31 July 2026, and they sort every urban co-operative bank into one of four Levels. The single most important thing to understand about that sorting is what it does not measure. Level is not deposits, not advances, not branches, not balance sheet. Paragraph 4 of RBI/DoS/2026-27/437 categorises a UCB "based on its digital depth and interconnectedness to the payment systems landscape". A ₹200 crore bank that is a CPS sub-member with a mobile banking app and direct UPI membership carries more of this instrument than a much larger bank that has neither.

Some of the early trade coverage has already reached for the wrong ladder, describing obligations for "Tier 3" and "Tier 4" UCBs. That deposit-based Tier 1 to Tier 4 classification is real and it governs a good deal of UCB regulation, but it has nothing to do with this instrument. The word used here is Level, the criteria are at para 4, and reading the Directions through the Tier lens will give you the wrong chapter list. Paragraph 10 reinforces the point from the other side: a UCB that already has a dedicated CISO or the Chapter VI governance structure may keep it "irrespective of its asset size".

Paragraph 10 also puts the classification in your hands. The UCB "shall undertake a self-assessment of the level in which it fits into" and ensure compliance with the applicable controls. You may go higher by Board decision. Nobody sends you a letter telling you which Level you are.

Level I: every UCB, Chapters II and III

Level I applies to every UCB "irrespective of digital services / products offered by it". It carries Chapter II (Board-approved technology and cybersecurity policies, para 7) and Chapter III, which runs from para 10 to para 102.

Chapter III is a working baseline, not a token one. A cybersecurity policy distinct from your IT policy, with each risk rated low, medium, high or very high (paras 11 to 12). An information asset inventory register with four minimum fields including where customer data sits and how critical each system is (para 21). Two-factor authentication on the CBS and on applications connecting to it, with a dynamic second factor that is not a static password and not tied to the terminal (para 47). Maker-checker on sensitive or high-value transactions (para 48). A bank-specific email domain with DMARC enforced at the email solution (para 54). Removable media default-denied unless specifically authorised for a defined use and duration (para 55). Periodic backups stored offline, on media that physically detaches (para 69). An IS Audit Cell, or a dedicated group who can perform the IS auditor function when required (para 94).

And two obligations that people miss when they conclude Level I means no testing. Paragraph 91 requires new system developments to be tested and reviewed by an IS auditor before implementation. Paragraph 96 requires a security review of the PCs and terminals used to access the corporate internet banking applications of scheduled commercial banks, of CBS servers, and of the network perimeter, "through a qualified IS auditor". That is a Chapter III obligation. It applies to the smallest UCB in the country.

Level II: where the VA/PT cadence begins

Level II catches a UCB that is a sub-member of Centralised Payment Systems and satisfies at least one of three tests at para 4: it offers internet banking, view-based or transaction-based; it provides mobile banking through a smartphone application; or it is a direct member of CTS, IMPS or UPI.

That is a low bar by design, and it is the bar most digitally active co-operative banks have already crossed. Crossing it adds Chapter IV, and Chapter IV is where the testing calendar starts.

Paragraph 116 requires VA/PT of internet-facing web and mobile applications, servers and network components across the lifecycle, pre-implementation, post-implementation and after changes. Then the cadence: "VA of critical applications and those on DMZ shall be conducted at least once in every six months. PT shall be conducted at least once in a year." Paragraph 115 adds application security testing before go-live and after every major change. Paragraph 119 requires penetration testing of public-facing systems and other critical applications to be carried out by professionally qualified teams, with findings monitored by the information security or IS audit team and by Senior Management. Paragraph 118 requires prompt remediation under your own risk treatment framework.

Chapter IV also brings the anti-phishing obligation at para 123: the UCB "shall subscribe to anti-phishing / anti-rogue application services from external service providers for identifying and taking down phishing websites / rogue applications". That is a mandatory subscription, and the paragraph names external providers as the source. It is not a control you can build in-house.

Alongside those: a named official responsible for information security, who need not carry the CISO title (para 104); separate LAN segments for ATM and CBS or branch networks (para 107); IPv6-capable public infrastructure (para 108); a data leakage prevention strategy extending to vendor-managed facilities (para 124); and BCP/DR plans tested at periodic intervals with the IS auditor assessing their effectiveness (para 133).

Level III: when the payment rails are yours

Level III is triggered by any one of three facts at para 4: direct membership of CPS, your own ATM Switch, or a SWIFT interface. The para 4 table then gives you Chapters II, III, IV and V together, whether or not you meet the Level II criteria.

Chapter V is largely a hardening chapter, and it is specific. Disable remote connections from outside machines into the network hosting critical payment infrastructure, and disable RDP on all critical systems (para 136). Restrict access to SWIFT and ATM Switch clients and servers by IP table (para 137). Assure the software integrity of ATM Switch and SWIFT applications (para 138). Disable PowerShell where it is not required (para 139). Restrict default shares including IPC$ (para 140).

Note the modality carefully at para 141: for critical business applications the UCB "may conduct source code audits by professionally competent personnel / service providers or have assurance from application providers / OEMs". That is a choice, not a mandate. Anyone selling you a source code audit as a Level III requirement is overstating it.

Paragraph 145 requires centralised authentication and authorisation through an IAM solution with strong passwords, two-factor or multi-factor authentication and least privilege, and it explicitly contemplates this being delivered "through the service provider if its infrastructure is hosted at a shared location at the service provider's end". Paragraph 158 adds risk-based transaction monitoring across all delivery channels, but only for a UCB that is a direct CPS member and has its own ATM Switch or SWIFT interface.

Level IV: a CSOC, and the governance that runs it

Level IV requires direct or sub-membership of CPS plus either your own ATM Switch and SWIFT interface together, or the fact that you host a data centre or provide software support to other banks, directly or through a wholly owned subsidiary. That second limb is worth reading twice: a CPS member or sub-member that serves other banks is a Level IV UCB.

Chapter VI requires a Cyber Security Operations Centre (para 159) delivering real-time or near-real-time posture visibility, SIEM integration, ticketing and case management (para 160), and responsible for monitoring, escalation, response across protect-detect-respond-recover, incident management and forensic analysis (para 161). Paragraph 165 puts 24x7 staffing squarely in scope, and para 165(2) names the alternative in the same breath: "finding staff with required skills / managing security service provider with required skill set". RBI is not insisting the CSOC be built and staffed in-house. Paragraph 170 requires network forensics, forensic investigation and DDoS mitigation support on standby.

Security Brigade does not run a SOC, an MDR service or DFIR retainers. Where a Level IV programme is being assembled, we work alongside the monitoring provider you choose and cover the assurance side of it.

The governance load at Level IV is substantial: a separate cybersecurity function (para 172), an IT Steering Committee, which the UCB "shall form" (para 174), a CISO reporting to the top executive overseeing risk management or to the MD and CEO, with no reporting line to the CIO or CTO and no business targets (para 175), quarterly cybersecurity review to the ITSC or Board (para 175(4)), and an Information Security Committee meeting at least quarterly (para 177). Note that the Board-level IT Strategy Committee itself is permissive: paras 8 and 173 both say the Level IV UCB "may consider" setting one up.

The shared-infrastructure problem, which is the real UCB problem

Most UCBs do not run their own CBS or their own switch. The Directions do not treat that as an exemption. They treat it as a contracting duty.

Paragraph 117 sits in Chapter IV, so it binds you from Level II upward, and it is direct: a UCB with its CBS on the shared infrastructure of an Application Service Provider "shall get its CBS application including the infrastructure hosting it subjected to VA / PT through the CBS-ASP". The testing still happens. It happens through the provider, and you are the party accountable for it happening.

The ATM Switch position is heavier and it starts at Level I. Paragraph 83 lists twelve control areas that third-party ATM Switch ASPs must implement where you run your switch ecosystem through their shared services. Paragraph 84 requires those controls to be written into the contract. Paragraph 85 then enumerates 37 baseline cybersecurity controls you shall mandate in your contractual agreement with the ASP, including ASP-conducted VA/PT of applications, servers and network components (para 85(34)), sharing of VA/PT reports and remediation status with you or with RBI on request (para 85(35)), source code audits of critical business applications by professionally competent personnel (para 85(15)), a CSOC with SIEM-based correlation (para 85(36)), and PCI-DSS and PCI-SSF compliance (para 85(37)). Paragraph 86 requires you to pass RBI circulars and advisories through to the ASP. Paragraph 73 requires a right to audit and RBI's right to inspect the provider.

Read that together and the asymmetry is stark. A Level I UCB, carrying no VA/PT cadence and no CSOC of its own, is nonetheless obliged to demand both of its ATM Switch provider by contract. If you take one action off this page, make it a review of your ASP contracts against paras 83 to 86 and a written request for the artefacts para 85(35) says you are entitled to.

Six hours, at every Level

Paragraph 88 sits in Chapter III, which means it binds every UCB from Level I upward: cyber incidents shall be reported "within six hours of detection on DAKSH platform". There is no materiality threshold and no grace period. Paragraph 87 separately requires you to proactively notify CERT-In; this instrument attaches no clock to that limb, though CERT-In's own 2022 Directions carry a six-hour requirement of their own. Paragraph 89 makes IB-CART threat-intelligence sharing optional, and para 90 makes cyber insurance optional.

Six hours is an operational problem before it is a compliance problem. It needs a named person, an out-of-hours path and a DAKSH login that somebody has actually used. That is a half-day of preparation and it is the cheapest risk reduction available in the whole instrument.

What a small team should do first

Four steps, in order. Complete the para 10 self-assessment and write down which of the para 4 criteria you meet and which you do not, because that document is the basis of every scoping conversation you will have about this instrument. Pull your ATM Switch and CBS-ASP contracts and check them against paras 83 to 86, and against para 117 too if you are Level II or above. Set up the six-hour reporting path under para 88. Then, if you are Level II or above, put the para 116 calendar in place: VA at six months, PT at twelve.

One thing you will not find anywhere in this instrument, at any Level, is a red teaming requirement. It is not there. If it is being sold to you as an RBI obligation for a UCB, it is not one.

Where Security Brigade fits

We are CERT-In empanelled and have been continuously since 2008, which is how a UCB evidences that the team touching its CBS servers and payment perimeter is qualified in the sense paras 96 and 119 require, and how the same evidence carries into an ASP's own assurance obligations under para 85. Over 1,000 clients and more than 6,700 assessments sit behind that, including banks working with the same constraints you have: a small IT team, a shared CBS, a switch you do not control.

Practically, that means scoping your para 116 programme so it covers what the paragraph actually names rather than everything you own, working through your CBS-ASP where para 117 requires it rather than around them, giving you the report format your ACB can act on under para 100, and under para 179 if you are Level IV, and helping you write the para 85 control set into the contract at renewal. If you are not sure which Level you are, send us your para 4 answers and we will tell you what falls in scope and what does not, including the parts that do not need us.