DPDP Act Implementation: A Practical Guide for Indian Enterprises

The DPDP Act is now in force. Here is what Indian enterprises actually need to do — Consent Manager architecture, Data Principal rights, DPO setup, and AI governance.

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. ● Consent architecture that treats consent as data-level metadata, not a system-level toggle. ● Consent Manager integration, or equivalent, for Data Principal-facing consent management. ● Data Principal rights workflows, access, correction, erasure, nomination, grievance, with measured SLAs. ● Breach detection and notification process tested via regular tabletop exercises. ● DPO appointed, where Significant Data Fiduciary thresholds apply, with adequate authority and budget. ● AI governance integration, consent for training data, explainability for decisions, erasure propagation to AI stores. ● Sector overlay handling, DPDP plus RBI, IRDAI, or SEBI requirements managed as one programme, not three. ● Annual Data Protection Impact Assessments for high-risk processing. ● Audit trails sufficient to demonstrate compliance to the Data Protection Board on demand. What bad DPDP implementation looks like ● Consent banner added to the website, treated as the sum of compliance. ● Privacy policy updated, treated as the sum of compliance. ● Consent captured but not propagated to downstream systems. ● Data Principal rights requests handled manually, with no SLA tracking. ● AI training proceeding on customer data with no specific consent and no anonymisation. ● Breach notification process documented but never tested. ● DPO appointed in name only, without authority or budget to enforce. ● Sector overlays handled by separate teams in silos, producing contradictory obligations. ● Audit trails fragmented across systems, making regulatory demonstrations impossible. ● Compliance treated as a one-time project rather than an ongoing programme. The 12-month implementation programme DPDP implementation is not a project. It is a programme. A credible 12-month programme for a mid-to-large Indian enterprise typically runs in four phases. Phase 1 (Months 1-2): Discovery and gap assessment Map every personal data flow. Identify every consent capture point. Identify every downstream system. Score the current state against the Act's obligations. Produce a remediation roadmap with effort estimates and dependencies. Output: a board-ready gap report and a programme charter. Phase 2 (Months 3-6): Architectural rebuild Implement consent architecture that propagates metadata across systems. Build, or integrate with, Consent Manager infrastructure. Implement Data Principal rights workflows with SLA tracking. Update privacy notices and consent flows across all customer touchpoints. Output: working consent and rights infrastructure, tested end-to-end. Phase 3 (Months 7-9): AI and sector integration Integrate DPDP requirements with AI workloads, training data consent, explainability for decisions, erasure propagation. For regulated sectors, integrate DPDP with RBI, IRDAI, or SEBI requirements as one unified programme. Establish breach detection and notification process. Output: AI governance plus sector overlay handling operationalised. Phase 4 (Months 10-12): Operationalisation and audit Establish ongoing operations, DPO function, audit logging, periodic DPIAs, Data Principal request handling at scale. Run breach response tabletop exercises. Prepare evidence base for regulatory inspection. Move from project mode to programme mode. Output: a steady-state DPDP function ready for regulatory scrutiny. The 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, and the executive bandwidth that comes from not being in firefighting mode. Better data hygiene, which compounds into better analytics, better AI models, and better customer experience. And the architectural foundation to build AI on personal data responsibly, which will only become more important as the regulatory environment tightens. Indian enterprises that get it wrong face the opposite, regulatory penalties, breach exposure, customer trust erosion, and a data architecture that becomes a liability for every AI initiative they try to build on top of it. The difference between the two outcomes is in the architecture, the discipline, and the depth of the implementation programme. 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 the corresponding Rules are notified. Significant Data Fiduciaries have been or are being identified. The practical position for most enterprises in 2026 is: operate as if fully enforceable, because partial enforceability has already started, and the cost of catching up later is higher than starting now. Does our organisation need to appoint a Data Protection Officer? Mandatory DPO appointment applies to Significant Data Fiduciaries, organisations notified by the Central Government based on thresholds including the volume and sensitivity of personal data processed. For other Data Fiduciaries, DPO appointment is not mandatory but a designated contact for grievance redressal is required. In practice, most mid-to-large Indian enterprises benefit from a DPO-equivalent function regardless of whether they are formally notified as Significant Data Fiduciaries. The operational requirements of the Act are difficult to discharge without dedicated ownership. How is DPDP different from GDPR? Conceptually similar but operationally different. DPDP is shorter and less prescriptive than GDPR. It has uniquely Indian features, the Consent Manager framework, the focus on Indian residents specifically, the integration with India's DPI stack. Cross-border transfer rules are more permissive than GDPR's, with the Central Government retaining the power to restrict specific destinations. Penalties are structured differently. DPDP uses defined upper limits per violation rather than GDPR's percentage-of-global-turnover model. Organisations already GDPR-compliant have most of the foundation but need specific updates for DPDP's Indian particulars. What about AI training on customer data, do we need fresh consent? Almost always, yes. Consent for service delivery is not consent for AI training. The DPDP Act treats AI training as a distinct purpose requiring specific consent, unless the data has been anonymised to the point that it falls outside the Act's scope, or unless a legitimate use provision applies. Organisations currently training AI models on customer data without specific consent are operating in regulatory grey territory and should address this before regulatory enforcement crystallises. What are the penalties for non-compliance? The Act establishes penalty bands per type of violation, with upper limits running to crores of rupees for serious breaches, particularly failure to take reasonable security safeguards leading to personal data breaches. The Data Protection Board adjudicates. Penalties are real and the Board has the authority to impose them. Equally important is the reputational and customer-trust cost of public enforcement. For consumer-facing enterprises, this often exceeds the financial penalty itself. How long does a credible DPDP implementation programme actually take? For a mid-to-large Indian enterprise, 9 to 12 months for the foundational programme, discovery, architecture, integration, operationalisation. Smaller organisations may complete in 6 months. Larger and more complex organisations, multi-entity groups, heavy AI use, multiple regulated sectors, may take 12 to 18 months. Beyond the initial programme, DPDP becomes an ongoing function, annual DPIAs, continuous Data Principal rights handling, evolving with each Rule notification. Can we just appoint a vendor and let them handle compliance? Partially yes, mostly no. Specific functions can be outsourced, Consent Manager integration, audit trail tooling, technical implementation. But the accountability sits with the Data Fiduciary, not the vendor. The DPO must be a real role with real authority inside the organisation. Strategic decisions, what data to process, for what purposes, with what retention, must be made by the business, not delegated. The right model is internal accountability with specialist external implementation support, which is the engagement pattern Mobiloitte runs for DPDP programmes.