The Digital Personal Data Protection Act, 2023 is usually introduced to a management committee as a legal development, and legal developments are handled by producing documents. A privacy policy is refreshed. A consent notice is drafted. A checkbox appears at signup. Somebody circulates a slide deck with the words data fiduciary and data principal on it, and the item is marked closed. Six months later an engineer asks a question that reopens it: when a user withdraws consent, what exactly happens to the copy of their data in the warehouse, and in the CRM, and in the analytics platform, and in the vendor system the marketing team onboarded last year.
Nobody has an answer, because the question was never a legal one. Consent, as the Act constructs it, is not a document. It is a state that has to be created against a specific purpose, evidenced afterwards, kept accurate as purposes change, and unwound on request across everywhere the data went. That is a system. It has a data model, an interface, a storage layer and an integration problem, and it does not appear because a policy said it should.
The argument in one line
Consent management is an engineering programme with legal requirements, not a policy document with an engineering afterthought. Organisations that treat it the second way produce a compliant-looking front end sitting on top of an estate that cannot honour anything the front end promised, and the gap between the two is exactly what an audit or a data principal complaint exposes.
A necessary orientation before anything else, and it can now be given in dates rather than in hedges. The Act was passed in 2023 and left almost everything operational to rules. The Digital Personal Data Protection Rules, 2025 were notified in November 2025, and their commencement is staged. The rules constituting and governing the Data Protection Board took effect on notification. The consent manager registration rule takes effect twelve months later, in November 2026. The substantive tranche, which is where the notice, consent and data principal rights machinery sits, commences eighteen months after notification, which falls in May 2027.
Confirm the operative position against what has actually been notified on the day you act, because staged commencement produces exactly the confusion you would expect. But note what the staging does not give you. This article still describes what the architecture has to be capable of rather than counting down to a date, and the reason is not caution. It is that an estate which cannot honour a withdrawal takes longer to fix than the runway that remains.
What the Act Actually Asks of Consent
Strip out the vocabulary and the demands are concrete. Consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and it must signify agreement to processing for the specified purpose and be limited to the personal data necessary for that purpose. It has to be preceded or accompanied by a notice describing the personal data, the purpose, how a data principal exercises their rights, and how a complaint is made. Withdrawal must be as easy as giving consent was. And consent is only one basis for processing: the Act also provides for certain legitimate uses, which are a defined set rather than a general convenience.
Each of those clauses translates into a design constraint, and the translation is where the difficulty lives.
| What the Act requires | What it means for the system | Where implementations fail |
|---|---|---|
| Specific consent, for a stated purpose | Consent has to be stored against a purpose identifier, not as a single boolean on the user record. | A legacy column called `consent_given` with no purpose dimension, which cannot answer any question the Act asks. |
| Informed, preceded by notice | The exact notice text shown at the moment of collection has to be versioned and retrievable years later. | The notice lives in the front end code and changes with each release, so the version a given user saw is unrecoverable. |
| Clear affirmative action | Pre-ticked boxes, bundled acceptance and consent inferred from continued use are not designs the Act contemplates. | Growth teams optimising the funnel by bundling marketing consent into terms acceptance, usually without legal seeing the change. |
| Limited to necessary data | Purpose to data field mapping has to exist, so that collection can be justified field by field. | Nobody has ever inventoried which fields are collected for which purpose, so the necessity test cannot be applied at all. |
| Withdrawal as easy as giving | A self-service withdrawal path, and a propagation mechanism that reaches every downstream system. | A withdrawal that updates the primary database and nothing else, while the warehouse, the CRM and four vendors carry on. |
| Demonstrability | An auditable ledger showing who consented, to what, when, under which notice version, and through which interface. | Consent captured in application logs with a thirty day retention, which is to say not captured at all. |
The Inventory That Has to Come First
There is a strong temptation to start with the consent banner, because it is visible and it can be shipped. It is the wrong first move. A consent interface is a promise about what the organisation will and will not do with data, and you cannot make that promise credibly until you know what it does now.
The prerequisite is a data inventory that answers four questions for every category of personal data the organisation holds: what is collected, where it is stored, what it is used for, and who it is shared with. In a mid-sized company this is three to six weeks of unglamorous work, and it will surface things nobody expected. A support team exporting customer records into a spreadsheet for a weekly review. A product analytics tool receiving more identifiers than anyone realised. A recruitment pipeline holding candidate data from four years ago because nobody defined a retention period. A vendor whose contract lapsed but whose integration is still live.
You cannot design consent for processing you have not mapped. The inventory is not preparation for the work, it is most of the work.
Purpose Granularity: The Hardest Product Decision
Once the inventory exists, the organisation has to decide how finely to slice purposes. This is presented as a legal question and is really a product question with legal consequences, and it is where most consent programmes go wrong in one of two directions.
Too coarse
One purpose called improving our services, covering analytics, personalisation, marketing, model training and vendor sharing. It is easy to build and easy to consent to, and it fails the specificity requirement in a way that is obvious on inspection. It also means any new use is arguably already covered, which is exactly the reasoning the specificity requirement exists to prevent.
Too fine
Twenty three separate purposes presented as a wall of toggles at signup. This is defensible on paper and terrible in practice: users accept none of it, the conversion cost is real, the business blames legal, and within a year someone quietly reduces it back to a single checkbox without telling anyone.
The workable middle
Six to ten purposes that a reasonable person would recognise as genuinely different things, grouped so that each maps to an outcome the user can understand: fulfilling the service, communicating about it, marketing, personalisation, analytics and improvement, sharing with named categories of partner. Each one maps to a defined set of data fields and a defined set of systems.
The test that resolves arguments
Would a user be surprised. If separating two uses into different purposes would surprise nobody, combine them. If a user who agreed to one would object to the other, they are different purposes, whatever the internal team structure says. This test settles most granularity debates faster than a legal memo does.
Purpose design deserves a named decision maker and a written record of the reasoning, because it will be revisited every time the business launches something. Without the record, each revisit restarts the argument from zero.
Notice, Language, and the Consent Ledger
The notice accompanying a request for consent has to describe the personal data and the purpose, and to explain how rights are exercised and how a complaint is made. The Act also contemplates the notice being available in English and in the languages specified in the Eighth Schedule to the Constitution, at the data principal's option. For an enterprise with a consumer base across India that is not a translation task appended at the end of the project. It is a content management requirement, because every version of every notice in every language has to be produced, reviewed, published and, critically, retained.
The consent ledger
The single most useful artefact to build, and the one most often skipped, is an append-only consent ledger. Not a column on the user table. A separate record of consent events, each carrying the data principal identifier, the purpose, the action taken, whether given or withdrawn, the timestamp, the interface it came through, and a reference to the exact notice version displayed.
- Append-only, never updated in place. A consent record that is overwritten when a user changes their mind destroys the history you will need to evidence the earlier state.
- Versioned notice text stored separately and referenced by identifier. Storing the notice inline in every record is wasteful, storing only a URL is useless once the page changes. Store versions, reference them, and never delete a version that has been referenced.
- Purpose taxonomy held as data, not as strings in code. Purposes will change. When they do, you need to know which consents attached to the old definition.
- Retention that outlives the relationship. A consent record proves what happened. It has to survive longer than the processing it authorised, and its own retention basis needs to be articulated.
- Queryable by data principal and by purpose. The two questions you will actually be asked are what did this person consent to, and who has consented to this purpose. If the schema cannot answer both cheaply, it will be rebuilt.
On consent managers
The Act contemplates a consent manager: an entity registered with the Board through which a data principal can give, manage, review and withdraw consent, operating through an accessible, transparent and interoperable platform. This is a genuinely distinctive feature of the Indian framework and it materially changes how consent can flow for consumer-facing businesses. Rule 4 of the 2025 Rules puts the machinery in place, providing for application to the Board for registration on the conditions set out in Part A of the First Schedule, and for operation in accordance with the obligations in Part B. Those conditions are not nominal: incorporation in India, a minimum net worth, and demonstrated technical, operational and financial capacity are among them, which tells you the role was designed for a small number of substantial intermediaries rather than for anyone who fancies it.
Rule 4 takes effect twelve months after notification, in November 2026, ahead of the substantive tranche. The architectural implication for a data fiduciary is unchanged by any of the dates: design for consent that arrives from outside your own front end. A system that can only record consent captured in its own signup flow is a system that will need reworking rather than configuring when the first consent manager sends it a record.
Withdrawal Is the Real Engineering Problem
Collecting consent is a form. Honouring its withdrawal is a distributed systems problem, and it is where the difference between a compliant appearance and a compliant organisation becomes visible.
Consider what happens to a single customer record in a typical mid-sized Indian enterprise. It is created in the core application database. It is replicated to a data warehouse overnight. A subset syncs to the CRM. Marketing automation holds an email address and an engagement history. The support tool has a contact record and the text of every conversation. A product analytics platform holds an identifier and a behavioural stream. Finance holds billing details. A partner integration received a copy last quarter. And backups taken at intervals contain point-in-time copies of most of the above.
When that customer withdraws consent for marketing, updating the flag in the core database is the easy five per cent. The remainder is propagation, and it has to be designed.
Map every downstream destination for each purpose
For each purpose, list the systems that receive data under it, internal and external. This falls straight out of the inventory if the inventory was done properly, and is impossible to construct retrospectively if it was not. The list is the scope of what withdrawal has to reach.
Decide the propagation mechanism per destination
Some systems can be updated through an interface, some through a scheduled reconciliation, some only by suppression lists, and some only by a manual process with a named owner and an SLA. All four are acceptable answers. Not knowing which applies to a given system is not.
Instrument confirmation, not just dispatch
The mechanism has to record that the downstream system acknowledged the change, not merely that a request was sent. Demonstrability means being able to show that the withdrawal took effect, and a fire-and-forget integration cannot show that.
Handle backups and archives explicitly
Backups cannot usually be edited selectively, and this is a genuine tension rather than a solved problem. The workable approach is a documented position: what the backup retention period is, that restored data is reconciled against current consent state before use, and who is accountable for that reconciliation. A written, reasoned position is defensible. Silence is not.
Set and monitor a withdrawal SLA
Define how quickly withdrawal must be effective across the estate, measure the actual time from request to confirmed propagation, and report the tail. The average is not interesting. The slowest ten per cent is where the exposure is.
Build or Buy, and the Retrofit Problem
The build or buy decision is usually framed around the consent capture interface, which is the cheapest part to build and the least differentiated part to buy. The decision should be framed around the ledger and the propagation layer instead, because that is where the cost and the risk sit.
Buying makes sense when the organisation has many consumer-facing surfaces, several languages, and no appetite to maintain a consent service as a permanent internal product. It brings a tested data model, an audit interface, and someone else's obligation to keep pace with the framework as it develops. Its weakness is the last mile: no vendor knows your internal estate, so the propagation to your warehouse, your CRM and your bespoke systems is integration work you will do regardless.
Building makes sense when the estate is small enough to enumerate, when the organisation already has strong platform engineering, and when consent is genuinely entangled with the product experience. Its weakness is that consent management is never anyone's roadmap priority after the first release, and an unmaintained consent service degrades quietly.
The retrofit question nobody wants to ask
Every established organisation faces the same uncomfortable problem: it holds personal data collected before any of this, under notices that described purposes loosely or not at all, from people who cannot now be meaningfully said to have consented to what the data is used for today. The instinct is to leave it alone and get the new flows right. That is a decision, and it should be taken consciously, documented, and revisited. The realistic options are to re-obtain consent for the material purposes, to narrow the processing of legacy data to what is genuinely supportable, or to delete what cannot be justified. Deleting is unpopular, cheap, and very often the correct answer for data nobody has used in three years.
Who Owns This Internally
Consent programmes fail on ownership more than on any technical question. Legal owns the interpretation and cannot ship code. Engineering owns the systems and cannot decide what specificity requires. Security owns the controls and is measured on incidents rather than on purpose mapping. Marketing owns the surfaces where consent is actually collected and has an interest that runs the other way. In that arrangement, everyone can be diligent and the programme still does not move.
The arrangement that works is joint legal and engineering ownership with one named accountable person, a standing forum where purpose decisions are made and recorded, and an explicit rule that changes to consent surfaces go through it. Where the organisation is a Significant Data Fiduciary, additional obligations apply, including appointing a Data Protection Officer, engaging an independent data auditor and carrying out data protection impact assessments. Whether that category applies to you depends on notification criteria that must be checked. Either way, the practical lesson from the impact assessment concept is worth adopting voluntarily: assess new processing before it ships, not after.
A Realistic Sequence
For an enterprise starting from a privacy policy and a checkbox, the order matters more than the pace. Inventory first, because nothing downstream is meaningful without it. Then purpose design, with a named decision maker and a written rationale. Then the ledger, because it is the foundation the rest attaches to and retrofitting it later means losing the history in between. Then collection surfaces, which are the visible part and the part everyone wanted to start with. Then propagation, which is the largest single piece of engineering. Then the legacy data decision, taken deliberately rather than by default. Then rights handling, which shares infrastructure with everything above and is much cheaper once the ledger exists.
Two years is a realistic horizon for a large enterprise to complete that sequence properly, which is worth holding against the calendar: the substantive tranche of the 2025 Rules commences in May 2027. That is uncomfortable to say to a board that wants a compliance date, and it is more useful than a plan that produces a banner in six weeks and an unhonourable promise underneath it. The honest framing for a board is that the notice is the smallest part of the work, the ledger and the propagation layer are the real programme, and the organisation's exposure is proportional to the gap between what the front end says and what the estate can do.
Build for the state, not for the document
Consent under the DPDP Act is a state the organisation has to be able to create, evidence, keep accurate and unwind across everywhere the data went. A notice and a checkbox describe that state. They do not produce it. Start with the inventory, design purposes deliberately, build the ledger before the banner, and treat withdrawal propagation as the engineering programme it actually is. The dates are published now, with the substantive tranche of the 2025 Rules commencing in May 2027 and the consent manager rule in November 2026, so confirm them as notified on the day you plan against, and treat this article as commentary rather than as advice on your own facts.
Explore CourtMesh
