DPDP Act 2023: Complete Guide for Indian Startups

What is the DPDP Act 2023?

The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's landmark data protection legislation, receiving Presidential assent on 11 August 2023. It replaces patchwork protections under the Information Technology Act and creates a comprehensive framework governing how digital personal data is collected, processed, and stored by every organisation operating in India or processing data of Indian residents.

The Act's territorial scope is deliberately wide. Section 3 applies it to digital personal data processed within India and to processing outside India if the purpose is offering goods or services to data principals in India. This means a fintech startup serving Indian users through an overseas cloud provider must comply just as fully as a Mumbai-headquartered company processing on domestic servers.

At its core, the DPDP Act is built on six principles: lawfulness (Section 4), consent (Section 6), purpose limitation, data minimisation, storage limitation, and accountability. For AI-powered products, these principles translate to concrete engineering obligations — every LLM call that touches personal data must be traceable, purposeful, and protective of user rights.

Who is a Data Fiduciary and why it matters

The Act introduces the concept of a 'data fiduciary' (Section 2(i)) — any person or entity that determines the purpose and means of processing personal data. If your SaaS product processes customer PII to deliver its service, you are a data fiduciary. This means you, not your cloud provider or AI model vendor, bear the primary compliance obligation.

A 'data processor' (Section 2(k)) is an entity that processes data on behalf of a fiduciary — think AWS, Azure, or OpenAI when acting under your instruction. Crucially, the Act's obligations fall primarily on fiduciaries. You cannot outsource accountability. Even if your LLM provider claims SOC 2 certification, you remain responsible for ensuring personal data sent to them is lawful, consented, and minimised.

The Ministry of Electronics and IT (MeitY) will designate certain data fiduciaries as 'Significant Data Fiduciaries' (SDFs) under Section 10 based on volume of data processed, sensitivity of data, national security implications, and other criteria. SDFs face additional obligations including Data Protection Impact Assessments and appointment of a Data Protection Officer.

Consent: the cornerstone obligation (Section 6)

Section 6 requires that personal data be processed only on the basis of free, specific, informed, unconditional, and unambiguous consent. Consent must be given through a clear affirmative action — pre-ticked checkboxes, silence, or bundled terms-of-service clauses do not meet the standard. The consent notice must describe the personal data sought, the purpose of processing, and how the data principal can withdraw consent.

For AI-powered products, consent must be granular. If your product uses customer data for a support chatbot and also for model training, these are separate purposes requiring separate consent. The consent you collected for 'improving service quality' in 2022 does not cover sending user messages to a large language model in 2024. Granular AI processing notices are not optional — they are a Section 6 requirement.

Withdrawal of consent is a right, not a favour. Section 6(4) requires fiduciaries to provide a mechanism for withdrawal as easy as the mechanism for giving consent. Practically, this means if users gave consent through a toggle in your app settings, withdrawal must be achievable through the same interface. You cannot require a support ticket to withdraw AI processing consent.

Deemed consent and legitimate uses (Section 7)

Section 7 provides for 'deemed consent' — circumstances where processing is lawful without explicit consent. Schedule I lists these: performance of a contract, compliance with legal obligations, protection of vital interests, public health emergencies, employment-related processing, and state functions. However, AI-powered processing rarely qualifies for deemed consent because it goes beyond the contractual minimum.

A common mistake is claiming deemed consent for AI analytics. Using customer transaction data to train a fraud detection model may be legitimate, but using the same data to generate marketing insights is not. The purpose must be specific and the processing must be necessary for that purpose. Indian courts and regulators will apply a proportionality test — AI use cases need to demonstrate they cannot achieve their purpose with less data or less invasive processing.

Importantly, deemed consent does not relax data minimisation or storage limitation obligations. Even when processing is lawful under Section 7, you must still collect only the minimum data necessary and delete it once the purpose is fulfilled. This matters enormously for AI training pipelines that accumulate data indefinitely.

Obligations of Data Fiduciaries (Section 8)

Section 8 imposes eight affirmative obligations on data fiduciaries that go beyond consent. Data minimisation (Section 8(7)) requires that only the personal data necessary for the specified purpose is collected. For AI products, this means stripping unnecessary context from prompts before sending to model providers. An LLM used for customer support does not need the customer's Aadhaar number, salary, or health data unless those are directly relevant to the support query.

Accuracy (Section 8(8)) requires that personal data used for significant decisions is accurate. This matters for AI models making credit decisions, insurance assessments, or medical recommendations — you must have processes to keep training data current and to handle corrections from data principals. Storage limitation (Section 8(9)) requires deletion when the processing purpose is fulfilled. AI audit logs are not exempt — you need a retention policy for every data store including vector databases, embedding stores, and prompt logs.

The accountability obligation (Section 8(10)) requires fiduciaries to take reasonable security safeguards and be able to demonstrate compliance. This is where tamper-evident audit trails become critical. If the Data Protection Board investigates a complaint, you need to be able to show exactly what personal data was processed, when, for what purpose, under which consent record, and what protective controls were applied.

Rights of data principals (Sections 12–16)

The Act grants data principals (individuals whose data is processed) a suite of rights that create corresponding technical obligations for your product. Section 12 gives the right to information — individuals can request a summary of their personal data being processed and the purposes. Your AI system must be able to generate this summary including data held in AI-specific stores like embedding databases and fine-tuning datasets.

Section 13 grants the right to correction and erasure. If a customer requests deletion of their personal data, you must erase it from all systems including AI systems. This is technically challenging when personal data has been used for model fine-tuning — the Act's practical implementation will require fiduciaries to maintain clear separation between training data and inference data, with documented deletion procedures for each.

Section 14 provides the right to grievance redressal. Fiduciaries must establish a mechanism for individuals to register complaints, and must resolve them within a specified period. Section 15 allows individuals to nominate another person to exercise their rights in case of death or incapacity. These rights create the skeletal structure for your privacy policy and user-facing controls.

Penalties and enforcement (Sections 25–32)

The DPDP Act's penalty structure is designed to be consequential. Section 25 prescribes penalties up to ₹250 crore for data breaches where the fiduciary has failed to implement reasonable security safeguards. Section 26 sets penalties up to ₹200 crore for failures to notify the Data Protection Board and affected individuals of breaches. Specific violations — such as processing children's data without verifiable parental consent — carry penalties up to ₹200 crore.

The Data Protection Board of India (Section 17) is the adjudicating authority. The Board can initiate proceedings on complaints from data principals, on references from the Central Government, or suo motu. The Board has powers to conduct inquiries, issue directions, and impose penalties. Appeals against Board orders lie to the Telecom Disputes Settlement and Appellate Tribunal.

Penalties are not capped per incident — they are per violation. A company that forwards Aadhaar numbers to an LLM provider without proper consent could face one penalty under Section 26 for the breach, another for failure to notify, and additional penalties if it processes children's data without parental consent. The cumulative exposure can run into hundreds of crores for companies with large user bases.

AI compliance: the practical implementation path

For Indian SaaS companies using LLMs, compliance requires four engineering capabilities: detection (knowing when personal data is present in AI inputs/outputs), redaction (removing or masking personal data before it crosses system boundaries), consent management (linking every AI processing event to a valid consent record), and audit trails (maintaining tamper-evident logs of all AI interactions with personal data).

The fastest path to baseline compliance is a gateway-based approach. By routing all LLM traffic through a governance gateway, you get universal enforcement of detection and redaction regardless of which team, SDK, or provider initiated the call. One environment variable change — OPENAI_BASE_URL to your gateway — applies DPDP controls to your entire AI surface. This is categorically easier than adding library-level controls to every AI feature in your codebase.

Compliance is not a one-time project — it is an ongoing operational capability. The Act will evolve through Rules published by MeitY (expected in 2025-26). Data Protection Rules will specify retention periods, breach notification timelines, cross-border transfer conditions, and the list of designated trustworthy jurisdictions for international data flows. Build your compliance stack to be configurable, not hard-coded, so you can adapt as Rules are published.

DPDP Act pillar implementation addendum

A pillar page should also connect the legal idea to a concrete implementation path. Start with ownership: name the product owner, engineering owner, security reviewer, and compliance reviewer for this topic. Then map the systems that can create, store, transform, or transmit the relevant personal data. The map should include frontend forms, backend APIs, queues, warehouses, LLM prompts, embedding stores, admin exports, vendor dashboards, and customer-success tooling.

Next, document the lawful purpose and the user-facing notice. The notice should be clear enough that a data principal understands what is processed, why AI may be involved, what categories of personal data are affected, and how consent or withdrawal works. If the workflow supports children, healthcare, financial services, employment, or government delivery, treat that context as higher risk and add stricter review before allowing personal data into model calls.

The engineering control should run before data leaves the application boundary. Scan the full prompt package, not just the user's message. That means system instructions, retrieved snippets, tool outputs, attachments, OCR text, chat history, and structured JSON all need inspection. When a high-confidence identifier is found, redact, tokenise, block, or route to a safer model depending on the policy. Keep the original sensitive value out of general logs unless a protected exception is approved.

Audit evidence should be designed for reconstruction. A reviewer should be able to answer: when did the request happen, which application sent it, which data type was detected, which rule fired, what action was taken, which provider received the final payload, and who approved any exception. Without that trail, teams are left with policy claims rather than proof. With it, they can respond faster to buyer diligence, internal audits, breach triage, and regulator questions.

Finally, make the process repeatable. Add sample payloads to tests, run scheduled scans against logs and representative documents, check sitemap and page health for public guidance, and keep the DPDP scanner linked from the page so readers can move from learning to action. The goal is not to freeze the system; it is to make every future AI workflow easier to review, safer to launch, and easier to explain.