RBI Operational Resilience: The Guidance Note Explained

In April 2024 the Reserve Bank of India issued its Guidance Note on Operational Risk Management and Operational Resilience, replacing the 2005 note and raising the bar for the entities it regulates. The shift is subtle but important: beyond managing the risk of loss from failed processes, people and systems, regulated entities must now demonstrate operational resilience, the ability to keep delivering critical services through disruption, whatever the cause. This guide explains what the Guidance Note requires, who it applies to, the core concepts (critical operations, impact tolerances and scenario testing), and how to build a program that stands up to supervisory scrutiny. It sits alongside your other RBI obligations, so start from the RBI cyber security framework if you are mapping the whole picture.

What is the RBI operational resilience guidance?

The Guidance Note on Operational Risk Management and Operational Resilience (April 2024) consolidates and modernises RBI's expectations for how regulated entities manage operational risk and stay resilient. It aligns RBI's guidance with the Basel Committee's Principles for the Sound Management of Operational Risk and its Principles for Operational Resilience, and reflects a financial system that is more interconnected and more exposed to disruption from IT failures, cyber attacks, fraud, third-party outages, and physical events. In short, it moves the goalposts from 'manage your operational risk' to 'prove you can keep critical services running when something goes wrong'.

Who does it apply to?

The Guidance Note has broad applicability across the entities RBI regulates. Assume you are in scope if you are one of:

• Commercial banks (including small finance banks and payment banks)
• Non-Banking Financial Companies (NBFCs)
• Co-operative banks (as specified for their tier)
• All India Financial Institutions (AIFIs)

As with most RBI expectations, the depth is proportionate: larger and more systemically important entities are expected to do more, more rigorously. Confirm how the Guidance Note applies to your category.

Operational risk vs operational resilience

The two are related but distinct, and the Guidance Note deliberately covers both. Operational risk management is about reducing the likelihood and impact of losses from inadequate or failed internal processes, people and systems, or from external events. Operational resilience assumes that some disruptions will happen anyway, and asks a different question: can you continue to deliver your critical operations, within acceptable limits, while it happens and until you recover? A mature program does both: it lowers the chance of disruption, and it prepares to absorb the disruptions that get through.

The core concepts: critical operations, impact tolerances and testing

Operational resilience, in the Basel and RBI framing, is built on a short chain of ideas. Get these right and the rest of the program follows.

• Critical operations: identify the services whose disruption would materially harm your customers, the market, or your own viability.
• Interconnections and dependencies: map the people, processes, technology, facilities and third parties each critical operation relies on.
• Impact tolerances: for each critical operation, define the maximum acceptable level and duration of disruption before the harm becomes unacceptable.
• Scenario testing: test whether you can stay within those tolerances under severe but plausible scenarios, and fix what the tests expose.

What RBI expects you to put in place

Turning those concepts into a supervisable program means having the governance and the operational-risk machinery behind them. Expect scrutiny of:

• Governance: board and senior-management ownership of operational risk and resilience, with clear roles and a defined risk appetite.
• The operational risk framework: risk and control self-assessment (RCSA), key risk indicators, loss-data collection, and disciplined incident management.
• Business continuity and disaster recovery, mapped to your critical operations with tested recovery objectives.
• ICT and cyber resilience, since technology failure and cyber attack are among the most likely sources of disruption.
• Third-party and outsourcing risk, because a critical operation is only as resilient as the vendors it depends on.
• Scenario testing and lessons learned, evidenced, not just documented.

How it connects to your other RBI obligations

Operational resilience does not sit on its own. Its ICT and cyber elements overlap heavily with the RBI cyber security framework, its assurance expectations connect to the RBI Information System Audit, and its business-continuity core aligns with ISO 22301. Treat them as one connected program rather than separate projects, and the same controls, evidence and critical-service mapping serve all of them. That is also the difference between a resilience program you can demonstrate at any time and one you rebuild for every review.

Common gaps at supervisory review

• No clearly identified critical operations, so scope is guesswork.
• Impact tolerances that are undefined or not tied to real customer or market harm.
• Business continuity plans that exist on paper but have never been tested against a severe scenario.
• Third-party dependencies for critical operations that are not mapped or overseen.
• Scenario testing done but not evidenced, and lessons not fed back into the program.

Putting it together

The RBI Guidance Note asks you to prove, not just assert, that you can keep delivering what matters through disruption. Identify your critical operations, map what they depend on, set impact tolerances, test against severe but plausible scenarios, and keep the evidence current. Build it as one program with your RBI cyber and audit obligations, and operational resilience becomes an operating rhythm you can demonstrate, rather than a report you scramble to assemble before a review.