The DPDPA consent requirements a CMP must satisfy
Section 6 sets five conditions for valid consent:
- Free: the Data Principal must not be compelled to consent (Section 6(1)).
- Specific: consent is given for each specified purpose (Section 6(3)).
- Informed: the Data Principal has received the notice under Section 5.
- Unconditional: consent must not be made a condition for accessing a service unless the personal data is necessary for the service (Section 6(5)).
- Unambiguous: the Data Principal’s affirmative action must be clear.
Section 6(4) adds that the Data Principal may withdraw consent at any time, with the same ease with which consent was given. This is the most common failure point in CMP implementations: the consent flow is prominent, but the withdrawal path is buried.
The Consent Manager under Rule 4 — and how it differs from a CMP
Rule 4 creates the Consent Manager as a registered intermediary. The Consent Manager enables a Data Principal to give, manage, review and withdraw consent through a single accessible, transparent and interoperable platform (Section 6(7)).
A Consent Manager is a registered entity, not a software product. It has registration requirements, interoperability obligations and fiduciary duties. A CMP is a software tool. They may overlap, but they are not the same thing.
An organisation may use a CMP without using a registered Consent Manager. If a Consent Manager is involved, the CMP must integrate with the Consent Manager’s systems.
How to evaluate a consent management platform
The evaluation maps each legal requirement to a technical capability:
| Requirement | DPDPA provision | CMP capability to check |
|---|---|---|
| Purpose-level consent | Section 6(3) | Can the CMP capture consent for each purpose separately, not in a single bundle? |
| Timestamped consent log | Section 6, evidence for Section 33(2) | Does the CMP store what was shown, what was chosen, and the timestamp? |
| Withdrawal mechanism | Section 6(4) | Is the withdrawal path as easy as the consent flow? Same number of clicks, same channel? |
| Downstream enforcement | Section 8(7), Section 8(2) | When consent is withdrawn, does the CMP trigger erasure or cessation in connected systems? |
| Consent Manager integration | Rule 4, Section 6(7) | Can the CMP exchange consent artefacts with a registered Consent Manager? |
| Multilingual support | Section 5(3) | Can the consent interface be presented in all 22 Eighth Schedule languages? |
| Audit trail | Rule 13, Section 33(2) | Can consent logs be exported for an independent data audit? |
Integrating the CMP with existing systems
A CMP that captures consent but does not enforce it downstream is a record-keeping tool, not a compliance tool. Integration means:
- When a Data Principal withdraws consent for a purpose, the systems processing data for that purpose stop processing and trigger erasure under Section 8(7).
- When a Data Principal gives consent for a new purpose, the systems are authorised to begin processing.
- The CMP’s consent log is available to the DPO, the auditor and the grievance handler.
- The CMP is connected to the Data Fiduciary’s notice: the notice presented in the consent flow matches the Section 5 notice on record.
How AMLEGALS advises on CMP selection
AMLEGALS is an Indian law firm. Its data privacy practice is led by Anandaday Misshra, Founder & Managing Partner. The team includes Rohit Lalwani, Associate Partner, who works on DPDPA compliance.
The team maps the legal requirements to the organisation’s systems, evaluates CMP options against the checklist, reviews the configuration for Section 6 compliance, and advises on Consent Manager integration where applicable.

