DPDP Phase II — Six-Month AI Compliance Playbook for India

Where India actually is on DPDP, today

The Digital Personal Data Protection Act and the Digital Personal Data Protection Rules, 2025 were notified by the Ministry of Electronics and Information Technology on 13 November 2025. That single date set in motion a three-phase rollout that ends in May 2027. As of late May 2026, we are squarely in the middle.

Here is the timeline, stripped of jargon:

• Phase I — 13 November 2025 (done). The provisions that stand up the Data Protection Board of India became effective the day the Rules were notified. The Board exists, it is staffed, and it is the body that will adjudicate complaints and impose penalties.
• Phase II — 13 November 2026 (the six-month window). Consent Manager rules become effective, twelve months from notification. Significant Data Fiduciary obligations intensify. This is the deadline that should be on every AI engineering leader's roadmap in India today.
• Phase III — 13 May 2027. The remaining substantive provisions of the DPDP Act take effect, eighteen months from notification. By this point the regime is fully live — every data fiduciary in scope is operating under the full Act.

Penalties go up to INR 250 crore per instance. That is roughly £23 million or US$30 million at current rates, applied per breach event rather than per organisation per year. For an AI platform with millions of Indian users, a single mishandled training-data exposure could in principle clear nine figures in fines if the Board chose to escalate.

Why this matters for AI teams specifically

DPDP enforces on a tight set of operational disciplines: notice and consent operations, breach notification, individual rights handling, retention limits and access controls. Each of those maps onto an AI-specific failure mode that generic privacy programmes routinely miss.

Consent has to cover training-data use, not just product use. A user who signed up for a chat assistant in 2024 did not consent for their prompts to fine-tune a model in 2026. Retention applies to prompt logs, conversation history, RAG corpora and fine-tuning datasets — not just the application database. Access controls govern which data scientist can pull a sample of personal data into a notebook. Breach notification covers a model that memorised personal data and regurgitated it to a different user, as much as it covers a database leak.

DPDP is classified as extremely relevant to financial institutions, hospitals, ecommerce marketplaces, telecom providers and AI-based service platforms — a near-perfect Venn diagram with where Indian AI builders are actually shipping product. If your platform sits in any of those verticals, you are in scope.

The six-month sprint, month by month

This is what we would do between June and November 2026 if we were running an AI engineering org in India today. It is sequenced because the later months depend on the earlier ones — you cannot wire consent into a system you have not yet inventoried.

Month 1 (June 2026) — DPDP data inventory

You cannot govern what you have not enumerated. Spend the first month producing a single source of truth for every place personal data touches your AI system, end to end. That includes:

• Training data. Every dataset used to train or fine-tune a model. For each: source, consent basis, retention policy, the model versions it influenced.
• RAG corpus. Every document store, vector index and knowledge base that the production model retrieves from. Personal data hiding in a customer-support ticket archive is still personal data.
• User prompts and outputs. What the user typed, what the model said back, and where both ended up — production database, analytics warehouse, training pipeline, error log.
• Operational logs. Prompt logs, conversation history, debug traces, request/response captures. These are the easy-to-forget category and the highest-probability place a regulator will find unprotected personal data.
• Third-party flows. Anywhere personal data leaves your perimeter — model APIs, vector database vendors, observability tools, support platforms, content-moderation services.

By the end of June you should have a data flow map that any engineering manager can read in fifteen minutes. If you cannot draw it on one A3 page, simplify until you can.

Month 2 (July 2026) — Consent architecture

With the inventory in hand, design how purpose-limited consent gets captured, stored and honoured across the system. The model is not "one big tick box at signup". It is granular: separate consent for product use, for analytics, for training-data use, for sharing with third-party model providers.

Consent state has to live somewhere queryable — every inference call, every fine-tuning job and every analytics query should be able to check what consents the user has granted before processing their data. The Consent Manager integration goes live with Phase II in November; for the deep-dive on Consent Manager mechanics specifically, see our DPDP Phase II Consent Manager checklist for AI Builders. This month, focus on the internal data model — the Consent Manager will plug into it later if you have built it cleanly.

Month 3 (August 2026) — Retention controls

DPDP requires that personal data is retained only for as long as necessary for the specified purpose. For AI systems that historically logged everything forever "for debugging", this is the policy shift that creates the most engineering work.

Build the purge schedules:

• Prompt logs. Pick a retention window — 30, 60 or 90 days are common — and enforce it with a scheduled job that actually deletes. Soft deletes do not count under DPDP.
• Conversation history. User-controllable: surface the deletion option in the product, honour deletions in the underlying store within a reasonable window.
• Fine-tuning datasets. Document the retention basis, set a sunset date if there is no ongoing legitimate purpose, and version-stamp the model that was trained from each dataset so you can answer "was this user's data in the model that served them" honestly.
• Backups and snapshots. The easy gap. A retention policy that applies to production but not to your 90-day backup tier is a retention policy that does not exist.

Month 4 (September 2026) — Access controls

Role-based access control, audit trails and the principle of least privilege, applied specifically to the engineers and data scientists who touch personal data. This is the month where governance work meets the IDE.

Practical patterns:

• RBAC on the data warehouse. Not every data scientist needs row-level access to user identifiers. Build aggregation views and pseudonymisation layers; gate access to raw personal data behind a justified-need workflow.
• Audit trails on notebook environments. If a data scientist pulls a sample of personal data into a Jupyter notebook, the query should be logged, the notebook should be tied to a named purpose and the data should not survive the session unless explicitly justified.
• Production model access. Inference endpoints that return personal data — for example, a customer-service agent that surfaces account details — should authenticate the requester and log the access. "The model said it" is not an exemption.
• Third-party API discipline. If your fine-tuning job ships training data to a third-party platform, that platform's access controls are now your access controls. Audit them.

Month 5 (October 2026) — Breach notification rehearsal

Write the playbook and run a tabletop. The Phase III breach notification regime arrives in May 2027, but Significant Data Fiduciaries already face intensified disclosure obligations under Phase II. You want the muscle memory in place before you are designated, not after.

The tabletop scenarios that catch teams out:

• Model regurgitation. A user reports that the model returned someone else's personal data in a response. Who triages? Who decides if it is a breach? What is the disclosure timeline?
• Training-data exposure. A researcher demonstrates that the model can be prompted to repeat verbatim chunks of training data, including personal data. Is this a breach? How do you investigate without making it worse?
• Vendor incident. A model API provider you depend on discloses a breach. What is your downstream obligation? Whom do you notify and when?
• Insider exfiltration. An engineer downloads a sample of personal data and the access log catches it after the fact. What is the response chain?

Month 6 (November 2026) — Final audit and SDF registration

The last month is verification and, where applicable, Significant Data Fiduciary registration. Engage internal or external audit to test the controls you have built across the prior five months. The questions to answer with documentary evidence:

• Can you produce a current, accurate data flow map on demand?
• Can you demonstrate the consent state for any user, for any purpose, at any point in time?
• Can you prove that retention purges actually run and actually delete?
• Can you produce an audit trail of every engineer who accessed personal data in the past 90 days, with the justification recorded?
• Can you walk through your breach response playbook from detection to Board notification without hesitation?

If your scale, sensitivity or decisioning surface puts you in Significant Data Fiduciary territory, complete the designation paperwork before the deadline rather than after. The intensified obligations include Data Protection Impact Assessments and a designated Data Protection Officer — both of which have lead time.

DPDP requirements mapped to AI builder actions

For the engineering leader who needs a single page to brief their team, here is the compact matrix:

DPDP requirement	What it means for AI	Builder action item	Deadline
Notice and consent	Purpose-limited consent for training-data use, RAG indexing and product inference	Granular consent store + Consent Manager integration	13 Nov 2026
Retention limits	Prompt logs, conversation history, fine-tuning sets cannot live forever	Scheduled hard-delete jobs across production and backups	13 Nov 2026
Access controls	Engineers and data scientists need least-privilege access to personal data	RBAC, pseudonymisation views, audit trails on notebooks	13 Nov 2026
Breach notification	Model regurgitation and vendor incidents both count	Playbook + tabletop; named on-call owner	13 May 2027
Individual rights	Access, correction and erasure across model artefacts, not just the app DB	Rights-fulfilment workflow that includes training-data lineage	13 May 2027
Significant Data Fiduciary duties	DPIAs, Data Protection Officer, intensified audit	Registration + DPO appointment for in-scope platforms	13 Nov 2026

The UK and international angle

UK readers should not file this under "India news, not relevant". DPDP has extraterritorial reach. If your London-based AI product processes the personal data of users located in India — and given the scale of the Indian market, that includes a large slice of UK-headquartered B2C and B2B platforms — the obligations attach to you. The good news is that a team that has already shipped a competent GDPR programme has roughly 70% of the controls already built. The work is in the differences, particularly around consent granularity for AI-specific purposes and the Indian Consent Manager integration.

For US vendors, the same applies with sharper teeth. There is no US federal privacy law that gives you a baseline; you may be building the controls largely from scratch. Treat DPDP as the forcing function to get the AI-specific privacy stack in order — the same controls will largely serve you when state-level US laws inevitably catch up.

The wider regulatory context matters too. The EU AI Act's August 2026 high-risk system deadline lands a few months before DPDP Phase II. Teams shipping into both markets are essentially running parallel compliance sprints with significant overlap on data governance — sequence the work so the overlapping controls are built once and counted twice.

Where DPDP intersects with other Indian AI rules

DPDP does not exist in isolation. The Ministry of Electronics and Information Technology has been busy. The 2026 amendments to the Information Technology Rules introduce explicit labelling and detection obligations for AI-generated content — covered in our India DPDP and deepfake rules builder checklist. Where a platform handles personal data and generates synthetic media, both regimes apply simultaneously.

The IndiaAI Mission's sovereign-stack push also matters. Government-backed model partnerships under the IndiaAI Mission's 12 LLM partners programme bring sharper data-locality expectations. Combined with funding rounds such as Sarvam's Series C for sovereign AI and the broader ecosystem story tracked in Krutrim's path to profitability, the direction is clear: India is building its own AI stack on its own data rules, and Phase II is the gate where that stack gets enforced.

The Builder's honest bottom line

A consultancy will sell you a twelve-month engagement and a 90-page deliverable. A working AI team has six months and a sprint cadence. Use the six months. Inventory in June, consent design in July, retention in August, access in September, breach rehearsal in October, audit in November. By the time Phase II goes live on 13 November 2026, the controls should already be production, not aspiration.

The teams that treat this as engineering work — discrete tickets, owners, acceptance criteria — will be ready. The teams that treat it as a governance project to be managed in PowerPoint will discover, somewhere around October, that they should have started in June. The window is open. Start.

Primary sources: the DPDP India 2026 handbook from Levo and India Briefing's DPDP compliance timeline coverage.