A Consent Manager goes live, and one assumption can start spreading internally: “Now the Consent Manager owns consent compliance.”
That assumption is where governance problems begin.
Under India’s Digital Personal Data Protection framework, a Consent Manager and a Data Fiduciary perform different roles. The Consent Manager helps a Data Principal give, manage, review and withdraw consent through a registered, interoperable platform. The Data Fiduciary remains the entity that determines why personal data is processed and how that processing is carried out.
For enterprises preparing to work with a Consent Manager in India, this distinction is not academic. It determines who owns the consent interface, who owns processing decisions, who keeps which records, and who must act when consent changes.
The practical question is therefore not whether both parties are involved.
It is where one role ends and the other begins.
The legal roles are different from the start
The Digital Personal Data Protection Act, 2023 defines a Consent Manager as a person registered with the Data Protection Board that acts as a single point of contact to enable a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform.
The Act defines a Data Fiduciary differently. It is the person who, alone or together with others, determines the purpose and means of processing personal data.
That distinction is the foundation for the rest of the operating model.
The Consent Manager facilitates the Data Principal’s consent decisions.
The Data Fiduciary decides why processing takes place and how its own processing environment operates.
Those responsibilities can interact closely. They should not be collapsed into one role.
Rule 4 gives the Consent Manager real obligations
The final Digital Personal Data Protection Rules, 2025 set out specific obligations for registered Consent Managers under Rule 4 and the First Schedule.
These are not superficial administrative duties.
A registered Consent Manager must, among other things, enable Data Principals to give consent to onboarded Data Fiduciaries through its platform. It must also maintain specified records, including records of consents given, denied or withdrawn, notices connected with consent requests, and certain records relating to the sharing of personal data.
The Rules also provide for Data Principal access to those records and require the Consent Manager to maintain them for the prescribed period.
That gives the Consent Manager a significant governance role.
But it still does not make the Consent Manager responsible for every processing decision taken by the Data Fiduciary.
The easiest way to understand the boundary
The cleanest distinction is between facilitating consent and controlling processing.
| Activity | Consent Manager | Data Fiduciary |
|---|---|---|
| Enable a Data Principal to give, manage, review or withdraw consent | Core role | Must be able to receive and act on the relevant consent state |
| Decide why personal data will be processed | No | Core responsibility |
| Decide how processing will be carried out | No | Core responsibility |
| Maintain the Consent Manager’s prescribed consent records | Yes | Maintains its own relevant operational and processing evidence |
| Provide Data Principal access to Consent Manager records | Yes | Handles its own Data Principal interactions and processing obligations |
| Apply withdrawal to internal systems | Facilitates the consent change | Data Fiduciary responsibility |
| Cause relevant processors to stop consent-dependent processing | Not the general downstream owner | Data Fiduciary responsibility |
| Secure the Consent Manager platform | Consent Manager responsibility | Separate responsibility for enterprise systems and processors |
| Meet Consent Manager conflict-of-interest and audit obligations | Yes | Separate governance duties apply |
| Decide whether processing can continue on another lawful basis | No | Data Fiduciary/legal governance responsibility |
The legal definitions and Rule 4 obligations come from the Act and Rules. The practical handoff between the two parties is where enterprises need to make their own operating model explicit.
A Consent Manager can carry the decision. It does not execute your internal processing.
Consider a retailer that has obtained a customer’s consent for promotional communications.
Later, the customer withdraws that consent through a Consent Manager.
The Consent Manager’s role is to make that withdrawal possible through its platform and maintain the relevant records required for its role.
Once that withdrawal reaches the retailer, the retailer still has work to do.
The changed state may need to reach:
- the CRM;
- the marketing platform;
- the customer data platform;
- campaign tools;
- external processors.
The Consent Manager does not automatically control those systems.
That responsibility remains with the Data Fiduciary.
This is why AquaConsento’s separate analysis of how consent withdrawals should move through downstream systems treats propagation as an enterprise execution problem rather than merely a consent-interface problem.
A valid withdrawal can be delivered correctly and still be implemented badly.
That is exactly why the role boundary matters.
The Consent Manager does not decide the business purpose
Another common misunderstanding appears when teams start treating the Consent Manager as if it were deciding whether the enterprise should process personal data.
It is not.
The Data Fiduciary determines the purpose and means of processing.
If an organisation processes personal data for marketing, service delivery, fraud prevention, analytics or another business purpose, those processing decisions remain part of the Data Fiduciary’s governance environment.
Where consent is the relevant basis, the Consent Manager can help the Data Principal manage that consent.
But it does not replace the organisation’s own Privacy, Legal, Product and Engineering decision-making.
That means the Consent Manager should not be treated as an outsourcing mechanism for internal accountability.
It changes how consent may be managed.
It does not remove the Data Fiduciary’s role in deciding and controlling processing.
Consent records and processing evidence are not the same thing
This distinction becomes especially important during audits and investigations.
The First Schedule requires the Consent Manager to maintain records of consent activity relevant to its role.
Suppose that record shows:
Consent withdrawn at 10:14 a.m.
That tells the enterprise when the Data Principal changed their decision.
It does not necessarily show when the retailer’s marketing platform stopped using the permission.
Those are two different facts.
The Consent Manager record proves the consent event.
The Data Fiduciary may still need to prove the processing outcome.
A strong internal evidence trail therefore connects the external event to what happened inside the enterprise:
consent changed → event received → purpose identified → systems updated → processors addressed → completion confirmed
That exact sequence is an operational model, not statutory wording.
But it gives the organisation a practical way to demonstrate that the consent event had the intended effect.
For teams designing these controls, a purpose-level consent lifecycle can help keep the user’s permission state connected to the enterprise processing that depends on it.
Interoperability does not transfer accountability
The DPDP framework expects Consent Managers to operate through an interoperable platform.
That makes integration a real enterprise concern.
A Data Fiduciary may need to receive consent events, resolve the Data Principal, match the relevant purpose and apply the changed state across its own environment.
But interoperability should not be misunderstood as a transfer of responsibility.
The Consent Manager has its own obligations around platform operation, records, security, conflict controls and audit.
The enterprise has its own obligations around processing, system behaviour, downstream processors and evidence.
The connection between them has to work.
The accountability boundaries still remain separate.
That is the practical significance of India’s DPDP Consent Manager framework. The important implementation question is not only whether an organisation can connect to a Consent Manager, but whether the governance handoff remains clear after that connection is live.
Where enterprises usually get confused
The legal definitions are not especially difficult.
The operating model is.
“The Consent Manager has the consent record, so we do not need one”
That is too simplistic.
The Consent Manager maintains the records required for its regulated role.
The Data Fiduciary may still need its own operational evidence showing how that consent state affected processing across systems and processors.
“The Consent Manager processed the withdrawal, so our systems are compliant”
Not necessarily.
The withdrawal still has to affect the processing environment that relied on the consent.
The enterprise must be able to show that the changed state reached the systems that actually use it.
“Interoperability means the Consent Manager owns the downstream workflow”
It does not.
Interoperability enables systems to exchange the relevant information or events.
The Data Fiduciary still owns the processing taking place inside its own environment.
“Using a Consent Manager transfers consent liability”
That is not a safe governance assumption.
The statutory roles remain distinct. Integrating with a Consent Manager does not automatically transfer all consent-related accountability away from the Data Fiduciary.
Security responsibilities also sit on both sides
The First Schedule requires the Consent Manager to maintain appropriate security safeguards for its platform and to operate the relevant sharing mechanisms in a way that prevents the Consent Manager from reading the contents of the personal data being made available or shared.
The Data Fiduciary has separate obligations for the personal data it controls, including processing carried out through Data Processors.
Rule 6 of the final DPDP Rules sets out minimum security safeguards for Data Fiduciaries.
This is a good example of parallel responsibility.
Both parties may participate in the same consent ecosystem.
Neither party’s security duties erase the other’s.
A practical way to settle ownership disputes
When teams are unsure who owns a particular task, the fastest way to clarify the boundary is to look at what the task is actually about.
If it concerns enabling the Data Principal to manage consent through the registered intermediary, it points toward the Consent Manager role.
If it concerns why the organisation processes personal data, it belongs to the Data Fiduciary.
If it concerns what happens inside the organisation after a consent event arrives, it remains an enterprise processing responsibility.
If it concerns the Consent Manager’s own platform records, prescribed disclosures, audit or conflict controls, it sits with the Consent Manager.
If it concerns whether processing can continue under another lawful basis, that belongs to the Data Fiduciary’s legal and privacy governance.
This is not a statutory test.
It is a practical way to stop responsibility from disappearing between two connected organisations.
Define the handoff before integration goes live
The best time to settle these boundaries is before production.
An enterprise should document not only the API integration, but the governance handoff around it.
That document should identify how the organisation will handle:
- identity resolution;
- purpose mapping;
- incoming consent events;
- downstream system updates;
- processor actions;
- failed events;
- acknowledgements;
- evidence;
- incident escalation.
Not every item above is directly prescribed by Rule 4.
They are practical implementation controls that reduce the chance of ambiguity between two legally distinct actors.
The goal is simple: when something goes wrong, nobody should be asking for the first time who owns the next action.
Frequently Asked Questions
What are the main responsibilities of a DPDP Consent Manager?
Under Rule 4 and the First Schedule, a registered Consent Manager has specific responsibilities around enabling consent management, maintaining prescribed records, providing Data Principal access to those records, maintaining its platform, applying security safeguards, managing conflicts of interest and meeting audit-related obligations.
Is a Consent Manager responsible for the Data Fiduciary’s processing?
No, not merely because it manages the consent interface.
The Data Fiduciary is the entity that determines the purpose and means of processing personal data. Its responsibility for its own processing environment does not disappear when consent is managed through a Consent Manager.
Can a Data Fiduciary rely only on Consent Manager records?
That would be risky.
Consent Manager records are important evidence of the consent interaction. The Data Fiduciary may still need evidence showing how the consent decision affected its own systems, workflows and processors.
Can the Consent Manager read the personal data being shared?
The First Schedule requires the Consent Manager to ensure that personal data is made available or shared in a manner that prevents the Consent Manager from reading the contents.
Does every business in India need to become a Consent Manager?
No. A Consent Manager is a specific registered role under the DPDP framework. Enterprises may instead need to ensure that their own systems and governance can interact correctly with Consent Manager-led consent flows where relevant.
The boundary should be clear before the systems connect
A DPDP Consent Manager can give the Data Principal a structured, interoperable way to manage consent.
That does not make the Consent Manager the owner of every processing decision inside the enterprise.
The cleaner operating model is one where both sides understand exactly what they are accountable for.
The Consent Manager should be able to show that it has performed its regulated intermediary role.
The Data Fiduciary should be able to show that consent events were interpreted correctly and that its own processing changed when required.
That is the real governance boundary.
For enterprises preparing for Consent Manager integration, the next useful step is to review whether consent ownership, system handoffs and evidence responsibilities are clear before external consent events start moving through production.
