Why self-serve Proof DPDP News Blog Support Contact | Academy Sign In
Home / Proof
EvidenceChain, live in production

Don't just claim compliance. Prove it, cryptographically.

When the Data Protection Board of India opens an inquiry, it will not ask what you say. It will ask what you can prove. dcomply's EvidenceChain hash-chains every consent, DSR, breach, and connector event so tampering is mathematically self-evident, not a matter of trust.

Start free See the architecture
// Every event carries the previous row's hash. // Tamper with row N and every row after breaks. current_hash = sha256( prev_hash + '|' + canonical_json(payload) + '|' + occurred_at );
Why this matters

A database row proves nothing on its own

Any conventional audit log is a claim. If the row could have been written, edited, or backdated at any time by anyone with database access, it does not constitute evidence in a regulatory inquiry. This is the same problem Vishwaas.ai raises, and we agree with the diagnosis. The question is whether your compliance vendor has actually solved it, and across how many modules.

What a regulator sees in a normal audit log

A row saying “consent granted on 2026-05-12 at 14:33.” No way to prove it wasn't inserted last week. No way to prove the timestamp wasn't rewritten. No way to prove any row above or below it wasn't quietly deleted. Legally, this is a claim, not evidence.

What a regulator sees with EvidenceChain

The same row, plus a current_hash tying it to the previous row's hash, the canonical payload, and the timestamp. To fake or alter one row, you must recompute and rewrite every subsequent hash. The verify() walk catches the first inconsistency and returns the offending row id. Independently rehashable.

The architecture

Four layers of tamper evidence

Each of these lives in production today inside dcomply. They are not marketing promises.

1

SHA-256 hash chain

Every evidence row's current_hash equals sha256(previous_hash + canonical_payload + occurred_at). Chain is per-tenant and lock-guarded so concurrent appends cannot fork.

2

Append-only tables

Dedicated tables (source_evidence_entries, breach_audit_logs, dsr_audit_logs, consent purposeLogs) accept INSERTs only. No update, no delete path exists in application code.

3

Canonical JSON payload

Payloads are serialised with JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES and no whitespace, giving a byte-identical string across environments. Regulators can rehash the payload themselves and get the same digest.

4

Independent verify walk

A public verify(tenant_id) method walks the chain in order and returns null if intact, or the id of the first inconsistent row. The DPBI export bundle ships the rows plus the verification code, so trust in dcomply is not required.

Roadmap: RFC 3161 trusted timestamping

Q3 2026. Each row will additionally carry a third-party RFC 3161 timestamp authority countersignature, attached as a sibling column so the existing chain remains valid. This binds every event to independently verifiable calendar time.

Under the hood

The actual production code

No marketing gloss. This is the append routine from app/Services/Discovery/EvidenceChain.php.

// Lock the tail of the chain so two concurrent appends cannot fork. $previous = SourceEvidenceEntry::where('tenant_id', $tenantId) ->orderByDesc('id') ->lockForUpdate() ->first(); $prevHash = $previous?->current_hash; $occurredAt = now(); $subjectHash = $subjectId ? hash('sha256', strtolower(trim($subjectId))) : null; $canonical = json_encode($payload, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_THROW_ON_ERROR); $currentHash = hash('sha256', ($prevHash ?? '') . '|' . $canonical . '|' . $occurredAt->format('Y-m-d H:i:s')); // Append-only. There is no update() or delete() path in application code. return SourceEvidenceEntry::create([ 'tenant_id' => $tenantId, 'event_type' => $eventType, 'subject_identifier_hash' => $subjectHash, // PII hashed, not stored raw 'payload' => $payload, 'previous_hash' => $prevHash, 'current_hash' => $currentHash, 'occurred_at' => $occurredAt, ]);

Backed by passing tests in tests/Feature/Connectors/EvidenceChainTest.php.

Coverage

Every regulated event, one chain

Consent-only cryptographic proof is a good start. But DPDP inquiries also demand evidence around DSRs, breaches, DPO decisions, and downstream data flows. EvidenceChain covers all of them.

Consent lifecycle

consent.granted consent.withdrawn consent.propagated consent.expired purpose.log.written

Data Principal Rights

dsr.requested dsr.identity.verified dsr.located dsr.export.generated dsr.erase.applied dsr.appeal.opened

Breach management

breach.opened breach.dpbi.notified breach.principal.alert.sent breach.72h.deadline.hit breach.closed

Governance & connectors

dpia.dpo.signoff connector.run.started connector.run.completed vendor.dpa.renewed sdf.designation.recorded
The DPBI export bundle

One click to a regulator-ready file

When the Data Protection Board sends a notice, a DPO does not need three weeks with spreadsheets. From the dcomply console, the DPBI export bundle produces:

  • The full EvidenceChain rows for the affected data principal or breach, in JSON.
  • The verification script. The regulator can rehash the payloads themselves without trusting dcomply.
  • Human-readable audit narrative tying events to DPDP Act sections (Sec. 6 consent, Sec. 8(2) processor oversight, Sec. 8(6) breach notification, Sec. 11–14 DSR).
  • Signed manifest listing every row hash, timestamp, and event type in the export.
  • Contemporaneous notices. The exact Privacy Notice version the data principal saw, retrieved by content hash.

The dcomply promise

If a regulator can rehash your evidence bundle offline and get a different digest than what we shipped, we will pay the DPBI penalty. Not because we plan to, but because the math will not let it happen.

Honest FAQ

Questions we get from CISOs and DPOs

Correct. It is tamper-evident, not tamper-proof. A sufficiently privileged attacker can rewrite the entire chain from the point of alteration onward. But because the chain is deterministic and the verify walk is public, any regulator or auditor will detect that rewrite the moment they compare the exported bundle against an earlier snapshot. In practice, this is the standard used by every ledger-based system, including central bank digital currencies.

Not yet. Today, timestamps come from the application server and are included in the hash. RFC 3161 trusted timestamping is on the Q3 2026 roadmap and will attach a third-party TSA countersignature as a sibling column, so the chain stays valid during the upgrade. In the meantime, if RFC 3161 is a hard requirement for your regulator, tell us and we will prioritise it for you.

SHA-256 is a hash function and does not use a signing key, so the chain itself does not require key management. The DPBI export manifest is signed separately. For customers who need HSM-backed signatures on exports, we support AWS KMS integration on Professional and above tiers.

The whole platform. Consent, DSR, breach, DPIA sign-off, vendor DPA renewals, SDF designation, and every connector adapter run write to EvidenceChain. This is the difference between a consent-only platform and dcomply: the crypto covers the 89-plus modules, not just one.

Yes. Sign up for a free tenant, trigger a consent grant and withdrawal, download the export bundle, run the verify script offline. If it does not verify, tell us and we will pay for your first year.

See it, don't just read about it.

Start a free tenant. Grant a consent. Download the export. Verify offline.

Start free dcomply vs Vishwaas.ai See pricing