HomeProjectsBlogContact

DPDP Compliance Is an Engineering Project, Not a Policy PDF

India's DPDP Rules give you until 13 May 2027 for full compliance, with the consent manager framework opening in November 2026. Most of what the law demands is code — consent infrastructure, deletion pipelines, DSAR workflows. Here is the build list.

DPDP Compliance Is an Engineering Project, Not a Policy PDF

DPDP Compliance Is an Engineering Project, Not a Policy PDF

Most companies we talk to have handled the Digital Personal Data Protection Act the way they handled cookie banners in 2019: a lawyer drafted a privacy policy, someone pasted it into a footer link, and the item got marked done.

It is not done. The overwhelming majority of what the DPDP Act and the DPDP Rules actually require is software — consent capture that produces an auditable record, deletion that reaches every replica and backup, rights workflows that resolve within a deadline, breach reporting that fires from your monitoring rather than from someone noticing on a Monday. None of that lives in a policy document. All of it lives in your codebase.

And the clock is specific.

The dates that matter

The DPDP Rules were notified on 13 November 2025, starting an eighteen-month implementation runway. Three phases follow from that:

Milestone Date What lands
Notification 13 Nov 2025 Rules in force; Data Protection Board operational; penalty framework active
Phase 2 13 Nov 2026 Consent manager registration framework becomes operational
Phase 3 13 May 2027 Full substantive compliance — notice, consent, security safeguards, breach reporting, data principal rights, retention limits

Penalties under the Act reach up to ₹250 crore per violation, and there is currently no signal of an extended grace period.

The trap in that table is the eighteen-month framing. It reads as generous. It is not, because the systems it demands — identity, consent state, data lineage, deletion orchestration — typically take twelve to eighteen months to implement properly in an organisation of any size. Practitioners have been consistent on this point: 2026 is the build-and-test year, and 2027 is when you should be refining, not starting.

November 2026 also marks one year since notification, and the Data Protection Board is widely expected to shift from awareness-building toward active supervision around that point.

Who this applies to (probably you)

If you process digital personal data in India, the Act applies. It also reaches outside India — any foreign business offering goods or services to Indian residents, or profiling them, falls in scope. A startup with entirely foreign users but Indian processing infrastructure is still caught.

For an agency's clients this usually means: yes. Your website visitors are data principals. Your employees are data principals. Your CRM is in scope.

The seven things you actually have to build

1. Consent capture that produces evidence

The requirement is not a checkbox. It is an auditable record that can demonstrate, later, that a specific person gave specific consent for a specific purpose at a specific time — and that they were shown a compliant notice when they did.

That means a consent event store, versioned notice text so you can prove what was displayed, purpose-level granularity rather than one blanket agreement, and the same rigour applied to withdrawal.

The design mistake we see most often is storing consent as a boolean on the user record. It needs to be an append-only log. When the Board asks what someone consented to in March 2026, a boolean tells you nothing.

2. Consent blocking that actually blocks

Non-essential scripts, pixels and trackers must not fire before consent. A banner that renders while Google Analytics has already loaded is not compliance, it is decoration.

This requires tag-firing to be gated at the consent layer, plus regular automated scanning to catch the marketing tag someone added through a third-party tool six months after launch. Cookie inventories drift. Treat scanning as a scheduled job, not a one-time audit.

3. Geolocation-aware consent flows

Most of our clients serve users across jurisdictions. Running separate consent stacks for DPDP, GDPR and CCPA is a maintenance nightmare.

The sane architecture is one consent platform with jurisdiction detection, triggering the appropriate flow per user. Build to the strictest standard and you satisfy the rest — GDPR's thirty-day response window is tighter than DPDP's ninety-day requirement, so a system that meets the former clears the latter automatically.

4. Data principal rights workflows

Access, correction, erasure and grievance redressal all need a path from request to resolution with deadline tracking.

Manual handling fails at scale, and it fails quietly — a request sits in a shared inbox, someone is on leave, the window closes. What you need is an authenticated self-service portal, automated discovery across databases, CRM, analytics and backups, workflow routing to the right team, and timestamped documentation of what was done.

5. Deletion that reaches everywhere

This is the single hardest engineering problem in the list, and it is where most compliance programmes quietly fail.

Erasure means erasure across primary databases, read replicas, search indexes, caches, data warehouses, analytics platforms, backups, third-party processors and log files. If your architecture has no data lineage map, you cannot honour a deletion request truthfully — you can only honour it in the places you happen to remember.

Build the lineage map first. Everything else in this section depends on it.

6. Retention automation

Purpose limitation and retention schedules have to be enforced by the system, not by intention. That means each data category carries a retention clock, and expiry triggers deletion or anonymisation without a human deciding to run it.

Legacy data is the sharp edge here. Personal data you collected before the DPDP framework existed still needs valid notice and consent to be retained. That backfill is a project in itself, and it is one of the compliance focus areas expected as enforcement matures.

7. Breach detection and reporting

Breach notification obligations are time-bound. If your detection depends on someone noticing anomalous behaviour, you will miss the window.

The build is: monitoring that identifies unauthorised access, an incident classification path, a pre-drafted notification pipeline, and a rehearsed runbook. Rehearsed matters. The first time you run your breach process should not be during a breach.

Two things worth knowing before you buy a tool

A consent manager is a regulated entity, not a product category. Under the Rules, a consent manager is a specifically defined role — an India-incorporated company meeting a minimum net worth threshold that acts as a single interface for individuals to give, review and withdraw consent across multiple fiduciaries. That is a narrower thing than "a company that sells consent software," and it excludes several well-known international platforms from operating in that registered capacity. Do not assume your existing vendor qualifies.

Buying a platform compresses the timeline but does not remove the work. A deployed consent management platform can cut months off custom development. It will not map your data lineage, refactor your deletion paths or classify your legacy records. Those remain yours.

Where to start if you have not

If you are reading this in the second half of 2026 with nothing built, the sequence that works is:

  1. Data mapping audit — what personal data you hold, where it lives, why, and who it flows to
  2. Gap analysis against the substantive obligations
  3. Consent infrastructure — the event store and the blocking layer
  4. Rights and deletion pipelines — built on the lineage map from step one
  5. Retention automation and breach runbook
  6. End-to-end testing with enough runway to fix what testing finds Steps one and two are weeks. Steps three through five are quarters. That arithmetic is why November 2026 is a more honest deadline than May 2027.

The short version

DPDP compliance is a build, and the build is bigger than it looks from the policy summary. Full substantive obligations land 13 May 2027, the consent manager framework opens 13 November 2026, penalties reach ₹250 crore, and the extraterritorial provisions catch far more businesses than most founders assume. The work that matters is an auditable consent event store, genuine consent-gated script blocking, rights workflows with deadline tracking, a data lineage map that makes deletion truthful, enforced retention clocks, and a rehearsed breach pipeline. Start with the data map — nothing downstream is buildable without it.

This post explains engineering practice and is not legal advice. Scope, classification as a Significant Data Fiduciary, and sector-specific obligations should be confirmed with counsel.

Keep reading

More from the workbench

All articles →