Do we have the compliance and reporting framework India needs to handle DPDPA?

I want to start this post with a question I've been asking compliance officers at every Indian organisation I've worked with in the last year. The question is: if the Data Protection Board called you tomorrow and asked for an evidence pack covering your DPDP compliance posture, how long would it take you to assemble it?

The answers I get fall into three buckets:

1. “A few hours” — almost no one
2. “A few weeks” — a noticeable minority, mostly in regulated sectors with mature compliance functions
3. “I have no idea, we'd have to figure it out” — the majority

The third answer is the one that reveals the structural problem. Indian organisations have been doing compliance work for decades — the compliance departments at large banks and insurers are some of the most mature in the world — but the frameworks they use were designed for a different set of obligations. The RBI Master Directions, the IRDAI Corporate Governance Guidelines, the SEBI LODR — none of them anticipated a horizontal data protection law that applies across sectors with its own evidence requirements and its own reporting cadence.

So the question I want to spend this post on is structural: does India have a compliance and reporting framework that can hold the DPDP Act, or are we improvising one as we go? The answer depends on what kind of organisation you are.

What the existing Indian compliance frameworks do well

Before I get to the gaps, I want to give credit where it's due. Indian compliance work is not starting from zero. There are several things the existing frameworks do extremely well, and the DPDP Act inherits those strengths whether or not it acknowledges them explicitly.

Audit-ready evidence culture. Indian regulated industries are accustomed to producing evidence on demand. RBI inspections are routine. SEBI LODR filings are time-stamped. The IRDAI conduct rules require quarterly returns. The muscle of “produce a document with a date and a signature when asked” is well-developed. The DPDP Act requires the same muscle — you need to be able to show, on demand, the consent records, the rights request logs, the breach incident timeline, the DPIA artifacts, and the training completion records. Organisations that already do RBI inspections will adapt to DPB inspections quickly.

Independent audit infrastructure. India has a deep bench of statutory audit firms, internal audit functions, and concurrent audit teams. The DPDP Act's Section 10 obligation for Significant Data Fiduciaries to engage an independent data auditor maps cleanly onto the existing audit ecosystem. The same firms that do statutory financial audits are now hiring privacy auditors and offering DPDP audit services. The capacity is being built, even if the supply is still tight.

Grievance redressal as a known pattern. I mentioned this in an earlier post but it's worth repeating here. Indian Data Principals know how grievance redressal works because every regulated industry already has a grievance mechanism. The DPDP Act's Section 13 grievance flow is operationally similar to the banking ombudsman flow, the IRDAI grievance flow, and the SEBI SCORES flow. The legal obligation is new, but the operational pattern is familiar.

Policy management infrastructure. Indian compliance teams know how to draft, version, approve, and publish policies. This is the daily bread of any compliance function. The DPDP Act adds a new category of policies (privacy notices, retention schedules, vendor DPAs, breach response runbooks) but the machinery of policy management already exists.

These four strengths are real, and they mean that the most mature Indian compliance functions can absorb DPDP without rebuilding from scratch. The framework gap is not at the bottom — it's at the operational seam.

Where the gaps are

Gap 1 — Cross-functional ownership

Almost every existing Indian compliance framework lives in one specific function. RBI compliance lives in the bank's Compliance Department. SEBI LODR lives in the Company Secretary's office. IRDAI conduct rules live in the insurance risk function. Each has a clear owner with clear authority.

DPDP doesn't fit that pattern. DPDP touches:

• Marketing (consent for promotional emails, cookie banners, analytics)
• Engineering (data flows, retention controls, deletion workflows, security architecture)
• Sales (CRM contact lists, vendor data sharing)
• HR (employee data, background checks, performance records)
• Legal (vendor DPAs, customer contracts, privacy notices)
• Customer Support (rights request handling, grievance routing)
• Security (incident response, access control, audit logs)
• Procurement (vendor due diligence, sub-processor disclosure)

No existing Indian organisational structure has a single role that owns all eight of those functions. The General Counsel touches some of them. The CISO touches others. The Chief Compliance Officer touches a third subset. Nobody owns the whole thing.

This is the single biggest framework gap in India today. The DPDP Act assumes a coherent owner. Indian organisations don't have one. The Data Protection Officer role (mandatory for SDFs under Section 10, recommended for everyone else) is the architectural answer — but most organisations have not yet appointed a real DPO with real authority.

The practical fix: build a cross-functional DPDP working group with weekly cadence, chaired by a named owner with C-suite air-cover. The named owner does not need to be a DPO formally — a senior Compliance officer or a CISO can run it during the interim — but they need explicit authority to make decisions that bind marketing, engineering, sales, and procurement. Without that authority, the working group becomes another committee.

Gap 2 — Reporting cadence

The existing Indian frameworks report on quarterly, half-yearly, or annual cycles. RBI compliance certificates are quarterly. SEBI corporate governance reports are half-yearly. Most internal audit committees meet quarterly.

DPDP doesn't fit a quarterly cadence. The reporting events under DPDP are:

• Breach notifications — within 72 hours of awareness, on demand
• Grievance responses — within the statutory window, often days
• DSR fulfilment — within the statutory window, often days
• Vendor sub-processor disclosures — when changes occur
• DPIA refresh — annually for SDFs, or on material change to processing
• Cross-border transfer impact — when restrictions are notified

Notice that none of these align to a quarterly cycle. They are event-driven, not calendar-driven. The Indian compliance reporting muscle is calendar-driven. This is a real mismatch.

The practical fix: treat DPDP reporting as two streams. The event-driven stream (breach, grievance, DSR, vendor changes) needs an always-on operational workflow with SLA alarms and escalation. The calendar-driven stream (annual posture review, quarterly board update, annual DPIA refresh) can fit into existing audit committee cadence. The two streams need to be mentally separated, because trying to handle event-driven obligations on a quarterly cycle is how organisations fail.

Gap 3 — Evidence traceability

Indian compliance frameworks generally produce evidence in aggregated form. The RBI gets a quarterly return that summarises lakhs of transactions. SEBI gets a half-yearly report that summarises hundreds of board decisions. The aggregation is the deliverable.

DPDP requires the opposite. Every consent given by every Data Principal needs to be traceable individually. Every rights request and its fulfilment needs to be traceable individually. Every breach action needs to be traceable on a per-action basis. Aggregated reporting is not enough — the Board may at any time ask for the underlying evidence behind a single individual's complaint.

This is a fundamentally different evidence model than what most Indian compliance functions are built for. Aggregated reporting is what spreadsheets and PDFs do well. Per-individual traceability is what databases and audit ledgers do well. Most Indian compliance functions don't have the database/ledger infrastructure yet.

The practical fix: stop trying to do DPDP compliance in spreadsheets. The volume of per-individual events that need to be traceable is too high for a spreadsheet to keep up with, and the audit failure mode (a deleted row, a corrupted file, a missing timestamp) is too easy to hit. You need a hash-chained ledger or equivalent immutable audit infrastructure. This is not optional. The first organisation that loses a Section 33 case because their consent records were a spreadsheet will become the case study that everyone else points at.

Gap 4 — Sectoral overlay coordination

This is the most subtle gap, but it's the one I expect to cause the most trouble in 2027.

When the first sectoral guidance lands — and it will, probably starting with banking, then insurance, then healthcare — it will layer on top of the DPDP Act. RBI is going to issue a master direction telling banks how to interpret the DPDP Act in the banking context. IRDAI will do the same for insurers. The Ministry of Health will eventually do the same for healthcare. Each of these will add specific requirements that go beyond the base DPDP Act, and each will need to be reconciled with the others.

Indian compliance teams already deal with sectoral overlays — a bank that's also a listed entity has to comply with both RBI and SEBI — and they're good at it. But the DPDP overlay is going to be the first horizontal regulation that every sectoral regulator has to layer on top of, and the coordination problem is harder than usual. If RBI says one thing about consent and IRDAI says a slightly different thing about the same consent flow for the same customer, the bank that also sells insurance has a contradiction to resolve.

The practical fix: treat the DPDP Act as the base layer and any sectoral guidance as a delta on top of it. Don't try to comply with every sectoral guidance separately — that way leads to madness. Build your DPDP programme on the broadest interpretation, then add the sectoral deltas as exceptions. When a regulator inspects you, they will see a coherent base programme plus their specific overlay rather than a Frankenstein of conflicting partial implementations.

So do we have the framework, or not?

My honest view: India has most of the framework, but it sits in pieces across different functions, none of which currently coordinate. The pieces are good — Indian compliance work is mature, the audit culture is real, the grievance pattern is well-known, the policy machinery exists. The gap is in the seams between the pieces, and that gap is filled by a coherent owner (the DPO, the Privacy Lead, whatever you want to call them) running an event-driven workflow on top of an immutable evidence ledger.

Organisations that have already appointed that owner are roughly six months ahead of where they would be if they hadn't. The ones who haven't are paying for the coordination cost in the form of slower decisions, missed deadlines, and uncertain readiness.

The good news is that the gaps I've described above are operational rather than legal. The Act doesn't need to change, the Rules don't need to change, no new infrastructure needs to be built nationally. What needs to happen is that Indian organisations have to upgrade their own internal coordination, evidence handling, and ownership models. That work can start tomorrow morning. It doesn't need permission from any regulator.

If you want to know specifically where your organisation sits on each of these four gap dimensions, our free assessment covers them in 13 categories of questions. The output is a posture score and a prioritised gap list — exactly the kind of evidence pack you'd need to hand to the Board if they called tomorrow and asked.