The DPDP Act in practice: what actually changes for your engineering team

The Digital Personal Data Protection Act moved data protection in India from a set of sectoral rules to a general obligation, and the practical weight of it lands on engineering rather than on legal. A policy document does not satisfy the Act. A working consent record, an enforced retention schedule and a breach notification path that runs on a clock — those do.

Here is what we find teams consistently underestimate when the programme starts.

Consent is a data structure, not a checkbox

The Act requires consent that is free, specific, informed and unconditional, and it requires you to be able to demonstrate it later. That means storing the purpose, the version of the notice shown, the timestamp and the withdrawal state — per purpose, not per user. Teams that modelled consent as a single boolean end up rebuilding it.

Withdrawal is the part that catches people out. It has to be as easy as giving consent, and it has to propagate to every downstream system that received the data, including the analytics warehouse and whatever was exported to a third party.

Retention becomes an enforced schedule

Personal data must be erased once the purpose is served and retention is no longer required. In practice this means someone has to own a retention matrix, and the deletion has to actually execute — including in backups, logs and derived datasets.

The uncomfortable question we ask early is simple: if a user asked you today to erase everything you hold about them, could you enumerate where it all lives? Most companies cannot on the first attempt, and the gap is almost always in log aggregation and analytics.

Breach notification runs on a clock

Notification obligations to the Data Protection Board and to affected principals do not wait for your investigation to conclude. That changes incident response design: you need a decision point early in the process where someone with authority determines whether the reporting clock has started, and you need the contact data and templates ready before the day you need them.

Companies already reporting under CERT-In directions have a head start here, but the two regimes have different triggers and different audiences. Run them as one workflow with two outputs, not as two separate scrambles.

Where to start

If the programme has not begun, this sequence has worked well for our clients:

• Map the data first — what personal data you hold, where it flows, and which third parties receive it.
• Fix retention before consent. Deleting what you should not hold shrinks every other obligation.
• Model consent per purpose with versioned notices, and build withdrawal at the same time.
• Wire the breach clock into your existing incident process rather than creating a parallel one.
• Assign a named owner. Obligations without an owner become findings.