Recording consent and acting on withdrawal

The customer who said stop

A D2C skincare brand in Surat takes most of its orders on WhatsApp. At checkout on its website, customers tick a box to receive offers. One regular customer replies to a broadcast in Gujarati asking the brand to stop sending promotions. The support agent marks it in the CRM. Two days later the same customer gets a Diwali offer from the WhatsApp broadcast tool, and a week after that an SMS from a marketing agency the brand hired for the festive season.

Nobody did anything wrong on purpose. The CRM knew about the withdrawal. The broadcast tool kept its own contact list, and the agency had been sent a spreadsheet in September. The brand recorded consent carefully, and then nothing downstream read the record. This is the most common consent failure, and fixing it is mostly integration work.

What the Act asks consent to be

Five conditions, and what each one demands

Where you rely on consent, the Digital Personal Data Protection Act, 2023 asks for it to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action for a specified purpose. Each of those words becomes a design constraint the moment a product team tries to honour it.

• Specific means one purpose at a time. Order delivery, product analytics and marketing offers each need their own choice, which ends the habit of putting several activities behind one tick box.
• Informed means the request comes with, or after, the itemised notice the Rules describe, so every consent is tied to a particular disclosure.
• Unconditional means you cannot refuse to deliver an order because the customer declined marketing.
• Unambiguous and affirmative together rule out silence, inactivity and the pre-ticked box. The person has to act.

The Act also asks that withdrawing be as easy as giving. If agreeing took one tap, withdrawing should not need an email to a support address and a ten day wait. When consent is withdrawn, processing that relied on it has to stop, and the processors working for you on that purpose have to stop too.

Read together, these conditions make consent a maintained record. For each person you have to know which purposes they agreed to, when, through which interface, against which version of the notice, and in which language that notice was shown. The notice and consent duties apply from around 13 May 2027 under the DPDP Rules, 2025, notified on 13 November 2025; check for later amendments.

Consent as a record with a life

A consent decision changes over time, and each change has to be recorded and has to alter what your systems are allowed to do. Consent is captured at a point in time against a purpose and a notice version. Later it may be extended to a new purpose, narrowed, withdrawn in whole or in part, or left to lapse because the purpose has been served.

Keep every change as a new entry, so the current state and the history are both available. Disputes almost always concern a past state. "What had I agreed to in March?" can only be answered if March is still in the record, and a system holding only today's position cannot answer it.

Capturing the decision

What to record when someone agrees

A consent record you can defend later answers five questions for each person:

1. Which purposes they agreed to, recorded one by one. They may have accepted order updates and declined offers. A record saying consent was given, without saying to what, cannot support any processing decision.
2. When they agreed, to the second.
3. Where they agreed: website checkout, app sign-up, a call with a support agent, a form at a clinic reception. Consent given during account creation sits in a different context from consent taken by an agent on a call, and if the decision is ever disputed you need to know which it was.
4. Which version of the notice they saw. This is the field most teams leave out, and its absence causes the most trouble later. A customer who agreed eighteen months ago saw a notice you have since revised twice. Without the version, there is no honest answer to the question of what they were told.
5. Which language the notice was in. The Act gives people the option to read the notice in English or in any of the 22 languages of the Eighth Schedule. For a brand selling across Gujarat and Maharashtra, that might be Gujarati, Marathi, Hindi or English.

Each of these fields should be captured by the system at the time. That is what separates a consent record from a consent claim: nobody types up afterwards what they believe a customer agreed to.

Designing how consent is asked for

How the choices are presented, which purposes appear, what the notice says and how it is worded are decisions for your company. Two constraints shape them. Consent has to be free and unconditional, so a design that makes the service unusable without agreeing to unrelated processing fails on its own terms. And withdrawal has to be as easy as giving, so the design has to show how someone gets back to change their mind.

Teams often design the giving flow with care and the withdrawal flow as an afterthought. A regulator will notice that imbalance, and the Act is explicit about the standard.

Making consent govern what systems do

The gap between recording and enforcing

A consent record achieves nothing unless the systems that process personal data read it. Companies that have done visible consent work often have exactly this gap: the screens exist, the choices are captured, and nothing downstream looks at the result. The email platform sends to its full list. The analytics pipeline processes every event. The recommendation model trains on everything. The consent record sits beside all of it as an archive of intentions.

A simple test shows whether the gap exists. Withdraw marketing consent on a test account, then watch your email tool, WhatsApp broadcast list, ad audiences and analytics for a day. If nothing changes, your consent record is documenting choices that no system obeys.

Closing the gap means every system that acts on personal data for a consented purpose either checks the current consent state before it acts, or only receives data that has already been filtered. The size of that task depends on how many systems you have.

Why the check has to happen when the system acts

The Act sets no grace period for withdrawal. A company that reconciles consent overnight spends the hours in between processing data with no basis. On a busy platform those hours contain real activity: messages sent, profiles updated, recommendations generated, events processed. Each one is processing the person has declined.

Meeting the standard means the consent state has to be available quickly enough to sit in the path of a request without slowing it down. Most teams end up with one authoritative consent store, kept current by events, and a local copy near each system that updates within minutes. A contact list exported once to an agency, as in the Surat example, is where the trouble starts.

That is an architectural decision with a cost attached, and it is why consent work takes longer than anyone estimates. The consent screen is the visible piece and the smaller one.

What has to happen after a withdrawal

Withdrawal creates work for several people

A withdrawal is an event that creates obligations, and the order matters:

1. Stop the processing for that purpose in every system and with every processor that does it.
2. Then deal with the data. If you held some data only for the withdrawn purpose, it moves into your erasure process, including copies in reporting stores, caches and outside services. Stop first, erase second. Erasing while a downstream tool is still running leaves that tool with no data and no instruction to stop.
3. Tell processors. The marketing agency, the SMS gateway, the email platform.
4. Record what was done, system by system, with dates.

Each of these should become an action with an owner and a due date. The person who recorded the withdrawal should not have to remember to chase five teams. When each completion is recorded, you can show that a withdrawal was received and also that it was acted on, in which systems, by whom and when.

Partial withdrawal

Most withdrawals are partial. The customer stops offers and keeps ordering. Handling this properly needs purposes to be separable in your systems as well as in the record. If one table holds phone numbers for delivery, offers and analytics with no distinction, a partial withdrawal forces a bad choice: stop all three and go further than the customer asked, or continue all three and fall short of the Act.

A purpose register earns its keep here. Data recorded against specific purposes can be handled according to which purposes remain. Teams that discover the problem late usually find that separating existing data by purpose is a substantial piece of engineering. Recording the purpose alongside the data from the start avoids it.

When something cannot be completed

Sometimes part of a withdrawal cannot finish as planned, usually for a legitimate reason. A law may require you to keep invoices that carry the customer's name. A processor may not have confirmed. A system may return a pending status.

Keep those items open, with the reason and an owner. Closing a withdrawal while data remains creates a record that says something untrue. An open exception also lets you answer honestly when the customer asks whether their withdrawal was fully carried out: here is what was done, here is what remains, and here is why.

Consent Managers are coming

Consent arriving from outside

The Act creates Consent Managers: registered intermediaries through which a person can give, review and withdraw consent across many companies from one place. Their registration and obligations sit in the second phase of commencement under the DPDP Rules, 2025, around 13 November 2026. A Consent Manager has to be a company incorporated in India with a net worth of at least 2 crore rupees.

For a Data Fiduciary, this means consent and withdrawals will start arriving from outside, in a format the intermediary defines, naming purposes you have to map to your own. A company whose consent state is already held centrally, with registered purposes and systems that read it, can add that channel as a bounded piece of work. A company where consent lives separately inside each application faces a much larger task. The internal work takes months, so it should start well before that date.

What preparation involves

The preparation is the same internal work that improves your position anyway: a purpose list, a single consent store holding the history, notice versions and languages, and processing systems that read it as they act.

Add a reliable way to match an incoming record to the right person across your systems. That is genuine work in companies where the same customer exists under a phone number in one system, an email address in another and a loyalty ID in a third.

Finally, map the intermediary's purposes to yours as a written decision. Reading an incoming purpose too broadly means processing without a basis. Reading it too narrowly means withholding something the person agreed to.

Where TrustOS fits

TrustOS keeps one consent record per person and purpose, with the time, the channel, the notice version and the language. Each change is a new entry, so the full history stays available, and the records are tamper evident. Notices can be published in the 22 languages of the Eighth Schedule, so the language a person saw is part of what is stored. The consent state is the authoritative record your systems check against.

The Privacy Centre gives Data Principals a place to see and change their own choices, which keeps withdrawal as simple as agreeing. When a withdrawal is recorded, TrustOS creates the follow-up work in order: stop actions for each system and processor, then erasure actions where the data was held only for that purpose, and only for the purposes actually withdrawn. Where a system is connected, the connector carries out the action and confirms it. Where it is not, the action goes to the system owner with the details attached. Anything that cannot finish stays open with its reason.

A company working this way can answer two questions without preparation. For any person: which purposes they agreed to, when, where, against which notice and in which language, and what happened after any withdrawal. For any purpose: who has consented, who has withdrawn, and which systems rely on that state. Regulators, auditors and enterprise customers all ask some version of those questions.

Where to start

Start with the purpose list, before the screens. Consent is specific to a purpose, and there is nothing to be specific about until the purposes are written down. Then build the consent store with its history and notice versions. Then take on the longer piece, bringing the processing systems to read it. Teams that reverse this order build good consent screens attached to nothing.

• Write down your purposes before you design any consent screen.
• Record purpose, time, channel, notice version and language for every decision.
• List every system and processor that acts on each consented purpose.
• Run the withdrawal test on a test account and fix what does not change.
• Make withdrawal as easy as giving consent, in the same place.
• Store data against purposes so partial withdrawal works.

The guide on linking purposes to grounds and notices covers the purpose register, and the guide on executing retention and erasure across systems covers what happens to data once a withdrawal reaches it. The Consent module page shows how a withdrawal turns into assigned work.