Consent Isn’t a Pop‑Up Anymore: DPDP Act, DPDP Rules 2025, CMS and Consent Managers – FAQs for Indian Companies

Rainmaker January 9, 2026 Data Protection & Privacy 7 min read

The Digital Personal Data Protection Act, 2023 (“DPDP Act”) and the Digital Personal Data Protection Rules, 2025 (“DPDP Rules”) have made consent the frontline test of lawful data processing in India. Consent is no longer a buried line in a privacy policy. It is how regulators, customers, employees, and partners will judge whether your organisation respects digital autonomy.

The DPDP conversation inside most organisations has shifted. Boards and leadership teams are now focusing on these key questions:

When is the end user’s consent actually valid – and when is it not?
Which consent screens and flows are most likely to be questioned by regulators?
Where does a Consent Management System (“CMS”) or a Consent Manager (“CM”) genuinely add value?
If the Data Protection Board of India (“DPBI”) asks for proof, what exactly will we be able to show?

This FAQ is built to answer those questions head‑on, with a focus on enforceable consent, not theory.

What is ‘consent’ under the DPDP Act and when do we need it?

Under the DPDP Act, consent is the default legal basis for processing digital personal data, unless the processing clearly falls within one of the enumerated ‘legitimate uses’ in Section 7.

Any organisation that processes digital personal data in connection with offering products or services in India – including data about customers, employees, end‑users, and vendors – will need valid consent unless it can point to a specific Section 7 ground such as legal obligations, medical emergencies, disaster response, certain government functions, or defined employment‑related uses.

Crucially, DPDP does not create a broad ‘legitimate interest’ ground like some international regimes. For each consent‑less use case, organisations should map the processing clearly to a specific Section 7 clause and retain documentation explaining that mapping.

What are the legal requirements for ‘valid consent’ under the DPDP Act?

Section 6(1) of the DPDP Act sets a high bar: consent must be free, specific, informed, unconditional and unambiguous, expressed through a clear affirmative action and limited to data necessary for the specified purpose.

Practically, this translates into five design tests:

Free: Consent cannot be forced through take‑it‑or‑leave‑it terms for non‑essential processing, or by denying core services if a user refuses marketing or profiling.
Specific: Each purpose must be clearly articulated. Vague expressions like ‘business improvement’ or ‘future innovation’ are unlikely to stand alone as ‘specific purposes’.
Informed: Consent must follow a notice that explains what personal data will be processed, why, for how long, with whom it may be shared, and how rights can be exercised.
Unconditional: Only data strictly necessary for the core service must be mandatory. All other processing (analytics, behavioural ads, cross‑selling, etc.) must be optional.
Unambiguous: Pre‑ticked boxes, silence, or bundled language do not count as unambiguous consent.

If a regulator asks “show us how this consent is free, specific, informed, unconditional and unambiguous”, you should have a clear answer for each of these terms.

What should a compliant consent notice under the DPDP Act contain?

Section 5 of the DPDP Act and Rule 3 of the DPDP Rules require that a notice:

Be presented and be understandable independently – not buried inside lengthy terms, sign‑up flows, or hyperlinked documents.
Use clear and plain language, in English or relevant Eighth Schedule languages, enabling the Data Principal to give specific and informed consent.
Provide, at minimum, an itemised description of the personal data, the specific purposes of processing, the identity and contact details of the Data Fiduciary, and ways to withdraw consent, exercise rights, and complain to the DPO or subsequently the DPBI.
Avoid dark patterns, misleading layouts, or confusing button labels that effectively steer people into agreement.

In an audit or investigation, regulators are likely to examine how the notice appears and functions in real user flows, not just what your policy PDF says.

Can we bundle multiple purposes and services into one blanket consent?

Not if you want your consent to be defensible. Section 6 of the DPDP Act, read with Rule 3 of the DPDP Rules implies that consent must be purpose‑linked and limited to what is necessary for that specified purpose. Bundled consent for unrelated activities undermines both specificity and meaningful choice.

In practice, this means:

Separating consent to create an account or deliver a core service, from consent for marketing, cross‑selling, personalisation, and onward sharing with partners.
Providing separate toggles or options for each broad purpose category, so Data Principals can accept some and decline others without being locked out of essential services.
Making ‘manage preferences’ and ‘unsubscribe’ flows genuinely usable, not hidden or designed to cause friction.

What happens when a Data Principal withdraws consent?

Section 6(4) of the DPDP Act is clear: withdrawal of consent must be as easy as giving it. Operationally, this requires that:

Every consent journey includes a clear, accessible route to withdraw consent (and to opt out of specific purposes), described in the original notice.
Once withdrawal is received, the Data Fiduciary stops processing for that purpose and erases the data unless another law requires retention.

How does the DPDP Act handle children’s consent and profiling?

For Data Principals below 18, Section 9 of the DPDP Act requires verifiable consent from a parent or lawful guardian before processing personal data. In addition, the DPDP Act restricts:

Behavioural tracking, profiling, and targeted advertising directed at children.
Processing that is likely to cause significant harm, particularly in digital environments aimed at children.

Children’s consents, age‑assurance measures, and profiling safeguards will be high‑risk, high‑attention areas. Weak flows here are likely to draw early scrutiny.

What is a CMS under DPDP era expectations?

While the DPDP Act does not define a ‘CMS’ directly, MeitY’s Business Requirement Document (BRD) and related commentary effectively create a reference standard for a CMS.

A DPDP aligned CMS should be able to:

Capture granular, purpose‑wise consents through interfaces that validate that consent is free, specific, informed, unconditional and unambiguous (in line with Section 6 of the DPDP Act).
Generate a ‘consent artefact’ with metadata – purpose IDs, timestamps, user IDs, channel, version of the notice – and store it securely.
Allow Data Principals to review, modify, and withdraw consents in real time through a dashboard or equivalent mechanism.
Alert Data Fiduciaries and Processors whenever consent is granted, updated, or revoked, and log whether and when those alerts are acted upon.

Who or what is a Consent Manager, and do we need one?

A Consent Manager is a registered intermediary envisaged under the DPDP Act to help Data Principals give, manage, and withdraw consent across one or multiple Data Fiduciaries via standardised, interoperable interfaces.

For Data Fiduciaries, key points are:

You are not compelled to use a CM. You can manage consent internally, through your own CMS, as long as you meet the DPDP Act standards.
If you do integrate with a CM, they become part of your DPDP compliance ecosystem, but legal accountability for compliance still rests with you.
For high‑volume consumer services, CMs may eventually become a practical way to reduce friction and give users a single pane of glass for consents – but this is a strategic choice, not an automatic requirement.

Think of CMs as optional infrastructure partners, not as a way to outsource responsibility for consent.

How should Indian companies design enforcement‑ready consent journeys?

An enforcement‑ready consent journey under the DPDP Act typically includes:

Stage‑appropriate notices: Short, plain‑language notices at decision points (sign‑up, feature activation, sharing to partners, etc.), linked to full policies but self‑sufficient.
Purpose‑wise controls: Distinct options for core service, analytics, personalisation, marketing, and onward sharing, with defaults set conservatively and clearly.
CMS integration: Each front‑end interaction writes back to a central CMS or equivalent, creating traceable consent artefacts and making withdrawals effective across systems.
Rights and grievance hooks: Obvious, functional ways to withdraw consent, unsubscribe, raise grievances, and trigger rights workflows, supported by SLAs and logs.

What consent‑related evidence will regulators expect us to show?

Consent‑specific evidence likely to be requested in audits, breaches, or complaints includes:

Historical versions of notices and consent screens, showing clarity, separation, and absence of dark patterns.
CMS logs and consent artefacts showing when consent was given, for which purposes, and under which notice version.
Withdrawal and preference‑change logs, including how quickly changes were propagated to internal systems and processors.
Records of data principal rights requests and grievances linked to consent (for example, “I never consented to this use”), and how these were resolved within the DPDP Act timelines.
Contracts and instructions to processors that demonstrate how consent and purpose limitations are respected downstream.

The central test will be whether your organisation can demonstrate reasonable, proportionate measures rather than merely assert that consent was obtained.

Wrapping Up

DPDP consent is no longer a formality. It is a trust framework, a control on digital risk, and a growing source of competitive advantage for Indian companies. Organisations that treat consent as a live system – redesigning notices, journeys, CMS, and evidence – will be the ones that earn regulator confidence and customer trust in India’s data‑driven economy.

Suggested Reading

children’s data CMS compliance consent journeys consent management system consent manager consent notice Data Fiduciary Data Principal data privacy data protection DPBI DPDP Act DPDP consent DPDP Rules 2025 employment data enforcement India 2026 Indian companies marketing consent MeitY BRD Rule 3 Section 5 Section 6 Section 7 Section 9