Website Compliance Checklist in India: Privacy, Cookies, Forms and DPDP

Website compliance starts with understanding what personal data your website handles, why it handles it and which rules apply to that activity. A privacy page or cookie banner by itself cannot certify compliance.

This is a website implementation checklist, not legal advice. I can discuss the technical behaviour of forms, links and tracking; a qualified Indian legal professional should advise on applicability, lawful processing and legal wording.

Legal position checked on 4 October 2026

The final DPDP Rules, 2025 use phased commencement: rules 1, 2 and 17–21 start on Gazette publication; rule 4 starts after one year; rules 3, 5–16, 22 and 23 start after eighteen months. The final Rules, rule 1 set those relative periods.

The separate Act commencement notification also phases provisions; core processing, notice, consent and rights sections are in its eighteen-month group. The notifications are dated 13 November 2025. The December 2025 corrigenda correct the Rules’ wording, including the reference to publication in the Official Gazette; they do not replace the stated one-year and eighteen-month periods. On this article’s check date, those later periods have not elapsed.

Do not treat draft proposals as enacted changes or conclude that all DPDP duties are already operative. Recheck the current MeitY documents, amendments and other applicable law with legal counsel. This guide does not establish a universal cookie-banner requirement for every Indian website.

Technical recommendation: draw the actual data flow

List each form field, submission destination, mailbox, database, analytics tool, embedded map and chat link. Record which actions send data to another provider and which choices are optional. Include hosting/server logs in the review rather than examining only browser cookies.

Example from this website’s implementation: without a configured form endpoint, the contact form prepares an email draft. I receive the details only if the visitor sends it. The WhatsApp link opens a separate service; the optional map loads after a visitor choice. The consent configuration loads configured analytics/advertising tools only after opt-in. These are technical design choices, not a legal certification.

Configuration can change. Confirm the deployed site and third-party behaviour before publishing or relying on a policy. The site privacy policy describes this site, not a reusable policy for every business.

Technical recommendation: minimise enquiry fields

Ask for what is needed to reply and understand the request. Use clear labels and a nearby explanation of purpose and destination. Do not request passwords or identity documents in a general contact form. Make an email-draft fallback explicit rather than displaying a misleading “sent” message.

Test validation, delivery, confirmation and recovery from provider failure. Explain what happens if an enquiry is sent through WhatsApp or another external service.

Best practice: make optional tracking understandable

Inventory the tools you really use. Search Console ownership verification is not the same as installing visitor analytics. Google Analytics, Clarity, advertising pixels and session recording have different data behaviour and settings.

Where you choose opt-in loading, test rejection, acceptance, withdrawal and changed tool configurations. Mask sensitive fields before using session recording. Do not preselect optional tracking or describe an inactive tool as currently running.

Legal review: notices, rights and retention

Ask counsel which rules and dates apply to your processing, what notice and choice are required, and how requests should be handled. Clarify children’s data, provider arrangements, transfers and sector-specific obligations where relevant. Do not copy another business’s promises.

From an implementation perspective, assign a contact, limit access and document retention/deletion decisions. A chosen twelve-month enquiry retention period is a business policy—not a universal statutory deadline. Preserve records when another applicable obligation requires them.

Technical recommendation: security and maintenance

• Use HTTPS and protected administrative access.
• Restrict provider and staff permissions to the agreed task.
• Maintain updates, backups and a tested recovery path.
• Avoid putting personal enquiry content in analytics URLs or events.
• Document an incident contact and escalation procedure with legal input.

Questions before launch

1. Which data is collected, and is every field necessary?
2. Where does it go, and who can access it?
3. Does the deployed behaviour match the policy?
4. Can a visitor understand and change optional choices?
5. Who handles requests, retention and incidents?
6. Which legal provisions apply now and which preparations are due later?

Can a developer make my website “DPDP compliant”?

A developer can implement agreed controls and verify their behaviour. Legal compliance also depends on the organisation’s actual processing, governance and applicable law. I do not present a technical checklist as a compliance certificate.