India compliance registry

Why one registry, rather than a page per regulator

Most Indian organisations of any size are bound by more than one instrument, and the obligations overlap in ways that are invisible if you read each one separately. A bank is under RBI supervision, the CERT-In Directions, the DPDP Act, and probably PCI DSS. A listed fintech adds SEBI's framework. A hospital adds health data considerations on top of DPDP.

Read individually, each produces a compliance programme. Read together, they produce roughly one programme with several reporting paths, because the underlying controls are largely the same: know your assets, control access, retain logs, detect incidents, report them, and be able to prove all of it.

This registry exists to make that overlap visible, so you build the control once and evidence it once.

The obligations that catch organisations out

Log retention. The CERT-In Directions require 180 days, maintained within India. Audits fail here more often than on the reporting clause, because retention is a budget decision made years ago by somebody who has left. Two questions worth asking today: do your logs cover the systems that would matter in an intrusion, and is the retention actually in India.

Multiple incident clocks. Reportable incidents go to CERT-In within six hours of noticing. Personal data breaches carry a separate DPDP obligation to the Board and to affected individuals. Supervised entities have their own regulator expectations on top. One detection process, three reporting paths.

Third party accountability. Outsourcing moves the work and not the accountability, under RBI supervision and under the DPDP Act alike. Contracts that predate these instruments almost never carry the obligations forward.

Retention of personal data. The DPDP Act requires you not to keep it past its purpose, which is where most estates are out of compliance today, because deleting data requires knowing where it is.

How to use the registry

Identify which instruments bind you, which is less obvious than it sounds. The CERT-In Directions have no small organisation exemption. The DPDP Act applies to processing digital personal data in India regardless of sector.

Then map each obligation to a control you already have, rather than to a new one. Most of what these instruments require is already partly in place; the gap is usually evidence rather than capability.

Then identify the single owner for each obligation. Where an obligation has no plausible owner, that is the finding. The commonest failure is IT, security and legal each assuming one of the others holds it.

Keeping it current

This is a live area. DPDP rules continue to develop, sectoral regulators issue and revise directions, and the frameworks themselves version.

Two habits keep a compliance register honest. Attach a source and a date to every obligation, so you can tell what has been checked recently. And review it on a fixed cadence rather than when something changes, because you will not hear about everything that changes.

Where an obligation's detail is still pending, record that explicitly rather than leaving a gap. A register that distinguishes not applicable from not yet defined is considerably more useful in a board conversation.