Most teams treat logging as an afterthought. Under India's Digital Personal Data Protection Act, that habit becomes a liability. There's no single line in the statute that says "keep an audit log," but the obligation runs through everything: consent, access, correction, erasure. So what does an immutable, regulator-grade log actually need to capture, and how do you build one that holds up when a Data Protection Officer or the Board asks you to prove what happened? That's what we'll work through.

This is general information for engineers and product teams, not legal advice. Confirm specifics with your own counsel.

Why DPDP Needs an Audit Trail

The DPDP Act does not use the phrase "audit log." It does something stronger: it assigns accountability to the Data Fiduciary (the entity deciding why and how personal data is processed) and gives Data Principals enforceable rights. Section 8 of the DPDP Act 2023 makes the Fiduciary responsible for compliance "whether or not the Data Principal has agreed," and requires it to implement technical and organisational measures. When the law says "be accountable," the only way to demonstrate accountability is to keep records.

The same expectation shows up in the Draft DPDP Rules 2025, where Significant Data Fiduciaries must run a Data Protection Impact Assessment and periodic audits. And you can't audit what you never recorded. The log is the evidence layer underneath every right and every obligation. A Data Principal withdraws consent and you keep processing? The audit trail proves the timeline. The Board investigates a breach? Your records are the difference between "here's exactly what happened" and a fine.

If you want the wider obligation set, our DPDP compliance checklist for SaaS maps the audit trail to the other pillars. For the roles referenced above, see Data Fiduciary vs Data Processor.

Think in terms of state changes to personal data and to consent. Every one of them is an event worth recording. The practical floor for a DPDP audit log covers four families.

Consent lifecycle. Section 6 requires that consent be free, specific, informed, and unambiguous, and that the Data Principal can withdraw it as easily as it was given. So you log the grant, the exact scope and purpose, and every withdrawal. Capture the language the notice was served in, since the Act requires a notice in English or any language in the Eighth Schedule of the Constitution.

Access and processing. Record who or what read or used personal data, when, and why. This is your defence against "purpose creep," where data collected for one purpose quietly gets used for another.

Correction and update. Section 12 gives the Data Principal a right to correction and completion. Log the before-state reference, the requested change, and the result.

Erasure and retention expiry. Section 12 also covers erasure. When you delete or when a retention clock expires, write a tombstone event rather than silently dropping the row.

Here is a minimal event shape. The point is that each row is self-describing.

{
  "event_id": "evt_01J9...",
  "occurred_at": "2026-06-21T08:14:09Z",
  "actor": "user:8f21",
  "action": "consent.granted",
  "data_principal": "user:8f21",
  "purpose": "kyc_verification",
  "scope": ["digilocker.aadhaar"],
  "provider": "digilocker",
  "ip": "203.0.113.7",
  "notice_language": "en",
  "prev_hash": "sha256:b1c2..."
}

NamoID is built so every state-changing operation appends exactly this kind of record. A consent grant, a passkey enrolment, a refresh-token rotation, a provider connection, an erasure: each one lands in a single append-only events table. You do not bolt logging on per feature, it is a property of the write path. For the consent side specifically, see our DPDP consent manager framework.

Append-Only vs Mutable Logs

A normal application table lets you UPDATE and DELETE. That's precisely what disqualifies it as an audit log. If a row can be edited after the fact, it can be edited to hide what happened, and a regulator knows it. An append-only log only ever inserts. History never gets rewritten.

Property	Mutable table	Append-only audit log
Writes allowed	INSERT, UPDATE, DELETE	INSERT only
Can history change?	Yes	No
Evidentiary value	Weak	Strong
Erasure handling	Row vanishes	Tombstone event added
Suits DPDP record keeping	No	Yes

The erasure row is the part teams get wrong. When a Data Principal exercises erasure, you must remove their personal data, but you should not erase the fact that data existed and was deleted on a given date. You reconcile this by separating the personal payload from the audit metadata. The personal data is soft-deleted or purged. The audit log keeps a tombstone that says "subject X erased at time T under request R," with no sensitive content. That satisfies both the right to erasure and the duty to keep DPDP record keeping intact.

In NamoID the events table is INSERT-only by contract, and deletion cascades a soft-delete plus a tombstone event rather than a hard wipe of history.

Retention and Tamper-Evidence

Two questions decide whether your log is regulator-grade. How long do you keep it? And how do you prove nobody altered it?

Retention. The DPDP Act does not give a single universal number. It ties retention to purpose: keep personal data only as long as the purpose needs it, then erase. Audit metadata is different from the personal data itself, and is generally retained longer to evidence compliance, subject to your DPO's guidance and any sectoral rules (RBI, SEBI, and similar regulators often mandate multi-year retention). Set an explicit retention policy per data category and per log type, and make the expiry itself an event.

Tamper-evidence. Append-only is necessary but not sufficient, because an administrator with database access could still rewrite rows. The standard fix is hash chaining: each event stores the hash of the previous event, so any change to an old row breaks every hash after it. You then periodically anchor the latest hash somewhere harder to alter (a separate write-once store, or a notarised checkpoint).

# Conceptual chain check: recompute each row's hash from its
# content + prev_hash, and confirm it matches what was stored.
for row in events:
  expect = sha256(canonical(row.payload) + row.prev_hash)
  assert expect == row.hash   # any tampering fails here

Pair this with least-privilege database roles, so the application can INSERT but not UPDATE the audit table, and with encryption at rest for any sensitive linked records. NamoID encrypts provider tokens at rest with AES-256-GCM and exposes only signing public keys, never private material. For where these records are allowed to live, read our note on data residency under DPDP Rule 15. And because the DPDP breach notification timeline is tight, a queryable, trustworthy log is what lets you reconstruct an incident fast.

Mapping Logs to Data-Principal Requests

An audit trail earns its keep when a request arrives. The DPDP Act gives Data Principals a right to information about processing under Section 11, which is the practical basis for a Data Subject Access Request (DSAR). To answer one, you need to assemble everything tied to that person.

A well-designed log makes this a query, not an archaeology project. Key the events by a stable Data Principal identifier and index that column, since it is the hot path for DSAR and erasure. Then a request becomes:

curl -H "Authorization: Bearer $TOKEN" \
  "https://issuer.example.com/v1/audit/export?subject=user:8f21"

The response should contain the person's full event history, their active and revoked consents, and which providers they connected. NamoID is built to return exactly this from a DSAR export endpoint: complete event history plus connected providers, drawn from the same append-only store that recorded them. Because erasure writes a tombstone, an export after deletion correctly shows that the subject existed and was erased, without leaking the erased content.

The same log underpins consent proof too. When someone disputes whether they ever agreed, you produce the timestamped grant and the conversation is over.

An Engineering Checklist

Use this as a build and review gate.

If you build to this list, you can answer the only question that matters when the Board calls: "Show us what happened." For where audit fits among auth choices, compare notes in build vs buy auth in India.

FAQ

Does the DPDP Act explicitly require an audit log?

Not by that name. The Act assigns accountability to the Data Fiduciary under Section 8 and grants enforceable rights to Data Principals, and the Draft DPDP Rules add audits and impact assessments for Significant Data Fiduciaries. An append-only audit log is the practical way to evidence all of it. This is general information, not legal advice.

How long should I keep DPDP audit records?

Personal data should be kept only as long as its purpose needs, then erased. Audit metadata is usually retained longer to prove compliance, and sectoral regulators like RBI or SEBI may set firm multi-year minimums. Set an explicit, documented retention policy per category with your DPO.

What makes a log "tamper-evident"?

Append-only writes plus hash chaining, where each event carries the hash of the previous one so altering any old record breaks the chain. Anchor the latest hash in a separate write-once store, and restrict database roles so the app can insert but not update audit rows.

How do I handle erasure without breaking the audit trail?

Separate the personal payload from the audit metadata. On erasure, remove or soft-delete the personal data and write a tombstone event recording that the subject was erased and when. History stays intact, and no sensitive content remains.

See It in Context

NamoID is built to give you this audit trail behind one OIDC issuer URL, alongside India verification rails and standard OAuth 2.1 auth, so the records and the rights line up by design. The product is in soft launch and ships shortly.

If you want to walk through your audit-trail design before then, book a demo or reach us at hello@namoid.in.