DPDP and the append-only chain

An evidence chain is valuable because past records cannot be changed without the change showing. The DPDP Act gives people a right to erasure. These two facts meet in every system that keeps evidence about personal data, and we would rather state the tension than hide it.

elan1's design keeps personal data out of evidence: the proof record holds F14 payload_hash, a hash of the payload, not the payload itself. An erasure request is honoured where the personal data lives, as a governed write that leaves its own record; the chain keeps only hashes. This note sets out elan1's role under the Act, the question that remains — whether a hash of personal data is itself personal data — and the options.

An evidence chain is valuable because past records cannot be changed without the change showing. India’s Digital Personal Data Protection Act, 2023 (the DPDP Act) gives people a right to have their personal data erased. Any system that keeps evidence about changes to personal data has to say how those two facts meet. This note states elan1's role under the Act, how erasure works in elan1 today, the question that remains, and what we commit to.

It is written for legal teams and data protection officers, CISOs, CA firms and Indian banking, financial services and insurance teams reviewing elan1 or any vendor whose evidence store is append-only. Section 9 is a checklist you can use with any of them.

The DPDP Act applies to digital personal data processed in India. The Digital Personal Data Protection Rules, 2025 phase its obligations in; check the notified dates in force. Five provisions bear on an evidence chain.

• Section 2(t), personal data. Any data about an individual who is identifiable by or in relation to that data. Whether a value is personal data depends on whether a person can be identified through it, not on its format.
• Section 8(5), security safeguards. A data fiduciary must protect personal data with reasonable security safeguards to prevent a breach.
• Section 8(7), erasure by the fiduciary. Personal data must be erased when consent is withdrawn or the specified purpose is no longer served, unless retention is necessary to comply with law, and the fiduciary must cause its processor to erase it too.
• Section 12, correction and erasure on request. A data principal may ask for erasure, and the fiduciary must erase unless retention is necessary for the specified purpose or to comply with law.
• Section 13, grievance redressal. A data principal can raise a grievance, and the fiduciary must be able to respond to it.

Two features of this framework matter here. Erasure is tied to purpose and consent, with an exception for retention that law requires. And the definition of personal data turns on identifiability, which is exactly what a hash may or may not preserve.

elan1's role under the Act

For personal data in customers' systems that elan1 processes on the customer's instructions through elan1 Govern, Work, Decide and Run (hosted deployments), the customer is the Data Fiduciary and ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED acts as its Data Processor, under a data processing agreement.

For personal data elan1 collects for its own purposes (website visitors, contact and design-partner forms, account administration, billing, our own staff and marketing), elan1 is the Data Fiduciary.

In customer-VPC, on-premises and sovereign deployments that the customer operates, elan1 does not process the personal data and is neither, except for any support access the customer grants, where it acts as Processor.

So for the evidence chain in a hosted deployment, the erasure duty in section 8(7) sits with you as the Data Fiduciary, and elan1 acts on your instructions as your Data Processor, under the data processing agreement.

Every governed write in elan1, allowed or refused, leaves one proof record of sixteen fields (Seal v6). Each record carries the digest of the one before it, so a changed, missing or reordered record shows when the chain is walked. Evidence rows are never updated or deleted. That is what makes the chain tamper-evident at L1.

The design keeps personal data out of evidence. The payload of a write, the actual values that changed, stays in your system of record. The proof record holds F14 payload_hash, a hash of the payload, not the payload itself. Figure 1 shows the split.

The table goes field by field. Most fields describe the chain or the rules; three groups can relate to a person.

Our reading of the design, not a legal conclusion. The column on the right is what we keep under review with counsel.

A tamper-evident chain works because nothing in it changes. If a record is edited, its digest no longer matches the next record’s F03 prev_digest. If a record is deleted, the sequence shows a gap. That is the property an auditor relies on, and it is the property an erasure would break if erasure meant removing rows from the chain.

There is a way to delete a row and keep a chain that looks whole: recompute every digest after it. That is rewriting history. A chain that can be rewritten for an erasure can be rewritten for anything, and it would no longer be tamper-evident to you. We do not consider it an option.

So the useful question is narrower. If the payload is erased from your system of record and the chain keeps only identifiers and hashes, is what remains in the chain personal data? If it is not, erasure in the system of record may be enough, and the chain can stay as it is. If it is, or partly is, the options in section 6 apply, and any change ships as a new seal version, never as an edit to records already written.

That is the remaining question. It turns on section 2(t): whether a person is identifiable in relation to a hash, a record identifier or an actor identifier, once the data they point to has gone. That is a legal judgement for each deployment, and we keep it under review with our counsel.

One part of the answer does not depend on that judgement. In elan1, an erasure is itself a governed write. It takes the same Right Path as any other change: the stop switch, identity, the write door, the pre-gates, rules evaluated with no model, the guardrail, autonomy and a named approver where your rules ask. In Mode A, the single writer carries it out in your system of record. Either way, it leaves a proof record.

An illustrative declaration for customer erasure, the same specimen shown on the India DPDP Act page:

# decl_customer_erasure · v2 (illustrative)
write_type: customer.erase
pre_gates: [G3_PERMISSIONS]
check: no_legal_hold
       and purpose_served_or_consent_withdrawn
approver: role:privacy_officer
approver_not_requester: true
record: always  # payload hashed, never stored

The declaration checks that no legal hold applies and that the purpose is served or consent withdrawn. It requires a privacy officer who is not the requester to approve. The erasure’s own proof record names the declaration and version (F06–F07), the approver (F09–F10), the customer record (F12) and the time (F16). F14 holds a hash of the erasure payload, not the data it removed. The record answers a grievance under section 13: what was done, under which rules, by whom and when.

The erasure is appended. Nothing before it changes. What the chain cannot do on its own is make earlier records stop relating to the person. That is where the options in section 6 come in.

Five design elements are on the table. Two are in the product today; three are under evaluation, and they can be combined. Any option that changes what a field holds ships as a new seal version, alongside Seal v6, never as an edit to records already written.

How the options fit together

Hashing alone may be enough where a hash, with the payload erased, does not identify anyone. The risk is guessability: a plain hash of a short value can be matched by hashing candidate values until one fits.

Salting answers guessability. The choice is about scope. One secret per tenant is simple to hold but shared by every record. One value per data principal is heavier to manage but, if destroyed, unlinks only that person’s hashes. At the far end, salting per data principal and crypto-shredding become the same idea: a secret held outside the chain whose destruction is the erasure.

Tombstones make an erasure visible to anyone reading the chain later, so records relating to an erased subject can be shown as such. They add a reference, and the reference may itself need care.

Crypto-shredding keeps the chain intact because digests are computed over values that never change; only the key that could read them is destroyed. Its open points are operational (many keys, inside the residency domain, with backups) and legal (whether a destroyed key is erasure under the Act).

What we are not evaluating

• Updating or deleting evidence rows. There is no UPDATE or DELETE on evidence, and erasure does not add one.
• Recomputing the chain after a removal. It would make the chain rewritable, and no longer tamper-evident.
• Storing payloads in evidence and redacting them later. Personal data stays out of evidence in the first place.

These are the commitments. Each is consistent with the claims register and the India DPDP Act page.

1. No overclaim about erasure. elan1 makes no claim that its evidence chain, on its own, meets the Act’s erasure duties. Those duties sit with the Data Fiduciary, and elan1 supports them as described here. No page, deck or contract says otherwise.
2. Personal data out of evidence. The proof record holds a hash of the payload in F14, never the payload. Any change to how F14 is computed is published here and on Disclosures.
3. No edits to evidence. Evidence rows are only ever appended. An erasure is never carried out by changing or removing them.
4. Erasure is a governed write. Checked, approved where your rules say, carried out by the single writer in Mode A, and recorded in every mode.
5. Residency. Personal data is processed in residency domain “in”: AWS ap-south-1, Mumbai.
6. Publication. Any change to this approach is published in this note and on the India DPDP Act page, with an entry on Disclosures.

These are the questions we keep under review with our counsel, in our words. We publish them so that your counsel can consider the same questions for your own deployment. The answers may differ by sector, deployment model and the laws that apply to your records.

1. Is a hash of a payload that contains personal data itself "personal data" under section 2(t), as data about an individual who is identifiable in relation to it? Does the answer change if the hash is salted or keyed, and with who holds the key?
2. Does F12 record_id remain personal data once the record it points to has been erased from the system of record?
3. F09 actor_id names the person who approved or acted, usually an employee. On what basis may it be kept in evidence, and for how long?
4. When a law requires books, audit trails or records of changes to be kept, does that requirement allow a proof record to be retained under the exceptions in sections 8(7) and 12(3)? Which laws are relevant for accounting, banking and insurance deployments?
5. Do any retention requirements in the Digital Personal Data Protection Rules, 2025 for logs of processing apply to the proof record, and if so, for how long?
6. Does destroying the only key to an encrypted value amount to erasure under the Act?
7. Is a tombstone record that refers to an erased subject's earlier records itself personal data, and what may it contain?
8. What should the proof record of an erasure contain, so that it shows the request was checked and done without holding the data it removed?
9. Where elan1 acts as a data processor, how should the duty in section 8(7) to cause a processor to erase be reflected for evidence held in elan1's residency domain?
10. How should a data principal's request for information about processing be answered where the only trace of that processing is a proof record?

For a DPO, CISO or auditor reviewing any vendor whose evidence store is append-only, including us. Each item should have a written answer, with its status, before you rely on the vendor for records about personal data.

• Does the vendor's evidence store hold payloads, or only hashes of them?
• If hashes: are they salted or keyed, and who holds the key, in which region?
• Are your record identifiers opaque, or are they natural identifiers such as a phone number, PAN or email address? Prefer opaque identifiers everywhere they reach evidence.
• Can anyone, including the vendor's operators, update or delete evidence rows? If yes, ask how tampering would be detected. If no, ask how erasure is handled.
• Is an erasure itself a checked, approved and recorded operation, with a legal-hold check before it runs?
• Is the person who approves an erasure always different from the person who requests it?
• What does a viewer or verifier show for records that relate to an erased subject?
• Where do evidence, keys and backups live, and can any of them leave the residency domain?
• Who sets the retention period for evidence, and is it recorded with each tenant's configuration?
• Has the vendor said plainly what its role is under the Act — Data Fiduciary or Data Processor — in each deployment model?
• Does the vendor's contract say what happens to evidence, keys and salts when you leave?

The same ground, framed as procurement questions, is in Q25–Q30 of the library’s RFP question set for AI agents that write.

If our view on any question in section 8 changes, a new version of this note sets out the answer, the option or combination chosen from section 6, and what changes in the proof-record design as a result. The version line moves, and the change is logged on the India DPDP Act page and on Disclosures with the reason.

If you are reviewing elan1, the honest summary is short. Personal data stays out of evidence. Erasure is a governed write. Whether that is sufficient under the Act depends on your deployment and your counsel’s view, and we make no claim beyond it.