Consolidated. Not Complete.

Issue 4 · August 2026

On 31 July 2026 the Reserve Bank of India issued the Commercial Banks Cybersecurity, Technology Risk, Resilience and Assurance Directions, 2026, and repealed the circulars that came before it. What follows is my reading of what it does well, where it still falls short of a bank that is no longer a fixed set of applications behind a perimeter, and why that gap matters more than any single missing clause.

One framework, four disciplines

Cybersecurity protects systems and information. Technology risk management identifies and treats the risk that technology creates. Resilience concerns the continuation and restoration of operations. Assurance tests whether the controls behind all three are actually working. These are usually run as separate disciplines with separate owners. RBI has placed all four inside a single supervisory instrument, applied to commercial banks other than small finance banks, payments banks and local area banks, with a qualified comply or explain route for foreign bank branches. The Directions took effect immediately.

That is a change in more than document structure. Board governance, CISO independence, technology risk management, asset inventory, application security, vulnerability management, third party controls, continuous surveillance, incident reporting, disaster recovery, forensic capability, a detailed cyber security operations centre model and information systems audit now sit inside one chain of accountability. My own assessment, having read it closely, is broadly positive. It is a serious supervisory instrument, considerably more detailed than its length suggests.

From	To
Adjacent disciplines	One supervisory chain
Circular by circular	A single consolidated Direction
General oversight	Named, accountable roles

Technology operates the controls. Risk and security oversee them. Audit independently tests whether the oversight is real.

Governance made real, not just required

The Board must approve every material technology and security policy at least once a year, and must maintain a Board level IT Strategy Committee chaired by an independent director with substantial technology experience, meeting at least quarterly. Its job is to judge whether the bank’s technology strategy, governance, staffing and budget are proportionate to its digital depth and its threat environment. That last point is the one I would underline for any director reading this. RBI has tied cyber risk directly to the allocation of money and people. A bank can no longer say security matters while leaving the function underfunded, or letting a known weakness sit unresolved because another investment carried more commercial weight.

The same logic protects the Chief Information Security Officer. The CISO must sit above the Head of IT’s reporting line, carry no business targets, hold an adequate budget and staff, and report cybersecurity preparedness to the Board at least quarterly. I read this as the right response to a familiar conflict. When security reports through the same chain as delivery, delivery’s priorities tend to win. RBI has protected the challenge function instead of assuming it would survive on its own.

The three lines, as RBI draws them

1. Head of IT. First line. Operates the controls day to day.
2. CISO and risk management. Second line. Independent oversight and challenge.
3. Audit Committee and IS audit. Third line. Tests whether the first two are working.

A security operations centre with a real job description

Chapter VI is one of the framework’s strongest sections, and it earns that place by being specific. The CSOC must run continuous log correlation, SIEM monitoring, root cause analysis, malware analysis, forensic imaging, threat intelligence assessment and honeypot services, staffed around the clock across three tiers of capability. RBI also expects banks to plan for the human side of running such a function: hiring, training, retention and continuity, not only technology.

Three tiers, staffed continuously

L1 Continuous monitoringRound the clock triage of alerts and events.

L2 Specialist analysisNetwork, data and endpoint security depth.

L3 Forensic depthPacket analysis, malware reverse engineering, custom detection.

My one reservation is that the model still leans heavily on logs, packet inspection and conventional SOC architecture. Identity analytics, cloud control plane monitoring, SaaS telemetry and API observability deserve equal weight in the next revision, since a growing share of a bank’s exposure now lives outside the network perimeter this chapter was written to watch.

Recovery has to be demonstrated

Critical systems must run a full disaster recovery drill at least every six months, including an actual switch to the alternate site and a full working day of operation there, covering both the start and close of business. Backups must be restored to confirm they work, not merely retained. Production and recovery environments must carry identical configurations and patch levels, and any failure uncovered during a drill has to be retested until it closes.

The drill, as a sequence

01 TriggerA scheduled or simulated failover event

02 SwitchoverAn actual move to the alternate site

03 Full day liveStart of day through close of business

04 RestoreBackups verified, reconciled where needed

05 RetestEvery failure closed, not just logged

This is the right instinct. A backup nobody has restored is a belief, not a control. A recovery site that has never carried a full business day is unproven. RBI has converted resilience into evidence, which is exactly what a supervisor should ask a bank to produce.

A backup nobody has restored is a belief. RBI is asking for evidence instead.

Assurance with teeth

Vulnerability assessment is required at least every six months for critical and customer facing systems, penetration testing at least annually, and RBI goes further than most peers by asking banks to judge the quality of the testing itself: the competence of the assessor, the coverage achieved, whether closure was genuine. A later compromise through a vulnerability the test should have caught is treated as a possible failure of the test, not only of the system. That shifts real responsibility back onto the bank commissioning the work.

Incident reporting, in one number

6Hours to report through DAKSH

6 moVA cadence, critical systems

12 moPT cadence, minimum

QtlyClosure reported to committees

CERT-InProactive parallel notice

Incident reporting carries the same clarity. A cyber incident must be reported through RBI’s DAKSH platform within six hours of detection, with proactive notice to CERT-In, and the obligation is to report that something material is underway, not to wait for a finished root cause analysis. Facts evolve in the first hours of any serious event. RBI’s rule respects that.

A strong system view, a thinner service view

The framework is built around information assets, critical systems, applications, and a recovery target for each. Those are the right units to measure technically, but a financial service is rarely delivered by one system. A single payment can depend on authentication, a payment switch, a fraud engine, a ledger and a handful of vendors, each of which might individually meet its recovery objective while the service the customer actually experiences stays down.

	RBI	UK	Australia	EU DORA
Names critical services explicitly	Partial	Explicit	Explicit	Partial
Sets an impact tolerance per service	Not yet	Explicit	Explicit	Partial

The UK’s operational resilience regime asks firms to name their important business services and set an impact tolerance for each, the maximum disruption a service can absorb before real harm follows. Australia’s CPS 230, in force since 1 July 2026, asks the same question of critical operations. RBI refers to business continuity and critical operations, but stops short of an explicit tolerance per named service. I would treat this as the clearest opportunity for the next revision, not a criticism of what already exists.

Point in time testing, a threat that does not wait

Much of the assurance model in the Directions is periodic. Vulnerability scans every six months, penetration tests annually, policy and architecture reviews once a year. These are sensible minimums, and RBI does allow continuous auditing for critical systems, but a bank’s exposure can change within hours of a clean test result: a new cloud resource goes live, a vendor discloses a critical flaw, a certificate lapses, a domain gets impersonated. The next step, in my view, is to make continuous evidence of exposure, configuration, identity and patch status the normal expectation for critical controls, with periodic independent testing sitting above it for adversarial depth rather than standing in for it.

Red team exercises, meanwhile, are left as something a bank may choose to run. For the largest and most systemically important institutions I would not leave that optional. A conventional penetration test asks whether a defined system has an exploitable flaw. A real red team exercise asks whether a realistic adversary can achieve an objective across people, process and technology, and whether the bank would notice in time.

From	To
Point in time testing	Continuous control evidence
Red team, optional	Red team, tiered by systemic significance

Recovering trust, not just uptime

The recovery provisions are demanding, but they are still built on a conventional disaster recovery model: production goes down, an alternate site takes over. A serious cyberattack can compromise both sides at once, reaching identity systems, backup infrastructure, deployment pipelines and the recovery environment itself. Requiring identical configurations and patch levels across primary and recovery sites improves consistency, and it can also copy the same weakness, or the same foothold, into both.

Cyber recovery asks a different question from disaster recovery: can the bank rebuild an environment it can actually trust, once the one it had can no longer be trusted. That calls for offline or immutable recovery copies, a separate administrative domain, clean room restoration and a defined test for whether a recovered system is safe to trust again, not only whether it is back online. Availability is one half of recovery. Integrity is the other.

A bank that restores a compromised system quickly has not recovered. It has repeated the mistake faster.

One bank’s contract cannot fix a systemic dependency

RBI holds banks firmly accountable for the vendors they choose: concentration risk, conflicts of interest, single points of failure, audit rights for the bank and inspection rights for RBI. That is a strong bilateral model, bank and provider, and it works well until many banks depend on the same provider. A disruption at a major cloud platform, core banking supplier, identity service or payment processor could touch several regulated banks at once, and no single bank has the visibility to see that concentration forming.

Already inside most banks’ own vendor registers	Increasingly common, rarely tracked as a concentration risk
Cloud platforms	Foundation model providers
Core banking suppliers
Identity services
Payment processors
Managed security providers

The EU’s DORA addresses this directly through a register and direct oversight of critical ICT providers. Australia asks institutions to maintain a register of material providers. A sector level view, common subcontractors, cross bank concentration, coordinated testing with systemically important providers, would close a gap that no individual contract can close on its own.

The largest gap is not a missing control. It is a missing chapter.

Read in August 2026, the most striking feature of the Directions is not something they require. It is something they do not mention. There is no definition of artificial intelligence, machine learning, generative AI, foundation models or autonomous agents anywhere in a technology risk framework issued this year.

RBI has separately published draft guidance on model risk management, and that work matters, but it is not a substitute. Model risk management asks whether a model is conceptually sound, well validated and properly monitored. An AI system in production depends on a great deal more than the model: the prompts around it, the data it retrieves, the tools it can call, the provider’s own updates, the permissions it holds. A model can pass every validation test and the system built around it can still be unsafe. A general purpose assistant that never touches a credit decision can still leak confidential information, generate insecure code or pass an invented fact into a customer’s hands, all without ever appearing in a model inventory built to catch decisioning models.

A model can be sound and the system built around it can still be unsafe. RBI has governed the model conversation. It has not yet governed the system.

What the next chapter needs to say

An AI overlay to the existing framework does not need to reinvent technology governance. It needs to extend the same instincts, inventory, accountability, lifecycle discipline and independent testing, to systems that reason, generate and increasingly act, rather than simply calculate.

Area	What the chapter has to cover
Inventory and classification	Every model, assistant and embedded AI feature, approved use and discovered shadow use alike, owned and risk tiered.
Accountability	A named business owner, technical owner and independent risk owner for every material system, built in house or bought.
Lifecycle and data	Material change control over prompts, retrieval sources, fine tuning data and provider updates, not only initial deployment.
Security and oversight	Testing for prompt injection, data leakage and unsafe tool use, with human review that carries real authority to stop an output.

An agent is a privileged identity before it is a clever feature

The most consequential shift is agentic AI, a system that can read data, reason over it and take an action inside the bank’s own systems within a single automated path. A human employee making a sensitive transaction usually needs separate access, approval and verification. An agent can interpret a request, retrieve the information and execute the action itself, inside one technical identity, which quietly erodes the separation of duties the rest of the framework is built to protect.

The Directions already say a great deal about privileged access, centralised authentication and logging. They do not yet say how those controls apply to a system that can act on its own. My own view is straightforward. Govern the agent as a privileged machine identity from day one, with least privilege, short lived credentials, a defined list of permitted actions and the ability to suspend it immediately, rather than granting broad standing access because the business wants it to do many things at once.

Four questions worth asking before deployment

• Does every agent carry its own identity, not a shared one?
• Can every agent be suspended immediately, on its own?
• Is the sensitive action still separated from the decision to take it?
• Does a provider’s model update require our review first?

Four regimes, one direction of travel

Put alongside the UK, Australia and the EU, RBI’s Directions are unusually prescriptive about what a bank must build internally: named committees, staffing tiers, testing frequencies, an actual switch to the recovery site. The UK and Australia lean more heavily on the service that has to survive disruption. DORA builds the widest supervisory net around shared providers.

	RBI	UK	Australia	EU DORA
Internal control prescription	Furthest ahead	Partial	Partial	Partial
Service impact tolerance	Partial	Furthest ahead	Furthest ahead	Partial
Systemic provider oversight	Open question	Partial	Partial	Furthest ahead
Threat led testing	Open question	Partial	Partial	Furthest ahead
Explicit AI governance	Open question	Open question	Open question	Open question

The 2026 Directions are a strong foundation. The next step is to make the harder answers just as demonstrable as the ones already required.