DPDP Consent and Notice Requirements: A Practical Guide

Short answer: Under India's DPDP Act, consent has to rest on a proper notice, and if consent is ever disputed in a proceeding, the business must prove both. Rule 3 of the DPDP Rules, 2025 requires a standalone notice in plain language that itemises the personal data you collect, states each specific purpose and the service it enables, and links to where a customer can withdraw consent, exercise their rights and complain to the Data Protection Board. Consent itself must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action. For marketing teams this means separate, opt-in purposes for analytics, advertising, marketing messages and personalisation; a notice programme for customers whose data you already hold; and consent records detailed enough to stand up as evidence. These obligations apply from 13 May 2027.

Most organisations will meet the Digital Personal Data Protection Act, 2023 through a consent banner. That is understandable, and it is where much of the risk sits. Under DPDP, a banner is only the visible end of two legal obligations: a notice that must meet a prescribed standard, and consent that the business must later be able to prove.

Our DPDP Act compliance guide covers the whole law and the timeline. This article goes deep on the two obligations that sit underneath every marketing data flow: writing a notice that meets Rule 3, and designing consent that holds up when someone challenges it. If you are looking for how registered Consent Managers work, we cover that separately in DPDP Consent Manager: what it is and isn't.

Why the notice comes first

Section 5(1) of the Act says every request for consent must be accompanied or preceded by a notice. Consent given without a compliant notice is unlikely to be informed consent, so even a well-designed banner sitting on a weak notice is exposed from the first step.

The second reason is evidential. Section 6(10) provides that where consent is disputed in a proceeding, the Data Fiduciary must prove that a notice was given and that consent was obtained in line with the Act and the Rules. In a dispute, the customer does not have to prove that you failed. You have to prove that you succeeded.

That shifts the question a marketing or data team should be asking. It is not "does our banner look compliant?" but "if a customer complains in 2028 about an ad that followed them, can we show exactly what they were told and what they agreed to on the day their data was collected?"

What Rule 3 requires in a notice

Rule 3 of the DPDP Rules, 2025 sets out what the notice must contain. In summary, the notice must:

1. Be presented, and be understandable, independently of any other information the business has made available. A paragraph buried in the terms of use does not qualify.

2. Give, in clear and plain language, a fair account of the details needed for specific and informed consent.

3. Include an itemised description of the personal data to be processed.

4. State the specified purpose or purposes, and describe the goods or services to be provided or the uses enabled by the processing.

5. Give the particular communication link to the business's website or app, and any other means, through which the customer can withdraw consent, with ease comparable to giving it.

6. Use the same link and means to explain how to exercise rights under the Act and how to complain to the Data Protection Board.

Separately, section 5(3) requires that the customer can access the notice in English or in any language listed in the Eighth Schedule to the Constitution.

The table below translates each requirement into what it means for a marketing and data stack.

Writing the itemised notice for a marketing stack

"Itemised" is the word that breaks most existing notices. The most practical approach is to build the notice from a table that your data team can also use as configuration. If the notice and the routing rules come from the same source, they cannot drift apart.

The example below is illustrative for a D2C brand. Your entries must reflect what your stack actually does.

Two things stand out once you write a notice this way. First, the same data item, such as an email address, appears against several purposes and recipients. That is the point of itemisation. Second, the table exposes flows nobody has written down, such as a reverse-ETL sync that sends warehouse audiences to an ad platform every night. If a flow is not in the notice, it has no consent behind it.

Designing purposes: the bundling problem

The most common design mistake is bundling. A single "marketing and analytics" toggle covers at least four purposes with different recipients and different expectations. Under section 6(1), consent must be specific, and a customer who is happy for you to count page views may not be happy for their hashed email to reach Meta.

At minimum, we suggest these separate purposes for a consumer stack:

• Analytics: understanding how the site or app is used, typically first-party and aggregated.

• Advertising: attribution, conversion measurement, retargeting and audience building on third-party platforms.

• Marketing messages: email, SMS, WhatsApp and push campaigns, ideally split by channel.

• Personalisation: on-site recommendations and tailored content.

Section 6(2) adds a useful discipline. Any part of a consent that infringes the Act, the Rules or another law is invalid to the extent of the infringement. A bundled consent therefore does not fail cleanly. It leaves you arguing, purpose by purpose, about which part survives. Separate purposes avoid that argument.

Granularity has a cost: more toggles usually mean lower opt-in rates for advertising. The place to recover performance is better measurement on consented data, not blurred purposes.

Consent design: the section 6(1) requirements in practice

Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the data necessary for the specified purpose. Each requirement maps to a design decision. The design column reflects our reading of the Act, not express rules.

A pre-ticked box fails the clear affirmative action requirement on its face. An "accept all" button is not banned in itself, but in our reading it should sit alongside an equally easy way to decline and controls that present each purpose specifically. A cookie wall that blocks the site until the visitor accepts every purpose is likely to make consent conditional. The test is simple: can a customer browse, buy and receive their order having declined every optional purpose? If not, redesign.

Section 7(a): where consent is not needed, and where it still is

Not everything needs consent. Section 7(a) allows processing of personal data that a customer has voluntarily provided for a specified purpose, where they have not indicated that they do not consent. The standard example is a customer who gives a phone number to receive a receipt.

The limit is in the words "for a specified purpose". The number given for a receipt can be used to send the receipt. It cannot be added to a WhatsApp marketing list, uploaded to Meta as a Custom Audience, or matched to a profile for retargeting. Each of those is a new purpose that needs consent.

This matters most in offline-to-online flows: retail point-of-sale, call-centre lead forms, events and loyalty sign-ups. A useful internal rule of thumb, not the legal test itself: would the person handing over the data reasonably expect this use? If they gave a number to get a bill, they did not ask for promotions.

Language

Section 5(3) requires that customers can read the notice in English or any language in the Eighth Schedule, and section 6(3) applies the same standard to the consent request itself. For a national consumer brand this is a product requirement, not a translation afterthought.

Store each notice as a versioned object with language variants, and record which language version the customer actually saw. If your checkout runs in Hindi, Tamil and Bengali, the notice and consent request should too. English is a permitted option, but in our view consent captured against an English notice shown to a customer who used Marathi throughout the journey may be harder to defend.

Customers whose data you already hold

Most businesses have years of customer data collected before the Act. Section 5(2) deals with this directly. Where a customer gave consent before commencement, the business must give them a notice as soon as it is reasonably practicable, and may continue processing until the customer withdraws.

That is helpful, but it is not a free pass. Existing consents still have to be consents. A record that only shows a pre-ticked box from 2021, or a newsletter list with no record of how people joined, is hard to defend as consent at all. For a large CRM, the notice programme is a project in itself:

1. Segment existing records by the purposes they are actually used for today.

2. Separate records with a defensible consent trail from those without one.

3. Prepare the itemised notice and choose channels: email, app, SMS or the logged-in website.

4. Re-seek consent where the original basis is unclear, rather than relying on silence.

5. Record when each notice was sent, in which language and version, and what happened next.

Plan this alongside your May 2027 readiness work, not after it. Notice campaigns to millions of customers take time to sequence and test.

Consent records as evidence

Because of section 6(10), your consent log is the evidence you will rely on if a complaint reaches the Board. "Our banner was configured correctly" is a claim. A record is proof. Each consent record should capture, at minimum:

1. Customer identifier: a pseudonymous ID that can be resolved to the customer, without storing raw personal data in the log itself.

2. Notice version and language: the exact notice text the customer saw.

3. Purposes: each purpose with its state: granted, declined or withdrawn.

4. Timestamps: at capture and at every change, in a consistent timezone.

5. Channel and surface: web banner, app, call centre, point of sale or Consent Manager.

6. Action: what the customer actually did, such as switching "advertising" off.

7. Withdrawals: when, through which channel, and confirmation that downstream processing stopped.

The last point is the one most teams miss. Recording that a customer withdrew is not the same as showing that processing stopped. The useful record shows which destinations received data before the withdrawal and that none received it afterwards.

Withdrawal, briefly

Section 6(4) requires withdrawal to be as easy as giving consent, and section 6(6) requires the business, and its processors, to stop processing within a reasonable time. Withdrawal does not make earlier processing unlawful (section 6(5)), but in practice it means data has to stop flowing to every destination that uses it for the withdrawn purpose.

In most stacks the consent platform updates a browser flag and nothing tells the nightly audience sync, the server-side container or the email platform. We go into this propagation problem, and how it interacts with the Consent Manager framework that commences on 13 November 2026, in DPDP Consent Manager: what it is and isn't.

A checklist before 13 May 2027

1. Inventory every flow of personal data to a third party, including server-side events and batch syncs. Site Intelligence gives you a free list of the tags firing on your site as a starting point.

2. Define your purposes at the granularity above and map each to its data items and recipients.

3. Write the itemised Rule 3 notice from that map, with the language versions your journeys need.

4. Rebuild consent controls: one per purpose, nothing pre-ticked, a reject option as easy as accept.

5. Make checkout and core service work with every optional purpose declined.

6. Review offline and call-centre flows that rely on s.7(a) and add consent where data is reused for marketing.

7. Plan the section 5(2) notice programme for existing customers.

8. Stand up consent records that capture notice version, language, purposes, channel and withdrawals.

9. Test that a withdrawal actually stops data reaching every destination.

Where Ingest Labs fits

Your consent platform records what the customer chose. The hard part is making every downstream system honour it and being able to prove that it did.

Ingest IQ sits between consent capture and your destinations. It reads consent state from your existing platform, whether OneTrust, Consentmo or a custom build, and applies it per event and per destination across more than 100 integrations, including Meta, Google Ads, GA4, TikTok, Klaviyo, Snowflake and BigQuery. The purposes in your notice map to destinations, so an event consented for analytics but not advertising reaches GA4 and not Meta. It keeps an audit trail per event and per destination, which complements the consent records you need under section 6(10), and withdrawals propagate to the destinations that received the data.

Under DPDP, Ingest Labs acts as your Data Processor and you remain the Data Fiduciary. The platform is architected for DPDP and holds SOC 2 Type II. Our DPDP resource page sets out the architecture in more detail.

Frequently asked questions

What must a DPDP notice contain?

Under Rule 3 of the DPDP Rules, 2025, the notice must stand on its own and be in clear and plain language. It must give an itemised description of the personal data, the specified purposes and the goods, services or uses they enable, and the link through which the customer can withdraw consent, exercise their rights and complain to the Data Protection Board. Section 5(3) requires the option to read it in English or any Eighth Schedule language.

Who has to prove that consent was valid?

The business. Section 6(10) of the DPDP Act provides that where consent is disputed in a proceeding, the Data Fiduciary must prove that notice was given and consent was obtained in accordance with the Act and the Rules. That is why consent records need notice versions, timestamps and the action the customer took.

Is a cookie banner with "Accept all" allowed under DPDP?

An "accept all" button is not prohibited in itself, but in our reading the banner should also offer an equally easy way to decline and present each purpose specifically. Pre-ticked boxes fail the clear affirmative action requirement, and a banner that blocks the site until every purpose is accepted is likely to make consent conditional.

Do we need new consent from customers whose data we collected before these provisions commence?

Section 5(2) requires a notice to those customers as soon as reasonably practicable, and allows processing to continue until they withdraw. That only helps where the original consent was genuine. Records with no defensible consent trail, such as pre-ticked boxes or lists with no sign-up record, are candidates for re-seeking consent.

Can we use a phone number collected for a receipt for WhatsApp marketing?

Not on the basis of section 7(a). That legitimate use covers data voluntarily given for a specified purpose, such as sending a receipt. Using the same number for WhatsApp promotions, Custom Audiences or retargeting is a different purpose and needs consent.

When do these consent and notice obligations apply?

The notice and consent obligations under section 5, section 6 and Rule 3 apply from 13 May 2027. The Consent Manager framework applies earlier, from 13 November 2026. As of late October 2026, no change to these dates has been notified.

If you want a structured view of where consent is recorded and where your data actually goes before May 2027, book a DPDP readiness call.

Sources

• DPDP Wiki, Section 5: Notice, Digital Personal Data Protection Act, 2023 (checked 2026-10-27): notice with every consent request; notice for consent given before commencement and continued processing until withdrawal; English or Eighth Schedule language

• DPDP Wiki, Section 6: Consent, Digital Personal Data Protection Act, 2023 (checked 2026-10-27): qualities of valid consent; partial invalidity; withdrawal and cessation by processors; burden of proof on the Data Fiduciary

• DPDPA.com, Rule 3: Notice given by Data Fiduciary to Data Principal (checked 2026-10-27): standalone notice; itemised personal data; specified purpose and goods or services; communication link for withdrawal, rights and complaints to the Board

• Sansa Legal, How to draft a DPDP notice that meets Rule 3 (checked 2026-10-27): Rule 3 elements as notified

• S.S. Rana & Co., MeitY notifies final Digital Personal Data Protection Rules 2025 (checked 2026-10-27): Rules notified as G.S.R. 846(E) on 13 November 2025; phased commencement

• DPDPA Support, Consent Managers under DPDP from 13 November 2026 (checked 2026-10-27): Consent Manager framework commences 13 November 2026

• India Data Law, Is the Data Protection Board of India operational? (checked 2026-10-27): no Chairperson or Members appointed as of October 2026

This article is general information about the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025, current as of October 2026. It is not legal advice. Please take advice from qualified Indian counsel on your specific position.