The Digital Personal Data Protection Act, 2023 is now in implementation across Indian enterprises. After years of consultation, the Act is law. Rules are being notified. Enforcement timelines are tightening. The Data Protection Board of India is operational. Significant Data Fiduciaries have been notified. And every CTO, CISO, and Chief Data Officer at a meaningful Indian enterprise is being asked the same question by their board — what does our DPDP compliance posture actually look like?
The honest answer for most enterprises is — uneven. Some teams have read the Act and started building. Others have outsourced the question to legal and are waiting for guidance. Many have built consent flows that satisfy the letter of the Act while missing its operational intent.
This pillar is a practical guide to what DPDP Act implementation actually requires — not a legal recitation, not a vendor pitch. What the Act does. What enterprises need to build. Where AI workloads create specific complications. How sector overlays (RBI, IRDAI, SEBI) intersect with DPDP. And what a credible 12-month implementation programme actually looks like.
What the DPDP Act Actually Requires — In Plain Terms
The DPDP Act regulates how Indian organisations process the personal data of Indian residents. It applies to any organisation processing digital personal data in India — and, in some cases, organisations outside India processing the personal data of individuals in India. At the architectural level, the Act establishes five core obligations:
1. Lawful Basis for Processing — Consent as the Default
Personal data can only be processed with the Data Principal's consent or for specific legitimate uses defined in the Act. Consent must be free, specific, informed, unconditional, unambiguous, and through clear affirmative action. Pre-ticked boxes do not count. Bundled consents that force agreement to multiple things at once do not count. Notice must precede or accompany consent, in the chosen language of the Data Principal, with specific information about what is being processed and why.
2. Purpose Limitation and Data Minimisation
Personal data may only be processed for the specific purpose for which consent was obtained. If the purpose changes, fresh consent is required. Organisations must process only the data necessary for that purpose — collecting more than necessary is itself a violation.
3. Data Principal Rights
Indian residents now have enforceable rights — to access information about their personal data being processed, to correction and erasure, to grievance redressal, and to nominate someone to exercise these rights in the event of death or incapacity. Organisations must build the operational infrastructure to fulfil these requests within specified timeframes.
4. Security Safeguards and Breach Notification
Organisations are responsible for protecting personal data from breaches — and for notifying both the Data Protection Board and affected Data Principals when breaches occur. The notification timeline is short. The standard for what counts as a reportable breach is broad.
5. Accountability — Including Data Protection Officer Requirements
Significant Data Fiduciaries (organisations crossing defined thresholds, typically by volume of personal data processed or sensitivity of the data) must appoint a Data Protection Officer based in India, conduct Data Protection Impact Assessments for high-risk processing, and undergo periodic audits. Other Data Fiduciaries have lighter — but still real — accountability requirements.
The Architectural Shift the Act Demands
Most Indian enterprises today have data architectures that grew organically. Customer data is in the CRM, in the data warehouse, in the analytics platform, in the customer service platform, in the marketing automation tool, in the payment processor, and increasingly in AI training datasets and vector databases. Consent — to the extent it was captured — sat in one system, while the data flowed through many.
DPDP requires this to change. The Act treats consent and purpose as data-level attributes, not user-level ones. A customer who consented to processing their data for service delivery has not consented to it being used for AI model training. A customer who consented to marketing in 2022 may have withdrawn consent in 2024 — and that withdrawal must propagate to every system holding their data.
The architectural shift is from system-of-record-driven data architecture to consent-driven data architecture. Three implications follow:
Consent Metadata Travels with the Data
Wherever personal data flows, the consent context flows with it — what was consented to, when, for what purpose, in what language, with what expiry. Systems downstream of the consent capture must check this metadata before processing. This is rarely how Indian enterprises have built data pipelines historically.
Consent Withdrawal Must Propagate in Near-Real-Time
When a Data Principal withdraws consent, every downstream system must reflect that — including AI models that may have trained on the data, analytics that may have used it, and partners who may have received it. Building this propagation is non-trivial. Doing it after a breach or complaint is far harder than doing it as part of architecture from day one.
Data Minimisation Forces Rationalisation of Legacy Collection
Many Indian enterprises collect more data than they actually use, because forms were designed for hypothetical future use cases. DPDP makes this unlawful. Implementation involves auditing every data collection point and either justifying it (purpose, necessity, consent) or removing it.
The Consent Manager — An Indian-Specific Innovation
India's DPDP architecture introduces a uniquely Indian concept — the Consent Manager. Modelled on the Account Aggregator framework that has been running successfully in BFSI since 2021, a Consent Manager is a regulated intermediary that lets Data Principals manage their consents across multiple Data Fiduciaries through a single interface.
For enterprises, integrating with a Consent Manager is increasingly the path of least friction. It externalises the consent management challenge to a specialist. It provides users with a familiar interface for managing consents across providers. And it generates the audit trail regulators will look for.
Technically, the Consent Manager integration looks similar to the FIU side of the Account Aggregator stack — token-based consent artefacts, structured purpose codes, expiry handling, withdrawal propagation through standardised APIs. Organisations that have already integrated with the AA framework will find the engineering pattern familiar.
Where AI Workloads Create Specific Complications
DPDP applies fully to AI workloads. The Act does not have a separate carve-out for AI — and recent regulatory communications make clear that AI training on personal data, AI inference involving personal data, and AI-driven decisions affecting Data Principals are all in scope. Four specific complications arise:
AI Training on Personal Data
Using customer data to train AI models is processing under the Act. It requires specific consent — and a customer who consented to service delivery has not consented to AI training. Most enterprises now training AI on customer data need to either obtain specific fresh consent, anonymise the data to the point that it falls outside the Act's scope, or rely on legitimate use provisions where applicable.
AI Inference and the Right to Erasure
When a Data Principal exercises the right to erasure, what happens to the AI model trained on their data? The Act does not require model retraining for every erasure — but it does require that the specific personal data be removed from systems where it is held. For vector embeddings, RAG knowledge bases, and similar AI-specific data stores, erasure must propagate. For trained model weights, the question is more complex and the regulatory position is still evolving.
Automated Decision-Making
When AI makes a decision that significantly affects a Data Principal — credit approval, claim settlement, hiring shortlist, fraud flagging — the Data Principal has rights to information about the decision and its basis. AI explainability is therefore not optional. Organisations using LLMs and generative AI in regulated decision contexts must be able to explain the basis of the decision, not hide behind 'the model said so.'
Cross-Border AI Processing
Many AI workloads use foundation models hosted outside India. DPDP allows cross-border processing of personal data — but with conditions, and with the Central Government empowered to restrict transfers to specific countries. Organisations relying on cross-border AI hosting need to monitor this position, understand the data flow, and have contingency plans for if specific destinations become restricted.
Sector Overlays: When DPDP Meets RBI, IRDAI, and SEBI
Indian financial services operate under three regulatory layers — DPDP for personal data, sector-specific regulators (RBI for banking and lending, IRDAI for insurance, SEBI for capital markets), and CERT-In for cybersecurity incident reporting. The layers do not contradict but do overlap, and implementation requires reading them together:
RBI and DPDP
RBI's Master Directions on Information Technology Governance and the IT Outsourcing framework already require banks and NBFCs to manage customer data with rigour. DPDP adds explicit Data Principal rights, consent requirements, and breach notification obligations. For most banks, this means refining existing data governance rather than building from scratch — but with specific architectural updates for consent metadata, withdrawal propagation, and AI training transparency.
IRDAI and DPDP
Insurance customer data has been regulated by IRDAI for years. DPDP adds — explicit consent for AI underwriting, transparency on automated claim decisions, and the right to challenge AI-driven adverse decisions. Insurers building AI underwriting models or AI claims processing need DPDP-compliant consent at the point of policy initiation and explainability at the point of decision.
SEBI and DPDP
SEBI's Cybersecurity and Cyber Resilience Framework intersects with DPDP at the incident reporting layer — incidents involving personal data may trigger both SEBI cyber reporting and DPDP breach notification, with different timelines and different recipients. Capital market intermediaries need a unified incident response process that handles both.
What Good DPDP Implementation Looks Like
- Comprehensive Personal Data Inventory: Every system, every flow, every purpose, every retention period documented.
- Consent Architecture: Treats consent as data-level metadata, not a system-level toggle.
- Consent Manager Integration: Standardized or equivalent connection for Data Principal-facing consent management.
- Data Principal Rights Workflows: Access, correction, erasure, nomination, and grievance handling backed by measured SLAs.
- Breach Detection & Notification: Rigorous protocols tested via regular tabletop simulation exercises.
- Dedicated DPO Appointment: Qualified Data Protection Officer appointed with adequate organizational authority and budget.
- AI Governance Integration: Explicit consent for training data, explainability for algorithmic decisions, and erasure propagation to AI vector stores.
- Unified Sector Governance: DPDP plus RBI, IRDAI, or SEBI requirements managed as one cohesive programme.
What Bad DPDP Implementation Looks Like
- Treating a simple cookie/consent banner on the website as the sum total of compliance.
- Updating the privacy policy on paper without re-engineering underlying data architecture.
- Capturing consent at intake but failing to propagate changes or withdrawals to downstream databases.
- Handling Data Principal rights requests manually through email inboxes without SLA tracking or verification.
- Training generative AI models on customer data without specific consent or verified anonymization.
The 12-Month Implementation Programme
DPDP implementation is not a one-time project — it is an enterprise programme. A credible 12-month programme for an Indian enterprise typically runs in four sequential phases:
- Phase 1 (Months 1–2) — Discovery and Gap Assessment: Map every personal data flow, identify all consent capture points and downstream systems, score gaps against statutory rules, and output a board-ready remediation roadmap.
- Phase 2 (Months 3–6) — Architectural Rebuild: Implement consent architecture that propagates metadata, integrate with Consent Manager protocols, and automate Data Principal rights workflows.
- Phase 3 (Months 7–9) — AI and Sector Integration: Operationalize AI governance (training consent, decision explainability, vector erasure) and merge sector overlays into a single incident response runbook.
- Phase 4 (Months 10–12) — Operationalisation and Audit: Transition to continuous operations, conduct DPIAs, run breach response drills, and establish verified audit trails ready for regulatory inspection.
The Strategic Shift to Make
Stop treating DPDP as a legal compliance project to be completed and ticked off. Start treating it as an architectural shift to a consent-driven data posture — one that compounds value over years, reduces breach risk, and positions the organisation for the AI workloads ahead.
Indian enterprises that get DPDP implementation right gain three durable advantages: reduced regulatory risk, better data hygiene that improves analytics and AI models, and the architectural foundation to build customer-facing AI applications responsibly.
Frequently Asked Questions
When does the DPDP Act actually become enforceable?
The Act is law. Rules under the Act are being notified in phases through 2025–2026. Some provisions are already enforceable; others come into effect as corresponding Rules are notified. Significant Data Fiduciaries are actively being designated, and the practical position for enterprises is to operate as fully compliant immediately.
Does our organisation need to appoint a Data Protection Officer?
Mandatory DPO appointment applies to Significant Data Fiduciaries notified by the Central Government. For other Data Fiduciaries, a designated grievance contact is required. In practice, mid-to-large enterprises require a dedicated DPO function to manage operational statutory requirements.
How is DPDP different from GDPR?
DPDP is shorter, focuses specifically on digital personal data, features India-specific innovations like Consent Managers, and imposes penalty caps per violation rather than percentage-of-global-turnover fines.
What about AI training on customer data — do we need fresh consent?
Almost always, yes. Service delivery consent does not cover AI training. Unless personal data is irreversibly anonymized or covered by specific legitimate use provisions, explicit affirmative consent is required.
