Title: Architecting DPDPA Compliance: How to Build an Immutable Consent Ledger

The Digital Personal Data Protection Act (DPDPA) marks a structural change for Indian engineering and compliance teams. Where privacy was once a static legal policy document maintained by corporate counsel, the DPDPA recasts certain obligations as engineering requirements that must be provably executed in code and infrastructure.

Two provisions in particular force changes to conventional database design and operational practice: Section 6 (valid, auditable consent) and Section 8(7) read with Rule 6 (mandatory data erasure). When regulators expect operational proof, ordinary transactional logs and ad-hoc SQL deletes will not suffice.

Below is a practical, law-informed architecture that engineers and legal teams can use to meet the statutory standard of proof.

I. Immutable Consent Logging: Recording the “Who, When, and What”

The Legal Requirement (Section 6): Consent must be free, specific, informed, unconditional, and unambiguous, demonstrated by a clear affirmative action. The Act explicitly places the evidentiary burden on the Data Fiduciary to show consent existed for particular processing activities.

The Engineering Implication: A standard boolean column such as is_consent_accepted = TRUE inside a users table documents only the current state. It cannot show what notice text the user actually saw, the specific purposes consented to at that time, or whether that consent was later modified or withdrawn.

Recommended Architecture: A Decoupled, Append-Only Consent Ledger

To ensure auditability, your infrastructure should adhere to three core design principles:

• Separation of Concerns: Store consent events in a dedicated ledger separate from operational user profiles and transactional databases. This reduces accidental overwrites and simplifies audit queries.
• Immutability: Use append-only writes (WORM semantics) and write-once storage patterns to preserve the historical record intact.
• Linkage to Notice Text: Tie each consent event to a specific notice version so you can prove the exact language presented to the user.
• Tamper Evidence: Record a cryptographic digest of key fields to detect retroactive modifications.

II. The Technical Schema Blueprint

To turn these design principles into working software, decouple your log architecture into a standalone database structure. Use the following suggested schema layout to track active states over time:

— Medium Code Block Format
CREATE TABLE consent_ledger (
consent_event_id UUID PRIMARY KEY, — v4 UUID for unique tracking
data_principal_id UUID NOT NULL, — Anonymized index referencing the user
notice_version_id VARCHAR(50) NOT NULL, — References the immutable notice repository
consent_purposes VARCHAR[] NOT NULL, — Array e.g., [Auth, Transaction_Sms, Analytics]
event_type VARCHAR(20) NOT NULL, — ENUM: [GRANT, WITHDRAWAL]
timestamp_utc TIMESTAMP WITH TIME ZONE, — Precise UTC audit stamp
signature_hash CHAR(64) NOT NULL — SHA-256 integrity token
);

Get Rupak Mukherjee’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

(Note: In the schema properties, signature_hash represents a SHA-256 generated string combining Principal_ID + Notice_Version + Timestamp to detect tampering ).

III. Core Design Rules: Mapping Code to System Logic

To maintain compliance readiness, the application layer must execute system logic that matches the underlying legal rationale.

1. Notice Versioning

• The Technical Execution: Maintain an immutable repository of privacy notices. If you change notice text or add translations, increment its version string (for example, v2.1.0_HI for Hindi). Map each ledger event to the exact version ID presented to the user at runtime.
• The Operational Legal Rationale: The regulator will ask, “What did the Data Principal actually see?” Maintaining a cleanly versioned repository allows you to map every ledger entry to the exact language presented.

2. Cryptographic Integrity

• The Technical Execution: Generate a SHA-256 hash of the transaction metadata at creation (combining Principal_ID + Notice_Version + Timestamp). Store this hash alongside the record to detect retroactive database alterations.
• The Operational Legal Rationale: A stored hash creates immediate tamper evidence. This supports statutory admissibility requirements under modern digital evidence laws by demonstrating that the ledger was not modified after the fact.

3. Withdrawal Symmetry

• The Technical Execution: The DPDPA requires that withdrawing consent be as easy as giving it. When a user opts out, do not run an UPDATE query to overwrite prior records. Append a completely new record with event_type = WITHDRAWAL to maintain a chronological, verifiable chain of custody.
• The Operational Legal Rationale: Because withdrawal must mirror consent ease, modeling withdrawals as clean, append-only events preserves chronology. This proves explicitly to auditors that the fiduciary honored the withdrawal request immediately.

Conclusion: The Techno-Legal Mandate

Relying entirely on a traditional legal policy no longer protects an enterprise processing data at scale. True compliance requires a unified techno-legal approach — where the code architecture natively executes the mandates of the law.

By decoupling consent tracking into immutable event ledgers, engineering teams can future-proof their production environments against escalating operational and regulatory risks.

About the Author: Rupak Mukherjee is a Partner at DRMLAW LLP, specializing in the intersection of data practice compliance, software engineering architecture, and digital forensics. For comprehensive techno-legal DPO insights and architectural auditing frameworks, access the resource center at www.drmlaw.in.

Disclaimer: This briefing is shared strictly for academic and educational purposes under Bar Council of India guidelines and does not constitute formal legal advisory.