Privacy Policy and DPDP Compliance for Indian Websites

Most Indian business websites still carry a privacy policy that was written once, years ago, and never touched again. It was probably adapted from a template, possibly one built for GDPR, possibly copied from a competitor's site, and it has sat there quietly ever since, doing its one job of existing so the footer link is not broken.

The Digital Personal Data Protection Act, 2023, changes what that page is supposed to do. It is not simply a legal formality anymore. It is a description of an actual system, consent, notice, and data handling, that regulators, customers, and eventually courts can hold a business to. A page that does not describe that system accurately is now a liability sitting in public view, not a compliance box quietly ticked.

This is not a legal filing checklist. It is what a founder-led business should understand and have in place before treating the privacy policy as done.

What the DPDP Act actually expects

The Act organises around a few core ideas, and it is worth understanding them in plain terms before worrying about specific wording.

A business that decides why and how personal data is processed is a Data Fiduciary. If your website collects a name, email, phone number, or any other personal data from visitors or customers, your business sits in this role for that data. The law places obligations on the Data Fiduciary, not on some abstract entity called "the website."

Consent has to be informed and specific. A visitor filling out a contact form, signing up for a newsletter, or creating an account needs to know, in reasonably clear language, what is being collected and why, before or at the point they hand it over. Consent obtained through a vague, all-purpose checkbox buried at the bottom of a long form sits on much shakier ground than consent obtained through a clear, specific statement next to the field it relates to.

Notice has to be in plain language. The Act's intent is that a person providing their data can actually understand what they are agreeing to, not that a business can point to a dense legal document and claim disclosure happened. A notice that is technically complete but practically unreadable does not fully serve the purpose the law is built around.

Purpose limitation matters. Data collected for one stated reason, say, to respond to an enquiry, should not quietly be repurposed for something else, such as ongoing marketing outreach, without that additional use being disclosed and consented to separately.

Retention should have a logic to it. The Act's direction of travel is that data should not be held indefinitely once the purpose it was collected for has been served. Exactly how long is appropriate varies by data type and business context, and this is a question worth working through deliberately rather than defaulting to "we keep everything forever, just in case."

None of this is exhaustive, and the specific compliance mechanics, thresholds, notification timelines, and obligations that scale with the volume or sensitivity of data processed are genuinely technical and still being clarified through rules and guidance. Where the details get specific, that is exactly the point at which this becomes a legal question rather than a marketing or website one, and it deserves a proper legal answer rather than a confident guess.

Why a copy-pasted policy is a real risk now

A generic privacy policy template usually has three problems, and any one of them is enough to matter.

It was written for a different law. Many templates in wide circulation were built around GDPR, a European framework with its own definitions, its own lawful bases for processing, and its own enforcement mechanics. Pasting that language onto an Indian business does not make the business DPDP-compliant. It makes the business look compliant to anyone who does not read closely, which is a worse position than having no policy at all, because it creates a false sense that the work is done.

It does not describe what the business actually does. A template is written to be generic enough to apply to any business, which means it is specific to none. If the actual policy on the site claims data is used only to fulfil orders, but the same site quietly adds every form submission to a marketing email list, or shares data with a third-party ad platform via a tracking pixel, the policy and the practice have already diverged. That gap is the first thing exposed by a customer complaint, a data breach, or a regulatory enquiry, and it is far easier to notice from the outside than most founders assume.

It was probably never revisited when the business changed. A policy written when the business had one product and one signup form rarely gets updated when a second product line, a new CRM integration, a WhatsApp bot, or a payment gateway gets added. Each of those additions changes what data is collected and where it goes. The policy, unless deliberately maintained, does not.

What a founder-led business should actually have in place

Three things, realistically, before anything else.

An honest inventory of what is actually collected, and why. This is less a legal exercise than an operational one. Walk through every form, signup flow, checkout process, and third-party integration on the site, CRM, email tool, analytics, ad pixels, payment gateway, chat widgets, and list what personal data each one touches and where it goes afterward. Most founders are surprised by how many places data quietly flows through once this is actually mapped out. This inventory is the single most useful thing to have before touching the policy itself, because it is the only way to know if the policy is telling the truth.

A policy that reflects that inventory, not a borrowed one. Once the inventory exists, the policy can describe reality: what is collected, the specific purpose for each category, how long it is kept, and who it might be shared with. This does not need to be long. It needs to be accurate, and it needs to be written so an ordinary visitor can actually understand it, not so it merely survives a skim by someone checking a box.

Visible, specific consent mechanisms at the point of collection. A single checkbox at the bottom of the site linking to the privacy policy is weaker than clear, contextual consent at each point data is actually gathered: a plain sentence near a newsletter signup describing what it is for, a distinct opt-in for marketing communications separate from transactional ones, a clear statement on a checkout form about what happens to payment and contact details. This is as much a design and structure decision as a legal one, and it is one every founder-led business can act on directly, well before any legal review happens.

Where this stops being marketing advice

Everything above is about getting the structural and website-facing side right: knowing what data actually moves through the business, describing it honestly, and building consent into the places it should live. That is squarely marketing and website architecture territory, and it is worth doing properly regardless of what the law ultimately requires, because it is also, simply, good practice with customer trust.

It is not legal advice, and it should not be treated as a substitute for it. The DPDP Act carries specific obligations, and specific consequences for getting them wrong, that go beyond what a website structure review can responsibly assess. Anything consequential, how the Act applies to your specific data flows, what your formal notice language should say, what obligations kick in at what scale, needs sign-off from a lawyer familiar with the DPDP Act. Treat this piece as the groundwork that makes that legal conversation faster and more useful, not as a replacement for it.

---

A privacy policy that does not match what your website actually does is an Architect pillar problem: structure that has not kept pace with the business. The Hexagram Diagnostic surfaces gaps like this alongside the rest of your marketing architecture. It takes 8 minutes and is free. Run it at adg-advisory.com.