There is a question that almost never gets asked in enterprise data privacy discussions, but probably should be asked first: if your consent records are stored in a database, how do you prove that nobody has changed them?
Not how do you claim they haven't been changed. How do you prove it.
That distinction — between assertion and proof — is at the heart of why blockchain infrastructure and standard relational databases are not interchangeable options for consent management under India's Digital Personal Data Protection Act. They are fundamentally different answers to fundamentally different questions. And understanding the difference is essential for any organisation that will one day need to defend its consent practices in front of the Data Protection Board of India.
What a Database Actually Does
A relational database — MySQL, PostgreSQL, Oracle, Microsoft SQL Server, or any of their variants — is one of the most powerful and reliable tools in modern software engineering. It is extraordinarily good at storing, organising, and retrieving data. Most of the software the world runs on is built on top of databases, and for the overwhelming majority of applications, a well-designed database is exactly the right tool.
But there is something a database does not do, and was never designed to do: it does not provide independent, verifiable proof that the data it contains has not been altered since it was written.
A database trusts its administrators. When a record is written, the database stores it. When an administrator — or an application with the right credentials — updates that record, the database updates it. When someone deletes a row, the database deletes it. This is not a flaw. It is precisely how databases are designed to work. They are mutable by nature, because most applications need to update their data.
The problem arises when mutable data needs to serve as immutable evidence.
The Mutability Problem in Plain Terms
Consider a simple example. A bank's loan origination system captures consent from an applicant in June 2024. The consent covers credit assessment and identity verification. The record is stored in a database table with columns for customer ID, consent type, timestamp, and a boolean status field.
In March 2026, a new product team decides to use existing customer data for a marketing campaign. Someone — not necessarily with malicious intent — updates the consent records for a batch of customers to include "marketing" as an approved purpose. It takes one SQL UPDATE statement and thirty seconds.
UPDATE consent_records
SET purpose = 'credit_assessment, identity_verification, marketing'
WHERE customer_segment = 'personal_loans'
AND consent_date < '2025-01-01';The database executes the command. The records now show marketing consent that was never actually given. If the customer complains, or if the DPBI investigates, the organisation points to its consent records. The records say consent was given. There is no way — from inside the database — to prove that the record was altered after the fact.
This is not a hypothetical edge case. It is a structural vulnerability of every database system ever built, and it requires no malicious actor to create serious compliance exposure. A developer fixing what they think is a data entry error, a migration script that runs with broader permissions than intended, an automated process that appends a new purpose without creating a new record — any of these can silently compromise the evidentiary value of consent records without anyone intending to cause a problem.
What Cryptographic Proof Actually Means
Cryptography offers a different approach. A cryptographic hash function takes any input — a document, a record, a string of text — and produces a fixed-length output, called a hash or digest, that has two critical properties.
First, the same input always produces the same hash. Second, any change to the input — even changing a single character — produces an entirely different hash. This second property is called collision resistance, and it is what makes cryptographic hashing useful for data integrity verification.
Here is how this applies to a consent record. When a consent interaction occurs, the full record — customer identifier, consent notice text, timestamp, purposes, channel, affirmative action taken — is assembled and a cryptographic hash of that record is computed. That hash is a kind of fingerprint of the data at that exact moment.
If the record is later altered in any way — a purpose added, a timestamp adjusted, a status field changed — the hash of the modified record will be completely different from the original hash. Anyone comparing the current hash of the record against the original hash can instantly detect that something has changed, even if they cannot determine what specifically was altered.
This does not require trust. It requires mathematics. The hash function is deterministic and public — anyone with access to the original hash and the current record can independently verify whether they match. No authority needs to vouch for the integrity of the record. The proof is self-contained.
Why Blockchain Takes This Further
A cryptographic hash stored in the same database as the record it is meant to verify is only marginally better than no hash at all. An administrator with write access to the database can update the record and then update the hash to match. The hash has been compromised alongside the data.
This is where blockchain architecture provides something qualitatively different from anything a standard database can offer.
A blockchain is, at its core, a chain of blocks where each block contains a set of records and a cryptographic hash of the previous block. This chaining means that altering any record in any historical block changes the hash of that block, which invalidates the hash reference in the following block, which invalidates the block after that, cascading through the entire chain. Altering a single historical record would require recomputing the proof-of-work or proof-of-stake for every subsequent block in the chain simultaneously — a computational task that is effectively impossible on any network with meaningful participation.
But the deeper innovation of blockchain for enterprise consent management is not the chaining of hashes. It is the separation of the ledger from the administrator.
In a permissioned blockchain designed for enterprise use, the ledger is maintained across multiple nodes, each independently validating and storing the same records. No single node — and crucially, no single organisation — controls the ledger. When a consent record is written, it is witnessed and validated by the network. To alter that record retroactively, an attacker would need to simultaneously compromise a majority of nodes in the network — not just one database server, not just one admin credential, not just one application.
The result is a consent record whose integrity can be verified independently, by anyone with access to the network, without relying on the trustworthiness of any single party. The organisation that collected the consent cannot alter its own records undetected. A regulator can verify a consent record independently. An individual can verify their own consent history. The proof does not depend on who you trust. It depends on mathematics and distributed consensus.
The Architecture That Works: On-Chain Consent, Off-Chain Data
Before going further, it is worth addressing the most common objection to blockchain for consent management: if data on a blockchain cannot be deleted, how does this work with privacy rights like the right to erasure under the DPDP Act?
The answer is in the architecture.
A well-designed blockchain consent management system does not store personal data on-chain. It stores the consent record — what was consented to, when, by a pseudonymous identifier, and any subsequent modifications — on the immutable ledger. The personal data itself is stored off-chain, in encrypted storage, where it can be deleted in response to an erasure request.
The on-chain record contains no personal data. It contains a cryptographic reference to the consent interaction. Even after personal data is deleted, the consent audit trail remains intact — showing that consent was sought, what was agreed to, and that the data was subsequently erased. This architecture satisfies both the DPDP Act's consent audit requirements and its provisions for data erasure simultaneously. Neither requirement is sacrificed for the other.
Why This Matters Specifically for the DPDP Act
The Digital Personal Data Protection Act does not prescribe specific technologies. But its requirements, read carefully, point clearly toward the properties that only cryptographically verifiable infrastructure can reliably provide.
The evidentiary standard
When the Data Protection Board of India investigates a consent complaint, it will not ask whether you have consent records. It will ask whether you can prove those records accurately reflect what actually happened. A database record says "consent was given on this date for these purposes." A blockchain record, with its cryptographic audit trail, proves it — and proves that the record has not been modified since it was created. These are different categories of evidence.
The tamper-evidence requirement
Section 6 of the DPDP Act requires consent to be accurately recorded and maintained. Accuracy over time is not just about capturing the right information at the point of collection. It is about ensuring that the record remains accurate — that it cannot be silently modified as business needs evolve or as individuals withdraw consent. A mutable database provides no structural guarantee of this. An immutable ledger does.
The Consent Manager standard
The DPDP Act's Consent Manager framework — which begins registration in November 2026 — explicitly requires Consent Managers to maintain consent records with auditability, integrity, and accessibility. These requirements map directly onto the properties of blockchain infrastructure. An independent Consent Manager operating on a mutable database is, structurally, a weaker form of the trust architecture the Act is trying to create.
The withdrawal verification problem
When an individual withdraws consent, the organisation must cease processing. But how does the individual — or a regulator — verify that processing actually stopped? With a database, they cannot. They must trust the organisation's assurance. With a blockchain, the withdrawal event is recorded on an immutable ledger with a timestamp. Processing that occurs after the withdrawal timestamp is verifiably post-withdrawal. The audit trail is forensic, not self-reported.
Penalties that concentrate the mind
The DPDP Act permits the Data Protection Board to impose penalties of up to ₹250 crore for consent violations. At that level of exposure, the question of whether your consent records can withstand forensic scrutiny is not an academic one. An organisation defending itself before the DPBI with database records that a determined auditor could characterise as mutable — and therefore potentially manipulated — is in a weaker position than one presenting cryptographically verified records whose integrity can be independently confirmed.
A Direct Comparison
It is worth being concrete about what the difference looks like in practice.
Scenario: A customer claims they never consented to their data being used for cross-sell marketing.
With a database system:
The organisation produces a record showing consent was given on a specific date. The customer disputes this. The investigation must rely on the organisation's own records, maintained in systems the organisation controls, by administrators who have write access. The organisation asserts the record is accurate. There is no independent verification mechanism.
With a blockchain system:
The organisation produces a cryptographically verified record showing the exact consent interaction — including the notice that was presented, the specific purposes consented to, and the timestamp of the affirmative action. The hash of that record can be independently verified against the blockchain. Any modification to the record since it was written would be immediately detectable. The organisation does not need to assert accuracy. The architecture demonstrates it.
The difference in regulatory credibility between these two scenarios is significant. The difference in legal exposure could be enormous.
What This Means in Practice
None of this means that databases have no role in a DPDP-compliant data architecture. Databases remain the right tool for most application data management. The argument here is specific: for consent records, which must serve an evidentiary function under the DPDP Act, the structural limitations of mutable databases create compliance risk that mutable databases cannot solve from within.
Organisations evaluating their consent management infrastructure should ask themselves four questions:
Can you produce a consent record whose integrity does not depend on trusting your own administrators?
If the answer is no, a determined auditor can always question whether the record reflects what actually happened.
Can you demonstrate that a consent record has not been modified since it was created, without relying on your own assurance?
Self-reported record integrity is a weaker form of evidence than independently verifiable proof.
Can you provide a regulator with independent, verifiable proof of a consent interaction — not just a printout from your own systems?
The Data Protection Board will scrutinise the evidentiary chain, not just the existence of records.
Can you show that processing stopped after a withdrawal event, with a timestamp that is independently verifiable rather than self-reported?
The Act's withdrawal obligations require demonstrable cessation, not just an internal log entry.
If the answer to any of these is no, the consent infrastructure is not operating at the evidentiary standard the DPDP Act implies. A database stores what you tell it. A blockchain proves what happened.
Conclusion
The choice between a database and a blockchain for consent management is not primarily a technology choice. It is a choice about what kind of evidence you want to be able to produce when your consent practices are challenged.
For most data storage tasks, a database is faster, cheaper, more flexible, and easier to operate than a blockchain. There is no argument to be made for replacing databases across the board.
But for consent records — records that must withstand regulatory scrutiny, that must demonstrate they have not been manipulated, that must provide individuals and regulators with independent proof of what was agreed to and when — the structural properties of blockchain are not a nice-to-have. They are the closest thing to a perfect fit that current technology offers.
The DPDP Act has raised the evidentiary bar for consent management in India. The question every enterprise needs to answer is whether their current infrastructure can clear it.
This article is for informational purposes and does not constitute legal advice. Organisations should consult qualified legal counsel regarding their specific DPDP Act compliance obligations.