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. It has sat there quietly ever since, doing its one job: 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 no longer simply a legal formality. 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. It is worth understanding them in plain terms before worrying about specific wording:

• The Data Fiduciary: A business that decides why and how personal data is processed. If your website collects a name, email, phone number, or any other personal data from visitors, your business sits in this role. The law places obligations on the fiduciary, not on an abstract entity called "the website."
• Informed and Specific Consent: A visitor needs to know, in reasonably clear language, what is being collected and why, before or at the point they hand it over. A vague, all-purpose checkbox buried at the bottom of a long form sits on much shakier ground than a clear statement next to the field it relates to.
• Plain Language Notice: The intent is that a person providing data can actually understand what they are agreeing to. A notice that is technically complete but practically unreadable does not serve the purpose the law is built around.
• Purpose Limitation: Data collected for one reason (e.g., responding to an enquiry) should not quietly be repurposed for something else (e.g., ongoing marketing outreach) without additional disclosure and separate consent.
• Logical Retention: Data should not be held indefinitely once the purpose it was collected for has been served. Defaulting to "we keep everything forever, just in case" is a risk worth working through deliberately.

None of this is exhaustive. Where the details get specific, thresholds, notification timelines, and obligations that scale with data sensitivity, this becomes a legal question rather than a marketing one.

Why a copy-pasted policy is a real risk now

A generic privacy policy template usually suffers from three critical failures:

1. It was written for a different law. Many templates were built around GDPR. Pasting that language onto an Indian business does not make it DPDP-compliant; it just makes the business look compliant to anyone who does not read closely. That is a worse position than having no policy at all, because it creates a false sense of security.
2. It does not describe what the business actually does. A template is specific to none. If your policy claims data is used only to fulfil orders, but your site quietly adds every form submission to a marketing list or shares data with an ad platform via a tracking pixel, the policy and the practice have diverged.
3. It was never updated as the business evolved. A policy written for one product and one signup form rarely gets updated when a new CRM, a WhatsApp bot, or a payment gateway is added. Each addition changes what data is collected and where it goes.

What a founder-led business should actually have in place

Realistically, three things are required before anything else:

• An honest inventory of what is actually collected, and why. Walk through every form, signup flow, checkout process, and third-party integration (CRM, email tool, analytics, ad pixels). List what personal data each one touches. This inventory is the only way to know if your 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, how long it is kept, and who it is shared with. It does not need to be long; it needs to be accurate and understandable.
• Visible, specific consent mechanisms at the point of collection. A single checkbox at the bottom of the site is weak. Instead, use clear, contextual consent: a plain sentence near a newsletter signup or a distinct opt-in for marketing communications separate from transactional ones.

Where this stops being marketing advice

Everything above is about getting the structural and website-facing side right: knowing what data actually moves, describing it honestly, and building consent into the architecture. This is squarely marketing and website architecture territory.

It is not legal advice. The DPDP Act carries specific obligations and consequences that go beyond what a website structure review can responsibly assess.

Anything consequential 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 has quietly drifted from what the business actually does is the same pattern covered in why you keep solving the wrong problem: a structural gap that stays invisible until something exposes 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.