A piece of privacy infrastructure no other major regime has built
Most data protection laws regulate consent. India is building infrastructure for it.
Under the Digital Personal Data Protection Act, 2023 and the DPDP Rules notified on 14 November 2025, a Consent Manager is a registered platform through which a Data Principal can give, manage, review and withdraw consent — across every Data Fiduciary they deal with, from one place. The framework is being operationalised between June and August 2026, built on interoperable APIs.
If you run privacy or security for an Indian company, this is not an abstract policy development. It changes the technical shape of your consent architecture, and the window to prepare is the one we are in right now: soft enforcement ends in November 2026, and hard enforcement of the full DPDPA obligation set arrives on 13 May 2027.
What a Consent Manager actually does
Think of the model in three roles:
- The Data Principal — the individual — gets a single pane to see which organisations hold consent for what, and to withdraw any of it without hunting through apps and settings pages.
- The Consent Manager — a registered intermediary accountable to the Data Protection Board — transmits consent, manages its lifecycle and routes withdrawal signals.
- The Data Fiduciary — you — must be able to receive consent artefacts from Consent Managers, act on them, and honour withdrawals when they arrive through the same channel.
The word doing the heavy lifting is interoperable. The framework is API-based by design, which means consent stops being something that only lives inside your sign-up flow and your CRM. It becomes a signal that can originate, change and terminate outside your systems entirely — and your obligation is to keep up with it.
Why the regulator cares so much about consent mechanics
Consent is the DPDPA's centre of gravity. Unlike GDPR, the Act has no legitimate-interests equivalent for most processing — consent is the primary lawful basis, so the integrity of consent mechanics carries the whole regime.
The enforcement record already reflects this. The first Data Protection Board actions, in Q1 2026, hit app developers over invalid consent — during the soft-enforcement window, before any of the headline deadlines. The Board went after consent quality first because everything else depends on it.
The bar the Act sets is specific:
- Consent must be free, specific, informed, unconditional and unambiguous, given by clear affirmative action.
- Withdrawal must be as easy as giving consent. This is the requirement the Consent Manager framework mechanically enforces — a withdrawal signal arriving via API does not care how many screens your retention flow has.
- Notices backing consent must be available in all 22 scheduled languages.
- Children's data requires verifiable parental consent, and behavioural advertising to minors is prohibited.
What Data Fiduciaries need to build
Between now and the framework going live in August 2026, four workstreams matter.
1. A consent registry you actually trust
Before you can interoperate with anyone, you need a single authoritative record of consent inside your own walls: who consented, to which purposes, against which notice version, in which language, when, and whether it was withdrawn. Most organisations discover their consent state is smeared across a marketing platform, a mobile backend and a data warehouse, with no single source of truth. Consolidating that is step one — an API integration on top of inconsistent records just propagates the inconsistency faster.
2. Integration readiness
When the interoperable APIs go live between June and August 2026, you need endpoints and processing logic that can ingest consent artefacts and withdrawal signals from registered Consent Managers. Scope this as a real engineering project: identity matching (is this withdrawal from the same person as this account?), purpose mapping (their taxonomy to your processing activities) and propagation (the withdrawal must actually reach the systems doing the processing).
3. Downstream enforcement of withdrawal
Honouring a withdrawal is harder than recording it. The signal has to switch off processing in your analytics stack, your marketing automation, your data pipelines and at your processors. This is where a consent registry needs to connect to your processing inventory — your ROPA — so a withdrawal maps to a concrete list of systems to act on. The ROPA and PIA workflows in Privacy Management are operational today and are the natural place that mapping lives.
4. Evidence
When the Board asks how you handled a withdrawal received on a given date, you need a timestamped trail: signal received, identity matched, systems updated, processors instructed. Treat consent events like incident events — logged, attributable and reportable. Notice versions and consent text belong under proper version control in Document Management, because a consent record is only as defensible as the notice it points to.
The timeline pressure behind the framework
The Consent Manager rollout sits inside a tight enforcement sequence:
- June–August 2026 — framework operationalised, interoperable APIs live.
- November 2026 — soft-enforcement window ends; the DPB shifts to active supervision and begins scrutinising legacy-data consent. Historical datasets need a defensible consent position: fresh consent, anonymisation or deletion, documented per dataset.
- 13 May 2027 — hard enforcement of the full obligation set: consent, notices, security safeguards, breach protocol, DSR infrastructure, SDF obligations, DPIAs and DPOs.
The stakes are stated plainly in the penalty schedule: up to ₹250 crore per breach category, stacking across categories, with the top tier attached to failure of reasonable security safeguards. Consent failures and safeguard failures from the same incident are separate categories — they add, not merge.
It is also worth remembering that consent is one obligation among many. A breach still has to be notified to the Data Protection Board regardless of risk threshold, with the separate CERT-In 6-hour cyber incident duty running in parallel — workflows that live in Incident Management rather than your consent stack. And the people operating all of this need to understand it, which is what DPDPA-specific modules in Security Awareness Training are for, verified periodically through Audit Management.
What this means for product and engineering teams
Privacy teams tend to read the Consent Manager framework as a compliance topic. It is at least half an engineering topic, and the teams that staff it that way move faster.
Consent becomes an event stream, not a database column. Today, most systems model consent as a boolean set at sign-up. Under the framework, consent is a lifecycle: granted, modified, withdrawn — possibly through a channel you do not control. Your data model needs to carry purpose-level granularity and history, not a single flag.
Withdrawal latency becomes a measurable obligation. When a withdrawal signal arrives via API, the gap between receipt and actual cessation of processing is observable — by you, and potentially in evidence. Pipelines that sync consent state nightly to downstream systems were tolerable when withdrawal meant an email to support; they look very different when the timestamp trail is machine-precise.
Purpose taxonomies need reconciliation. A Consent Manager expresses consent against purposes; your systems process data for purposes described in your ROPA. If those two vocabularies do not map cleanly, every incoming signal becomes a manual interpretation exercise. Settle the mapping before integration, not during.
None of this is exotic engineering, but all of it takes calendar time — which is exactly the resource the June–August 2026 operationalisation window limits.
The build-vs-buy question, honestly
The market response to this framework has been a wave of DPDPA point solutions, mostly consent-management-focused, pricing at ₹15–40 lakh per year. For some organisations that is the right call. But note what you are buying: one obligation's tooling, at a price comparable to a platform that also runs your DSRs, ROPA, breach clocks, notices, training and audits.
Our position is to treat consent as one module of a privacy operation, not the whole operation. The Compliance Enablers DPDPA Operations Suite — consent registry, DSR SLA clocks and SDF obligation tracker — is rolling out ahead of the November 2026 deadline, on top of the privacy, incident, document, training and audit modules that are operational today.
How to prepare this quarter
- Consolidate consent records into a single authoritative registry.
- Fix any consent flow that would not survive Board scrutiny — that risk is live now, as the Q1 2026 actions showed.
- Scope the Consent Manager API integration with engineering before the June–August window.
- Map consent purposes to your ROPA so withdrawals propagate to real systems.
- Decide your legacy-data position before November 2026.
For the full obligation picture beyond consent, work through the DPDPA framework guide. If you want to see how the consent registry, DSR clocks and SDF tracker fit your environment, book a demo — bring your current consent flow and we will pressure-test it together.
This is general information, not legal advice.