Founders read a summary of the DPDP Act, see the penalty numbers, and either panic or decide it is a problem for later. Both reactions skip the useful part: nearly everything the Act asks a small product team to do is ordinary engineering work, and most of it makes the product better anyway.
This is not legal advice — for a regulated sector or a large data estate, get a lawyer. What follows is the engineering checklist I work through with teams before an assessment, because the same gaps that fail an audit are the ones that turn a bug into a reportable breach.
1. Know what you hold
Every other obligation depends on an inventory, and almost nobody has one. Not a diagram — a list, kept current, of every store that holds personal data and why.
- Primary databases, obviously, but also caches, search indexes, queues, analytics warehouses and object storage.
- Third parties: crash reporters, analytics SDKs, support desks, email tools, payment processors. Each one that receives personal data is a processor you are responsible for.
- Logs. Request bodies in application logs are the single most common place a team accidentally retains personal data it never intended to store.
- Backups and snapshots, including the ones an engineer took manually two years ago.
The practical form is a table in your repository, updated in the pull request that adds a new field or integration. Review it quarterly. Nothing else on this list works without it.
2. Consent, per purpose, with a record
The Act treats consent as specific and purpose-bound. Consent to process an address for delivery is not consent to use it for marketing. In engineering terms: a boolean called terms_accepted is not enough.
- Store consent as rows, not a flag: purpose, version of the notice, timestamp, and how it was collected.
- Version your privacy notice, and record which version each consent refers to.
- Withdrawal has to be as easy as granting. Build the switch-off path before you need it.
- Pre-ticked boxes and bundled consent are not consent.
3. Deletion that actually deletes
A deletion request must reach every copy, which is exactly why the inventory comes first. Soft-deleting a row and leaving the same data in three caches, a search index, last month’s backup and your support tool is not erasure.
- Write a deletion runbook per data store, and script the parts you can.
- Decide up front how backups are handled — most teams document a retention window after which restored data is re-deleted, rather than surgically editing backups.
- Propagate to processors: if your support tool holds tickets containing personal data, deletion has to reach it too.
- Log deletions. You will be asked to prove one happened.
4. Breach notice on a clock
The Act requires notification of the Data Protection Board and affected users, and the timelines are short enough that improvising will fail. What makes this survivable is deciding in advance, while nothing is on fire.
- Define what counts as a personal data breach for your product, in writing.
- Name who declares one, out of hours included.
- Make sure you can answer "whose data, how much, for how long" — which needs audit logging that already exists at the moment of the incident, not logging you add during it.
- Draft the notification templates now. Writing them under pressure is how facts get stated wrongly.
5. Reasonable security safeguards
The Act does not enumerate controls, which makes people nervous. In practice the expectation looks like the baseline any enterprise customer already asks for.
- Encryption in transit everywhere, and at rest for personal data.
- Access control that is enforced server side and reviewed periodically — the most common finding in real assessments is still an endpoint that trusts a client-supplied identifier.
- Multi-factor authentication on administrative access, and no shared admin accounts.
- Patching and dependency updates that actually happen, with evidence that they happen.
- A penetration test or code review at a sensible cadence, with the findings closed and the closure recorded.
Data minimisation is the cheapest control
Every field you do not collect is a field you cannot leak, do not have to inventory, do not have to delete and cannot be asked about. Before the compliance work, spend an afternoon deleting collection you never used: the date of birth nobody reads, the full address for a digital-only product, the contacts permission the app requested in 2023.
Teams that do that first find the rest of the work shrinks by more than the afternoon cost.
Where to start this week
- Write the data inventory. One table, in the repo.
- Grep your logs for personal data and stop writing it.
- List every third party receiving personal data and confirm each is contractually a processor.
- Write the deletion runbook, and run it once against a test account end to end.
- Book the security assessment before an enterprise customer asks for one — the report is evidence of the safeguards obligation, and it is much cheaper before it is urgent.