India's DPDP Consent Manager Deadline: What Your Website Needs Before 13 November 2026

The dates, in order

Three dates govern DPDP planning. 13 November 2026 is when Rule 4, the Consent Manager framework, is scheduled to take effect. Through 2026, enforcement is widely expected to be soft — guidance and warnings. 13 May 2027 ends the eighteen-month transition, when the remaining substantive provisions and operational rules apply and enforcement becomes real.

This guide is a practical summary for business owners, not legal advice. Where your processing is unusual or high-volume, the cost of an hour with a data protection lawyer is trivial against the exposure.

What a Consent Manager actually is

A Consent Manager is a registered intermediary that gives people one interoperable place to grant, review, and withdraw consent across many services, rather than hunting through dozens of separate account settings.

The concept is genuinely user-friendly and structurally significant. Consent stops being something buried in each company's preferences page and becomes something a person manages centrally and can revoke wholesale. For businesses, the practical implication is that withdrawal will get easier for users and therefore more frequent, and the systems on your side need to handle it cleanly rather than treating it as an exception.

One honest caveat about the current state. Reporting through 2026 has repeatedly flagged that the registration machinery for Consent Managers was still being operationalised as the date approached, which introduces real uncertainty about how much of the framework will be functioning on day one. Plan for the obligations, not for the infrastructure — the underlying consent duties bind you whether or not the registry is populated.

What binds an ordinary business

Most Indian businesses reading this are not going to become Consent Managers and will not need to integrate with one immediately. What they do need is for the consent underneath to be valid, because that requirement does not wait for the framework.

Under the DPDP Act, consent must be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action, and as easy to withdraw as it was to give. Read against a typical Indian business website, that rules out several things which are currently near-universal:

• Pre-ticked boxes. A checkbox already selected is not a clear affirmative action.
• Bundled consent. One box covering service delivery, marketing emails, WhatsApp promotions, and sharing with partners is not specific.
• Consent as a condition of service. Requiring marketing consent to complete a purchase fails the unconditional test where the marketing is not necessary to deliver the service.
• Withdrawal that is harder than signing up. One-click opt-in and an email-us-to-unsubscribe exit is exactly the asymmetry the Act targets.
• No record. If you cannot evidence what a person was shown and what they agreed to, you cannot demonstrate consent, and in a dispute that is equivalent to not having it.

Notice: the part that has to be readable

The notice accompanying consent has to state what personal data you are collecting, the purpose for each category, how the person exercises their rights, and how to complain to the Data Protection Board. It must be available in English and in the Eighth Schedule languages, which for most businesses means a genuine translation workflow rather than a plugin.

The itemised requirement is the one that breaks existing privacy policies. A single paragraph saying data is collected to improve services does not survive it. Each purpose needs to be listed and matched to the data it justifies, which in practice forces the data inventory most businesses have never done.

Legacy data: where most sites will fail

A compliance focus during this period is legacy data — personal data collected before the framework, which is expected to be supported by notice and consent consistent with the Act.

For most businesses this is the largest piece of work, and it is not a website change at all. The typical situation is a database assembled over years from webforms, trade shows, WhatsApp enquiries, imported spreadsheets, and a CRM nobody has audited, with no reliable record of what any given person was told or agreed to.

The remedy is a re-consent exercise: issue fresh notice to the existing base, capture affirmative consent, and stop processing for those who do not respond or decline. Everyone who has run one reports the same two findings — response rates are low, and the list that remains is far more valuable than the one that preceded it, because it consists of people who actively chose to hear from you.

Start this early. A re-consent campaign runs over months, not weeks, and doing it under enforcement pressure produces a rushed version that satisfies nobody.

Where the website work actually lands

Concretely, on a normal business site:

Forms. Separate, unticked consent for each distinct purpose. Contact form consent covers replying to the enquiry; it does not cover a monthly newsletter, and it certainly does not cover WhatsApp broadcasts.

A consent record. Store the timestamp, the notice version shown, and what was agreed, against the person. This is a small database change that takes an afternoon before launch and is painful to retrofit across years of records.

A withdrawal route that works end to end. A preferences page that unsubscribes someone from your email tool but leaves them in the WhatsApp broadcast list and the CRM's automation is not withdrawal, it is a partial one, and it is the most common failure we find in audits.

Analytics and pixels. Tracking scripts that fire before consent are the single most frequent finding. If your tag manager loads the advertising pixels on page load, no banner is fixing that. The mechanics of doing this properly across GDPR and DPDP are in our guide to cookie consent and website privacy compliance.

Children's data. If under-eighteens can plausibly use your service, verifiable parental consent obligations apply and behavioural advertising to them is restricted. This is strict by international standards and worth specific advice if it touches you.

What to do now and what to defer

Do now, because they take longest and are useful regardless: the data inventory, the consent and notice rebuild on forms, consent record-keeping, a genuine withdrawal route, and planning the legacy re-consent campaign.

Defer sensibly: integrating with a specific Consent Manager, which cannot be finalised while the registry is still being stood up, and any vendor tooling sold specifically as Consent Manager integration. Buying that now means buying against an unfinished specification.

A useful way to see the split: nothing in the first list depends on the framework's infrastructure existing. Every item is a requirement of valid consent on its own terms and would be worth doing if the deadline moved again.

Cost, realistically

For a small business site with a handful of forms, rebuilding consent capture, adding consent records, and wiring a working withdrawal route is typically ₹40,000 to ₹1,00,000 of implementation, depending on how many downstream systems have to be connected. A privacy policy and notice rewritten properly against your actual processing, in the required languages, is usually ₹25,000 to ₹75,000 including translation.

The legacy re-consent campaign is the variable one, because its cost is mostly in the data cleanup preceding it rather than the emails. For a database of any real size, budget for weeks of work rather than days.

Against a penalty ceiling of ₹250 crore for security failures — a maximum applied to the facts rather than a standard fine, and unlikely to land on a small business — the more realistic argument for doing this well is not the fine. It is that the alternative is discovering during a dispute that you cannot evidence consent for anyone. Send us your site and we will tell you which of these you already satisfy.