Home · Guides

DPDPA notice and consent architecture for 2026–27 — a practitioner reference

ControlForge free guide · 2026-05-24 · Reflects DPDP Act 2023 + DPDP Rules 2025 (notified 13 November 2025) and the Consent Manager runway to 13 November 2026

Quick reference

  • The hard timing facts:
  • 13 November 2025: DPBI operational; legacy-data assessment under-recognised pre-DPDPA standards already begin to count against compliance posture.
  • 13 November 2026: Consent Manager registration framework activates (Rule 4). Only India-incorporated entities with ₹2 crore minimum net worth can register — excluding foreign consent platforms (OneTrust, TrustArc, BigID, etc.) from operating as DPDPA-registered Consent Managers themselves.
  • 13 May 2027: full operational enforcement; Section 5 (notice), Section 6 (consent), Section 7 (legitimate uses), and all penalty provisions live.
  • The four most-misunderstood points in 2026: 1. DPDPA has no "legitimate interest" basis. Consent or one of the Section 7 legitimate uses; nothing else. 2. Consent must be "free, specific, informed, unconditional, unambiguous" — five tests, not one. 3. Withdrawal must be as simple as giving consent originally. UX symmetry is a hard requirement. 4. Legacy consents are grandfathered only on a fresh notice — meaning organisations must serve a DPDPA-compliant notice to existing customers before continuing to process under pre-DPDPA consent.
  • Audience: DPOs, Privacy Counsel, Product Managers, UX leads, CISOs, Marketing technology owners.
  • ControlForge density: 25+ controls across cl-consent-management, cl-data-subject-rights, cl-notice-and-transparency, and cl-pims-consent-management; cross-walked with GDPR, ISO 27701, IRDAI 2023, and sectoral regulators.

Why this is harder than GDPR

A surprising number of Indian DPDPA programmes in 2026 are being scoped on the basis of "we already comply with GDPR — DPDPA is similar." That assumption is partially correct but materially misleading. Four structural differences make DPDPA's notice-and-consent regime harder than GDPR's in practice.

First, there is no legitimate-interest basis. Under GDPR, the legitimate-interest basis (Article 6(1)(f)) is one of six lawful bases and is heavily used for analytics, fraud detection, marketing, and security. DPDPA has no analogous basis. Section 7 of the Act lists specific "legitimate uses" — voluntarily provided personal data for the purpose for which the Data Principal volunteered it, employment-related processing, medical emergency, compliance with judgment or court order, and a handful of state-related uses. Outside Section 7, processing requires consent. This means many processing activities that GDPR-trained programmes route to legitimate interest will, under DPDPA, require consent.

Second, the consent standard is more restrictive. DPDPA's "free, specific, informed, unconditional, unambiguous" formulation looks similar to GDPR's "freely given, specific, informed, unambiguous" — but DPDPA adds "unconditional". The unconditional requirement is being interpreted by Indian practitioners and the early DPBI guidance as prohibiting bundling: each consent must be for a specific purpose, not bundled across multiple purposes. The granularity bar is higher than GDPR's, even though GDPR is also strict on granularity.

Third, withdrawal must be operationally symmetric. DPDPA requires that withdrawal of consent be "as easy as giving consent". This is more demanding than GDPR's equivalent — GDPR requires that withdrawal be "as easy as" giving consent but the operational tests have varied across DPAs. The Indian DPBI is signalling a strict reading: if consent is captured via a one-click button on the website, withdrawal must be available via a one-click button at a similar prominence and reachability. This forecloses the common pattern where consent is given easily on signup but withdrawal requires a support ticket or email request.

Fourth, the Consent Manager ecosystem is a structural innovation with operational consequences. From 13 November 2026, registered Consent Managers can operate as intermediaries providing Data Principals with a centralised consent-management platform. Critically, only India-incorporated entities with ₹2 crore minimum net worth can register as Consent Managers — excluding foreign consent platforms (OneTrust, TrustArc, BigID and similar) from acting as DPDPA-registered Consent Managers themselves. Organisations have a choice: integrate with an Indian-registered Consent Manager, build their own consent infrastructure satisfying Rule 4 expectations, or operate without a Consent Manager (which is permitted but operationally harder for high-volume processors).

The notice obligation (Section 5 + Rule 3)

Before collecting personal data with consent, the Data Fiduciary must give the Data Principal a notice. Section 5 specifies four required elements:

  • The personal data being collected and the purpose.
  • The manner in which the Data Principal can exercise their rights under DPDPA.
  • The manner in which the Data Principal can make a complaint to the DPBI.
  • (Rule 3 specifics) Additional content per Rule 3, including the Data Fiduciary's contact details, the specific communication link for rights exercise, and language accessibility.

The notice must be in the Data Principal's preferred language from the schedule under Article 348(2)(b) of the Constitution — meaning the 22 scheduled languages. In practice this is a translation problem: Hindi and English are typically straightforward, but languages like Maithili, Konkani, Manipuri, Bodo, and Santali are operationally harder.

The specific communication link referenced in Rule 3 is operationally consequential: a single URL or contact point from which the Data Principal can exercise all rights (access, correction, erasure, grievance, withdrawal of consent). The link must be reachable from the notice and must be operational.

Common notice failures observed in 2026 implementations:

  • Single umbrella notice covering all processing activities — too vague to be informed consent for any specific purpose. DPDPA requires separate notices per processing activity.
  • Notice delivered after collection (e.g., on first login rather than at signup or pre-collection). Section 5(1) is explicit: "before processing", which is interpreted to mean before collection in most contexts.
  • Translation absent or limited to Hindi and English when other scheduled languages are relevant. The standard is the Data Principal's preferred language from the schedule, not just the major languages.
  • "Manner to exercise rights" referenced but the actual mechanism is non-functional — a link to a contact-us page rather than a working rights-exercise mechanism.
  • Burying the notice in long terms-of-service text where the consent prompts appear separately and the notice content is not surfaced at the point of consent.

The cleanest pattern: layered notice — a concise summary at the point of collection with a "more information" link to the full notice, available in the user's preferred scheduled language at any point in the user journey.

Consent is the operational core of DPDPA. The five-test standard:

  • Free — not coerced, not conditional on service delivery unless the service is genuinely impossible without the data.
  • Specific — for a specific purpose, not bundled.
  • Informed — the Data Principal has received the Section 5 / Rule 3 notice.
  • Unconditional — separate from other transactions; not a precondition to unrelated services.
  • Unambiguous — clear affirmative action, not pre-checked boxes or inferred from silence.

Free is operationally tested by asking: can the Data Principal refuse this consent and still receive the service? If refusal materially impedes service delivery and the data is not strictly necessary, the consent is not free.

Specific rules out bundled consent — "I consent to service improvement, analytics, marketing, and partner sharing" is one consent for four purposes, which is impermissible. The cleanest approach is one consent toggle per processing purpose, with each toggle linked to a notice describing only that purpose.

Informed is tested by reviewing whether the notice content reaches the Data Principal at the point of consent. A notice buried elsewhere is not informed consent.

Unconditional is the test most often failed in practice. Service signups that bundle "agree to terms of service AND consent to marketing communications" as a single checkbox are conditional consent — the Data Principal is conditioning consent on receiving the service. Unbundle.

Unambiguous rules out pre-checked boxes, inferred consent from silence, dark patterns, and any prompt that does not require clear affirmative action from the Data Principal.

The operational consent record must capture: identity of the Data Principal (or pseudonymised reference), purpose of consent, granularity of consent (which toggles were on / off), timestamp, capture mechanism, version of the notice the Data Principal viewed, and IP address / device context as available.

Withdrawal — the operational hardest part

DPDPA's withdrawal requirement is among the most operationally demanding provisions. The test:

Consent must be capable of being withdrawn at any time, and the mechanism for withdrawal must be as easy as the mechanism for giving consent originally.

A 2026-compliant withdrawal mechanism has the following properties:

  • Reachable from the Rule 3 specific communication link.
  • Available in the Data Principal's preferred scheduled language.
  • Operationally as simple as the consent capture — if consent was a click, withdrawal is a click; if consent was via app permission, withdrawal is via app permission; if consent was via UPI flow, withdrawal is via comparable digital flow.
  • Effective without requiring identification beyond what was required at consent capture. If the consent was captured from an authenticated user, withdrawal from that same authenticated session is sufficient. Heavy identity verification before allowing withdrawal would create asymmetry.
  • Propagated downstream. Withdrawal at the customer-facing layer must signal back to all downstream systems, analytics platforms, ad networks, and third-party processors that received the data under the now-withdrawn consent.

The downstream propagation is often the operationally weakest area. A typical pattern: consent is given via a clean UX; withdrawal happens via the same UX; the database flips a flag — but the analytics events that already flowed to a separate platform are not retracted, the marketing automation continues running, and the partner who received the data under the withdrawn consent has no notice.

The remediation is withdrawal-aware data architecture: at consent capture, record the downstream destinations of the data; at withdrawal, signal each destination to cease processing under the now-withdrawn consent and to delete or anonymise the data unless retention is mandated for another purpose.

From 13 November 2026, Rule 4 activates. Consent Managers are intermediaries registered with the DPBI providing Data Principals with a centralised consent-management platform across multiple Data Fiduciaries. The Consent Manager registration requirements (per Rule 4 and the schedule):

  • India-incorporated entity — companies incorporated under the Companies Act, 2013, or equivalent Indian law.
  • Minimum net worth ₹2 crore.
  • Director and key personnel fit-and-proper criteria.
  • Technology and operational capabilities to operate the consent management platform at scale with security, availability, and integrity safeguards.
  • Independence from the major Data Fiduciaries it serves (the registration framework limits cross-shareholding).

Critically, the foreign-headquartered consent management platforms (OneTrust, TrustArc, BigID, Securiti, and similar) cannot themselves register as Consent Managers in India without establishing India-incorporated subsidiaries meeting all the registration criteria. The Indian consent-tech market through 2026–27 has seen multiple new entrants and several legacy Indian privacy-tech vendors positioning for Consent Manager registration.

Strategic options for Data Fiduciaries as of mid-2026:

  1. Integrate with a registered Consent Manager when registrations open. Pros: standardised consent capture across Data Fiduciaries, easier Data Principal experience, regulatory alignment. Cons: dependence on the Consent Manager's reliability and security; integration cost.

  2. Build proprietary consent infrastructure satisfying Rule 4 expectations without registering as a Consent Manager. This is the path most large Data Fiduciaries (banks, insurers, large enterprises) are taking — they need consent infrastructure regardless, and they don't need the inter-Fiduciary aggregation that justifies Consent Manager registration.

  3. Operate without a Consent Manager — permissible but operationally limiting, particularly for high-volume B2C Data Fiduciaries where Data Principal experience matters.

The DPBI is expected to publish the registered Consent Manager directory after 13 November 2026; Data Fiduciaries that plan to integrate should be ready to evaluate and integrate within Q4 2026 / Q1 2027.

DPDPA includes a grandfathering provision for consent given before the Act's commencement: such consent remains valid subject to the Data Fiduciary giving a fresh notice. This is operationally significant.

The implication: organisations that have been processing personal data under pre-DPDPA consent must, before 13 May 2027 (full enforcement), serve a DPDPA-compliant notice to all such Data Principals. This is a substantial communication exercise for high-volume B2C Data Fiduciaries — banks may have tens of millions of legacy customers, telcos may have hundreds of millions.

Recommended approach:

  • Identify the legacy population — Data Principals with active relationships whose consent predates DPDPA.
  • Draft the re-notice — a DPDPA-compliant notice covering the existing processing activities, in the Data Principal's preferred scheduled language where reasonably ascertainable.
  • Choose the channel — email, SMS, in-app notification, postal mail where digital channels are not reliable. Multi-channel is common.
  • Track delivery and response — record the notice delivery, any opt-out / withdrawal in response, and the Data Principal's continued engagement as implicit affirmation of the existing consent.
  • Operationalise withdrawal handling — the re-notice must include the specific communication link for withdrawal, and the withdrawal mechanism must be live before the re-notice is served.

Organisations that have not completed the legacy re-notice exercise before 13 May 2027 face supervisory exposure on every continued processing of pre-DPDPA data — which for most large B2C Data Fiduciaries is the majority of their processing.

Architecture patterns — what good looks like in 2026

A mature DPDPA notice-and-consent architecture has the following operational properties.

Notice layer: - Per-processing-activity notice templates, version-controlled. - Multi-language support across the 22 scheduled languages, with at least English, Hindi, and the regional language for the customer's stated state. - Notice delivery at the point of collection through layered presentation (summary + full notice on demand). - Notice version tracking — the specific version the Data Principal viewed at consent capture is captured in the consent record.

Consent capture layer: - Granular toggles per processing purpose. - No pre-checked boxes, no inferred consent. - No bundling — unrelated purposes are separated. - Consent records capture purpose, timestamp, mechanism, notice version, Data Principal context. - Confirmation of consent capture to the Data Principal (e.g. confirmation email or in-app receipt).

Withdrawal layer: - Reachable from the Rule 3 specific communication link. - Available across all channels where consent was captured. - Operationally symmetric with consent capture (one click for one click; app permission for app permission). - Multi-language support. - Downstream propagation to all systems and third-party processors that received the data under the withdrawn consent.

Rights exercise layer: - Single specific communication link supporting all rights (access, correction, erasure, grievance, withdrawal). - Identity verification proportionate — strong enough to prevent impersonation, light enough not to chill rights exercise. - SLA per rights category (anticipated guidance from DPBI; pending Rules clarification). - Audit trail of rights requests and responses.

Legacy data layer: - Inventory of legacy Data Principal populations. - Re-notice templates and delivery infrastructure. - Tracked delivery and response.

Consent Manager integration layer (Q4 2026 onwards, where applicable): - API integration with the registered Consent Manager(s) of choice. - Reconciliation between internal consent records and Consent Manager records. - Fallback to internal consent capture where the Consent Manager is unavailable.

How auditors and DPBI inspections will test this

DPBI inspections (anticipated from May 2027 enforcement onwards) and internal / external compliance audits will exercise:

Notice content: sample 3 processing activities and review the notice content against Section 5 / Rule 3 requirements.

Notice delivery: trace from the collection point through the notice surface to verify the notice is reached pre-collection.

Language coverage: test the notice and consent UX in 2-3 non-English scheduled languages.

Consent granularity: review the consent capture UX for any bundling or pre-checked boxes.

Withdrawal mechanism: exercise the withdrawal flow end-to-end and verify the operational symmetry with consent capture.

Downstream propagation: trace a withdrawn consent through all downstream systems to verify propagation.

Consent records: sample 5 consent records and verify completeness (purpose, granularity, timestamp, mechanism, notice version).

Legacy re-notice: review the legacy re-notice exercise — population identified, notices sent, response handling.

Consent Manager integration (post-November 2026): review API integration, reconciliation logs, fallback handling.

Common findings expected: - Bundled consent on signup flows. - Withdrawal accessible only via support ticket. - Downstream propagation incomplete; analytics / ad networks continue receiving data after withdrawal. - Legacy re-notice not executed or partially executed. - Multi-language support limited to English and Hindi. - Pre-checked marketing-consent boxes. - "Specific communication link" pointed to a generic contact-us page.

Cross-references and sectoral overlays

DPDPA does not operate in isolation. Sectoral regulators layer their own consent and notice expectations on specific data categories:

  • RBI — payment data localisation; sectoral consumer protection rules.
  • IRDAI — policyholder consent for specific processing activities; sectoral notice expectations.
  • SEBI — investor consent for specific data sharing; KYC and KRA framework.
  • TRAI / DoT — telecom subscriber consent; commercial communications consent (DND, DLT registration).
  • MeitY IT Rules 2021 + 2026 amendments — intermediary content moderation, SGI labelling.
  • Aadhaar Act + UIDAI regulations — Aadhaar-specific authentication and information handling.

In sectoral conflicts, the stricter clause wins (Section 38 of DPDPA — conflict-of-laws provision applies where another law imposes stricter requirements; DPDPA does not displace stricter sectoral protections).

How ControlForge supports this

ControlForge curates the consent-and-notice obligation surface across:

  • cl-consent-management — operational consent capture and withdrawal.
  • cl-notice-and-transparency — notice content and delivery.
  • cl-data-subject-rights — the broader rights mechanism.
  • cl-pims-consent-management — ISO 27701-aligned consent under a privacy management system.
  • cl-data-classification — data inventory and category-mapping.
  • cl-personal-data-erasure — withdrawal-driven erasure obligations.

The synthesis surfaces the strictest-clause patterns across DPDPA + GDPR + UK GDPR + LGPD + CCPA / state privacy laws, allowing multi-jurisdiction Data Fiduciaries to satisfy overlapping obligations through a single evidence trail.

Further reading

  • DPDP Act 2023 + DPDP Rules 2025 — https://www.meity.gov.in/
  • Section 5 (notice), Section 6 (consent), Section 7 (legitimate uses), Section 10 (Significant Data Fiduciaries) — Act text.
  • Rule 3 (notice content), Rule 4 (Consent Managers), Rule 5 (consent), Rule 6 (security safeguards), Rule 7 (breach notification) — Rules text.
  • ISO/IEC 27701:2025 Edition 2 (Privacy Information Management) — aligned with DPDPA management-system approach.
  • ControlForge clusters: cl-consent-management, cl-notice-and-transparency, cl-data-subject-rights, cl-pims-consent-management — DPDPA cross-walked against GDPR, ISO 27701, IRDAI 2023, and sectoral consent regimes.

This guide is a practitioner reference, not legal advice. It reflects DPDP Act 2023 + DPDP Rules 2025 (notified 13 November 2025) and publicly available DPBI / MeitY guidance as of 24 May 2026. Compliance teams should validate specific obligations against the current Rules text, anticipated DPBI guidance, and counsel review. The Consent Manager registration framework is operational only from 13 November 2026; integration decisions should be deferred until the registered Consent Manager directory is published.