How do we build privacy into a new product or system?
Reviewed by InfraVeritas360 ResearchFirst published Last reviewed
Sources: DPDP Act, 2023 and DPDP Rules, 2025 (MeitY)
Short answer: Four questions at design, then build the basics in
Ask four questions at the design stage: what personal data, why, for how long, and who sees it. Then build in what the Act assumes: a notice, consent where needed, role-based access, logs of record views, a way to delete, and a way to answer requests. Adding these after launch costs far more.
Why it matters
Sections 5 to 12 assume systems that can show notices, record consent, limit access, log, delete and answer requests.
- Section 5 · Rule 3: When you ask for consent, give a clear notice that stands on its own: what data, for what purpose, how to withdraw consent, how to use the rights and how to complain to the Data Protection Board. For data collected before the Act, a notice is due as soon as reasonably practicable.
- Section 6: Consent must be free, specific, informed, unconditional and unambiguous, given by a clear action, limited to the data needed for the purpose, and as easy to withdraw as it was to give.
- Section 8(5) · Rule 6: Protect personal data with reasonable security safeguards. Rule 6 lists the minimum: encryption, masking or tokenisation; access control; logs and monitoring; backups for continuity; keeping logs for at least one year; and security terms in contracts with processors.
- Section 8(7) · Rule 8: Erase personal data when its purpose is over or consent is withdrawn, unless a law requires you to keep it, and have your processors erase it too. Rule 8(3) asks every Data Fiduciary to keep personal data, traffic data and logs for at least one year for purposes listed in the Rules.
- Sections 11–14 · Rule 14: People can ask for a summary of their data and who it was shared with, ask for correction, completion, updating or erasure, complain, and nominate someone to act for them. You must publish how to do this.
A worked example
A bank's new app feature would collect location all the time. Design review asks why; location is needed only at KYC. The permission is limited to that step before build.
Steps
- Add the four questions to design templates.
- Drop data you do not need.
- Build access roles and record-view logs.
- Build deletion and request export.
- Register the system in the inventory at launch.
Evidence to keep
- Design review records
- Inventory entries
- Deletion tests
Common mistakes
- Privacy review only at launch
- Collecting 'in case we need it'
- No delete function
Who does what
- CTO / Engineering head: Make the privacy questions part of design review, not a sign-off at the end.
- Data and analytics head: Work with masked or aggregated data wherever the question allows.
- Product head: Add four questions to every feature brief: what data, why, how long, who sees it.
- Data and analytics department: Mask and aggregate by default.
- Software engineering department: Build the four questions into design review.
What a good answer from management sounds like
“Every design review answers the four questions, and new systems launch with access roles, logs and deletion in place.” Effort and time: Light per project.