Preparing for registered Consent Managers

The Digital Personal Data Protection Act, 2023 leans on consent more heavily than many other data protection laws. Processing without consent is allowed only under the legitimate uses in section 7, which are a closed list: data a person voluntarily provided for a specified purpose, State subsidies and functions, legal obligations and court orders, medical emergencies, disasters, employment and a few others. There is no general ground of the "legitimate interests" kind found in European law. Most commercial processing therefore needs consent, and the three hardest parts of the Act sit on or next to that requirement.

Some of that consent will arrive from outside your organisation. The Act creates a Consent Manager: an entity registered with the Data Protection Board of India that runs a platform where a person can give, review, manage and withdraw consent across many organisations from one place. Under Rule 4 and the First Schedule of the DPDP Rules, 2025, the Consent Manager provisions commence around 13 November 2026, one year after notification. The DPDP Rules, 2025 were notified on 13 November 2025; check for later amendments. No entity holds the registration yet.

A Data Fiduciary has to build specific capabilities to work with a registered intermediary, and that build is more demanding than it first looks. Receiving a consent record from a third party means checking it, mapping its purposes onto the purposes you actually process for, and acting on a withdrawal quickly. Architectures that reconcile consent overnight struggle to meet that standard.

A few organisations also face a separate decision: whether to seek registration as a Consent Manager themselves. The conditions attached, including a net worth requirement and duties of interoperability, security and transparency, make that a business commitment with a filing attached.

This is not legal advice; take advice on your own facts.

What a Consent Manager is

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 Board and runs a platform through which a person can give consent, look at the consent already given, manage it and withdraw it, across every organisation that participates. The person deals with one interface and stops tracking permissions separately with every company they have ever signed up with.

Picture a salaried professional in Bengaluru. Over ten years she has agreed to data processing by a bank, two insurers, a broker, three lending apps, a telecom operator, several shopping apps and a hospital's patient portal. She has no practical way to see all those permissions in one place, let alone withdraw the ones she no longer wants. A single dashboard makes that possible. The Act already requires that withdrawing consent be as easy as giving it, and an intermediary of this kind is one way that standard becomes real in practice.

For the organisation, the arrangement changes where consent comes from. A company that has always collected consent through its own signup screen will start receiving consent records created somewhere else, in a format defined by the intermediary, naming purposes the company has to interpret. Withdrawals will arrive the same way, without warning, and they need action. Consent becomes a process you share with an outside party.

How it differs from your own consent tool

This distinction causes regular confusion. Many companies already run consent management software: it shows choices on their website or app, records what the user picked and stores the result. That software belongs to the company, serves only the company, and can be bought from many vendors today. It is useful, and it is a different thing from a Consent Manager in the sense the Act uses.

A Consent Manager is a registered intermediary serving people across many organisations. Registration is with the Board, on conditions set by the Rules, and once the provisions commence an entity acting in that role without registration is in breach. Calling your internal tool a Consent Manager does not make it one, and a vendor selling consent software is not offering registration by supplying the product.

Control separates them too. You control your own consent tool completely: when it changes, what it records and how it presents choices. You control none of that at an intermediary, where the screens belong to the platform and the person, and you receive the outcome. Product teams used to designing consent screens as part of the user experience should note this, because the flow at an intermediary is outside their design.

The practical consequence is that you need both, and they answer different questions. Your own consent handling is how you collect and enforce consent for your processing, and it should be ready before most Data Fiduciary duties apply around 13 May 2027, as notified, unless amended. The intermediary is an extra channel through which consent will arrive, and preparing for it means building an interface to something outside your walls. Teams that treat the purchase of a consent product as covering both have dealt with one and left the other open.

Where the framework stands

The registration window and its conditions

The Rules commence in phases. The definitions and the provisions setting up the Board took effect on notification in November 2025. The Consent Manager framework under Rule 4 follows twelve months later, around 13 November 2026. At eighteen months, around 13 May 2027, most duties of Data Fiduciaries take effect, covering notice, security safeguards, breach intimation, erasure, children's data and the additional duties of Significant Data Fiduciaries. A proposal in January 2026 to shorten that timeline was not notified, so the published dates stand.

Registration carries real conditions. A Consent Manager must be a company incorporated in India with a net worth of at least 2 crore rupees. It must show the technical, operational and financial capacity to run the full consent lifecycle, with standards for interoperability, security and transparency. A platform serving many organisations has to talk to all of them, and it has to be trusted by the people whose permissions it holds. Governance conditions cover how the company is directed, how conflicts of interest with Data Fiduciaries are handled, and the duties it accepts towards Data Principals, including keeping records of consents given, refused and withdrawn.

The net worth condition shapes who can realistically apply. Read it as a statement about the role. The Board expects a Consent Manager to be a substantial and lasting entity, since people will depend on it to hold and honour their permissions across many organisations, and a platform that collapses takes those records with it.

Until registrations are actually granted, any product on the market is consent software, however capable. Organisations evaluating vendors should keep that in mind. When a vendor describes itself as a Consent Manager before the framework commences, that describes an intention.

The institutional position

There is a practical difficulty under the November date. The Rules set up the Data Protection Board of India from November 2025. Registration under Rule 4 runs to that Board, and how quickly it will receive and assess applications in the first months is not yet known. An applicant preparing to file in November should allow for that.

The uncertainty this creates is about sequencing. The date in the Rules is set. 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 running similar infrastructure.

Financial services firms have a partial reference point. The Reserve Bank of India's Account Aggregator framework already intermediates consent for financial data, under a different regulator and with published technical specifications. Firms connected to it should watch whether the two frameworks are linked in any way, and whether experience from one carries into the other.

For a company that plans to work with an intermediary and has no wish to become one, this uncertainty changes very little. The interface work described next takes months, and it depends on your own systems being able to receive, check and act on a consent record from outside. It does not depend on which entities end up registered. Waiting for the first registered intermediary before starting squeezes that work into whatever time remains before May 2027.

What a Data Fiduciary has to build

Receiving and checking a consent record

The first piece of work is an interface that accepts a consent record from an intermediary and confirms it is genuine. You need to know which intermediary sent it, that the message was not altered on the way, and that the person it refers to is someone you actually hold 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.

Identity is the step that causes trouble. A record created at an intermediary identifies the person by whatever reference that platform uses. You identify the same person by a customer number, an email address or a mobile number. Linking the two needs a matching step, and the matching has to be reliable, because acting on a consent record matched to the wrong person creates two failures at once: you process one person's data without consent and you ignore another person's choice. Companies that never built identity matching across their own systems, a gap that shows up in most readiness work, will meet the problem again here.

Checking has a second dimension that is easy to miss, which is scope. A record from an intermediary covers particular purposes for a particular person, and you should accept only what the record actually grants. If a platform sends a broad record naming categories you do not process for, no permission arises for those categories. Read the record precisely, and reject or query anything malformed. Interpreting it generously is where errors start.

The record 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 your notice, and in which language the notice was shown. The Act gives a person the option of reading a notice in English or in any language listed in the Eighth Schedule to the Constitution. A consent obtained through an intermediary carries the same expectation, so the record has to capture the language along with everything else.

Acting on withdrawal promptly

Withdrawal is the demanding half. When a person withdraws consent at an intermediary, the organisations relying on that consent have to stop the processing it covered. Section 6 requires you, and your Data Processors, to cease processing within a reasonable time. The Act does not define that period, and nobody should count on it being generous. A design that queues consent changes and applies them on a nightly cycle leaves a window in which you process personal data without a basis, and on a busy platform that window contains real activity: messages sent, profiles updated, data shared. A design that applies a withdrawal within seconds or minutes is far easier to defend.

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

Withdrawal also has to travel further than the system that received it. Personal data held for a withdrawn purpose enters your erasure duties, unless a law requires you to keep it. Copies in reporting databases, caches and outside services need bringing into line. Processors acting on your instructions need to be told, and they need to act. None of this is new under the Act. A withdrawal arriving from an intermediary simply makes it visible, because an outside party now holds a record of exactly when the withdrawal was sent to you.

Reconciliation and the evidence trail

Two parties holding a record of the same consent will sometimes disagree, and a working arrangement needs a way to settle that. Reconciliation means regularly comparing the consent state you hold with the state the intermediary holds for the same people, finding differences and fixing them under a written rule about which record wins in which situation. Anyone who has integrated with an outside system of record will recognise the pattern. The difference here is that a mismatch carries regulatory weight as well as commercial weight.

A reconciliation process also needs a defined response to each kind of difference. Some differences are timing: a change is in flight and the two records agree an hour later. Some point to a failed message: a withdrawal never arrived, and you have been processing without a basis since. The second case is a compliance incident, and the process should be written to recognise it as one, with an escalation path, a named owner and a record of what was done about it. Treating it as a data quality ticket in someone's backlog misses the point.

Alongside reconciliation sits the evidence trail. For any person and any point in time, you should be able to show what consent you held, where it came from, and what your systems did when it changed. Building this while the interface is built costs little. Assembling it afterwards is close to impossible, because the events it would describe have already happened and nobody recorded them. That applies to compliance evidence generally, and it applies with extra force to a consent channel you share with a third party who keeps its own records.

The design decisions this forces

Where consent gets checked

Preparing for an outside consent channel pushes you towards a design decision many organisations have avoided: where in your systems consent actually gets checked. Three arrangements are common, and they hold up very differently.

• In the first, consent is recorded at signup and nothing consults the record afterwards, so processing carries on regardless of what the person later chose.
• 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 each operation.

Only the third arrangement reliably meets the standard of ceasing within a reasonable time. Reaching it is much easier when consent is treated as a service that other systems query, and much harder when it is a column in a table that every system copies. One authoritative consent store serves this well. It is updated by events from the intermediary interface and from your own consent screens, and it is queried by the marketing platform, the analytics pipeline, the recommendation engine, the WhatsApp messaging tool and anything else that acts on personal data. That gives you one place to get right and one place to audit.

Getting the processing systems to consult it is the larger half of the work. Each system either checks consent before acting or receives only data already filtered against it, and every one of those integrations is a separate piece of engineering with its own owner and its own timeline. When you estimate the effort, count the systems. Connecting to an intermediary is a defined job. Bringing eleven internal systems into line is the bigger one.

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 record arriving from an intermediary names the purposes the person agreed to. Those names have to correspond to the processing you actually perform. Take a general insurer. If the intermediary carries a purpose called "service communications", and the insurer separates policy renewal reminders, claim status updates and new product offers, someone has to decide which of the three the incoming consent covers.

Errors run in both directions. Read an incoming purpose too broadly and you process without a basis. Read it too narrowly and you withhold a service the person agreed to receive, which they experience as your system not working. So the mapping should be decided deliberately, written down, and reviewed whenever either side changes its purpose definitions. Leaving it to whoever happens to write the integration is how the wrong reading gets built in.

This connects to a piece of internal work that has value whatever happens with intermediaries: a register of the purposes for which you process personal data. Many organisations do not hold one, and their purposes exist only implicitly in what each system does. A register that names each purpose, describes it in plain words and records which systems act on it is what an incoming consent record maps onto. Building it is a prerequisite for this integration, and it also feeds your notices and your records of processing.

Deciding your position

Whether to seek registration

A small number of organisations will consider registering as a Consent Manager themselves. The status is open to Indian companies that meet 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 a company already running consent infrastructure at scale, or one working alongside existing consent intermediation in financial services, the question is a fair one.

Assess it as an operating business. A Consent Manager serves Data Principals directly, holds their consent records, has to work with many Data Fiduciaries, and carries duties of security and transparency that the Board will examine. It must also act in a fiduciary capacity towards the people it serves and manage conflicts of interest with the organisations on its platform. Cost the platform, the ongoing compliance and the support load for individuals who will call when something goes wrong, and compare that with what the position is worth to you commercially.

There is a middle path that suits some organisations. A company with strong consent infrastructure can offer that capability to others as software and leave the registered role to whoever takes it on. That keeps the commercial benefit of the capability without the duties attached to the status. Firms already selling consent software in India are in this position, and they should state clearly to their own customers what they sell and what registration would confer.

Most organisations will not seek registration. Their priority is preparing to receive consent from an intermediary, work that is needed whether or not registration is ever considered.

What to do before the window opens

The order of work between now and May 2027 is clear enough to act on:

1. Build the purpose register. Everything else depends on it, and it serves several duties at once.
2. Set up one authoritative consent store with the full lifecycle the Act requires, linked to the notice versions each consent was given against and the languages in which those notices were shown.
3. Bring your processing systems to the point where they consult that store as they act, and stop working from their own copies.
4. Build identity matching, so a record about a person reliably reaches your own records for that person.
5. Design reconciliation and the evidence trail alongside the interface, while the people who understand it are still on the project.

With those in place, the interface to an intermediary becomes a bounded piece of work. It accepts records, checks them, translates purposes through your written 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.

Summary

The Act creates a registered intermediary through which people will give, review and withdraw consent across many organisations from one place. The Consent Manager provisions under Rule 4 commence around 13 November 2026, and no entity holds the status today. The framework is separate from the consent software an organisation runs for itself, and you need both. Registration requires a company incorporated in India with a net worth of at least 2 crore rupees, and demonstrated capability across the consent lifecycle, with standards for interoperability, security and transparency. The pace at which the Board will process applications is not yet known, while the date itself stands.

For a Data Fiduciary, the preparation is mostly internal and it takes months:

• a register of the purposes you process personal data for;
• one authoritative consent store holding the lifecycle, the notice versions and the languages;
• processing systems that consult that store as they act, since withdrawal has to take effect within a reasonable time and overnight reconciliation is hard to defend;
• identity matching reliable enough to link an incoming record to the right person;
• a written mapping between the purposes an intermediary names and the processing you perform;
• an evidence trail built while the systems are built.

Organisations that finish this can add the outside interface as a defined piece of work. Organisations that defer it will meet both at once before May 2027.

TrustOS keeps consent records tamper evident and tied to purposes, notice versions and languages, which gives this work a place to run and its evidence a place to live. The purpose register, the mapping decisions and the identity matching are choices your teams have to make, and Code Colonies consulting can help design and build them inside your systems. For the basics of the framework, see the guide to Consent Managers. Consent for children's data is covered in handling the personal data of children.