DPDP compliance for a small Indian product team

Most Indian founders treat data protection as a problem for later — something to solve at Series A, alongside the auditor and the ESOP pool. Meanwhile their app has 40,000 phone numbers in a database with no retention rule and no deletion path.

The law does not scale with your headcount. If you hold personal data of people in India, the duties apply now. The good news is that for a small team the honest compliance work is about a week, and most of it is engineering you should have done anyway.

This is a practitioner’s checklist, not legal advice. For anything contentious, and certainly before you process children’s data or health data, talk to a lawyer.

What counts as personal data

Anything that identifies a person. Name, phone, email, address, device identifier, photo, location, order history tied to any of those. In practice, if you can look at a row and work out who it is, it is personal data.

Most product teams underestimate the surface. It is not only your users table. It is your support inbox, your analytics, your logs, your CSV exports on somebody’s laptop, your WhatsApp business account, and the spreadsheet your operations person keeps.

First task: write down every place personal data lives. This inventory is the foundation of everything else, and almost nobody has one.

The five things that actually matter

1. A notice people can understand

At the point you collect data, say what you are collecting, why, and how someone can withdraw consent later. Plain language. Not a 4,000-word policy nobody opens.

Practically: a short notice next to the signup form, linking to the full policy. If you operate in multiple languages, the notice belongs in those languages too — a Hindi-speaking customer consenting to an English wall of text is a weak position to defend.

2. Purpose limits and unbundled consent

Collect for a stated purpose, use it for that purpose. If you later want to use order data to train a recommendation model or send promotions, that is a new purpose and needs its own consent.

The single most common failure in Indian apps: one tick-box covering account creation, order updates and marketing together. Split it. Transaction fulfilment does not need a marketing opt-in, and forcing them together taints both.

3. A deletion path that works

Someone asks you to delete their data. Can you? Actually?

Most teams cannot, because data is scattered across a database, a mailing tool, a support desk, an analytics product and three backups. Build the path before someone asks:

• A single function that removes or anonymises a user across every system on your inventory
• A documented rule for what must be retained anyway, for example invoices kept for tax purposes, and for how long
• A record of the request and what you did

Anonymising is usually better than deleting for financial records — keep the invoice, sever the identity.

4. Retention rules

Data you no longer need is pure liability. Set a rule for each category and enforce it with a scheduled job.

Reasonable defaults for a small product: raw application logs 30 days, support conversations 12 months, inactive accounts flagged at 24 months, invoices per your tax obligations, marketing lists purged of anyone who has not engaged in a year.

The job that enforces this is twenty lines of code and removes an enormous amount of risk.

5. Somebody who owns a breach

You need to know quickly when something goes wrong, and you need one named person who runs the response.

Minimum viable process: error and access alerting that reaches a human within the hour, a written page describing who to call and what to check, a template notice for users, and a log of what you did. Rehearse it once. An untested plan is a document, not a process.

The engineering that doubles as compliance

Almost everything above is also good practice.

Least privilege. Your operations team does not need a full database export to answer a support ticket. Build the narrow view they need.

No personal data in logs. Redact phone numbers and emails at the logging layer. This one change removes an entire category of exposure, because logs end up in more places than anyone tracks.

Encrypted at rest and in transit. Standard on any modern managed database, but check rather than assume, particularly for older self-hosted setups and backups.

Access records. Who read what, when. Managed platforms give you most of this for free if you switch it on.

Region awareness. Know where your data physically sits and whether any of your processors move it elsewhere. If you serve UAE or Oman clients as well as India — which many of our clients do — the answer is likely different per region, and it belongs in the inventory.

Working with vendors

Every third-party service that touches personal data is your responsibility to the user. Payment gateway, messaging provider, analytics, email tool, AI model provider.

Two practical rules. First, keep a list with what each one receives. Second, do not send personal data to a model provider unless you have decided that is acceptable and said so in your notice — stripping names and numbers before a prompt is usually easy, and worth building as a habit before it becomes an incident. Our post on AI feature costs covers the logging you should already have; the same table tells you what was sent.

A one-week plan

Day 1 — inventory every place personal data lives, including spreadsheets and inboxes. Day 2 — rewrite the collection notice, split bundled consents. Day 3 — build the deletion and anonymisation function. Day 4 — write retention rules and the job that enforces them. Day 5 — redact logs, tighten access, set up alerting and write the breach page.

That is genuinely most of it for a small product team. Nothing here requires a compliance hire, and all of it makes the codebase better.

Why this is worth doing now

Two reasons beyond the law. Enterprise and export clients increasingly ask for this in procurement, and “we have a deletion path and a retention policy” wins deals. And retrofitting privacy into a product with 200,000 users is a project; doing it at 2,000 is a week.

If you want the inventory and the deletion path built as a scoped sprint, that is a fixed-price engagement. If you are also carrying an AI-written codebase, run the production triage first — exposed data usually shows up there before it shows up in a legal review.