The Digital Personal Data Protection Act, 2023 is frequently discussed in terms of penalties and rarely in terms of what has to change in an actual application. This is a practical view of the engineering implications.
This is a technical summary and not legal advice — the specifics of your obligations depend on your business, and you should take proper counsel on them.
Consent has to be granular and withdrawable
A single checkbox accepting a general privacy policy does not satisfy the requirement. Consent must be specific to a purpose, informed, and as easy to withdraw as it was to give.
In practice that means a consent record per purpose with a timestamp and the notice version that was shown, plus a mechanism for withdrawal that genuinely propagates — stopping the processing rather than just setting a flag nobody reads.
Purpose limitation constrains your data model
Personal data collected for one purpose cannot be freely reused for another. This has a direct engineering consequence: the ad-hoc analytics table that quietly accumulates everything is now a liability rather than a convenience.
Data collection should be justified per field. If nobody can articulate why a field is collected, the safest and cheapest action is to stop collecting it.
Erasure has to actually work
Data principals can request erasure, and the obligation extends to processors acting on your behalf. Most systems handle this poorly because personal data is scattered — the primary table, audit logs, backups, exported reports, the search index, the email service provider, the analytics platform.
Building an inventory of where personal data lives is unglamorous work and the single most useful preparation. Without it, an erasure request cannot be answered honestly.
Retention needs to be defined and enforced
Data must not be kept longer than the purpose requires. Practically, that means a defined retention period per data category and a scheduled job that actually enforces it. Indefinite retention because storage is cheap is no longer a defensible default.
Note the tension with other obligations — statutory record-keeping under tax and company law requires retention for defined periods. Retention policy has to reconcile both.
Children's data is treated differently
Processing a child's data requires verifiable parental consent, and behavioural advertising or tracking directed at children is prohibited. Any product with users under eighteen — education platforms especially — needs age determination and a parental consent flow built in.
Breach notification is time-bound
Personal data breaches must be reported to the Data Protection Board and to affected individuals. Meeting that in practice requires knowing a breach has occurred, which requires logging and monitoring adequate to detect unauthorised access rather than discovering it months later.
A reasonable starting point
Inventory where personal data lives. Remove fields nobody can justify. Implement per-purpose consent with withdrawal. Define retention per category and enforce it in code. Build an erasure process that covers every location, including third parties. Ensure logging is sufficient to detect a breach.
None of this is technically difficult. It is mostly a matter of doing it deliberately rather than discovering the gaps under a deadline.