DPDP is not GDPR with Indian labels. Start with the operating model.
A practical DPDP readiness plan for Indian companies that need to turn the Act and Rules into product, security, and operating decisions.
India’s Digital Personal Data Protection framework is no longer a bill to watch. The Act and final Rules now have a staged commencement schedule, with most operating obligations due to take effect eighteen months after the 13 November 2025 Gazette notification. For most companies, the useful question is no longer whether DPDP is coming. It is whether the product, support, security, and vendor workflows will be ready when the principal duties apply.
The implementation window is an operating deadline
The Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 do not begin all at once. The 13 November 2025 commencement notification brought some institutional provisions into force immediately, scheduled another group after one year, and placed most of the duties that affect ordinary Data Fiduciaries on an eighteen-month timeline.
That makes 13 May 2027 the practical readiness date for many organisations, subject to the exact provision and any later government action. A company should verify the provisions that apply to it rather than treating one date as a substitute for legal analysis.
The runway is useful only if it changes the operating plan. A privacy notice can be drafted quickly. Finding every collection point, repairing consent flows, setting deletion triggers, changing processor contracts, and testing a breach response cannot.
Do not copy a GDPR programme and rename it
DPDP borrows familiar privacy ideas, but its structure and language are its own. It applies to digital personal data processed in India and can also reach processing outside India when connected with offering goods or services to Data Principals in India. It uses Data Principal, Data Fiduciary, and Data Processor rather than the GDPR vocabulary many teams already know.
The lawful-use model also deserves care. Consent is central, but the Act separately permits specified “certain legitimate uses.” That is not an invitation to import a broad GDPR legitimate-interests assessment into every use case.
Nor does every company need a GDPR-style data protection impact assessment. Under DPDP, periodic DPIAs are among the additional obligations that may apply to a Significant Data Fiduciary notified by the Central Government. An ordinary Data Fiduciary may still use a privacy risk assessment because it improves a risky product decision, but should not confuse useful governance with a universal statutory requirement.
Build the programme from the Indian framework and the company’s real processing—not from a renamed European template.
Start with five operating decisions
### 1. Know what personal data supports each purpose
Create a short register of meaningful processing activities: account creation, payments, customer support, employee administration, product analytics, marketing, fraud prevention, identity checks, and model training. For each activity, record the personal data used, the purpose, the source, the systems and processors involved, the retention trigger, and the accountable owner.
This is not inventory for its own sake. It is how the company finds data collected without a clear purpose, vendors nobody is managing, and records nobody knows how to delete.
### 2. Choose the permitted basis before designing the notice
For every activity, decide whether the processing depends on consent or a specific use permitted by the Act. Do not use one bundled acceptance to cover unrelated purposes.
Where consent is used, the request must support a free, specific, informed, unconditional, and unambiguous choice through clear affirmative action. The Rules require a standalone, understandable notice that itemises the personal data and explains the specified purpose and the goods, services, or uses it enables. Withdrawing consent should be as easy as giving it.
The product question is practical: can the company show what the person agreed to, which version of the notice they saw, and what downstream processing stops after withdrawal?
### 3. Give people one route that actually works
Rights should not depend on finding the correct internal team. Create a visible route for access to prescribed information, correction, completion, updating, erasure, and grievance handling. Decide how the company will verify the requester, locate the relevant data, coordinate with processors, record the outcome, and escalate a disputed response.
Nomination also needs a place in the design: the Act allows a Data Principal to nominate another individual to exercise rights in the event of death or incapacity.
A rights page with no operating queue behind it is not readiness. Test the journey with a real customer record before launch.
### 4. Turn “reasonable security” into evidence
The final Rules make security an operational obligation, including for processing performed by a Data Processor. Expected safeguards include measures such as encryption, obfuscation, masking or virtual tokens where appropriate; access controls; logs and monitoring; backups and recovery; and contractual provisions requiring processors to protect the data.
Connect these measures to the systems that hold personal data and retain evidence that they operate. A generic security policy will not show whether an old support export, analytics workspace, or vendor integration received the same protection as the main product database.
Build the breach workflow at the same time. The company should be able to identify affected Data Principals, explain the likely consequences and mitigation, communicate with them, and supply the Board with the information required by the Rules. Run a tabletop before an incident supplies the deadline.
### 5. Make deletion a product capability
DPDP does not support indefinite retention by default. When consent is withdrawn or the specified purpose is no longer being served, the company may need to erase the personal data and cause its processors to erase it, unless retention is required by law.
Define the event that ends each purpose: account closure, contract termination, completion of a support request, expiry of a legal retention period, or another observable trigger. Then identify where deletion is immediate, delayed, legally restricted, or technically propagated to backups.
If the organisation offers services to children, treat that as a separate design track. Verifiable parental consent and restrictions on tracking, behavioural monitoring, and targeted advertising cannot be added reliably at the end of development.
The next 30 days
The objective is not to produce the largest compliance tracker. It is to enter the enforcement phase with fewer unknown data flows, fewer promises the product cannot honour, and a short list of controls that have already been tested in operation.
- Name one accountable DPDP readiness owner.
- List the ten most important processing activities and their owners.
- Mark which activities rely on consent and which rely on a specific provision of the Act.
- Test one consent-withdrawal journey and one erasure request from end to end.
- Identify processors that handle personal data and check the security and deletion terms in their contracts.
- Run a breach tabletop using a real product data flow.
- Decide whether children’s data or a possible Significant Data Fiduciary designation creates additional work.
Primary references
- Ministry of Electronics and Information Technology, Digital Personal Data Protection Act, 2023: https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf
- Ministry of Electronics and Information Technology, Digital Personal Data Protection Rules, 2025: https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa
- Gazette of India, commencement notification G.S.R. 843(E), 13 November 2025: https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf
Useful now, not someday.