A consent checkbox is not evidence. Here’s what is.

Every system that asks for consent stores the answer. Almost none of them store evidence. The difference does not matter until a Data Protection Officer, an auditor or the Data Protection Board asks you to show that a particular person agreed to a particular thing on a particular day — and then it is the only thing that matters.

What the DPDP Act asks that a checkbox cannot answer

India’s Digital Personal Data Protection Act puts the burden of proof on the data fiduciary. That is you. Consent has to be free, specific, informed and unambiguous, tied to the notice the person actually saw, and withdrawable as easily as it was given. Each of those words turns into a question you have to answer with a record:

• Specific to what? Which purpose, named separately, not bundled into one blanket agreement.
• Informed by what? Which version of the notice was on screen at that moment.
• When? A timestamp you can defend, in order, relative to every other event.
• And since then? Whether the record has been altered, and how you would know.

A consent_given: true column answers none of these. It tells you the state of a decision, not its history. Overwrite it on withdrawal and the earlier grant disappears; keep it and you cannot say which notice it referred to.

Why the usual record does not survive scrutiny

We have looked at a lot of these while migrating customers. Three failures repeat.

The record is mutable. Consent lives in a row on the user profile that the application updates in place. Anyone with database access, and every migration script that has ever run, could have changed it. Nothing in the system would show that it had been.

The notice is not versioned. The privacy notice is a page on the website. It was edited in March. Whether the person who agreed in February saw the old wording or the new one is now unanswerable.

Withdrawal is a deletion. Somebody opts out, the row is removed, and with it the proof that processing was lawful for the eleven months before that. The obligation to show lawful processing does not end when consent does.

Append-only, and what that has to mean in practice

“Append-only” is easy to claim and easy to get wrong, because the honest version means giving up abilities you normally want. In Learnify a consent event can be written and read. It cannot be updated or deleted — not by an administrator, not by support, not by us. That is enforced in three places rather than one, on the principle that a single guard is a guard someone will route around:

• At the schema, where update and delete operations throw before they reach the database.
• In the data layer, where the mutating functions exist only as stubs that refuse.
• At the API, where the routes that would edit or remove an entry answer 405.

Withdrawal, then, is not an edit. It is a new event that says consent was withdrawn, appended after the one that granted it. The ledger holds both, in order, forever. That is also what makes the “as easy to withdraw as to give” requirement checkable rather than aspirational: both actions leave the same kind of mark.

Notices are versioned alongside it. Every event names the version of the notice the person was shown, so “informed” is a fact you can retrieve years later rather than a claim about what your website used to say.

The chain, and what it does and does not prove

Each entry carries a SHA-256 hash computed over the previous entry’s hash together with the identity, purpose, event type, notice version and timestamp of this one. The first entry hashes a fixed seed. Every subsequent entry therefore depends on the entire history before it, and a verification endpoint walks the chain and reports the first link that does not reconcile.

The practical effect: you cannot quietly change one consent event. Altering a field that the hash covers breaks that entry and every entry after it, and the break is visible on demand rather than at the point where somebody has already been asked to explain it in a hearing.

Now the part most vendors leave out. A hash chain is tamper-evident, not tamper-proof. Ours is an unkeyed digest, so someone with direct write access to the database and enough motivation could recompute a consistent chain from the point they changed onward. It also covers the fields that establish the consent decision itself — who, which purpose, which event, which notice version, when — and not the contextual ones such as channel, language or device, which are recorded but not chained.

We say that plainly because the alternative is worse. A control you have oversold is a control your auditor will eventually test, and the moment it fails to do what your marketing said, every other claim you have made goes on the list too. What this chain buys you is a specific, defensible statement: the consent decisions in this ledger are in the order they happened and have not been edited since, and here is the endpoint that demonstrates it.

Consent is one record. The obligation is wider.

Evidence of consent is necessary and not sufficient. Alongside the ledger, the machinery that a data-protection review actually asks about is the boring part: data-rights requests recorded against statutory deadlines, exports that run against the real records rather than a report, erasure that runs on a grace window and then anonymises in place — so a certificate someone earned in 2024 stays valid while the person behind it becomes unidentifiable — and a retention period that does nothing until you set it, then does exactly that, on schedule.

The ledger is the part people underestimate, because it is the part that has to be right before anything was written, not after somebody asks.

Five questions worth asking any vendor

Whether or not you look at Learnify, these five separate a consent feature from consent evidence. Ask them of your current system too.

1. Can an administrator edit or delete a consent record? If yes, it is a preference store, not evidence. Ask them to try it in front of you.
2. Does each record name the version of the notice shown? Without it, “informed” is undemonstrable.
3. What happens on withdrawal? An appended event keeps your proof of lawful processing for the period before it. A deletion destroys it.
4. How would you detect tampering — and can you show me? Ask for the verification mechanism, and ask what it does not cover. A vendor who cannot name a limitation has not thought about it.
5. Who holds the keys, and where does the data sit? Ask about the region, and ask what happens to consent records when a retention policy fires.

Learnify is AWS Qualified Software: Amazon Web Services reviewed our cloud architecture, security and operational reliability against their own requirements. That is worth something in a vendor review, and it is not the same thing as the four answers above. Those you should make us give you in writing.

If you would like to see the ledger, the notice versions and the request lifecycle on your own data, start a workspace and load one policy. It takes about an afternoon.