Preparing for Registered Consent Managers

Abstract

This article is the first in a three part series called Consent Under the DPDP Act. The series takes consent as its subject, not as one obligation among several, because the Digital Personal Data Protection Act 2023 rests on consent in a way that other frameworks do not. There is no general ground equivalent to legitimate interests. Most commercial processing needs consent, and the three hardest parts of the Act all sit on or beside that requirement.

This first article deals with consent arriving from outside the organisation. The Act creates a category of entity called a Consent Manager, registered with the Data Protection Board, through which an individual can give, review, manage, and withdraw consent across many organisations from a single place. Registration opens on 13 November 2026 under Rule 4 of the Digital Personal Data Protection Rules 2025. That date is a matter of months away, and no entity holds the registration today.

The article covers what the framework establishes, where it currently stands, and what a data fiduciary has to build in order to work with a registered intermediary. That build is more demanding than it first appears. Receiving a consent record from a third party means validating it, mapping its purposes onto the purposes the organisation actually processes for, and acting on a withdrawal quickly enough to satisfy a standard the Act sets without a grace period. Architectures that reconcile consent overnight do not meet it.

The article also covers a decision some organisations face. Whether to seek registration as a Consent Manager rather than only prepare to work with one. The conditions attached to that status, including a net worth requirement and obligations of interoperability, security, and transparency, make it a commitment, not a filing. The second article in the series covers the personal data of children, and the third covers the circumstances in which the Act permits processing without consent at all.

1. What a Consent Manager Is

1.1 The role the Act creates

The Act introduces an entity that sits between individuals and the organisations holding their data. A Consent Manager is registered with the Data Protection Board and operates a platform through which an individual can give consent, look at the consent they have already given, manage it, and withdraw it, across all the organisations that participate. The individual deals with one interface instead of tracking permissions separately with every company they have ever registered with.

From the individual’s side the appeal is clear. A person who has consented to processing by forty organisations over a decade has no practical way to review those permissions or to withdraw the ones they no longer want. A single dashboard makes that possible. The Act supports this by requiring that withdrawal be as easy as giving consent, and an intermediary of this kind is one way that standard becomes achievable in practice and not only in principle.

From the organisation’s side the arrangement changes where consent comes from. An organisation that has always collected consent through its own signup flow will begin receiving consent records generated elsewhere, in a format defined by the intermediary, referring to purposes the organisation has to interpret. It will also receive withdrawals the same way, arriving without warning, requiring action. The consent record stops being something the organisation owns end to end and becomes something it participates in.

1.2 The difference from a consent tool of your own

A distinction causes regular confusion and it is worth settling early. Many organisations already run a consent management platform, meaning software that presents consent choices on their own website or application, records what the user selected, and stores the result. That software belongs to the organisation, serves only the organisation, and can be bought from any number of vendors today. It is a useful thing to have and it is not a Consent Manager in the sense the Act uses.

A Consent Manager is a registered intermediary serving individuals across many organisations. The registration is with the Board, the conditions are set by the Rules, and after 13 November 2026 an entity operating in that role without registration is in breach. An organisation cannot describe its internal consent tool as a Consent Manager, and a vendor selling consent software is not offering registration by supplying the product.

A further point separates them. An organisation controls its own consent tool completely, including when it changes, what it records, and how it presents choices. It controls none of that at an intermediary, where the presentation belongs to the platform and the individual, and the organisation receives the outcome. That shift matters for teams accustomed to designing consent flows as part of a product experience, because the flow at an intermediary is not theirs to design.

The practical consequence is that both are needed and they answer different questions. The internal platform is how an organisation collects and enforces consent for its own processing, and it should already exist ahead of the May 2027 enforcement date. The intermediary framework is an additional channel through which consent will arrive, and preparing for it means building an interface to something outside the organisation. Teams that treat the purchase of a consent product as satisfying both have addressed one and left the other.

2. Where the Framework Stands

2.1 The registration window and its conditions

The commencement schedule set by the Rules notified on 13 November 2025 runs in phases. The provisions establishing the Board and the foundational definitions took effect immediately. The Consent Manager framework, under Rule 4, takes effect twelve months later, on 13 November 2026. At eighteen months, in May 2027, the substantive obligations take effect, covering notice, consent, security safeguards, breach reporting, retention, and the rights of data principals.

Registration carries substantial conditions. An applicant has to be an Indian entity meeting a minimum net worth of two crore rupees. It has to demonstrate technical infrastructure capable of managing the full consent lifecycle, along with standards for interoperability, security, and transparency. A platform serving many organisations has to speak to all of them, and it has to be trusted by the individuals whose permissions it holds. Governance conditions apply to how the entity is directed and to the obligations it accepts toward data principals.

One condition deserves separate attention because it shapes who can realistically apply. The net worth requirement is not a filing fee. It signals that the Board expects a Consent Manager to be a substantial and durable entity, since individuals will depend on it to hold and honour their permissions across many organisations, and a platform that fails takes those records with it. An applicant should read the condition as a statement about the seriousness of the role, not as a threshold to clear.

No entity in India holds this registration at present, because the window has not opened. Until it does, the accurate statement about any product in the market is that it is consent software, however capable. Organisations evaluating vendors should note the distinction, since a claim to be a Consent Manager before the framework commences describes an intention, not a status.

2.2 The institutional position

A practical difficulty sits underneath the November date and deserves plain description. The Rules established the Data Protection Board of India from November 2025, and through the first half of 2026 the Chairperson and Members contemplated by the Act had not been appointed. Registration under Rule 4 runs to that Board. An applicant preparing to file in November faces a regulator that has to be constituted in practice before it can receive and assess applications.

The uncertainty this produces concerns sequencing, not the obligation itself. That date in the Rules is statutory. What is not yet visible is how quickly applications will be processed once the window opens, how the Board will assess the technical conditions, and whether any transitional arrangement will be made for entities already operating adjacent infrastructure. Organisations in regulated financial services have a partial precedent in the Account Aggregator framework, where consent intermediation already operates under a different regulator with published technical specifications, and entities connected to that framework should follow whether any recognition of it emerges.

For a data fiduciary that intends to work with an intermediary instead of becoming one, this institutional uncertainty changes very little. The interface work described in the next section takes months and does not depend on which entities eventually hold registration, because it depends on the organisation’s own systems being able to receive, validate, and act on a consent record from outside. Waiting for the first registered intermediary to appear before beginning that work compresses it into whatever time remains before May 2027.

3. What a Fiduciary Has to Build

3.1 Receiving and validating a consent record

The first piece of work is an interface that accepts a consent record from an intermediary and establishes that it is genuine. The organisation has to confirm which intermediary sent it, that the message has not been altered in transit, and that the individual it refers to corresponds to a person the organisation holds data about. Each of these is ordinary integration work and each has to be done before any consent arriving this way can be relied on.

The identity step is the one that causes trouble. A consent record generated at an intermediary identifies the individual by whatever reference that platform uses. The organisation identifies the same person by its own customer number, or by an email address, or by a phone number. Connecting the two requires a resolution step, and the resolution has to be reliable, because acting on a consent record matched to the wrong person creates two failures at once. Organisations that have never built identity resolution across systems, a gap described in earlier writing on readiness, will meet it again here.

Validation has a second dimension that organisations sometimes miss, which concerns scope. A consent record from an intermediary covers particular purposes for a particular individual, and the organisation should accept only what the record actually grants. Where a platform sends a broad record covering categories the organisation does not process for, no permission arises for those categories. Reading the record precisely, and rejecting or querying anything malformed instead of interpreting it generously, is part of doing this correctly.

The record itself then has to be stored in a form that supports later questions. Which intermediary supplied it, at what time, for which purposes, against which version of a notice, and in which language it was presented. The Rules require notices in English and in the languages of the Eighth Schedule to the Constitution, and a consent obtained through an intermediary carries that same requirement, which means the record has to capture the language along with everything else.

3.2 Acting on withdrawal without a delay

The demanding half of this work is withdrawal. When an individual withdraws consent at an intermediary, the organisations relying on that consent have to stop the processing it covered. The Act provides no grace period for this. An architecture that collects consent changes into a queue and applies them on a nightly cycle leaves a window in which the organisation processes personal data without a basis for it. On a busy platform that window contains real activity.

Meeting the standard means the systems that perform processing check consent state at the moment they act, rather than relying on a copy refreshed periodically. That is an architectural position with consequences. The consent state has to be available quickly enough to sit in the path of a request without slowing it. In practice that means a local store kept current by events from the interface, rather than a call out to the intermediary for every operation. Designing that correctly is a piece of engineering, and it is the piece most often deferred.

Withdrawal also has to reach further than the system that received it. Personal data held for a withdrawn purpose enters the erasure obligations. Copies in reporting stores, caches, and outside services have to be brought into line. Processors acting on the organisation’s instructions have to be told. None of this is new under the Act, and a withdrawal arriving from an intermediary makes it visible, because the organisation now has an external counterparty with a record of when the withdrawal was communicated.

3.3 Reconciliation and the evidence trail

Two parties holding a record of the same consent will occasionally disagree, and a working arrangement needs a way to resolve that. Reconciliation means periodically comparing the consent state the organisation holds against the state the intermediary holds for the same individuals, identifying differences, and correcting them under a documented rule about which record prevails in which circumstance. Organisations that have integrated with any external system of record will recognise the pattern, and the difference here is that a discrepancy has regulatory weight and not only commercial weight.

A reconciliation process also needs a defined response to a difference it finds. Some differences are timing, where a change is in flight and the two records agree an hour later. Some indicate a failed message, where a withdrawal never arrived and the organisation has been processing without a basis since. The second case is a compliance incident, not a data quality issue, and the process should be written to recognise it as one, with an escalation path and a record of what was done.

Alongside reconciliation sits the evidence trail. The organisation should be able to show, for any individual and any point in time, what consent it held, where that consent came from, and what its systems did in response to a change. Building this while the interface is built costs little. Assembling it afterward is difficult, since the events it would describe have already happened and were not recorded. Earlier writing in this area made the same point about compliance evidence generally, and it applies with force to a consent channel shared with a third party.

4. The Design Decisions This Forces

4.1 Where consent gets checked

Preparing for an external consent channel pushes an organisation toward a design decision it may have avoided. Where in the system consent gets checked. Three arrangements are common and they differ in how well they hold up. In the first, consent is recorded at signup and nothing consults the record afterward, so processing continues regardless. In the second, consent is used to filter data sets on a schedule, so a withdrawal takes effect when the next batch runs. In the third, the systems that process personal data check consent state as part of performing the operation.

Only the third arrangement satisfies a withdrawal standard with no grace period. Reaching it is easier when consent is treated as a service that other systems query instead of a column in a table each system copies. One authoritative store serves this well. It is updated by events from the intermediary interface and from the organisation’s own consent screens, and queried by the marketing platform, the analytics pipeline, the recommendation systems, and anything else acting on personal data. That gives one place to get right and one place to audit.

The work of getting the processing systems to consult it is the larger half. Each system either checks consent before acting or receives only data already filtered against it, and every integration is a separate piece of engineering with its own owner and its own timeline. An organisation counting the effort should count the systems and not the interface, because the interface to an intermediary is a defined piece of work and bringing eleven internal systems into line is not.

4.2 Purposes that mean the same thing on both sides

A subtler problem sits in the purposes themselves. Consent under the Act is specific to a purpose, and a consent record arriving from an intermediary names the purposes the individual agreed to. Those names have to correspond to the processing the organisation actually performs. If the intermediary carries a purpose called service communications and the organisation distinguishes between transactional notifications, service updates, and product announcements, somebody has to decide which of the three the incoming consent covers.

Getting this wrong produces errors in both directions. An organisation that reads an incoming purpose too broadly processes without a basis. One that reads it too narrowly withholds a service the individual agreed to receive, which the individual experiences as the system not working. The mapping therefore needs to be decided deliberately, written down, and reviewed when either side changes its purpose definitions, and not settled by whoever writes the integration.

This connects to a piece of internal work that has value regardless of the intermediary framework. A register of the purposes for which the organisation processes personal data. Many organisations do not hold one, and the purposes exist implicitly in what each system does. A register that names each purpose, describes it, and records which systems act on it is the thing an incoming consent record maps onto. Building it is a prerequisite for this integration and it also serves the notice obligations and the record of processing activities the Act requires.

5. Deciding Your Position

5.1 Whether to seek registration

A small number of organisations will consider registering as a Consent Manager instead of only interfacing with one. The status is available to Indian entities meeting the net worth condition and the technical and governance requirements, and it carries a defined role in a framework that every data fiduciary in the country will eventually touch. For an entity already operating consent infrastructure at scale, or one positioned in financial services alongside existing consent intermediation, the question is a real one.

The commitment should be assessed as an operating business and not as a registration. A Consent Manager serves data principals directly, holds their consent records, has to be interoperable with many fiduciaries, and carries obligations of security and transparency that the Board will assess. The net worth condition indicates the seriousness with which the framework treats the role. An organisation weighing this should cost the platform, the ongoing compliance, and the support obligation to individuals, and compare that against what the position is worth to it commercially.

There is a middle position that suits some organisations. Rather than seeking registration, an entity with strong consent infrastructure can offer that capability to others as software, leaving the registered intermediary role to whoever takes it on. That keeps the commercial benefit of the capability without the obligations attached to the status. Firms already selling consent software in India are in this position, and the distinction between what they sell and what registration confers should be stated clearly to their own customers.

For most organisations the answer is straightforward and the question does not need long consideration. The work that matters is preparation to receive consent from an intermediary, which the previous sections describe, and that work is required whether or not the organisation ever considers registration.

5.2 What to do before the window opens

The sequence available between now and the enforcement date is clear enough to act on. Build the purpose register, since everything else depends on it and it serves several obligations at once. Establish a single authoritative consent store with the lifecycle the Act requires, including the versioned notices consent is bound to and the languages in which they were presented. Bring the processing systems to the point where they consult that store instead of acting on their own copies. Build identity resolution so that a consent record referring to an individual can be matched reliably to the organisation’s own records.

With those in place, the interface to an intermediary becomes a bounded piece of work and not a programme. It accepts records, validates them, translates purposes through a documented mapping, writes to the consent store, and triggers the same downstream behaviour that an internal consent change triggers. An organisation that has done the internal work can add that interface when the first registered intermediaries appear. An organisation that has not will be attempting both at once, against a date that does not move.

The second article in this series turns to the hardest form of consent under the Act. Consent for the personal data of a child, where the organisation has to establish age and obtain a verifiable parent, then refrain from processing the Act forbids regardless of any consent given.

Conclusion

The Act creates a registered intermediary through which individuals will give, review, and withdraw consent across many organisations from one place, with registration opening under Rule 4 on 13 November 2026 and no entity holding that status today. The framework is separate from the consent software an organisation runs for itself, and the two answer different questions. Registration is conditional on an Indian entity, a net worth of two crore rupees, and demonstrated capability across the consent lifecycle with standards for interoperability, security, and transparency. Through the first half of 2026 the Board to which applications run had not been fully constituted, which leaves the sequencing uncertain while leaving the statutory date in place.

For a data fiduciary the preparation is largely internal and it takes months. A register of the purposes the organisation processes for. A single authoritative consent store holding the lifecycle, the notice versions, and the languages. Processing systems that consult that store as they act rather than working from periodic copies, since a withdrawal standard with no grace period rules out overnight reconciliation. Identity resolution reliable enough to match an incoming record to the right person. A documented mapping between the purposes an intermediary names and the processing the organisation performs. An evidence trail built while the systems are built. Organisations that complete this can add the external interface as a defined piece of work, and organisations that defer it will meet both at once before May 2027.