India built its privacy law in two layers, and most teams only read the first one.

The Digital Personal Data Protection Act, 2023 is the statute. It defines who a Data Fiduciary is, what valid consent looks like, and what a Significant Data Fiduciary must do. But on the questions practitioners actually need answered — how fast you report a breach, how a consent manager gets registered, what a verifiable-consent flow has to capture — the Act repeatedly defers. The phrase "as may be prescribed" runs through it like a watermark.

That second layer is the DPDP Act rules 2026: the subordinate rules the Central Government is empowered to make under Section 40. The Act sets the obligation. The Rules set the parameter. You cannot operationalise one without the other.

This piece separates the two. Where the Act itself says something, we cite it. Where a detail lives in the Rules — breach clocks, registration thresholds, consent-manager net worth — we say so, and we resist inventing a number the statute does not contain.

What is the DPDP Act and who must comply in 2026?

The DPDP Act regulates the processing of digital personal data — personal data in digital form, or non-digital data later digitised.

Two roles carry the weight. A Data Fiduciary determines the purpose and means of processing. A Data Principal is the individual the data is about. A Data Processor processes on a Fiduciary's behalf, and under Section 8(2) may only be engaged under a valid contract.

The Act's central discipline is consent. Section 6(1) requires consent to be "free, specific, informed, unconditional and unambiguous with a clear affirmative action," limited to the personal data necessary for the specified purpose. Before requesting it, the Fiduciary must give notice (Section 5) describing the data and the purpose, the way the Data Principal can exercise her rights, and how to complain to the Board.

Crucially, Section 6(10) puts the burden of proof on the Fiduciary: if a question arises in a proceeding, the Fiduciary must prove that notice was given and consent was obtained in accordance with the Act. Consent you cannot evidence is, for enforcement purposes, consent you do not have.

Beyond consent, the Act recognises certain legitimate uses in Section 7 — the voluntary-provision ground, several State-function grounds, medical emergencies, epidemics, disasters, and employment-related processing to safeguard the employer from loss or liability. These are narrower than they look, and most commercial processing still routes back to consent.

Compliance is responsibility, not delegation. Section 8(1) makes the Data Fiduciary responsible "irrespective of any agreement to the contrary" for any processing undertaken by it or on its behalf by a Data Processor. You can outsource the processing. You cannot outsource the accountability.

If you are mapping these duties against an existing programme, our GDPR solution and broader privacy controls pages walk through how overlapping obligations get reconciled rather than duplicated.

Which entities qualify as Significant Data Fiduciaries under the draft rules?

The Act creates a heightened-duty tier called the Significant Data Fiduciary. Section 10(1) is explicit that this status is conferred by notification — the Central Government "may notify any Data Fiduciary or class of Data Fiduciaries" as significant. It is not a self-assessed threshold you cross automatically.

The Act lists the factors the Government weighs: the volume and sensitivity of personal data processed, risk to the rights of Data Principals, potential impact on the sovereignty and integrity of India, risk to electoral democracy, security of the State, and public order (Section 10(1)(a)–(f)). What the Act does not do is fix a record count or revenue figure. Any specific quantitative threshold lives in the Rules or in a notification — so treat any hard number you see attributed to "Significant Data Fiduciary" as a Rules detail to verify against the gazetted text, not as a statutory line.

Once designated, the obligations in Section 10(2) are concrete and non-negotiable:

  • Appoint a Data Protection Officer who represents the SDF under the Act, is based in India, is an individual answerable to the Board of Directors or equivalent governing body, and is the contact point for grievance redressal.
  • Appoint an independent data auditor to evaluate the SDF's compliance.
  • Undertake periodic Data Protection Impact Assessments and periodic audits, plus such other measures as may be prescribed.

The Act defines the DPIA itself: a process describing the rights of Data Principals and the purpose of processing, and the assessment and management of risk to those rights (Section 10(2)(c)(i)). The cadence of "periodic," and the matters the DPIA must additionally cover, are left to the Rules.

For global firms, the India-resident DPO requirement is the operational pinch point. It is a statutory locus, not a paperwork title — and it is the single duty most likely to force an org-chart change.

How does consent-manager registration work and what are the obligations?

The consent manager is the structural innovation that has no clean GDPR analogue.

Section 6(7) lets a Data Principal "give, manage, review or withdraw her consent to the Data Fiduciary through a Consent Manager." It is an accountable intermediary — a single interface through which an individual can administer consent across many Fiduciaries.

Two duties anchor it in the Act:

  • Section 6(8): the Consent Manager "shall be accountable to the Data Principal and shall act on her behalf," subject to obligations as may be prescribed.
  • Section 6(9): "Every Consent Manager shall be registered with the Board in such manner and subject to such technical, operational, financial and other conditions as may be prescribed."

Read that carefully. The requirement to register with the Data Protection Board is statutory. The conditions of registration — the technical, operational, and financial criteria — are explicitly prescribed by the Rules. This is exactly where consent manager registration India becomes a Rules question: any net-worth floor, governance composition, interoperability standard, or fit-and-proper test sits in the subordinate rules and any associated registration form, not in the Act.

The Act does give the Board teeth here. Section 27(1)(c) lets the Board inquire into and penalise a Consent Manager's breach of its obligations on a Data Principal's complaint, and Section 27(1)(d) covers breach of any condition of registration. A consent manager that drifts out of its registration conditions is directly exposed.

So when you read "consent managers" in coverage of the 2026 Rules, hold two facts apart: the role and the duty to register come from Sections 6(7)–(9); the eligibility bar comes from the Rules. Conflating them is how compliance plans end up built on a number that was never in the statute.

What are the new breach-notification timelines under the DPDP rules?

This is the question that generates the most confusion, so it deserves the most precision.

Section 8(6) of the Act states the duty in full: "In the event of a personal data breach, the Data Fiduciary shall give the Board and each affected Data Principal, intimation of such breach in such form and manner as may be prescribed."

Note what the Act does and does not say. It establishes a dual-notification obligation — both the Data Protection Board and every affected Data Principal must be told. It does not state a number of hours or days. There is no "72 hours" in the DPDP Act. The DPDP breach notification timeline — the actual clock, the staged-reporting structure, the content of the intimation — is set by the Rules, under the Section 40(2)(f) rule-making power for "the form and manner of intimation of personal data breach to the Board."

That distinction is not pedantry; it is liability. The Act backs Section 8(6) with one of its largest penalties.

Two separate breach-related failures are penalised, and they are not the same line item:

  • Failure to take reasonable security safeguards to prevent a breach (Section 8(5)) — penalty up to 250 crore rupees under the Schedule.
  • Failure to give the Board or affected Data Principals notice of a breach (Section 8(6)) — penalty up to 200 crore rupees under the Schedule.

So an organisation can be penalised for the breach-prevention failure and, independently, for botching the notification. The reporting obligation has its own price tag.

Operationally, the safe posture is to engineer your breach runbook to the tightest timeline the Rules impose and to satisfy the dual-recipient structure the Act fixes — Board and individuals — rather than assuming a GDPR-style single-supervisor flow. The deadline number is a Rules input; confirm it against the gazetted Rules and any prescribed reporting form before you hard-code it into your incident playbook.

How do DPDP consent and notice requirements compare to GDPR?

The DPDP vs GDPR comparison matters because most multinationals already run a GDPR programme and are tempted to treat DPDP as a regional copy. It is not.

Lawful bases. GDPR offers six lawful bases, including legitimate interests and contractual necessity. DPDP is consent-first: outside the narrow "certain legitimate uses" of Section 7 — voluntary provision, specified State functions, medical emergencies, employment safeguarding, and a few others — processing rests on consent. There is no broad legitimate-interests balancing test. A processing activity that you justify under GDPR's legitimate interests may have no lawful basis under DPDP unless it maps to a Section 7 ground or you obtain consent.

Consent standard. Both demand consent that is free, specific, informed, and unambiguous, signified by a clear affirmative action — DPDP's Section 6(1) language tracks GDPR closely on quality. And like GDPR, DPDP Section 6(4) requires withdrawal to be as easy as the original grant.

Burden of proof. DPDP Section 6(10) makes the Fiduciary prove notice and consent were properly obtained. GDPR's Article 7(1) places a comparable demonstrability burden on the controller. Here the two laws converge.

The consent manager. This is the clean divergence. GDPR has no registered, Board-supervised consent-management intermediary built into the statute. DPDP's Sections 6(7)–(9) create one. If you are localising a GDPR consent stack for India, the consent-manager pathway is net-new architecture, not a configuration toggle.

Children. DPDP Section 9 requires verifiable parental (or lawful-guardian) consent before processing a child's data, and flatly prohibits tracking, behavioural monitoring, and targeted advertising directed at children. That is a brighter, more categorical line than GDPR's age-of-consent patchwork across member states.

Data subject rights. DPDP grants access (Section 11), correction and erasure (Section 12), grievance redressal (Section 13), and a distinctive right to nominate (Section 14) — an individual to exercise rights on the Data Principal's behalf in the event of death or incapacity. That nomination right has no direct GDPR equivalent.

Answer once. Assess everything. The overlap between the two regimes is real, but the deltas — consent-first basis, the consent manager, the nomination right, the children's prohibitions — are where localisation work actually concentrates.

What cross-border data transfer restrictions apply under DPDP?

DPDP's transfer model is the inverse of GDPR's, and the difference is strategically important.

GDPR is restrict-by-default: transfers outside the EEA need an adequacy decision, standard contractual clauses, or another Chapter V mechanism. DPDP, by Section 16(1), is closer to permit-unless-restricted: "The Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified."

In other words, the baseline under the Act is that transfer is permitted, and the Government can carve out a blacklist of restricted destinations by notification — rather than maintaining a positive adequacy allowlist.

Two caveats keep this from being a free pass:

  • Section 16(2) preserves any other Indian law that imposes a higher degree of protection or a stricter transfer restriction. Sectoral rules — for banking, telecom, health — can be tighter than DPDP, and DPDP does not override them.
  • The specific list of restricted countries, and any conditions attached, are notification-and-Rules territory. The Act supplies the mechanism, not the destinations.

For data-architecture decisions, see our data protection coverage on mapping transfer dependencies against both DPDP and the sectoral overlay. The practical risk is not the DPDP baseline; it is the stricter sectoral law sitting on top of it.

How should global teams operationalize DPDP alongside existing privacy programs?

The trap is treating DPDP as a standalone project. The leverage is treating it as a delta on top of controls you already run.

A defensible operational sequence:

  1. Map your processing to a lawful basis under DPDP specifically. Do not assume GDPR legitimate-interests carries over. Identify every activity that survives only on consent and confirm the consent flow meets Section 6(1) — and that you can evidence it under Section 6(10).

  2. Decide your consent-manager posture. Will you integrate with registered consent managers, or build direct consent capture? Either way, design for the registration conditions the Rules impose on consent managers and for the Board-supervised accountability in Sections 6(8)–(9).

  3. Engineer the breach runbook to the dual-recipient structure. Board and every affected Data Principal, in the form the Rules prescribe, on the tightest timeline the Rules impose. Wire the two penalty exposures — safeguards (250 crore) and notification (200 crore) — as distinct controls.

  4. Pressure-test for Significant Data Fiduciary designation. If volume, sensitivity, or systemic-risk factors put you in range of a Section 10 notification, stand up the India-resident DPO, the independent data auditor, and the periodic DPIA/audit cadence before the notification lands.

  5. Reconcile, don't duplicate. Where DPDP and GDPR demand the same control — withdrawal parity, demonstrable consent, erasure — operate one control and evidence it against both. Where they diverge — consent manager, nomination right, children's advertising ban — build the India-specific piece.

This is precisely the work a source-grounded control map does well: the same data-retention or breach-response control answers a DPDP obligation and a GDPR one without you re-answering from scratch.

Map DPDP obligations against your existing privacy controls in aegis-grc.com — answer once, assess everything across 245+ regulations.

FAQ: DPDP Act enforcement, penalties, and consent-manager questions

Who enforces the DPDP Act? The Data Protection Board of India, established under Section 18 as a body corporate. By Section 28(1) it functions as a digital office "digital by design." It can direct urgent remedial measures on a breach intimation, inquire into complaints, and impose the Schedule penalties (Section 27). Appeals go to the Appellate Tribunal within 60 days of the order (Section 29(2)).

What are the maximum penalties under the Act? The Schedule sets penalties per breach type: up to 250 crore rupees for failing to take reasonable security safeguards (Section 8(5)); up to 200 crore for failing to notify a breach (Section 8(6)); up to 200 crore for children's-data violations (Section 9); up to 150 crore for Significant Data Fiduciary obligation failures (Section 10); and up to 50 crore as a residual penalty for other breaches. Penalties are credited to the Consolidated Fund of India (Section 34).

Does the DPDP Act specify a breach-notification deadline? The Act itself does not state a number. Section 8(6) requires intimation to the Board and each affected Data Principal "in such form and manner as may be prescribed." The actual timeline is set by the DPDP Rules under the Section 40 rule-making power — confirm it against the gazetted Rules.

Do consent managers have to register with anyone? Yes. Section 6(9) requires every consent manager to be registered with the Data Protection Board, subject to technical, operational, financial, and other conditions prescribed by the Rules. The duty to register is statutory; the eligibility criteria are in the Rules.