Privacy debt behaves like technical debt: fixing it after scale is slower, costlier and more disruptive.
Quick View
Add privacy questions to product requirements, architecture, QA and launch approval rather than relying on a final legal review.
Add privacy section to product brief.
Product requirements.
Legal review on launch day.
Why It Matters
The Digital Personal Data Protection Act, 2023 and the final Rules notified in November 2025 follow phased commencement. As of 25 June 2026, organisations should separate duties already operative from consent, grievance, rights, children, Significant Data Fiduciary and other operational provisions scheduled for later commencement, while continuing to comply with the IT Act, CERT-In directions and sector-specific rules already in force.
The DPDP framework emphasises purpose, necessity, security, accuracy, rights, erasure and processor accountability. These requirements are easier to meet when product architecture supports them from the start.
Privacy by design is an operating method, not a certification label. It should produce measurable technical behaviour and evidence.
Control Framework
| Area | What to establish | Operating rule |
|---|---|---|
| Discovery | Purpose, users and risk. | Challenge the feature need. |
| Design | Minimum data and privacy-protective default. | Avoid opt-out dependence. |
| Build | Access, logging, deletion and vendor controls. | Create testable functions. |
| Release | Notice, consent and regression tests. | Block unresolved high risk. |
Action Checklist
- Add privacy section to product brief.
- Review every new field and SDK.
- Use protective defaults.
- Create deletion and export functions.
- Test vendor and API behaviour.
- Retain launch approval and screenshots.
Practical Example
Evidence to Keep
- Product requirements.
- Data-field decisions.
- Architecture and API map.
- Privacy test cases.
- Release approval.
- Post-launch telemetry review.
Warning Signs
- Legal review on launch day.
- Default tracking on.
- Deletion available only manually.
- No API data minimisation.
- Privacy controls excluded from QA.
Detailed Review
A reliable control should connect the individual, data field, purpose, notice or sector disclosure, system, employee access, vendor access, retention rule and closure evidence. A policy statement that cannot be traced through this chain is difficult to operate.
Maintain a legal-timing matrix. Record the DPDP provision, phased commencement status, current IT Act or sectoral duty, business owner, system dependency and implementation deadline. Avoid one blanket label such as compliant or not compliant.
Build controls into technology and workflow. A written instruction cannot stop an SDK from collecting contacts, a campaign tool from re-importing suppressed users or an agent from downloading medical records unless the system enforces the decision.
Use proportionate verification. Weak checks can expose another person’s information; excessive checks create more Aadhaar, health, payroll or bank data that must be protected and deleted later.
Generate evidence during ordinary operations: versioned screens, event logs, access approvals, vendor tickets, complaint chronology, deletion reports, test recordings and management decisions.
Run a negative-path test: refusal, withdrawal, account closure, vendor breach, employee exit or child-user flow. The control should continue to protect data outside the happy path.
Management reporting should show overdue actions, repeat complaints, failed tests and residual risk rather than only the publication of policies.
Control Test
Select one real user or transaction journey and trace it from collection through sharing, access, retention, withdrawal, complaint or closure. Capture the evidence at each stage.
Test the control on production-like systems rather than screenshots alone. Review network traffic, event logs, suppression status, vendor responses, role access and deletion output.
Run an adverse scenario: the vendor is breached, the user is a child, the borrower alleges harassment, the employee leaves or the app permission is revoked. Record the response and gaps.
Compare public wording with actual behaviour. Product forms, call scripts, privacy notices, contracts, SDKs and support tools should tell the same story.
Assign a named owner, funded action and closure date to each gap. Retain the reason when management accepts residual risk or chooses a less intrusive alternative.
Escalation Route
Start with the privacy, security, product or regulated-business owner and preserve system evidence before changing configuration or deleting records. Separate current sector and CERT-In obligations from future DPDP readiness.
For serious complaints, children’s data, financial harassment, medical exposure or suspected cybercrime, involve qualified legal, privacy, cyber, banking, insurance or healthcare specialists and use the applicable official channel.
Common Questions
Is privacy by design a separate product?
No. It is a way of designing ordinary products.
Who owns it?
Product owns implementation with privacy, legal, security and engineering support.
What is the strongest evidence?
Working defaults, logs, tests, controls and release decisions.
Can old products be improved?
Yes, through risk-based redesign and deprecation plans.
Official Sources
- MeitY — Digital Personal Data Protection Act 2023 PDF
- MeitY — Digital Personal Data Protection Rules 2025
Use current commencement notifications, final Rules, CERT-In directions and sectoral regulator material. Applicability depends on dates, roles, systems, users and facts.