How RBI, SEBI, IRDAI, and DPDPA overlap: a survival guide

Many organizations in India operate under more than one of the country's four major regulators — RBI, SEBI, IRDAI, and the Data Protection Board under the DPDPA. This article walks through what each regulator expects, where their cybersecurity and privacy expectations overlap, and how to run a single coherent program that satisfies all of them without double-booking work.

The four regulators in one paragraph each

The Reserve Bank of India regulates banks, NBFCs, payment system operators, and a number of other entities. Its cybersecurity expectations are codified primarily in the Cybersecurity Framework circulars and in the Master Direction on IT Governance. The Securities and Exchange Board of India regulates stock exchanges, depositories, registered intermediaries, and a long list of market participants. Its cybersecurity expectations are codified in the Cybersecurity and Cyber Resilience Framework, which has been amended several times. The Insurance Regulatory and Development Authority of India regulates insurers and their intermediaries. Its cybersecurity expectations are codified in the Information and Cyber Security Guidelines. The Data Protection Board under the DPDPA is a cross-sectoral privacy regulator — it sets privacy obligations that apply to any organization processing digital personal data, regardless of sector.

Where the expectations overlap

The overlap is significant. All four regulators expect an information security management system, access control, change management, vulnerability management, incident response, board-level accountability, periodic independent audit, and breach notification. The details differ — notification timelines, audit cadences, board reporting formats — but the control surface is substantially the same. If you are running ISO 27001, most of your existing controls will satisfy most of the expectations of all four regulators. The gaps tend to be in sector-specific requirements: RBI's Cyber Crisis Management Plan, SEBI's specific incident reporting timelines, IRDAI's specific CISO role expectations, the DPDPA's consent and notice specifics.

Where they diverge

Divergence is mostly in process details, not in control substance. RBI has specific expectations about board-level cybersecurity reporting formats. SEBI has specific timelines for incident reporting that are tighter than the DPDPA's. IRDAI has specific expectations about the CISO being a senior executive with direct board access. The DPDPA has specific requirements about consent flows that do not exist under any of the sectoral regulations. An organization that treats these as separate programs will end up rebuilding most of the same thing four times. An organization that treats them as one program with sector-specific extensions will run the whole thing with a fraction of the effort.

A worked case

Consider a life insurance company that is also a SEBI-registered mutual fund distributor and handles health data. It is subject to IRDAI (as an insurer), SEBI (as a distributor), the DPDPA (as a data fiduciary handling significant sensitive data), and — because it issues some products through a banking partner — bound by RBI's third-party risk management expectations via its banking partner. That is four regulators in one organization, all asking similar but not identical things. A single coherent control library, mapped to all four frameworks, with sector-specific extensions where the details diverge, is the only tractable approach. Running four separate programs is an unforced multiplication of work.

A consolidated control narrative

The single-program approach looks like this. One ISMS. One set of controls — access control, change management, vulnerability management, incident response, and so on — with ownership and cadence defined once. One risk register. One incident response runbook with sector-specific notification annexes (one each for RBI, SEBI, IRDAI, and the Data Protection Board). One evidence collection schedule. One internal audit plan that covers all four sectors in one cycle. Cross-framework mapping that shows which control satisfies which obligation under each regulator. The program is one program; the frameworks are outputs.

Reporting obligations in parallel

Even with a single program, reporting obligations must be met in parallel. Each regulator has its own reporting format, cadence, and timeline. The best approach is a reporting calendar that tracks every obligation — with its owner, its deadline, and its format — as a first-class object. Missing a reporting deadline because you were focused on another regulator's deadline is one of the most preventable compliance failures.

Tags