Privacy by Design Under the DPDP Act: A Practical Framework for Businesses

Let me describe a meeting that’s probably happening somewhere right now. Two days before launch, loyalty app for a chain of chai shops (made up, but you’ll know the type). The signup screen wants name, phone, date of birth, home address, monthly income - income! for a cup of chai - and permission to read your contacts. Someone from legal asks why. The PM shrugs. “In case we need it later.” Nobody can say when later is. Four hours, three coffees and one slightly tense call with the engineers afterwards, half the fields are gone and the release slips a day.

That, give or take, is the whole case for privacy by design under DPDP. Same argument, same people. In week one it costs you a whiteboard. In week fifty it costs you a sprint.

Dates, quickly, because someone always asks. The real duties kick in on 13 May 2027, and the Act reckons a failure to take reasonable security safeguards is worth up to ₹250 crore, the top rung. Most of the other things you could get wrong land in the catch-all bucket, up to ₹50 crore. So about seven months. Not nothing, not plenty either.

A small confession about the phrase

The DPDP Act never says “privacy by design.” Not once. That’s GDPR vocabulary (Article 25, data protection by design and by default), and a civil-society submission on the draft Rules argued that the Rules’ wording on technical measures is narrower than Article 25. So if somebody tells you the Act mandates privacy by design, they’re being generous.

But, and it’s a big but, the Act is full of bits that add up to the same thing. A fiduciary has to put appropriate technical and organisational measures in place so the Act is observed (that’s Section 8(4)). Consent has to be limited to the data the purpose needs. Taking it back has to be as easy as giving it. And the data should go once the job’s done. Line those up and you’ve built privacy by design DPDP-style without ever using the label. What follows is my way of organising it, not the statute’s, so a product team can pick it up on a Monday.

Start at the form

Back to the chai app. The first thing I’d do is sit with the signup form and ask, for every field, what breaks if it isn’t there? Phone number - we need it to send points. Name - nice on the receipt. Date of birth - fine for a birthday freebie, so make it optional and say why. Income? Contacts? Gone.

The Act has its own example of this, a telemedicine app that also asks for the phone’s contact list, and the answer is the same: consent is limited to the data the service needs, so the extra ask doesn’t stand. If your honest answer to “why do we collect this” is “dunno, we always have,” that field is a liability sitting in your database.

The notice nobody reads (so make it readable)

Then the notice. It has to come with or before the ask, and Rule 3 wants it in clear, plain language and able to stand on its own, with an itemised list of what you take and what for. No hiding it on page 14 of the privacy policy. It also needs a link, or some way, to withdraw consent, use her rights and complain to the Board, and you’ve got to offer it in English or any language in the Eighth Schedule.

My test is simple. Show the screen to someone from the shop floor, not a lawyer, and ask what they just agreed to. If they can’t tell you, go again.

An off switch that works

Say a customer gets fed up with the marketing texts and pulls her consent. You stop, and make your processors stop. She can also ask for her data to be corrected or erased, and she has a right to know who else has been given her info - a pretty unpleasant surprise for anyone whose vendor list is in disarray.

The off switch can’t just be a button in the app that someone thoughtfully clicks and that’s it, it needs to actually reach all the different systems it’s connected to - the SMS vendor, the analytics platform, the warehouse, to name a few. Try being the customer and seeing if you can actually turn it off yourself. Then go check the vendor’s end a week later - because that’s usually where you’ll find the problem.

Boring defaults

Rule 6 basically reads like a security to-do list: encryption, access control, logging and monitoring in place, backups, and keeping all your logs and data for a whole year. For the chai app that turns into masked data in test environments (please), phone numbers visible only to the loyalty team, and a retention period decided on day one, say two years after the last purchase. That number’s mine, not the law’s.

It’s all very dull. That’s the point. I’d bet few breaches start with a default somebody set sensibly on day one.

Evidence, or it didn’t happen

If there’s ever a dispute about whether you followed the rules, the Act forces the onus onto you: you have to prove you actually gave notice and got the right consent in line with what the Act requires. So log every piece of consent with the version of the notice, the date and time, keep copies of all past notices, and make a note of why you made the design decisions you made. And date it all. Future you, when you’re standing in front of the board, will be mighty grateful.

What to ask in the design review

Illustrative design-review prompts, not legal advice.

Figure 1. Privacy by design in five steps: collect less, explain simply, switch it off, safe by default, prove it.

Where it fits in the week

You don’t need a new department. Bolt a short privacy check onto three things you already do. When a feature’s first written up, run the five steps on one page. At design review, hold the screens up against Rule 3 and the withdrawal path. Before launch, confirm the defaults, the logs and the vendor list. Thirty minutes each, with product, engineering and somebody from legal (or the DPO’s office) in the room.

And if you might end up notified as a Significant Data Fiduciary, the formal grown-up version of all this is the DPIA, which Section 10 describes as a process covering a description of the rights of Data Principals and the purpose of processing, plus an assessment and management of the risk to those rights. Do the five steps on every feature and that exercise gets a lot less painful.

How teams fake it

Never on purpose, to be fair. It’s what happens when the deadline’s tight. A cookie banner with a pre-ticked box, or one that only has “Accept all.” A privacy policy doing a notice’s job. Consent captured on screen and logged nowhere. A “delete my account” button that hides the record in the front end while the warehouse keeps hold of it. Production data copied to staging “just for testing” and left there for two years. An analytics tag fires off before the visitor has even had a chance to click anything - there’s a quick ten-minute test for it in Your Tags Are Firing Before Consent.

And if you’re looking at this from the perspective of users under 18, the design needs to have age signals and parental consent built right in from day one, not just tacked on at the end as an afterthought.

Who gets to draw the line

Not just lawyers alone please. The product team decides what data gets collected, design figures out how to explain it, engineering sorts out who gets access to what and where it lives, security comes in to lock it all down, and procurement has a say on what the vendors can do with it. Pick one person to be the point person on privacy by design & Data Protection by Design work and give them the real power to pull the plug on a launch - if not, it’s just a bunch of advice.

Train the people who actually call the shots - designers and engineers - using specific examples from your own product rather than some generic slide presentation. That way they’ll remember the one field they argued over last quarter long after they’ve forgotten some jargon definition.

The next 30 days - a reality check

Pick the journey that’s got the most personal data floating around. Run those five key steps on it with the whole team in the room. Write down what fields you can safely ditch, what notices need a rewrite, and all the places withdrawal just isn’t working. Fix the easy stuff this month & schedule the rest for later - and then, get to work on the next product. Seven months is long enough to sort out most of your main journeys if you start right now - but don’t wait until the Board comes along & asks you to.