Recording Consent and Acting on Withdrawal

The Digital Personal Data Protection Act 2023 requires consent to be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action for a specified purpose. Each of those words sets a design constraint once a product team tries to honour it.

Specific means one purpose at a time. A company processing data for service delivery, analytics and marketing needs consent for each of those separately, which ends the practice of bundling several activities behind one agreement box.

Informed means the consent request is preceded or accompanied by the itemised notice the Rules describe, and that ties every consent to a particular disclosure. Unconditional means access to a service cannot depend on consent for processing the service does not need. Unambiguous and affirmative together rule out silence, inactivity and the pre ticked box.

Read together, these conditions turn consent from a formality into a maintained record. For each individual, a company has to know which purposes were consented to, when, through which interface, against which version of the notice, and in which language that notice was presented.

A consent decision changes over time. Each change has to be recorded, and each change has to alter what the systems are permitted to do.

Consent is captured at a point in time against a purpose and a notice version. It may later be extended to a new purpose, narrowed to fewer purposes, withdrawn in whole or in part, or allowed to lapse because the purpose has been served.

TrustOS records each of those transitions with a timestamp, so the current state and the history are both available. A question about what an individual had agreed to on a particular date is answered from the record.

That history matters more than companies expect. Disputes about consent almost always concern a past state and not the present one, and a system holding only the current position cannot address them.

When an individual gives consent, TrustOS records the purposes covered, the time, the interface it came through, the notice version presented, and the language it was presented in. The Rules require notices in English and in the languages of the Eighth Schedule, so the language is part of the record and not an incidental detail.

The notice version is the field companies most often leave out, and its absence causes the most difficulty later. An individual who consented eighteen months ago saw a notice that has since been revised twice. Without the version recorded against their decision, no honest answer exists to the question of what they were told at the time.

Recording the interface matters for a reason that appears during disputes. Consent given during account creation on a website sits in a different context from consent given by a support agent on a call, and a company defending the validity of a decision needs to know which it was.

The purposes are recorded individually and not as a group, because the individual may have agreed to some and declined others. A record showing that consent was given, without saying to what, cannot support any processing decision.

Each of these fields is captured by the system at the time, and that separates a consent record from a consent claim. Nobody is typing up afterwards what they believe an individual agreed to.

The platform allows the consent experience to be configured, covering how the choices are presented, which purposes appear, what the notice says and how the whole thing is worded. That configuration is a decision for the company and not a fixed arrangement.

Two constraints shape it. The Act requires consent to be free and unconditional, so a design that makes a service unusable without consent for unrelated processing fails on its own terms. And the Act requires withdrawal to be as easy as giving, so the design has to account for how somebody gets back to change their mind.

Companies frequently design the giving flow with care and the withdrawal flow as an afterthought. That imbalance is visible to a regulator, and the standard in the Act is explicit about it.

A consent record achieves nothing unless the systems that process personal data consult it. Companies that have done visible consent work often have exactly this gap, because the screens exist, the choices are captured and nothing downstream reads the result.

The pattern is familiar. A marketing platform sends to its full list. An analytics pipeline processes every event. A recommendation system trains on all available data. The consent record sits alongside all of it as an archive of intentions.

A quick test shows whether your own company has this gap. Withdraw consent on a test account and watch what changes in the systems downstream. If nothing changes, the consent record is documentation and not a control.

Closing that gap is an integration task, and the scale of it depends on how many systems act on personal data. Each one either checks consent state before it acts or receives only data that has already been filtered against consent.

TrustOS holds the consent state as the authoritative record for those checks. The alternative arrangement, where each system keeps its own copy refreshed periodically, leaves a window during which a system acts on a state that is out of date.

The Act sets no grace period for withdrawal. When consent is withdrawn, processing that rested on it has to stop, and a company reconciling consent overnight spends the intervening hours processing data without a basis.

On a platform of any size those hours contain real activity. Emails sent, profiles updated, recommendations generated, events processed. Each of those is processing that the individual has declined.

Meeting the standard means the consent state is available quickly enough to sit in the path of a request without slowing it. In practice that points to a local store kept current by events from the platform, and not a call out to a central service for every operation.

That is an architectural decision with cost attached, and it is the reason consent work takes longer than companies estimate. The screens are the visible part, and they are the smaller part.

A withdrawal is an event that creates obligations, and TrustOS turns those obligations into assigned actions the moment it is recorded.

Processing for the withdrawn purpose has to stop, and stopping it may involve several systems. Data held only for that purpose enters the erasure obligations, so an erasure action reaches every place it sits. Processors acting on the company instructions have to be told. Copies in reporting stores, caches and outside services have to be brought into line.

Each of those becomes an action with an owner and a due state. The privacy officer who recorded the withdrawal does not have to remember to chase five teams, because the work has already reached them with the context attached.

Sequencing matters inside that set of actions. Stopping the processing comes before erasing the data, because erasing first while a downstream system continues to run leaves that system with no data and no instruction to stop. TrustOS creates the actions with that order in mind so the owners are not left deciding it themselves.

The completion of each action is recorded, so the company can show not only that a withdrawal was received but that it was acted on, in which systems, by whom and when.

An individual may withdraw consent for one purpose and leave others in place, and that case arises more often than complete withdrawal. Somebody stops marketing consent and continues using the service.

Handling this correctly requires the purposes to be separable in the systems as well as in the record. Where data was collected for three purposes and stored in one place with no distinction, a partial withdrawal has no clean effect. The company either stops all three, going further than the individual asked, or continues all three, falling short of what the Act requires.

Here the purpose register does its work. Data recorded against specific purposes can be treated according to which purposes remain, and TrustOS creates actions only for the purposes that were withdrawn.

Companies discovering this late often find that separating existing data by purpose is a substantial piece of engineering. Recording purpose alongside data from the beginning avoids that entirely.

Some withdrawal actions cannot complete as intended, and the reasons are usually legitimate. A statutory retention requirement may cover part of the data. A processor may not have responded. A system may return a pending verification.

TrustOS keeps those cases open with their reasons attached and assigned to somebody, instead of recording the withdrawal as fully actioned. A company that closes a withdrawal while part of the data remains has created a record stating something untrue.

Keeping the exception visible also gives the privacy function what it needs to answer honestly. Where an individual asks whether their withdrawal was fully implemented, the answer can be specific about what was done and what remains, with a reason.

The Act creates a registered entity called a Consent Manager, through which an individual can give, review and withdraw consent across many companies from a single place. Registration under the Rules opens in November 2026, and the substantive obligations follow in May 2027.

For a data fiduciary, this means consent records and withdrawals will begin arriving from outside the company, in a format defined by the intermediary, referring to purposes that have to be mapped onto the ones the company actually processes for.

A company whose consent state is already held centrally, with its purposes registered and its processing systems consulting it, can add that external channel as a bounded piece of work. A company where consent lives inside each application separately faces a much larger task.

That difference deserves attention now and not in late 2026, because the internal work described in this article takes months and does not depend on which entities eventually hold registration.

The preparation is internal and it is the same work that improves your position regardless of the intermediary framework. A register of the purposes you process for. A single authoritative consent store holding the lifecycle, the notice versions and the languages. Processing systems that consult that store as they act.

To that, add the ability to match an incoming record to the right individual across your systems, and that is a genuine piece of work in companies where the same person exists under different identifiers in different places.

A documented mapping between the purposes an intermediary names and the purposes you actually process for completes it. That mapping needs a decision and not an assumption, because reading an incoming purpose too broadly means processing without a basis and reading it too narrowly means withholding a service the individual agreed to.

A company operating this way can answer a specific question about any individual without preparation. Which purposes they consented to, when, through which interface, against which notice version and in which language. Whether anything was later withdrawn, when, and what the company did in response.

It can also answer the question in the other direction. For a given purpose, which individuals have consented, which have withdrawn, and which systems are relying on that state.

Those two views are what a regulator, an auditor and an enterprise customer each ask for in slightly different words. A company holding them can respond in hours. A company assembling them from application databases and email threads responds in weeks, incompletely.

For companies that have not begun, the first step is the purpose register and not the screens. Consent is specific to a purpose, and there is nothing to be specific about until the purposes are written down.

From there, the consent store with its lifecycle and notice versions. Then comes the harder and longer piece, bringing the processing systems to consult it. Companies that reverse this order build good consent screens attached to nothing.

The article on purposes, grounds and notices in this series covers the register itself, and the article on retention and erasure covers what happens to data once a withdrawal reaches it. Consent sits between the two, and it works only when both sides of it are in place.

TrustOS is a DPDPA compliance platform developed and operated by Code Colonies Private Limited. It gives privacy, legal, security, technology, operations and audit teams a single system for personal data records, purposes and notices, consent and withdrawal, requests and grievances from individuals, retention and erasure, breach response, processor oversight and compliance evidence. Every obligation is connected to a responsible owner, turned into assigned work, tracked through to completion, and left with the records that an audit or a regulatory response will call for.

The platform can be deployed inside infrastructure that you control, and the agreed scope can include source code handover, environment setup, security configuration, technical documentation, integration support and knowledge transfer. A scoped gap assessment establishes your current position, the responsible teams, the priority gaps, the technical dependencies and a practical order in which to implement.

To see the platform or to discuss your requirements, continue to the product overview or start a gap assessment. To learn more about our consulting and engineering work, visit codecolonies.com. To start a conversation, write to us at consulting@codecolonies.com.