DRMLAW · Techno-Legal | Data Protection | Digital Forensics

Author: Rupak Mukherjee, Partner | www.drmlaw.in

DPDPA Section 8(4) and 8(5): Why “Privacy by Design” Isn't Optional Anymore — It's the Law

“Privacy by Design” has become the most quoted phrase in Indian compliance decks and the least practiced discipline behind them. Everyone puts it on slide three. Almost no one can open their own production system and show you where it actually lives in the architecture. That gap — between the phrase and the proof — is exactly where a Data Protection Board hearing will go looking first.

The Digital Personal Data Protection Act (DPDPA) marks a structural change for Indian engineering and compliance teams. Privacy used to be a policy document maintained by counsel and revisited once a year. Under the DPDPA, it becomes a set of statutory duties that have to be provably executed, continuously, in code — not asserted in a PDF.

This is where most compliance programmes quietly fail. A privacy notice gets published. A consent banner gets deployed. But the database underneath still stores raw phone numbers in plaintext, the CRM still lets any employee query any customer's full history, and the audit trail — if one exists at all — is a system log built for debugging, not for standing in front of a regulator. Privacy by Design means the architecture itself refuses to allow the violation, rather than relying on a policy that asks employees not to commit one.

Below is what that looks like when it's engineered rather than merely written down — including a live, redacted excerpt from our own production system, because a claim this specific should be provable, not just asserted.

I. The Act Never Says “Privacy by Design.” It Just Makes It Mandatory.

Search the text of the DPDPA and the phrase “Privacy by Design” does not appear once. That has led more than a few organisations to treat it as aspirational language for a conference slide, not a statutory requirement. That reading will not survive contact with the Data Protection Board. The Act does not need the phrase. It builds the substance directly into four legal duties, and each one is unsatisfiable without exactly the architecture the doctrine describes.

Four Statutory Mandates, Not a Slogan

• Technical and organizational measures — Section 8(4): The Act requires a Data Fiduciary to implement appropriate technical and organizational measures to ensure effective compliance. That is not a suggestion to “consider” privacy controls — it is a standing obligation to build them, before the fact, into how systems operate.
• Reasonable security safeguards — Section 8(5): Breach prevention stops being a security team's aspiration and becomes an engineering and operational duty with a statutory penalty attached — up to ₹250 crore for a single failure. “Reasonable” is doing a lot of work in that clause, and a Board will judge it against what was technically feasible at the time, not what was convenient.
• Data minimization: A Data Fiduciary may only collect personal data that is strictly necessary for the stated purpose. Not useful. Not potentially valuable later. Necessary. Every extra field on an intake form is a liability the moment this is read literally — and a regulator will read it literally.
• Mandatory security floors: The Rules move past principle into specification — encryption, access logs, and safe data backups are named as baseline controls, not optional hardening. A system without an access log isn't under-engineered; under the Rules, it's non-compliant by construction.

Put together, these four provisions describe an architecture, not a policy stance: systems built to operate correctly by default (Section 8(4)), engineered against breach as a first-order requirement (Section 8(5)), collecting the narrowest data footprint the purpose allows (minimization), with encryption, logging, and backup as non-negotiable floor controls, not premium features. Elsewhere in the world this bundle of commitments has a name — Privacy by Design, first codified by Dr. Ann Cavoukian and now embedded in GDPR Article 25, ISO/IEC 27701, and the NIST Privacy Framework. DPDPA didn't import the label. It independently arrived at the same architecture, because there is no other way to satisfy Sections 8(4) and 8(5) at scale.

This is where most compliance programmes quietly fail. A privacy notice gets published. A consent banner gets deployed. But the database underneath still stores raw phone numbers in plaintext, the CRM still lets any employee query any customer's full history, and the audit trail — if one exists at all — is a system log built for debugging, not for standing in front of a regulator. Section 8(4) does not ask for a policy that describes good behaviour. It asks for a system that cannot misbehave.

Below is what that looks like when it's engineered rather than merely written down — including a live, redacted excerpt from our own production system, because a claim this specific should be provable, not just asserted.

II. The Doctrine Behind the Statute: Seven Commitments, Four DPDPA Anchors

If Section 8(4) and 8(5) are the legal command, Privacy by Design is the engineering discipline that answers it. Here is how the seven foundational principles map onto the specific DPDPA mandates above:

• Proactive, not reactive: Security safeguards (Section 8(5)) are designed before the first user record is ever stored — not patched in after the first incident.
• Privacy as the default setting: A user who does nothing is protected by default. Consent (Section 6) is opt-in and purpose-specific; nothing is pre-checked, nothing is bundled.
• Embedded into design, not appended: Data minimization is a schema-level constraint, not a review-stage checklist — a field that isn't strictly necessary for the stated purpose is never collected in the first place.
• Full functionality — positive-sum, not zero-sum: A compliant system still has to work. Privacy controls are built to coexist with usability, not to justify a broken client experience as the price of compliance.
• End-to-end security, full lifecycle protection: Data is protected from collection through to erasure (Section 8(7), Rule 6) — not just while it sits in the primary database.
• Visibility and transparency: The mandatory security floor — encryption, access logs, backups — exists precisely so the system can show, on demand, exactly what happened to a given record.
• Respect for user privacy — user-centric: Grievance redressal (Section 13) is a built-in channel, not a buried email address three menus deep.

III. Immutable Consent Logging — Section 8(4) at the Database Layer

Legal Requirement

Section 6 requires consent to be free, specific, informed, unconditional, and unambiguous, demonstrated by an affirmative action. The evidentiary burden sits with the Data Fiduciary — not the regulator, not the user — to show consent existed for a particular processing activity, at a particular time.

What This Is — and Isn't — an Example Of

It's worth being precise about what a consent ledger actually satisfies, rather than waving at “Privacy by Design” as a catch-all. Section 6's burden-of-proof requirement is the direct driver: the Act puts the obligation to demonstrate consent on the Fiduciary, not the obligation on the Data Principal to disprove it. A boolean flag cannot discharge that burden. An append-only ledger, tied to a specific notice version and timestamp, can. That's Section 8(4)'s “technical and organizational measures” requirement taken to its logical conclusion — a system built so the proof exists by construction, not assembled after the fact when a notice from the Board arrives.

Two honest caveats, so this doesn't overreach: the ledger's own fields — IP address, device signature, event timestamps — are operational metadata the Fiduciary generates about its own compliance process, not personal data collected from the Data Principal for a business purpose. And the ledger doesn't change what happens to the user by default — their consent choice produces the same outcome whether or not the ledger exists. What it changes is whether the Fiduciary can meet the Section 6 burden when challenged. That's a narrower, more defensible claim than “this is Privacy by Design,” and it's the one this architecture actually earns.

Engineering Implication

A boolean column such as is_consent_accepted = TRUE in a users table proves nothing beyond today's state. It cannot show what notice the user actually saw, which purposes they agreed to, or whether they withdrew consent last month and a stale record never caught up. Put an auditor in front of that column and the honest answer is: we don't know.

Recommended Architecture: A Decoupled, Append-Only Consent Ledger

Design principles

• Separation of concerns — store consent events in a dedicated ledger, separate from operational user profiles and transactional tables.
• Immutability — append-only writes (WORM semantics), never an in-place update, never a hard delete of a consent record.
• Linkage to notice text — every consent event references the exact version of the notice the user saw.
• Tamper evidence — a cryptographic digest of key fields on every entry, so retroactive edits are detectable.

Suggested schema

consent_event_id : UUID (v4) PK
data_principal_id : UUID FK (anonymized index to user)
notice_version_id : VARCHAR (references immutable notice repository)
consent_purposes : ARRAY [Auth, Transaction_Sms, Analytics]
event_type : ENUM [GRANT, WITHDRAWAL]
timestamp_utc : TIMESTAMP
signature_hash : SHA-256 (Principal_ID + Notice_Version + Timestamp)

IV. Proof, Not a Promise: A Live Excerpt From Our Own System

Architecture diagrams are easy to draw and easy to ignore. So here is a redacted excerpt pulled directly from DRMLAW's own internal matter-management audit trail — the same append-only logging discipline described above, running on a live system, not a slide. Identifying values (IP addresses, client contact details, monetary figures) have been generalized for publication; the structure is exactly as it runs in production.

21/07/2026 14:07:58 IST QC & legal review marked complete
EVENT_CODE : CERTIFICATE63.QC_LEGAL_REVIEW_COMPLETED
ACTOR : Admin (admin@drmlaw.in)
PAYLOAD : —

21/07/2026 14:07:43 IST Certificate 63A/63B generated (internal only)
EVENT_CODE : CERTIFICATE63.GENERATED
ACTOR : Admin (admin@drmlaw.in)
PAYLOAD : {
"cert_no_63a": "DRMLAW/2026/07/21-01",
"cert_no_63b": "DRMLAW/2026/07/21-02",
"certificate_63a_id": "ddf550da-4d30-...",
"certificate_63b_id": "5bae4ce1-0ed1-..."
}

21/07/2026 14:07:40 IST Forensic examiner assigned for signing
EVENT_CODE : CERTIFICATE63.EXAMINER_ASSIGNED
ACTOR : Admin (admin@drmlaw.in)
PAYLOAD : {
"examiner_email": "[examiner]@drmlaw.in",
"declarant_examiner_email": null
}

21/07/2026 07:03:50 IST Client accepted quotation
EVENT_CODE : QUOTATION.ACCEPTED
ACTOR : Client ([redacted]@[domain])
IP / AGENT : [redacted IP] · Mobile Safari, iOS
PAYLOAD : {
"quotation_id": "87557c84-...",
"ref": "Q-000002",
"is_revision": false,
"amounts": { "subtotal_inr": [x], "tax_inr": [x], "total_inr": [x] }
}

Fig. 1 — Redacted excerpt, DRMLAW internal matter-management audit trail. Identifying values generalized for publication.

Four things to notice — because each one maps directly to what Section 6 and a DPB hearing actually demand:

• Every row has a precise timestamp, to the second, with timezone. Not “sometime in July.” An exact, defensible moment.
• Every row has an attributed actor — a named account, not a generic system user. The regulator's question “who did this, and were they authorised to?” has a one-line answer.
• Every row carries a structured JSON payload, not a free-text note. A payload is queryable, exportable, and cannot be quietly reworded after the fact the way a comment field can.
• Client-side events capture IP and device signature. This is the difference between “we have a record that says accepted” and “we have forensic linkage proving this specific device, at this specific address, performed the action” — the same standard of proof used in digital evidence certification under BSA Section 63.

This isn't a consent-specific screenshot — it's our certificate and matter-management workflow. We're showing it deliberately: the discipline is identical whether the event is “client accepted a quotation” or “data principal granted consent to Purpose X.” Immutable, timestamped, actor-attributed, structured — the pattern doesn't change based on what's being logged. That consistency is exactly what a Data Protection Board looks for: not a one-off artifact built for a DPDPA audit, but a firm-wide operating discipline.

V. Design Rules Mapped to Law

1. Notice Versioning

• Technical: Maintain an immutable repository of privacy notices. Every change — including translations — increments the version (e.g., v2.1.0_HI for Hindi). Every ledger event references the exact version ID shown to the user.

Why it matters at a hearing: The regulator's first question is rarely “did they consent” — it's “what did they actually see when they did?” Without version-linkage, you're guessing.

2. Cryptographic Integrity

• Technical: Generate a SHA-256 hash of the transaction metadata at creation (Principal ID + Notice Version + Timestamp) and store it alongside the record.

Why it matters at a hearing: A stored hash is tamper evidence. It lets you demonstrate — not just assert — that the ledger wasn't quietly edited after an incident.

3. Withdrawal Symmetry

• Technical: The DPDPA requires withdrawal to be as easy as granting consent. Model a withdrawal as a new event_type = WITHDRAWAL record — never an update or deletion of the original grant.

Why it matters at a hearing: This is the single most common failure point we see: systems that “helpfully” overwrite the old consent status, destroying the very chronology that would have proven compliance.

VI. The Quality Standard: Where DPDPA Meets the Rest of the World

None of this is exotic or unique to India. It borrows directly from disciplines that already carry decades of audit and forensic scrutiny: the seven foundational principles of Privacy by Design; structured event logging aligned to ISO/IEC 27701 (Privacy Information Management) and ISO/IEC 27001 Annex A logging controls; the risk-based lifecycle approach of the NIST Privacy Framework; WORM storage patterns used in financial recordkeeping; the indigenous Digital Governance and Protection Standard of India (DGPSI) developed by FDPPI; and the same chain-of-custody rigor Indian courts already expect for electronic evidence certified under Section 63 of the Bharatiya Sakshya Adhiniyam.

DPDPA didn't invent this bar. It gave India's version of a standard the rest of the world already holds itself to — and made it enforceable with a nine-figure penalty attached.

The standard we hold every build to is simple: if this record were the only thing standing between a client and a ₹250 crore penalty, would it hold up unassisted? If a log entry needs a verbal explanation to make sense to a regulator, it isn't a compliance artifact yet — it's a note-to-self.

VII. From Principle to Practice: The Six Moves That Make It Real

Every credible privacy framework — DPDPA included — converges on roughly the same operational sequence to move Privacy by Design from doctrine to something a regulator can inspect. We run every client engagement, and our own platform, through the same six moves:

• 1. Assess before you build. A Privacy Impact Assessment happens at the design stage, not as a retrospective audit after launch. Risks get designed out while they're still cheap to fix.
• 2. Write policies that bind, not policies that decorate. Internal data protection policies have to be specific enough to enforce — retention periods, escalation paths, named owners — not a restatement of the Act in softer language.
• 3. Embed privacy into the product itself. Encryption, consent capture, and access control ship in version one. They are not a Q3 roadmap item added after a client asks about them.
• 4. Harden security as a default, not a response. Encryption in transit and at rest, strong authentication, and continuous monitoring are baseline configuration, not incident-driven upgrades.
• 5. Train the people, not just the policy. Everyone who touches personal data — not only the compliance team — needs to know what their specific role requires under the Act.
• 6. Give users real control, not a settings page nobody can find. Consent choices, correction requests, and grievance redressal need to be reachable in a few clicks — and logged with the same rigor as every other event on the platform.

None of these six moves is exotic on its own. What separates a genuine Privacy by Design programme from a compliance slide deck is whether each one produces an artifact you can hand a regulator — a DPIA report, a named policy owner, a config file, an audit log — rather than a claim you have to ask them to trust.

VIII. Walking the Talk: Privacy by Design Inside Our Own Front and Back Office

Every consultant can recite “Privacy by Design.” Far fewer have actually rebuilt their own firm's operating system around it before ever pitching it to a client. We did the second one first.

DRMLAW does not run its practice on a patchwork of spreadsheets, WhatsApp threads, and a generic CRM bolted on as an afterthought. Every matter — from the first client quotation to the final signed certificate — runs through a single in-house platform we designed and built ourselves, covering both front office (client intake, quotations, communications) and back office (matter assignment, examiner workflows, certification, billing). We built it this way deliberately: if we are going to tell a client their systems need to be re-architected around DPDPA, our own had to survive that scrutiny first.

Here is what that meant in practice, mapped to the sections of the Act we ask our own clients to answer for:

• Purpose limitation & data minimization (Section 4 & 5): Every intake form on our platform collects only what a specific matter requires — no bundled marketing consent, no “collect it now, justify it later.” A quotation workflow captures billing and scope data; it does not silently harvest fields a forensic engagement would need. Each is a separate, purpose-bound data path.
• Role-based access, by design, not by policy (Section 8(5)): Client data, examiner assignments, and certificate generation each sit behind distinct role permissions. An examiner assigned to sign a certificate can see the matter file; they cannot browse the firm's full client ledger. Access is structurally impossible, not just discouraged in an employee handbook.
• Immutable, auditable event logging (Section 6 evidentiary burden): The very audit trail shown in Section IV of this article is not a feature we bolted on for this article — it is how every matter on our platform has run since day one. Quotation acceptance, examiner assignment, certificate generation, QC sign-off: each is a timestamped, actor-attributed, structured event, permanently recorded.
• Security safeguards as default configuration (Section 8(5)): Encryption in transit and at rest, session-based authentication, and IP/device fingerprinting on client-facing actions were built into the platform's first version — not retrofitted after a scare. Reasonable security safeguards were the starting requirement, not a post-launch patch.
• Retention discipline and lifecycle control (Section 8(7) & Rule 6): Matter data has a defined lifecycle from intake to closure to archival, instead of accumulating indefinitely in an inbox no one prunes. What a closed matter no longer needs to retain does not linger simply because deleting it was inconvenient.
• Accessible grievance and correction pathways (Section 13): Clients are not left guessing who to email if something about their data looks wrong. The same platform that manages their matter gives them a direct, logged channel to raise it — and that request is tracked with the same rigor as any other matter event.

This is the difference between compliance as a claim and compliance as a structure. Any firm can put a privacy policy on its website. Far fewer can open their own admin console, mid-conversation with a prospective client, and show the exact append-only record of who touched what data, when, and why. We can — because we had to build it that way before we could credibly ask anyone else to.

That is the real purpose behind showing our own audit trail in this article rather than a generic mock-up. Trust in a techno-legal advisor cannot rest on credentials alone. It rests on evidence that the advisor lives under the same discipline it prescribes — walking the talk, not just billing for it.

The DRMLAW View

A privacy policy is a promise. A consent ledger is proof. Regulators under the DPDPA will not accept the former as evidence of the latter — and neither will the Data Protection Board when it asks a Data Fiduciary to substantiate a claim of compliance after a breach.

Privacy by Design was never meant to be a values statement. It is an engineering discipline with seven specific commitments, and it either shows up in your schema, your access controls, and your audit log — or it doesn't exist. We built our own firm on it first, which is precisely why we know what a defensible architecture looks like under scrutiny: we've had to produce ours.

Rupak Ranjan Mukherjee is Founder Partner at DRMLAW LLP, a Kolkata-based techno-legal practice specialising in DPDPA compliance, DPO-as-a-Service, and digital forensics. Read more at drmlaw.in/technolegal/dpdpa.