Skip to main content
Consent architecture, India

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.

Book a consent architecture reviewSee what has to change
Consent architecture and notice design for DPDP compliance
  • November 2026Rule 4 in force
  • Per purposeNot per signup
  • As easy to withdrawAs it was to give
  • Under 18Verifiable guardian consent
What lawful consent requires of your systems

Seven properties your consent record has to have.

The Act describes consent in legal terms. Translated into system requirements, it resolves into seven properties. A consent implementation is compliant when the record has all seven and broken when it is missing any one, and the one almost universally missing is the third.

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.

The data model

What a consent record has to contain.

This is the shape we implement. Each column exists because something downstream needs it: the notice version for provability, the purpose for specificity, the withdrawal path for the as-easy-as requirement, the cascade list for processors.
AttributeWhy it existsWhat breaks without it
Data principal identifierTies the consent to a person you can locate across systemsRights requests and withdrawal cannot be executed reliably
Purpose, itemisedConsent is given per specified purpose, not per accountYou cannot show what the individual actually agreed to
Notice version and text at time of consentConsent was to what the notice said then, not what it says nowProvability is lost the first time the notice is edited
Timestamp and capture mechanismEvidence of clear affirmative action at a point in timeNo defence against a claim that consent was never given
Status and full historyGranted, withdrawn or expired, with every transition retainedA withdrawal that overwrites the grant leaves no audit trail
Downstream recipientsThe processors and systems that received data under this consentWithdrawal cannot cascade, so processing continues unlawfully
Guardian verification, where applicableEvidence of verifiable parental or guardian consent for minorsProcessing children data with no defensible basis
How we approach it

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.

Where this gets hard

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.

Self-assessment

Twelve questions that tell you where your consent stands.

Run these against your own systems before talking to anybody. If you can answer yes to all twelve you are in a small minority and probably need very little from us. Most organisations answer yes to four or five, and the pattern of which ones fail tells you where the work is concentrated.

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
The gap in most implementations

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 registrationOne record per purpose, per individual
The notice
A privacy policy link in the footer, edited in place over timeA standalone, plain-language, itemised notice, versioned so consent is provable
Capture
Bundled with terms acceptance, sometimes pre-tickedSeparable, unbundled, clear affirmative action per purpose
Withdrawal
Email an address in the privacy policy and waitSelf-service, and no harder than granting was
Cascade
Updates the primary database onlyPropagates to every downstream system and processor
History
Current state only, overwritten on changeFull transition history retained and auditable
Children
A self-declared date of birth field, if anythingAge assurance plus verifiable guardian consent, no profiling
Interoperability
Bespoke to the applicationExportable 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
The engagement

Five stages from boolean to purpose-scoped.

  1. 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. 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. 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. 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. 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.

Questions we get asked

Consent under DPDP, answered plainly.

No. Rule 4 comes into force in November 2026 and provides for registered, India-based, independent Consent Managers to operate, giving individuals one place to give, review, manage and withdraw consent across multiple data fiduciaries. It creates the framework for them to exist; it does not compel every business to route consent through one. What it does mean is that individuals will increasingly expect to manage consent centrally, and that your consent has to be represented in a form an external platform could act on. That design implication is live now even though integration is optional.

That is a legal determination and it depends on what your records can evidence, which is exactly why we start with an audit. The test is whether the consent was free, specific, informed, unconditional and unambiguous, given by clear affirmative action against a notice that itemised the data and the purpose. Consent captured as a bundled acceptance with no record of purpose and no version of the notice shown is hard to defend against that test. Consent captured recently through a granular, unbundled flow usually survives. Most businesses find the answer differs by vintage, which is why a targeted re-consent campaign is more common than either extreme of doing nothing or starting over.

It means the effort has to be comparable, not that the mechanism has to be identical. If consent was one tap during checkout, withdrawal cannot require finding an email address in a privacy policy, composing a request and waiting. A self-service preference centre reachable from the account area and from every marketing email, where each purpose can be switched off individually and the change takes effect promptly, meets the standard comfortably. The failure mode we see most is a preference centre that records the change but is not wired to the systems that act on it, so the individual sees a confirmation and keeps receiving the messages.

It has to end up in the same record as digital consent, because a rights request or a withdrawal does not care how consent was captured. In practice that means the paper form has to be itemised and versioned like the digital notice, and the capture has to be entered into the consent store with the form version, date and purpose rather than filed in a drawer. Healthcare and clinic settings hit this hardest, where consent is taken at a counter under time pressure. The workable pattern is usually a tablet at the counter capturing directly into the system, with paper retained as a fallback rather than as the primary record.

Employees are data principals, but consent is usually the wrong basis for employment processing, because it is difficult to argue that consent given by an employee to their employer is freely given when refusing has career consequences. Most workforce processing rests on other grounds, such as performance of the employment contract or compliance with a legal obligation. The practical work for most employers is therefore removing consent language from HR processes where it was never the correct basis, rather than building consent machinery. Your counsel determines the basis; we implement the notice and the records that go with it.

The Act requires verifiable consent from a parent or lawful guardian before processing the data of anyone under eighteen, and prohibits targeted advertising and behavioural profiling directed at children. The Rules contemplate verification against reliable identity or virtual token details rather than a self-declaration. The engineering reality is that there is no single approved mechanism, so the defensible position is a documented age assurance approach proportionate to the risk of your service, plus a verification step for the guardian that is more than a tick box. If your product is not intended for children, you still need to be able to demonstrate the assurance you applied.

A cookie banner covers a narrow slice and is often the least important part. It addresses consent for tracking on your website. It does not address consent for the personal data you collect through signups, forms, in-store capture, call centres and partners, which is where most of your processing actually happens and where the Act bites hardest. Banners also tend to be bought as a plug-in and left with defaults that pre-tick categories or infer consent from continued browsing, both of which fail the clear affirmative action standard. We look at the banner, and we spend most of the engagement on everything else.

It depends almost entirely on whether your applications are configurable or need development. If consent lives in a commercial platform with a preference centre feature, much of this is configuration and integration work measured in weeks. If consent is a boolean column in a home-grown application, you are looking at a data model change, a migration of existing records, interface work on every capture point, and integration work for the cascade, which is a development roadmap item rather than a project we can complete for you unilaterally. We scope it after the audit, and we are explicit about which parts your development team has to own.

Yes, and it is the cheapest thing on this page to do and the most expensive to retrofit. Consent is consent to what the individual was told at the time. If your notice has been edited in place over three years with no history, you cannot demonstrate what any past consent was actually given against. Putting the notice under version control and stamping the version into every consent record takes very little effort today. Reconstructing what your notice said eighteen months ago after the fact is generally impossible.

You inherit their consent records and their problems with them. The acquired entity personal data comes with whatever basis it was collected under, and if their consent capture was weaker than yours then the weaker standard is what you now hold. This is worth doing as due diligence rather than discovering afterwards, because it is one of the few compliance findings that can genuinely affect what an acquisition is worth. The practical work post-completion is an audit of their consent records against the same test you applied to your own, a decision on which vintages carry forward, and a re-consent campaign for the rest. Merging two customer databases without doing this produces a single list where nobody can say which records are safe to market to, and unpicking that later is far harder than assessing it at the outset.

It depends on whether the processing is genuinely necessary for the purpose the individual already agreed to, or whether it is a separate purpose in its own right, and that is a determination for your counsel rather than for us. What we can tell you is where the engineering line usually falls. Aggregated analytics that cannot identify an individual is a different proposition from behavioural profiling tied to a person. If your analytics pipeline retains identifiers, and most do by default because it makes debugging easier, then you are processing personal data for a purpose that probably was not itemised in your notice. The cheapest fix is frequently technical rather than legal: strip or tokenise identifiers at ingestion so the analytics estate holds no personal data at all, which removes the question instead of answering it.

Yes. Consent work is audit, workshops, data model design and integration, all of which we deliver remotely and most of our engagements run that way. The one part that benefits from a site visit is auditing physical capture points, counters, reception desks, in-store tablets and paper forms, where watching how consent is actually taken tells you more than a description of how it is supposed to be taken. We are based in Gachibowli, Hyderabad and serve organisations across India, with senior engineers travelling where a site visit genuinely adds something. Initial enquiries get a reply within 4 business hours.
Related reading

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 more

DPDP data mapping

The discovery work that tells you which downstream systems and processors a withdrawal has to cascade to.

Learn more

Microsoft Priva

Privacy risk management and subject rights request handling for organisations already running on the Microsoft stack.

Learn more
References

Official documentation

Next step

Find 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.

Book a consent architecture reviewSee the full DPDP obligation set

Related Services

Explore more solutions that work great with this service

DPDP Act Compliance

The engineering half of DPDP, not the legal one

Learn more

DPDP Data Mapping

Find the personal data you actually hold

Learn more

Microsoft Priva

Privacy risk management and compliance

Learn more

Microsoft Purview

Data governance and compliance solutions

Learn more