RBI, SEBI and IRDAI: three cyber frameworks, one control set — if you map it right

A financial group with a bank, a broking arm and an insurance subsidiary answers to three regulators on cyber security: the RBI's IT Governance Directions, SEBI's Cybersecurity and Cyber Resilience Framework, and IRDAI's cyber guidelines. Each was written independently, by a different regulator, on a different timeline, and none references the other two.

The instinct — understandable, and wrong — is to run three separate cyber compliance programmes, one per regulated entity, because the source instruments are separate. That produces triple the audit burden for a control environment that is, in most conglomerates, substantially shared infrastructure.

Where the three frameworks actually overlap

Comparing the three obligation sets clause by clause, the overlap is larger than the surface differences suggest.

Governance structure. All three expect board-level oversight of cyber risk, a designated CISO-equivalent role, and periodic reporting to the board or a board committee. The reporting cadence and exact committee structure differ in wording but not in substance.

Incident reporting. All three require reporting of significant cyber incidents to the regulator, though the trigger definitions, timelines and formats differ — RBI's reporting timeline, SEBI's CSCRF incident categories, and IRDAI's own notification requirement are three separate forms with three separate submission portals, even when the underlying incident is a single event affecting shared infrastructure.

Third-party and vendor risk. All three expect due diligence, contractual security requirements and ongoing monitoring of technology vendors, with broadly similar expectations about audit rights and exit planning.

Periodic testing. Vulnerability assessment, penetration testing and audit expectations appear in all three, on different but overlapping cycles.

Where they genuinely differ

SEBI's CSCRF introduces a graded structure by entity size — market infrastructure institutions, qualified stock brokers and others carry different obligation depth — that has no direct equivalent in the RBI or IRDAI frameworks.

RBI's directions go deeper on IT governance generally, not just cyber security specifically, covering change management and business continuity in ways the other two treat more lightly.

IRDAI's guidance is comparatively newer and less prescriptive on specific technical controls, leaning more on principles than the other two.

Building the shared control set

The practical approach we have seen work: build one control library mapped to shared infrastructure — the SOC, the vulnerability management programme, the vendor risk process, the incident response plan — and then map each regulator's specific obligations onto that shared library as an overlay, rather than building three parallel programmes.

Concretely:

1. One incident response plan, three notification annexes. The technical response is identical regardless of which regulated entity is affected. What differs is which regulator gets notified, on what form, within what window. Build the response plan once and attach three notification procedures as annexes triggered by which entity's data or systems are involved.
2. One vulnerability management and penetration testing programme, scheduled to the tightest of the three cycles. Running to the most frequent requirement satisfies all three; running three separate schedules wastes testing budget without adding assurance.
3. One vendor risk register with a field for which regulatory framework each vendor engagement falls under. A shared cloud vendor serving all three entities gets assessed once, with the assessment mapped against all three frameworks' vendor risk expectations, rather than assessed three times by three different teams who do not compare notes.
4. A control-to-obligation matrix maintained centrally, showing which shared control discharges which specific clause in which regulator's framework. This is the artefact that lets you answer an examiner from any of the three regulators without rebuilding the mapping under time pressure.

What this does not solve

The three separate notification obligations remain three separate obligations — you cannot merge RBI, SEBI and IRDAI incident reporting into a single form, because none of the regulators has agreed to that, and each retains its own timeline and format. What the shared control approach solves is the underlying compliance work: assessment, testing, vendor management and governance, which is genuinely one job wearing three regulatory hats, not three separate jobs.

Conglomerates that build three parallel programmes typically discover the duplication during their first joint audit cycle, when three different teams present three different versions of what should be a description of the same underlying control. Building the shared library first avoids that discovery being expensive.