How to implement privacy by design in software development under DPDP
Privacy by design embeds data protection into your product from the start, not as an afterthought. Here is how software teams implement it under the DPDP Act.
What are the seven principles of privacy by design for software teams?
The seven PbD principles applied to software: (1) Proactive, not reactive — address privacy risks in design, not in incident response; (2) Privacy as the default — the most privacy-protective setting should be the default without user action; (3) Privacy embedded in the design — not a feature add-on, but part of the system architecture; (4) Full functionality — privacy-protective design does not compromise product functionality; (5) End-to-end security — protect data throughout its lifecycle; (6) Visibility and transparency — users can see what data is collected and how it is used; (7) User-centric — design puts the data principal in control.
How do you implement privacy by design in the product requirements stage?
At requirements definition: for every feature that involves personal data, add DPDP requirements: what data does this feature need to function? What is the minimum data set? What consent is needed? Who can access this data? How long is it retained? What happens when the user deletes their account? Convert these into user stories: 'As a data principal, I can download all my personal data from my account settings' and 'As a data principal, I can delete my account and all associated data within 30 days.' Privacy requirements should be in the same product backlog as feature requirements — not a separate compliance checklist that engineering discovers at the end.
How do you implement data minimisation in code?
Data minimisation in code: only define database columns for data you will actually use; resist the temptation to collect 'interesting' data fields you might use later; add code review checks for new database columns or API parameters that collect personal data — each should have a justification; implement request/response field filtering in APIs so internal services do not expose more personal data than the calling service needs; and audit database schemas periodically against your data inventory to identify orphaned data columns that are no longer used.
How do you implement access control for personal data in software?
Role-based access control (RBAC) for personal data: define roles that reflect actual need-to-know (customer service can see customer contact and order data, but not payment card details; finance can see payment data, but not customer support conversation history); enforce RBAC at the API and database query level, not just in the UI; log every access to sensitive personal data fields (who accessed what, when, from which system); alert on anomalous access patterns (a user downloading 1,000 customer records in 10 minutes); and revoke access immediately when an employee's role changes or they leave.
How do you build data deletion into software architecture?
Data deletion is technically challenging in distributed systems. Design for it from the start: use soft deletes in the database with a deletion date, and a scheduled job that permanently removes records after the retention period; build a cascade-delete function that identifies and removes all records associated with a user across related tables when they request erasure; ensure data warehouse and analytics pipelines have a mechanism to propagate deletions (event-driven pipelines can process delete events); and test deletion in staging — confirm that a deletion request actually removes data from all systems, not just the primary database.
How do you implement encryption at the application level?
Application-level encryption protects sensitive fields even from database administrators and cloud provider access. Implement: encryption at rest for sensitive fields (health data, financial data, identity document scans) using application-managed keys, not just database encryption; encrypted transit for all API calls (TLS 1.2 minimum, preferably 1.3); field-level encryption for particularly sensitive data (card numbers, Aadhaar numbers stored in masked form); and key management using a secrets manager (not hardcoded keys in source code). Rotate encryption keys on a schedule and test key rotation without data loss.
Frequently asked questions
Should privacy requirements be handled by the engineering team or the legal team?
Both. Privacy by design requires legal/privacy input (what are the DPDP requirements?) and engineering implementation (how do we build them?). The privacy team translates DPDP obligations into technical requirements; the engineering team implements them. The privacy team should be involved in product design reviews and architecture decisions that affect personal data. A privacy review gate before any feature launch that processes personal data — similar to a security review gate — is the right structural solution.
How do we retrofit privacy by design into an existing system?
Retrofitting is expensive but necessary. Prioritise: first, identify and fix the highest-risk gaps (unencrypted sensitive data, no access controls on personal data databases, no deletion mechanism). Second, implement a data inventory to understand what data you hold and where. Third, add consent management and rights mechanisms. Fourth, work through lower-risk improvements systematically over a 12-month roadmap. Document the improvement plan — if the Board investigates, showing a credible remediation roadmap is far better than no plan at all.
Does privacy by design apply to AI and machine learning features?
Strongly yes. AI and ML features that process personal data — recommendation engines, fraud detection, churn prediction, hiring algorithms — are high-risk processing activities under DPDP. Apply PbD: train models on de-identified or synthetic data where possible; implement differential privacy for models trained on personal data; audit model outputs for discriminatory patterns against sensitive categories; build an explanability mechanism for automated decisions that affect individuals; and conduct a DPIA before launching any AI feature that processes personal data at scale.
Embed DPDP privacy controls in your engineering process
Niti Bharat's CTO Engineering Privacy Pack provides a complete privacy-by-design framework — technical requirements template, code review checklist, access control matrix, and deletion architecture guide for DPDP-compliant software development.
Get the Engineering Privacy Pack