Most of the companies we talk to about the Digital Personal Data Protection Act are not ignoring it. They are stuck. Someone has read the Act, someone else has read a forty-page checklist, and the product team has been told to hold off on anything involving personal data until legal comes back. That can go on for months.
It does not have to. Most of the work is ordinary engineering and housekeeping, and it can run alongside the roadmap if you do it in a sensible order. This is the order we use.
This is a practical guide from an engineering team, not legal advice. The Act and the Rules are short enough to read in full, and you should. For anything that turns on interpretation, talk to a lawyer.
Where things stand
The Act was passed in 2023. The Rules that make it work were notified in November 2025, and they come into force in stages. The provisions setting up the Data Protection Board applied straight away. Registration of consent managers follows a year after notification. The obligations most businesses care about, including notices, security safeguards, breach reporting and the rights of the people whose data you hold, apply eighteen months after notification, which takes you to around mid-May 2027.
That sounds like plenty of time. It is less than it looks once you account for budgeting cycles, vendor contracts and the fact that the data map alone tends to take longer than anyone expects.
Start with a map, not a policy
Everything else depends on knowing what personal data you hold, where it lives, why you collected it and who you share it with. Without that, a privacy notice is guesswork and a retention policy is a wish.
A good first map does not need a tool. A spreadsheet with one row per system is enough: what personal data it holds, the purpose, where it is stored, which vendors can see it, and how long it is kept today. Include the awkward places. Shared drives, exported spreadsheets on laptops, the CRM a sales team signed up for on a credit card, and old backups.
Engineers can fill in most of it in a couple of weeks. The surprises you find here, and there are always surprises, are the most useful output of the whole exercise.
You cannot write an honest privacy notice for data you did not know you had.
Notices and consent people can read
The Act expects consent to be free, specific, informed and unambiguous, and given through a clear affirmative action. The notice that goes with it has to be understandable on its own and tell people what data you are collecting and why.
In practice that means three changes for most products. Notices get shorter and more specific, written for the person filling in the form rather than for a regulator. Pre-ticked boxes and bundled “I agree to everything” consent go. And withdrawing consent has to be about as easy as giving it, which is a product and engineering question as much as a legal one.
Your data map tells you which purposes need consent and which rely on another lawful basis. Take that list to your lawyer before you redesign anything.
Children, if you have them
Under the Act, anyone under eighteen is a child, and processing their personal data needs the verifiable consent of a parent or lawful guardian. Tracking, behavioural monitoring and targeted advertising aimed at children are restricted.
For edtech, coaching and many consumer apps this is the single biggest change, because a large share of users are under eighteen and the sign-up flow was never built to tell. Work out early how you will know a user’s age, how you will verify the parent, and what the product does differently for a child. It touches onboarding, analytics and marketing all at once, which is exactly why it should not be left to the end.
Security you can evidence
The Act requires reasonable security safeguards to prevent a personal data breach, and the heaviest penalty in the Act, up to ₹250 crore, is for failing to take them. The Rules spell out what reasonable looks like in practical terms: encryption or similar measures, access control, logging and monitoring so misuse can be detected, backups and continuity, and contracts that hold your processors to the same standard.
None of this is new to a team that already follows ISO 27001 or a similar framework. What changes is that you need to be able to show it. Access reviews that actually happened, logs that are kept and looked at, and vendor contracts that say the right things.
Rehearse the breach before it happens
If personal data is breached, you have to tell the Data Protection Board and each affected person. The notice to people has to be plain and prompt, and has to say what happened, what it means for them and what they can do. The Rules then expect a fuller report to the Board within seventy-two hours of becoming aware of the breach.
Seventy-two hours is not long when you are also trying to contain an incident. Write the plan now: who decides it is a breach, who drafts the notices, how you reach every affected person, and who talks to the Board. Then run it once as a tabletop exercise. The first rehearsal always finds a gap, and it is far better to find it on a quiet Tuesday.
Retention and erasure
Personal data should be erased once the purpose it was collected for is served, unless a law requires you to keep it. Most systems were built to keep everything forever, so this is real engineering work: deciding a period for each kind of data, building the deletion, and making sure it reaches backups and the copies in your vendors’ systems.
Be aware that deletion and logging pull in opposite directions. The Rules also expect certain logs to be kept for a minimum period to support investigations. Your retention schedule should say which wins for each kind of record.
An order that keeps the roadmap moving
Here is how we sequence it so the product team keeps shipping:
- Weeks 1 to 3: the data map. Engineers and a privacy lead, one row per system.
- Weeks 3 to 6: a short gap list. Ranked by risk, with an owner per item. Product work that does not touch the risky areas carries on.
- Next: notices, consent and children. These change user-facing flows, so they go into the normal sprint plan like any other feature.
- In parallel: security evidence and vendor contracts. Mostly a job for the platform team and procurement.
- Before the deadline: the breach drill and the retention jobs. Both need the map to exist first.
The point of the order is that nothing waits on everything else. A team that starts the map now has comfortable time. A team that waits for perfect legal certainty before touching anything will be doing all of it at once in the spring of 2027.
Written by the people at Ucanly who do this work for clients. If you think we have got something wrong, or you have seen it go differently, we would genuinely like to hear it: support@ucanly.in.