India's DPDP Act: What Your Website Actually Has to Do

India's Digital Personal Data Protection Act is the country's first comprehensive data protection law, and it applies far more broadly than most business owners assume. If your website has a contact form, a newsletter signup, a login, or analytics that identifies visitors, you are processing personal data and the Act is relevant to you. The size of your business does not exempt you.

This is a practical guide to the parts that touch your website. It is not legal advice — for your specific obligations, particularly around consent notices and any sensitive data, you need a lawyer. What we can usefully explain is the engineering: what has to change in the code, and in what order.

Who the Act applies to

The Act governs the processing of digital personal data within India, and also processing outside India where goods or services are offered to people in India. Personal data means any data about an identifiable individual — which is broader than most people expect. A name and email in a contact form obviously counts. So does an IP address combined with behavioural data, which is what most analytics collects by default.

In the Act's vocabulary you are almost certainly a Data Fiduciary: the entity deciding why and how personal data is processed. Your hosting provider, your email platform and your analytics vendor are Data Processors acting on your instructions. The obligations sit primarily with you, not with them — which is the point most often misunderstood.

The five obligations that touch your website

1. Notice before collection

Before collecting personal data you must tell the person what you are collecting, why, and how they can withdraw consent or complain. Critically, this must be at the point of collection — a privacy policy linked in the footer does not by itself satisfy a notice requirement for a form the user is filling in now.

In practice this means a short, readable line next to your submit button explaining what happens to the data, linking to the full policy. Not a wall of text; a sentence a person would actually read.

2. Genuine consent

Consent must be free, specific, informed, unambiguous, and given by clear affirmative action. That rules out several patterns common on Indian websites: pre-ticked boxes, consent bundled with terms acceptance so that agreeing to one means agreeing to both, and "by using this site you consent" banners with only an OK button.

It must also be as easy to withdraw as it was to give. If someone subscribed with one click, unsubscribing should not require an email to support.

3. Purpose limitation and data minimisation

Collect only what you need for the stated purpose, and use it only for that purpose. This is the obligation most routinely broken by ordinary contact forms — asking for a phone number, a company name and a budget range when you only need an email to reply. Every extra field is data you must now protect, justify and be able to delete.

4. Rights: access, correction and erasure

A person can ask what data you hold, ask you to correct it, and ask you to erase it. That last one has real engineering consequences. Can you actually delete someone completely — from the database, the CRM, the email platform, the backups and the spreadsheet on someone's laptop? Most businesses discover the answer is no, and that discovery is better made now than in response to a request.

5. Breach notification

Personal data breaches must be reported to the Data Protection Board and to affected individuals. This requires knowing that a breach happened, which requires logging and monitoring — the practical reason a compliance requirement turns into an infrastructure requirement.

Where Indian business websites typically fail

The second row is worth dwelling on. Most Indian business sites load Google Tag Manager, analytics and advertising pixels the moment the page opens, before any consent is expressed. Those scripts set identifiers and begin collecting behavioural data immediately. Fixing this means holding non-essential scripts until consent is given, which is a real technical change rather than a policy paragraph — and it is the single most common gap we find in audits.

What a compliant contact form looks like

Most business sites need surprisingly little. Concretely:

• Only the fields you genuinely need. Name and email is usually enough; phone if you will actually call.
• A short notice next to submit: what you collect, why, how long you keep it, and a link to the full policy.
• An unticked checkbox if you intend to send marketing later — separate from the enquiry itself.
• A retention rule: enquiries deleted after a defined period rather than kept indefinitely.
• A working route for someone to ask for their data or its deletion, with a named person responsible.

None of this harms conversion. In our experience shorter forms with a clear explanation convert better than longer ones, so this is one of the rare cases where the compliant version is also the commercially better version.

Consent management without wrecking your analytics

The common objection is that consent banners destroy analytics data. Partly true, and manageable. Two things help: distinguishing genuinely essential cookies — session, security, load balancing — which do not require consent, from analytics and advertising, which do; and configuring analytics in a privacy-preserving mode where possible, so you retain aggregate insight without individual tracking.

Avoid the dark patterns. A banner where "Accept All" is a bright button and "Reject" is grey text three clicks deep does not produce valid consent, and European regulators have been fining exactly this pattern for years. Indian enforcement is newer, but designing for the standard now is cheaper than rebuilding later.

If your consent banner is designed so that refusing is inconvenient, you have not collected consent. You have collected a click.

A practical order to fix things

Sequenced by effort against risk reduction, which is not the same as the order the Act lists them.

1. Audit what you collect and where it ends up. You cannot protect data whose location you do not know. Include spreadsheets and inboxes.
2. Delete unnecessary form fields. Free, immediate, and reduces everything downstream.
3. Add notice at the point of collection. An hour of work.
4. Set retention rules and actually enforce them. Old enquiry data is liability without value.
5. Implement consent gating for analytics and advertising scripts. The largest technical item.
6. Build a deletion process and name the person responsible for requests.
7. Update the privacy policy last — it should describe what you do, so do it first.

That final point is the one businesses most often get backwards. A privacy policy written before the practices exist describes an aspiration. Regulators and courts look at what actually happens.

If you serve customers outside India

Many of our clients export or sell internationally, which means more than one regime applies at once. Serving EU or UK customers brings GDPR obligations regardless of where your business sits. Californian customers bring CCPA/CPRA.

The practical approach is to build to the strictest regime you are subject to rather than maintaining separate behaviour per visitor. GDPR is generally the strictest, and a site built to it will satisfy DPDP requirements comfortably. Building three parallel systems is more expensive and considerably more likely to break.

Third parties are where the data actually goes

Businesses tend to think about their own database and overlook the dozen external services their website hands data to. Every one of them is a processor acting on your instructions, and the obligation stays with you.

The last two rows catch people out most. An embedded video or map contacts a third party the moment your page loads, before the visitor has done anything. And a deletion request is not satisfied if the person still exists in a backup you keep for two years with no expiry policy.

The useful exercise is a data map: list every service your site sends data to, what it receives, where it stores it, and how long for. Most businesses find at least one tracking script nobody remembers adding, usually for a campaign that ended years ago. Removing those is free, immediately reduces your exposure, and makes the site faster.

Who is responsible inside your business

The Act expects a contactable route for people to exercise their rights, and larger or higher-risk organisations may need a designated Data Protection Officer. Even where that formal requirement does not apply, a named internal owner is what turns policy into practice.

That person does not have to be technical. They need to know where data lives, be able to reach whoever can delete it, and respond within a reasonable time. What does not work is leaving it unassigned — requests then arrive at a general inbox, sit there, and become a complaint rather than a routine task.