India's Digital Personal Data Protection Act 2023 has introduced a deceptively simple mandate: before you collect or process personal data, you must obtain the individual's consent. On the surface, this sounds like something most organisations already do — a checkbox here, a terms acceptance there. But the DPDP Act means something fundamentally different by consent, and the gap between what organisations have been doing and what the Act actually requires is wider than most compliance teams have yet appreciated.
The critical word is not "consent." It is "proof."
The DPDP Act does not merely require that consent was obtained. It requires that consent can be demonstrated — to regulators, to auditors, and to individuals themselves — as valid, specific, informed, and freely given at the moment it was captured. That distinction, between obtaining consent and being able to prove its validity, changes everything about how organisations need to think about their consent infrastructure.
What the DPDP Act Actually Requires
Section 6 of the Digital Personal Data Protection Act lays out the conditions under which a Data Fiduciary — any organisation that determines how and why personal data is processed — may collect personal data from individuals. The consent obtained must satisfy five conditions simultaneously:
- Free — the individual must not be coerced, pressured, or incentivised into giving consent. Consent bundled as a condition of accessing a service, where refusing means being denied the service entirely, is not valid consent under the Act.
- Specific — consent must be sought separately for each distinct purpose for which data will be used. A single consent for "marketing and analytics and third-party sharing and product improvement" is not specific. Each purpose requires its own consent interaction.
- Informed — before giving consent, the individual must have received a notice that clearly explains what data is being collected, why, how it will be used, who it may be shared with, and for how long. The consent is only valid if the notice preceded it and was comprehensible.
- Unconditional — there can be no conditions attached to withdrawal. The individual must be able to withdraw consent at any time, and the process of withdrawal must be as straightforward as the process of giving consent.
- Unambiguous — consent must be demonstrated through a clear, affirmative action. Silence, inaction, pre-ticked boxes, and implied consent through continued use of a service are all explicitly invalid.
These five conditions are not new to global privacy law — they largely mirror the GDPR's consent standard. What is new in the Indian context is the enforcement architecture being built around them and the specific obligations around maintaining records that can demonstrate compliance.
The Proof Problem
Here is where organisations face a challenge that is easy to underestimate.
Most existing consent systems were designed to collect consent, not to prove it. A typical implementation captures a timestamp and a boolean flag — "user accepted on [date]" — stored somewhere in a CRM or database. This was adequate when consent was primarily a formality and enforcement was theoretical.
Under the DPDP Act, consent records serve an evidentiary function. When the Data Protection Board of India investigates a complaint or conducts an inquiry, it will ask an organisation to produce evidence that a specific individual, at a specific point in time, was presented with a specific notice, understood its contents, and gave affirmative consent to a specific set of purposes. The organisation must be able to answer every element of that question reliably and completely.
This is not a documentation exercise. It is a forensic one. And the difference has profound implications. Consider what a regulator will actually scrutinise when examining a consent record:
Was the notice presented before consent was captured?
Not after, not bundled with a wall of terms and conditions, but specifically before the consent interaction. The sequence matters. Many existing implementations capture consent at the start of a form and present the notice buried elsewhere on the page, or link to a separate document. Under the DPDP Act, the notice and the consent must be demonstrably linked.
Was the consent interaction genuinely affirmative?
A pre-ticked checkbox that the user did not uncheck is not affirmative consent. The record must show that the user performed a positive action — a click, a tap, a signature — that corresponds to their agreement.
Was consent specific to the purpose for which data is now being used?
If an organisation obtained consent for email marketing in 2024 and is now using that data for credit risk assessment in 2026, the consent record from 2024 does not cover the new use. The organisation must show a separate consent interaction for the new purpose.
Has consent since been withdrawn?
If an individual withdrew consent at any point after initially granting it, processing that began after the withdrawal date is a violation, regardless of what the original consent record shows. The organisation's records must capture the full history of each consent relationship — not just its beginning.
Is the record itself trustworthy?
This is the question most organisations have not yet thought through. A consent record stored in a standard relational database can be modified. A timestamp can be changed. A status field can be updated. If the integrity of the record itself cannot be independently verified, its evidentiary value is limited. An organisation cannot simply assert that its consent records are accurate — it needs to demonstrate that they have not been altered since they were created.
Why Standard Systems Fall Short
The proof problem exposes structural weaknesses in how most organisations currently manage consent.
CRM systems
Built to manage customer relationships, not consent lifecycles. They store data about people, but they do not typically maintain immutable, timestamped logs of every consent interaction. Records can be overwritten, fields can be updated, and there is usually no mechanism for detecting or preventing retroactive modification.
Homegrown consent forms
Built by development teams to satisfy a specific product requirement, these typically capture the minimum required to complete a transaction. They were not designed with regulatory scrutiny in mind. The logs they generate are usually housed in the same database as the rest of the application data, with the same access controls and the same vulnerability to modification.
Cookie consent managers
The familiar banners that appear on websites were designed primarily for GDPR cookie compliance. They handle browser-level consent preferences reasonably well but are not equipped for the broader consent management obligations of the DPDP Act, which extend to every data collection interaction, not just cookies.
Manual processes
Paper forms, call centre scripts, and email confirmations generate consent records that are difficult to query, impossible to audit at scale, and extremely vulnerable to gaps and inconsistencies.
None of these systems, individually or collectively, were designed to answer the forensic question a regulator will ask. They were designed to facilitate transactions. The DPDP Act requires them to serve as evidence.
The Technology Implications
Complying with the DPDP Act's consent requirements is not primarily a legal challenge. It is an infrastructure challenge. Organisations need to think carefully about what properties their consent management systems must have to satisfy the Act's evidentiary standard.
Immutability
Once a consent record is created, it must not be possible to alter it without that alteration being detectable. This is a stronger requirement than simply "keeping good records." A well-intentioned organisation might update a consent record to correct an error and inadvertently destroy its evidentiary value. A less well-intentioned actor might alter records to conceal non-compliance. The consent infrastructure must make both impossible.
Traditional database architectures do not provide immutability by default. Ensuring it requires additional engineering — audit logging, write-once storage, cryptographic hashing of records at the time of creation — or the use of infrastructure that is immutable by design.
Cryptographic approaches are particularly relevant here. A consent record that is cryptographically hashed at the moment of creation carries a verifiable fingerprint. Any subsequent modification to the record changes its hash, making the alteration immediately detectable. This is not a new concept — it is the same principle used to verify the integrity of software packages, legal documents, and financial records — but its application to consent management is only now becoming a practical necessity.
Distributed ledger technology takes this a step further. When consent records are written to an append-only distributed ledger, they cannot be altered or deleted by any single party, including the organisation that created them. The record is witnessed by the architecture of the system itself. This structural immutability — as opposed to procedural controls that depend on humans following rules — is the highest standard of consent record integrity currently achievable.
Completeness
A consent record is only evidentially useful if it captures the full context of the consent interaction: the exact text of the notice that was presented, the specific purposes for which consent was requested, the timestamp of the interaction, the channel through which it occurred, and any subsequent modifications including withdrawal. Partial records create gaps that regulators will notice.
Completeness is harder to achieve than it sounds. In large organisations, consent interactions happen across dozens of touchpoints — web forms, mobile apps, call centres, in-branch interactions, third-party integrations. Maintaining a unified, complete consent record across all of these touchpoints requires deliberate architecture, not just a policy directive.
Accessibility
The DPDP Act grants individuals the right to access information about their consent. An organisation must be able to respond, within defined timelines, to a request from an individual asking what data is held about them, what consents have been given, and what processing is taking place under those consents. This requires consent records to be queryable by individual — a seemingly simple requirement that many organisations' current systems cannot satisfy without significant manual effort.
Auditability
Beyond individual access requests, the DPDP Act's regulatory framework implies that organisations must be able to produce consent records on demand for regulatory inspection. The consent infrastructure must support audit — not just record-keeping. This means maintaining records in a format that can be exported, reviewed, and independently verified, and ensuring that the chain of evidence from consent interaction to stored record is unbroken and demonstrable.
Scalability
For large organisations — banks with tens of millions of customers, insurers with complex policyholder data, e-commerce platforms with high transaction volumes — consent management at scale is a genuine engineering problem. The consent infrastructure must be capable of handling millions of interactions without degradation, maintaining record integrity across all of them, and querying the full history of any individual's consent interactions within the response timeframes the Act specifies.
The Consent Manager Framework
The DPDP Act introduces a specific category of regulated intermediary to address the complexity of consent management at scale: the Consent Manager. Registered with the Data Protection Board of India and accountable to individuals rather than to the organisations using their data, Consent Managers provide a neutral layer between individuals and the enterprises that process their data.
The structural logic of the Consent Manager is important. By placing consent management with an independent, regulated intermediary rather than with the Data Fiduciary itself, the Act creates a separation of concerns that addresses the proof problem directly. An organisation cannot manipulate consent records that are managed by an independent third party. An individual's consent history is not dependent on any single company's systems remaining intact and accurate. The regulatory framework creates accountability at the infrastructure level, not just at the policy level.
The Consent Manager registration process, which opens in November 2026 under the DPDP Rules timeline, will set out the technical and governance requirements that Consent Managers must meet. These requirements will effectively define the minimum standard of consent infrastructure for the Indian market — and they will reflect everything discussed above: immutability, completeness, accessibility, auditability, and scalability.
What This Means for Organisations Now
The compliance deadline of May 2027 is not as distant as it appears. Building or procuring consent infrastructure that meets the DPDP Act's evidentiary standard takes time — time to evaluate options, time to integrate with existing systems, time to migrate historical consent records where possible, and time to train teams on new processes.
Organisations that wait until 2027 to begin will find themselves making rushed decisions under regulatory pressure. Organisations that begin now can approach the problem methodically and build something that serves them beyond compliance — as a genuine trust layer between them and their customers.
The questions every organisation should be asking today:
Can you produce, within 48 hours, a complete and verified history of every consent interaction for any specific individual?
If the answer requires manual effort across multiple systems, the infrastructure is not adequate.
Can you demonstrate that your consent records have not been altered since they were created?
If the answer relies on internal access controls and trust in your own systems, the evidentiary standard may not be met.
When an individual withdraws consent, can you verify that processing stopped within the timeframe the Act requires?
If withdrawal is handled manually or through a ticket-based process, the latency creates compliance risk.
Are your consent flows specific to each processing purpose, and can you show that each purpose was separately presented and accepted?
If a single consent captures multiple purposes, it does not meet the specificity requirement.
Are your consent notices available in the relevant Indian languages for your user base?
The DPDP Rules require accessibility in all 22 scheduled languages. English-only consent flows are not sufficient for most Indian consumer-facing organisations.
A Note on Technology Choice
The DPDP Act does not prescribe specific technologies for consent management. It specifies outcomes — valid consent, verifiable records, accessible audit trails — and leaves organisations to determine how to achieve them. This is deliberate. Technology evolves; outcomes persist.
What the Act's requirements do imply, however, is a shift in the architectural philosophy that organisations bring to consent management. The question is no longer "how do we capture consent?" It is "how do we build a system whose records will be trusted by a regulator, an auditor, and a court?"
That question has a different answer depending on the organisation's scale, sector, and existing infrastructure. For some, enhanced audit logging on existing database systems may be sufficient. For others, the combination of regulatory scrutiny, transaction volume, and third-party data sharing creates requirements that only purpose-built, integrity-by-design infrastructure can meet.
The emergence of distributed ledger technology as a foundation for consent management is not a coincidence. Immutability, cryptographic verification, and append-only record-keeping are properties that map directly onto what the DPDP Act requires consent records to be. Whether those properties are delivered through blockchain-based infrastructure, cryptographic audit logs, or some future technology is a secondary question. The primary question is whether the system can produce, under regulatory scrutiny, records that no party — including the organisation itself — can credibly be accused of having manipulated.
That is the standard the DPDP Act sets. It is a higher standard than most organisations are currently meeting. And the time to build towards it is now.
Conclusion
Consent under the DPDP Act is not a checkbox. It is not a terms-and-conditions acceptance. It is not a pre-ticked box or a vague authorisation buried in fine print. It is a specific, informed, freely given, affirmative agreement — for each purpose, at each interaction — backed by records that must withstand forensic scrutiny.
The organisations that understand this distinction early will build consent infrastructure that is genuinely compliant, genuinely trustworthy, and genuinely useful as a competitive differentiator in a market where data trust is becoming a material factor in enterprise purchasing decisions.
The organisations that treat consent as a documentation formality will find, when enforcement begins, that their records cannot answer the questions regulators will ask.
The DPDP Act has defined what valid consent looks like. The technology question — how to prove it — is now the most important infrastructure question in Indian data governance.
This article is for informational purposes and does not constitute legal advice. Organisations should consult qualified legal counsel for guidance on their specific DPDP Act compliance obligations.