How to choose a DPDP consent management platform: 12 tests

A DPDP consent management platform is software a Data Fiduciary uses to give notices, record consent purpose by purpose, carry a withdrawal to every system and vendor that uses the data, and answer rights requests. Judge it first on evidence. Where consent is your basis and it is questioned, you must prove the notice you gave and the consent you received (s. 6(10)). The duties start on 13 May 2027, so a platform chosen by early 2027 still leaves time to connect it and run your notice campaign for existing data. A platform is a different thing from a Consent Manager, which must register with the Data Protection Board from 13 November 2026 (s. 6(9), Rule 4).

Like the Act (s. 2(y)), we say "she" and "her" for every person.

Jump to:

• Buying now: The 12 tests, A 45-minute demo script, Scoring sheet, Cost and effort.
• Comparing vendors: Kinds of vendor, How our platform scores.
• Legal and DPO: Contract terms, Where the law is unclear.

What the platform is for

Think of a platform as the place where the Act's consent duties become daily behaviour. A person is told what you collect and why before she is asked. She says yes or no to each purpose separately. She can change her mind as easily as she agreed, and when she does, every system and vendor stops. She can ask what you hold and get an answer. A good platform makes each of those happen across every channel you use, and leaves a record each time.

A website cookie banner covers one channel. The harder cases are a consent taken by a field worker on a shared phone with no signal, a withdrawal that has to reach a CRM, an SMS gateway and a payments system, and a request that arrives as a voice note on WhatsApp.

A platform cannot choose your legal basis. You must decide, purpose by purpose, whether consent or a named clause of section 7 applies, and write down why. Nor can it make an unfair consent fair: if refusing means losing a scholarship or a loan, a beautifully logged "yes" is still a weak basis.

The 12 tests

1. Notices built from itemised purposes, with versions

Why: a notice must stand on its own and itemise the data, the purpose and what it enables (Rule 3(a), (b)).

Good looks like: a register of purposes, each with its data items, basis, retention period and owner, from which notices are generated. Every change creates a new version, and old texts are kept. Each consent record points to the exact version and language shown.

Ask: "Change one data item in this purpose. Show me the new notice version, and show me that last month's records still point to the old text."

2. The 22 languages, and audio for everyone else

Why: the notice and request must be available in English or any of the 22 Eighth Schedule languages (s. 5(3), s. 6(3)).

Good looks like: notice texts in any of the Scheduled languages you choose, held as linked translations of one version, with audio attached. A language or dialect outside the Schedule, such as Marwari, Bhili or Tulu, does not satisfy the rule on its own, so a field worker or IVR plays the dialect audio while the Scheduled-language text stays available. The record shows which language she read or heard. How many languages to offer is an open question, covered in the notice guide.

Ask: "Add Odia text and Kui audio to this notice. Show me a record that says she heard the Kui audio and could see the Odia text."

3. Offline and assisted capture in the field

Why: the whole notice must come before or with the first yes/no question, however the consent is taken (s. 5(1)).

Good looks like: an app that works with no network, plays the notice, records each decision with the collector's ID and device time, and syncs later without losing or duplicating records. Each worker has her own login. The record shows that it was captured offline and when it synced.

Ask: "Put the tablet in flight mode. Take two consents, change one, then reconnect. Show me both records and their history."

4. Consent per purpose, with no bundling

Why: consent must be specific, unconditional and limited to the data needed for the purpose (s. 6(1)).

Good looks like: each purpose is a separate choice, with refusal recorded as clearly as acceptance. Purposes that rest on a legitimate use (s. 7) are shown to her for information, with no question attached. The platform shows which data fields each purpose needs, so you stop collecting fields that serve no purpose.

Ask: "Show me a person who said yes to the service and no to photographs. Show me how the photo library knows."

5. Withdrawal as easy as consent, and propagation to processors

Why: withdrawal must be as easy as giving consent, and you and your processors must then stop within a reasonable time (s. 6(4), (6)).

Good looks like: she can withdraw on the channel she used to consent, and on any other you offer. The withdrawal goes to each connected system and processor, each confirms, and the record shows when processing stopped in each place. Failures raise an alert.

Ask: "Withdraw this person's marketing consent by WhatsApp. Show me the email tool, the CRM and the SMS vendor confirming, with times. Now unplug one connector and show me the alert."

6. Evidence that would satisfy section 6(10), for one person across channels

Why: in a proceeding, you must prove the notice and the consent (s. 6(10)).

Good looks like: one record per person, per purpose, per decision, holding the identifier, purpose, notice version and language, channel, collector, timestamp, decision and later changes.

Two capabilities separate strong platforms here.

• Identity resolution. The same woman appears as a WhatsApp number, a CRM contact, a beneficiary ID in a field register and a donor record. The platform should link these to one person, show how each link was made (same verified mobile, same enrolment ID, a manual match by a named staff member), and let you undo a wrong match. Without it, a withdrawal on WhatsApp never reaches her CRM record, and an access request returns half her data.
• Tamper-evidence. Records should be append-only: corrections add an entry and never overwrite one. A good answer to "how do I show this was not edited?" names a mechanism: each entry carries a cryptographic hash of the one before it (hash chaining), so any edit breaks the chain; records or periodic snapshots are kept in write-once storage (often called WORM) that even administrators cannot alter; and exports are digitally signed, with the notice text included, so a reader can check them independently. Access to records is itself logged (Rule 6(1)(c)).

Ask: "This person messaged us on WhatsApp and is also in our CRM and field app. Show me her single record. Then export everything you would give the Board for her, and show me how a third party could check the export was not altered."

7. Children and people with lawful guardians

Why: before processing a child's data you need a parent's verifiable consent, with due diligence that she is "an adult who is identifiable if required in connection with compliance with any law" (s. 9(1), Rule 10(1)).

Good looks like: the platform records the method used to check the parent's identity and age, beyond a ticked box. It blocks downstream processing of a child's record until verification is complete. For a person with a disability, it records how the guardian's appointment was checked (Rule 11). It can mark purposes that fall under a Fourth Schedule exemption, with the exemption named, and keep tracking and targeted advertising away from children (s. 9(3)).

Ask: "Enrol a 15-year-old. Show me where the parent's identity and age check is recorded, and show me that the learning app cannot see her until it is."

8. Rights requests and grievances in one queue

Why: for data processed on consent, including under s. 7(a), people can ask for access, correction and erasure, and anyone can nominate or raise a grievance, answered within a published period of no more than 90 days (ss. 11(1), 12(1), 13, 14, Rule 14(3)).

Good looks like: requests from WhatsApp, the helpline, email, the website and field workers land in one queue with an owner and a clock. Identity checks are recorded. An access answer includes the fiduciaries and processors her data was shared with (s. 11(1)(b)). Every reply carries your contact person (Rule 9). An erasure goes to every connected system, and anything kept because a law requires it is listed with the reason.

Ask: "A donor asks on WhatsApp what you hold about her and who you shared it with. Show me the reply you would send, and where the list of vendors comes from."

9. Retention and erasure that actually run

Why: erase when consent is withdrawn or the purpose ends, unless a law requires you to keep it, while keeping data and logs for at least one year (s. 8(7), Rule 8(3)).

Good looks like: each purpose carries a retention rule; erasure jobs run on schedule, reach connected systems and write their own record. Legal holds keep what another law requires, with the reason shown. The one-year logs sit apart from live data with restricted access. E-commerce entities and social media intermediaries with at least two crore registered users in India, and online gaming intermediaries with at least fifty lakh, also have fixed erasure periods and a 48-hour warning (Rule 8(1)–(2), Third Schedule).

Ask: "Show me last month's erasure run: what it erased, where, and what it kept and why."

10. Integrations with the systems you actually run

Why: a withdrawal ignored by the email tool is a failure of s. 6(6), and the notice drive for existing data needs your old contact lists (s. 5(2)).

Good looks like: connectors for your CRM, survey and field tools, HR, payments and messaging, an API and SDK for your own apps, and a route for spreadsheets and legacy databases. Systems can ask "may I use this person's data for this purpose?" before acting, and receive changes as they happen. The vendor says plainly who does the integration work.

Ask: "Which of our twelve systems do you connect to out of the box? For the other five, who writes the integration, and how long did a similar one take?"

11. Ready for Consent Managers later

Why: a person may give, manage, review or withdraw consent to you through a registered Consent Manager (s. 6(7)).

Good looks like: an architecture that can accept a consent or withdrawal from an outside source through an API, map it to your identifier for her (Rule 14(5)), act on it like any other withdrawal, and acknowledge it with times. The Board's standards for Consent Manager platforms (First Schedule, Part A, item 9) had not been published as far as we found on 25 October 2026, so message formats are unsettled. A vendor should say what it will build once they are, without claiming to be "Consent Manager ready" today.

Ask: "If a withdrawal arrives tomorrow from an external platform via API, what happens to it?"

12. Data residency, security and the vendor as your processor

Why: the vendor is your processor, so you need a valid contract and stay responsible for its safeguards (s. 8(1), (2), (5), Rule 6(1)).

Good looks like: a stated hosting location for data, backups and logs; a list of sub-processors; security controls mapped to Rule 6 with evidence; breach notice to you within hours; and help with your own Board and, where they apply, CERT-In reports. The Act lets data go abroad unless a country is restricted (s. 16(1)), but sector rules can be stricter (s. 16(2)), and the CERT-In Directions ask covered entities to keep ICT logs for 180 days within Indian jurisdiction. CERT-In's FAQs of 18 May 2022 allow logs to be stored abroad if they can be produced in reasonable time (Q35), but Q36 says a service provider offering services to users in India must keep logs and records of financial transactions in India; the FAQs are guidance, not the Directions themselves. A consent platform holds a map of everyone you deal with, so a breach of it is serious.

Ask: "Where are our records, backups and logs stored? Who in your company can read them, and how would I know if they did?"

A 45-minute demo script

Vendors demo their best path. Make them run yours. Send this a week ahead with three of your real purposes, notice texts and systems, and ask to see it live.

If any step needs "our team will configure that later", note it as a gap and ask for the date in writing.

A scoring sheet you can copy

Score each test 0 (absent), 1 (partly, or only with custom work) or 2 (shown working in the demo). The weights are our suggestion, set by how much each failure would cost; adjust them to your organisation.

Multiply each score by its weight and add up. Our view: treat a 0 on test 5 or test 6 as disqualifying, whatever the total.

Cost and effort

We do not publish prices, and no one else's are quoted here. In our view, what follows is how vendors in this market commonly charge and what drives the bill, so you can compare quotes on the same basis.

Pricing models you will meet:

What drives implementation cost: the number of systems that must check consent or receive withdrawals; how many are custom-built or legacy; field collection and offline sync; languages and audio recording; children's verification flows; identity resolution across messy data; migrating existing consent records; and the notice drive for data you already hold. Licence fees are often the smaller part of the first year.

Time to go live. These are planning assumptions, not quotes, and assume your purposes and notices are drafted:

Build or buy. Building suits an organisation whose consent lives inside one product it already engineers, with a team that will maintain notice versions, exports and tamper-evidence for years. Buying suits organisations whose data sits across many tools, or who need field capture, languages and rights workflows quickly. Either way, budget for integration work and a named internal owner.

The kinds of vendor on the market

We name no brands. The categories matter more, because each tends to be strong and weak in predictable places.

How our platform scores on these tests

We sell a consent platform, so here is our row against the twelve tests, drawn only from what our home page describes. Where the site says nothing, the cell says so. Ask us for those items in writing, and for a live run of the demo script.

The platform is available on its own or as part of the full programme. If we have also assessed you, see the FAQ on conflicts below.

Contract terms that matter

Your platform contract is a processor contract, and it holds your evidence. Our view of the terms to insist on:

• Security: measures mapped to Rule 6(1), with the right to see evidence, and a named sub-processor list with notice of changes.
• Breach notice: to you within a stated number of hours of the vendor becoming aware, with the facts you need for Rule 7 and, where they apply, the CERT-In Directions.
• Withdrawal: a stated maximum time for carrying a withdrawal to connected systems, and alerts on failure.
• Records: append-only consent records, access logging, and logs kept for at least the year Rules 6(1)(e) and 8(3) need.
• Exit: a full machine-readable, verifiable export of records, notice texts and history, tested during the trial; then erasure by the vendor with written confirmation (s. 8(7)(b)).
• Location: where data, backups and logs are stored, and no move without notice.
• Help with requests: support for access, erasure and breach reports, at a known cost.

Data fiduciary or processor? covers the wider set of processor terms.

Platform or Consent Manager?

A consent management platform works for you, as your processor; a registered Consent Manager works for the person, must be an India-incorporated company worth at least ₹2 crore registered with the Board, and must not be able to read the data it carries (s. 6(8), (9), Rule 4, First Schedule). Registration needs a functioning Board, and none of its Chairperson or Members had been appointed as far as we found on 25 October 2026. Registration, the independence rules and a decision tree are in Consent Managers under DPDP.

Where the law is unclear

How long should consent records be kept? For as long as a past consent could be questioned, which in practice means the life of the relationship plus a limitation period your lawyer is comfortable with. Why: s. 6(10) puts the burden of proof on you, but the Act sets no period for the fiduciary's own records; the seven-year rule binds only Consent Managers (First Schedule, Part B, item 4). Would change if: the Board sets an expectation in guidance or an order. Confidence: medium.

What is a "reasonable time" to stop processing after withdrawal? Our view as advisers: design for the same day across connected systems, and a few days at most for processors that need manual steps. Why: s. 6(6) gives no number; ease comparable to giving consent (s. 6(4)) and a person's reasonable expectations both point to speed. Would change if: the Board publishes guidance or decides a complaint on it. Confidence: medium.

Is an OTP to the parent's phone enough for Rule 10? Not on its own. Why: Rule 10(1) asks for due diligence that she is an identifiable adult, by reference to details of identity and age; an OTP shows who controls a number. Combine it with an identity and age detail you hold or she provides. Would change if: the government or the Board endorses specific methods. Confidence: medium.

Does the vendor's knowledge of a breach start your 72 hours? Unsettled. Why: Rule 7(2)(b) runs from the fiduciary becoming aware, and you remain responsible for your processor (s. 8(1)). Contract for notice within hours so the question rarely matters. Would change if: the Board rules on it. Confidence: low.

What to do in the next six weeks

1. List every channel where you collect personal data on consent today, and every system that uses it.
2. Draft three real purposes and one notice, so each vendor demos your case. How to write a DPDP notice has copyable formats.
3. Send the demo script to two or three vendors from different categories, including any build-it-yourself option.
4. Score them on the sheet with your DPO, IT lead and one programme or product owner in the room.
5. Ask each for pricing on the same basis, including implementation and message costs.
6. Negotiate the contract terms before price.
7. Plan the integration and the s. 5(2) notice drive for data you already hold: see The data you already hold and, for field settings, Consent in the field. The DPDP timeline works back from 13 May 2027.

How we wrote this guide. We worked from the text of the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), and the CERT-In Directions of 28 April 2022. The status of the Board's Consent Manager framework was last checked on 25 October 2026. Pricing models, vendor categories and time estimates are our judgement of the market, not data. The description of the Commons Trust platform is taken from our own home page. This guide explains the law; it is not legal advice.