What counts as evidence, in a DPBI inquiry.
When the Data Protection Board of India opens an inquiry, it does not ask whether you say you obtained consent. It asks you to prove it — and a database row that any administrator could have edited is not proof. This is the difference between a claim and evidence, and why the mechanism behind your records is the whole game.
A claim is not evidence.
Most organisations conflate having a record with being able to prove it. The Board does not.
A claim is an assertion that something happened: "the user consented on this date." A claim with a record is slightly better — a row in a table that says the user consented on that date. But if that row could have been written, edited, or back-dated at any time by anyone with database access, it proves nothing about what actually happened. It is still, in evidentiary terms, just a claim.
Evidence is a record whose integrity is independently checkable — where any alteration is detectable, and the time of the event is bound by a party with no stake in the outcome. The gap between "we have a record" and "we have evidence" is exactly the gap a DPBI inquiry probes.
The alterability of database logs.
The trouble with ordinary logs is not that they are wrong — it is that nothing about them rules out their being wrong.
A standard application or database log records consent events faithfully in the normal course. But it carries no proof of its own integrity. A database administrator can update a consent flag, change a timestamp, delete a row, or insert a back-dated one — and the log itself shows no sign that anything happened. The record after tampering looks identical to a record that was never touched.
That is fatal in an evidentiary setting. If the platform cannot rule out silent alteration, then every record it holds is, at best, an assertion the Fiduciary makes about itself. The Board has no reason to take an unverifiable self-assertion as proof, and neither would a court.
How hash chains make tampering self-evident.
The first move is to make any change to the record break something visible.
A SHA-256 hash chain links each consent record to the one before it: every record includes a cryptographic fingerprint that incorporates the previous record's fingerprint. Change any record — a flag, a timestamp, a single byte — and its fingerprint changes, which breaks the link to every record that came after it. The tampering is not hidden; it is mathematically self-evident the moment anyone re-computes the chain.
Layered on top, RSA digital signatures sign each record so its origin and integrity can be cryptographically verified, and append-only storage enforces at the database level that the ledger only ever grows — no updates, no deletes. Together these mean a record cannot be silently altered: alteration either breaks the chain or fails the signature check. The record stops being a claim and becomes tamper-evident.
How RFC 3161 timestamps prove the when.
Tamper-evidence proves the record was not changed. Independent timestamping proves when it existed.
A hash chain proves internal consistency, but a Fiduciary timestamping its own records is still attesting to its own timeline. RFC 3161 trusted timestamping closes that gap: a third-party Time-Stamping Authority issues a cryptographic timestamp binding the record's fingerprint to calendar time. Because the authority is independent and the timestamp is itself signed, the time of the event is independently verifiable — not something the Fiduciary can have set or moved after the fact.
This is what turns "we say it happened then" into "an independent authority confirms this exact record existed at this time." Tamper-evidence and trusted-timestamping together give a record that is both unalterable-without-detection and time-anchored by a party with nothing to gain.
The evidence-package export.
When the inquiry comes, what you produce should be a package the Board can verify — not a database dump it has to take on trust.
The point of building on hash chains, signatures, append-only storage, and RFC 3161 timestamps is that, on the day the Board asks, you can export a self-contained evidence package: the relevant consent records, their chain of fingerprints, the signatures, and the trusted timestamps — everything needed to independently verify that the records are intact and were created when they claim to have been.
That is what "DPBI-ready" means in practice. Not a promise that you are compliant, and not a claim that the evidence is legally conclusive — that is for the Board to weigh — but a record set that is tamper-evident, trusted-timestamped, and independently verifiable, produced in minutes rather than reconstructed over weeks. The difference between weeks of scrambling and a one-click export is the difference between a record that hopes to be believed and evidence that can be checked.
Hold evidence, not just records. Be ready before the inquiry.
See how Vishwaas AI makes every consent event tamper-evident, trusted-timestamped, and independently verifiable — and how a DPBI-ready evidence package exports in one click.