Most systems can record a yes. Very few can say what it was for, or take it back.
Under the DPDP Act consent has to be free, specific, informed, unconditional and unambiguous, and withdrawal has to be as easy as giving it was. That last clause is where almost every implementation fails, because consent was built as a boolean on a signup form rather than as a record of which purpose an individual agreed to and a mechanism that can unwind it across every downstream system. Registered Consent Managers arrive under Rule 4 in November 2026, and interoperating with them assumes your consent is purpose-scoped in the first place.
- November 2026Rule 4 in force
- Per purposeNot per signup
- As easy to withdrawAs it was to give
- Under 18Verifiable guardian consent
Seven properties your consent record has to have.
Specific to a purpose, not to a signup
Consent is given for a specified purpose, and Rule 3 requires the notice to carry an itemised list of the data and the specific purpose for each. That means one individual can hold several consents at once: yes to processing an order, no to marketing, yes to a loyalty programme. A single boolean on a registration form cannot represent that, which is why almost every existing implementation has to be reworked at the data model rather than the interface.
Given by clear affirmative action
Pre-ticked boxes, consent inferred from continued use, and bundled acceptance where agreeing to terms of service also agrees to marketing all fail the standard. The affirmative action has to be unambiguous and it has to be separable per purpose. In practice this is a redesign of the signup and checkout flow rather than a copy change, and it is worth doing once properly because the pattern then repeats everywhere.
Withdrawable as easily as it was given
If consent took one click at signup, withdrawal cannot require an email to a support address and a five day wait. This is a statutory requirement rather than a courtesy, and it is the single most common gap we find. It usually means building a preference centre the individual can reach without assistance, and wiring it to actually change processing rather than to record a preference nobody acts on.
Able to cascade to processors
When consent is withdrawn, every downstream system and every processor that received the data has to stop. Marketing automation, the analytics platform, the SMS gateway, the partner who received a list. If withdrawal updates your database but your email platform keeps sending, you have not honoured it. This is integration work, and it is the part most commonly discovered late because it is invisible from the interface.
Provable long after the fact
You have to be able to demonstrate that a specific individual gave consent for a specific purpose at a specific time, on the basis of a specific notice. That means versioning the notice, because a consent given against the 2024 notice was consent to what that notice said, not to what your current one says. Almost nobody versions the notice, and it is a small change now that is impossible to reconstruct retrospectively.
Interoperable rather than bespoke
Rule 4 comes into force in November 2026 and provides for registered, India-based, independent Consent Managers running an interoperable platform where an individual gives, reviews, manages and withdraws consent across multiple data fiduciaries from one place. Whether or not you integrate with one immediately, the design implication is now: consent has to be represented in a form that can be exported, reconciled and acted on by an external platform, which rules out a boolean buried in a users table.
Guardian-verified where the individual is a child
Processing the data of anyone under eighteen requires verifiable consent from a parent or lawful guardian, and targeted advertising and behavioural profiling directed at minors are prohibited outright. The engineering questions are age assurance and how verification is performed, and the answer has to be defensible rather than a self-declared date of birth field where the honest expectation is that it is ignored.
Unconditional, so it cannot be coerced
Consent cannot be conditioned on providing more data than is necessary for the purpose. A service that refuses to function unless the individual also agrees to marketing has not obtained free consent for the marketing. This tends to surface as a product decision rather than an engineering one, and it is worth resolving early because the alternative is a growth mechanic that has to be dismantled later.
What a consent record has to contain.
| Attribute | Why it exists | What breaks without it | |
|---|---|---|---|
| Data principal identifier | Ties the consent to a person you can locate across systems | Rights requests and withdrawal cannot be executed reliably | |
| Purpose, itemised | Consent is given per specified purpose, not per account | You cannot show what the individual actually agreed to | |
| Notice version and text at time of consent | Consent was to what the notice said then, not what it says now | Provability is lost the first time the notice is edited | |
| Timestamp and capture mechanism | Evidence of clear affirmative action at a point in time | No defence against a claim that consent was never given | |
| Status and full history | Granted, withdrawn or expired, with every transition retained | A withdrawal that overwrites the grant leaves no audit trail | |
| Downstream recipients | The processors and systems that received data under this consent | Withdrawal cannot cascade, so processing continues unlawfully | |
| Guardian verification, where applicable | Evidence of verifiable parental or guardian consent for minors | Processing children data with no defensible basis |
Consent is a data model problem wearing an interface costume.
We start at the data model, not the banner
Most consent projects begin with a cookie banner because that is the visible part. The banner is the easiest piece and it is not where compliance is won or lost. We start by designing the consent record, because everything else, the interface, the preference centre, the cascade, the export to a Consent Manager, is downstream of whether the record can represent purpose, version and history.
We map the cascade before we build it
Withdrawal is only real if it reaches every system that received the data. That means knowing which systems those are, which comes straight off the data map. Where the map does not exist we build the portion we need, because implementing withdrawal without knowing its blast radius produces a feature that looks right and does not work.
We build for November 2026 rather than to it
Rule 4 arrives in November 2026 and most businesses will not integrate with a Consent Manager on day one. The design decisions that make integration possible later, purpose-scoped records, stable identifiers, exportable state, are nearly free now and expensive to retrofit. We build so the integration is a connector rather than a re-platform.
We record the basis, your counsel determines it
Whether consent is the right lawful basis for a given purpose, whether legitimate uses apply instead, and whether your historic consent survives are legal determinations. We implement what your counsel decides and give them an accurate account of what your systems currently hold. We do not offer legal advice, and a vendor that does is selling you a risk rather than a service.
Sectors with the most consent rework ahead.
Retail, D2C and loyalty
The largest volume of consent and the weakest provenance. Lists merged from acquisitions and campaigns, marketing consent bundled into account creation, and no record of which notice anybody saw. Usually the strongest candidate for a structured re-consent campaign.
Education and edtech
Processing children data by definition, so verifiable guardian consent and the profiling prohibition attach to everything. Age assurance is a genuine engineering problem here rather than a checkbox, and the prohibition on targeted advertising to minors can affect the business model.
BFSI and fintech
Multiple overlapping bases, since a good deal of processing is statutory rather than consent-based. The work is separating what genuinely rests on consent from what rests on legal obligation, so the preference centre does not offer withdrawal of something that cannot lawfully be withdrawn.
Healthcare and diagnostics
Consent captured at a counter on paper or on a shared terminal, with the record living in a practice management system that was never designed to hold purposes. Reconciling paper consent with digital records is the specific hard problem.
SaaS and platforms
Frequently processing on behalf of customers rather than as fiduciary, so the first task is establishing which role applies to which flow. Where you are the processor, the consent obligation sits with your customer and your job is to give them the controls to honour it.
Employers with workforce data
Consent is a weak basis in an employment relationship because it is difficult to argue it was freely given. Most workforce processing rests on other grounds, and the rework is usually removing consent language that was never the right basis rather than building consent machinery.
Twelve questions that tell you where your consent stands.
The record
- Can you list the distinct purposes you process personal data for?Not categories of data. Purposes
- Can one individual hold different consent states for different purposes?If consent is one column, the answer is no
- Do you store which version of the notice was shown at the time?Without it, past consent is unprovable
- Is the full history of grants and withdrawals retained rather than overwritten?A status field alone destroys the audit trail
The capture
- Is marketing consent separable from accepting terms of service?Bundled acceptance is not free consent
- Are all consent boxes unticked by default?Pre-ticked fails the affirmative action standard
- Does the service still work if somebody declines optional purposes?Otherwise consent is conditional
- Is consent taken on paper or at a counter recorded into the same store?A drawer is not a consent record
The withdrawal
- Can an individual withdraw without contacting a human?It has to be as easy as granting was
- Does withdrawal reach your email and messaging platforms automatically?The most common silent failure
- Do you know every processor that received data under each consent?You cannot cascade to a list you do not have
- Could you export consent state for one individual in a portable form?This is what Consent Manager interoperability assumes
What you probably have against what the Act requires.
| Feature | Aspect | Typical implementation today | What the Act requires |
|---|---|---|---|
Granularity | One flag per user, set at registration | One record per purpose, per individual | |
The notice | A privacy policy link in the footer, edited in place over time | A standalone, plain-language, itemised notice, versioned so consent is provable | |
Capture | Bundled with terms acceptance, sometimes pre-ticked | Separable, unbundled, clear affirmative action per purpose | |
Withdrawal | Email an address in the privacy policy and wait | Self-service, and no harder than granting was | |
Cascade | Updates the primary database only | Propagates to every downstream system and processor | |
History | Current state only, overwritten on change | Full transition history retained and auditable | |
Children | A self-declared date of birth field, if anything | Age assurance plus verifiable guardian consent, no profiling | |
Interoperability | Bespoke to the application | Exportable and reconcilable with a registered Consent Manager |
Existing consent may not carry forward.
The uncomfortable question in every consent project is what happens to the consent you already hold. If it was captured as a bundled acceptance, without an itemised notice, with no record of purpose and no version of what the individual was shown, it is difficult to argue it meets the standard the Act sets. That does not automatically mean deleting your database, and the answer is a legal determination your counsel makes rather than one we make. What we can tell you is what your records actually contain, which is the input that determination needs.
- Audit what your existing consent records can and cannot evidence, per purpose
- Expect the answer to differ by vintage, since capture practice usually changed over time
- Plan for a re-consent campaign as a possible outcome and design it before you need it
- Re-consent is far cheaper to run once, properly, than repeatedly as gaps surface
Five stages from boolean to purpose-scoped.
- 1
Audit what your consent records actually contain
Every capture point inventoried, from the website signup to the in-store tablet to the paper form at reception, and every consent store examined for what it can evidence. The output is a plain statement of which purposes you can prove consent for, which you cannot, and how that differs by vintage.
- 2
Define the purposes with the business
Purposes have to be specific and they have to be the real ones. This is a workshop rather than a technical task, and it is where most of the value is, because a purpose list that is honest and stable is what the notice, the consent record and the preference centre are all built against. Your counsel determines lawful basis per purpose alongside this.
- 3
Design the record and the notice together
The consent data model implemented with purpose, notice version, timestamp, capture mechanism, status history and downstream recipients. The notice rewritten as a standalone, plain-language, itemised document and put under version control so consent remains provable after it changes.
- 4
Build capture, preference centre and cascade
Signup and checkout flows reworked so each purpose is separable and unbundled. A self-service preference centre where withdrawal is no harder than granting. And the cascade wired to every downstream system and processor, which is the part that turns a preference into an actual change in processing.
- 5
Re-consent where needed, then keep it maintainable
Where existing consent cannot carry forward, a structured campaign designed to be run once rather than repeatedly. Then the operating discipline: new purposes go through the same definition step, the notice is versioned on every change, and new processors get added to the cascade at procurement rather than at the next audit.
Consent under DPDP, answered plainly.
What sits either side of this.
DPDP Act compliance
The full obligation set and the phased timeline, and where consent sits among the other six duties.
Learn moreDPDP data mapping
The discovery work that tells you which downstream systems and processors a withdrawal has to cascade to.
Learn moreMicrosoft Priva
Privacy risk management and subject rights request handling for organisations already running on the Microsoft stack.
Learn moreFind out what your consent records can actually prove.
The audit is the useful first step and it usually produces a clearer answer than expected: some vintages of consent are fine, some are not, and the re-consent campaign is smaller than feared. Tell us where consent is captured today and we will tell you what the rework looks like. Remote-first from Hyderabad, serving all of India.
Related Services
Explore more solutions that work great with this service