Guide · 9 August 2026

Purposes & Notices under DPDP: what they are and how to write them

The short answer: under India's DPDP Act, you need one purpose for each reason you process personal data, and each purpose needs a plain-language notice before you ask for consent. Consent is only valid purpose-by-purpose — one blanket "I agree" covering everything is not consent under the Act.

What counts as a purpose?

A purpose is one specific reason you use personal data: sending marketing emails, handling contact-form enquiries, evaluating job applications, invoicing customers. Section 6 of the Act requires consent to be free, specific, informed, unconditional and unambiguous — "specific" is the word doing the work. If your users can't tell which uses of their data they said yes to, the consent doesn't hold.

A practical test: if you can withdraw one use of the data without breaking another, they are separate purposes. A user should be able to stop your newsletters while keeping their account — so "marketing" and "account & service delivery" are two purposes, not one.

What must a notice contain?

Section 5 requires a notice, given before or at the moment you request consent, that tells the person in plain words:

• What data and why — the personal data you collect and the specific purpose it serves.
• How to exercise rights — how to withdraw consent, request correction or erasure, and raise a grievance.
• How to complain to the Board — the manner of making a complaint to the Data Protection Board of India.

Withdrawal deserves special attention: Section 6(4) says withdrawing consent must be as easy as giving it. If consent was one click, withdrawal can't be an email to legal.

Which languages does a notice need?

The user must have the option to read the notice in English or any of the 22 languages in the Eighth Schedule of the Constitution. You don't need all 22 on day one — start with English plus the languages your users actually speak (for most Indian mid-market companies that means Hindi and one or two regional languages), and treat the rest as demand appears.

A worked example you can copy

Here is a complete, compliant notice for a website contact form — data, purpose, retention, and rights, in under 80 words:

"We use the details you submit through our contact and enquiry forms — your name, email address, phone number and message — to respond to your enquiry and follow up on it. We keep enquiries for 24 months, then delete them. You may withdraw consent or exercise your data rights at any time via our data-rights portal; withdrawal does not affect processing already carried out."

Notice what it does: names the exact data fields, states one purpose, commits to a retention period, and points to a working withdrawal route. That's the whole recipe.

The mistakes that invalidate consent

• Bundling. One checkbox for marketing, analytics and everything else. Consent must be purpose-wise.
• Making service conditional on unrelated consent. You can't refuse the service because the user declined marketing — that makes consent no longer "free".
• Changing the notice without re-asking. When your notice changes materially, previously collected consent goes stale — users need to be re-prompted against the new text.
• No record. If you can't show which text the user consented to and when, you can't prove consent at all. Keep the notice version on every consent record.

How ProofKosh handles this for you

In ProofKosh, purposes are structured records that drive everything downstream: the consent widget asks purpose-by-purpose in 8 Indian languages, every choice lands in a tamper-evident ledger stamped with the notice version, and publishing a new notice version automatically marks affected consents stale for re-prompt. The starter library ships 8 ready-made purposes — marketing, analytics, contact forms, support, recruitment, billing and more — each with pre-written English and Hindi notices you can enable with one click and edit any time.

Related: the DPDP deadline timeline — when each of these obligations becomes enforceable.