DPDP Act Website Compliance for Indian Businesses

DPDP Act Website Compliance in India: A Practical Guide for Businesses

DPDP Act website compliance in India means reviewing how your website collects, uses, stores, shares and deletes personal data, then putting clear notices, consent controls, security measures and user-request processes in place. It applies to more than large technology companies: schools, clinics, NGOs, D2C brands, agencies and small businesses can all have website-related responsibilities when they process personal data.

The Digital Personal Data Protection Act, 2023, commonly called the DPDP Act, is India’s main personal data protection law. Its operational requirements depend on commencement notifications and rules issued by the government. Businesses should therefore track the latest official notifications rather than relying only on summaries published during the passage of the Act.

This article explains what an Indian business should review on its website and connected systems. It is practical guidance, not a substitute for advice from a qualified privacy lawyer.

What the DPDP Act Means for a Website

A website processes personal data whenever it handles information that can identify, or be reasonably linked to, an individual.

Examples include:

• Name, email address and mobile number in a contact form
• Delivery address and phone number for an online order
• Student and parent details collected by a school
• Patient enquiries and appointment details for a clinic
• Donor information collected by an NGO
• Job applicant information submitted through a careers page
• IP address, device information or identifiers collected through certain tools
• Login credentials and account activity
• Enquiry history recorded in a CRM or WhatsApp-connected system
• Information collected through cookies, analytics, advertising pixels or chat widgets

The organisation deciding why and how this data is processed is generally the Data Fiduciary. A service provider processing data on that organisation’s instructions is generally a Data Processor.

For example, a clinic may be the Data Fiduciary for appointment information, while its website hosting company, cloud CRM, email platform or form tool may act as a Data Processor for particular activities. The business remains responsible for understanding its data flows and selecting suitable vendors.

The Act can apply to processing in India and, in some circumstances, processing outside India connected with offering goods or services to people in India. An Indian D2C store using an overseas email platform should not assume that the location of the server removes its responsibilities.

Website compliance is not only a privacy policy

Uploading a privacy policy does not, by itself, make a website compliant. A proper review normally covers:

• What data each page and form collects
• Why each data item is needed
• Whether consent is required or another permitted basis applies
• What the user is told before submitting data
• Whether consent can be withdrawn
• Who receives the information
• How long the information is retained
• How users can exercise their rights
• How the business handles complaints and breaches
• Whether vendors and integrations are properly controlled
• Whether the website uses unnecessary tracking or dark-pattern interfaces

A website is often only the visible part of the processing. The form may send data to a CRM, email inbox, spreadsheet, WhatsApp workflow, payment gateway and marketing platform. All of these connections matter.

First Step: Create a Website Data Inventory

Before changing banners or drafting a policy, create a simple inventory of personal data collected through the website.

Review every page and feature, including:

• Contact forms
• Enquiry and quotation forms
• Newsletter subscriptions
• Account registration
• Login and password reset
• Checkout and payment pages
• Appointment booking
• Donation forms
• School admission or application forms
• Recruitment forms
• Downloadable resources
• Live chat and chatbot tools
• Social media plugins
• Analytics and advertising tools
• Reviews, comments and testimonials
• Embedded videos, maps and external content

For each item, record the following:

This exercise often identifies unnecessary fields. A basic enquiry form may ask for full address, company size, date of birth and other information that the sales team does not need. Removing unnecessary fields reduces risk and makes the form easier to complete.

Do not collect “just in case” data. A school may need parent contact details for an admission enquiry, but it should consider carefully whether the first website enquiry requires a child’s full medical history. A clinic may need health information for an appointment, but should avoid collecting detailed clinical records in a general contact form unless the process is designed for that purpose.

Notice and Consent Requirements

The DPDP Act requires a Data Fiduciary to provide notice in a clear and understandable way when requesting personal data. The notice should explain what information is being collected and the purpose for which it will be processed.

A website notice should be connected to the actual form or activity. A privacy policy hidden in the footer is unlikely to be a useful explanation on its own if a form collects additional information for a specific purpose.

What a website notice should explain

Depending on the activity, the notice should cover:

• The categories of personal data being collected
• The purpose of collection and processing
• How the information will be used
• How the user can withdraw consent, where consent is the basis
• How the user can exercise applicable rights
• How the user can raise a grievance
• Relevant contact details for the organisation
• Information about sharing with processors or other recipients where appropriate
• Links to the full privacy policy or detailed notice

The wording should be understandable to the intended user. A school serving parents, a local NGO serving beneficiaries and a B2B agency serving business contacts may need different explanations.

Consent should be specific and informed

Where consent is required, it should be free, specific, informed and unambiguous, with a clear affirmative action. Pre-ticked boxes and vague statements such as “By using this website, you agree to everything” create avoidable problems.

A useful form might separate different purposes:

• “I agree to be contacted about the enquiry submitted through this form.”
• “I would like to receive product updates and marketing emails.”
• “I agree to the processing described in the privacy notice.”

Marketing consent should not automatically be bundled into a request for a quotation or a necessary service. If a visitor wants to download a brochure, the business should not force them to subscribe to promotional messages unless there is a clear and lawful reason for doing so.

Consent records should show what the person agreed to, when they agreed, the version of the notice presented and the channel used. A small business may manage this through its form or CRM system, but it should be able to retrieve the information if a question arises.

Withdrawal should be practical

The DPDP Act provides for withdrawal of consent. A business should make withdrawal reasonably easy and should explain what happens after withdrawal.

Suitable methods may include:

• An unsubscribe link in marketing emails
• A preference centre
• A clear email address for privacy requests
• A form for withdrawal or deletion requests
• A support process for account holders

The method should not be substantially more difficult than giving consent. A one-click subscription with a complicated request process is poor practice.

Withdrawal may not erase every legal or operational obligation immediately. For example, a business may need to retain transaction records for accounting, tax or dispute purposes. The response should distinguish between data used for marketing and data that must be retained for another valid purpose.

Cookies, Analytics and Advertising Trackers

Cookies require a practical review because not all cookies serve the same function.

Some cookies may be needed for core website functions, such as maintaining a login session, protecting a form or remembering a checkout basket. Others support analytics, personalisation, advertising, remarketing or cross-site measurement. The data protection treatment depends on what the tool collects, how it identifies visitors and why the data is used.

The DPDP Act does not simply translate into a rule that every website must copy a particular European cookie banner. However, if a website collects personal data through analytics, advertising pixels or similar tools, the organisation should assess the processing and provide appropriate notice and consent where required.

A good cookie and tracking review should identify:

• Every analytics and advertising script installed
• The provider receiving information
• Whether the tool sets cookies or uses other identifiers
• Whether the data is linked to an account, email address or device
• Whether the tool creates user profiles
• Whether marketing consent is required
• Whether data is transferred outside India
• Whether the tool can be disabled when consent is not available

Avoid loading optional advertising and remarketing scripts before the visitor has made the relevant choice, where consent is required. Also avoid a design in which “accept all” is prominent but refusing optional tracking is hidden or confusing.

The privacy or cookie notice should not claim that tracking is anonymous if the business or vendor can connect the data to an identifiable person. Analytics settings should be configured deliberately, not accepted by default without review.

User Rights and Website Processes

The DPDP Act gives Data Principals, meaning the individuals to whom personal data relates, rights that businesses must be prepared to support. These include rights concerning access to information about personal data and processing, correction and erasure in applicable circumstances, grievance redressal and nomination.

A website does not necessarily need a public “privacy portal” on day one, but the organisation needs an internal process for receiving, verifying, recording and responding to requests.

Access and information requests

A person may ask what personal data the organisation is processing and related information. The business should be able to search the places where website data is stored, including:

• Website databases
• CRM records
• Email inboxes
• Support tools
• Marketing platforms
• Booking systems
• Payment or order systems
• Spreadsheets and shared drives

If staff copy website leads into personal phones or informal messaging groups, finding and managing the information becomes harder. The solution is not necessarily to ban every practical tool, but to set rules for access, storage, export and deletion.

Correction and erasure

A user may request correction of inaccurate or incomplete information. The organisation should identify which system is the source of truth and update connected systems where appropriate.

Erasure requires a retention policy. A business should not promise to delete every record immediately if certain records must be kept for legal, tax, accounting, fraud-prevention or dispute-related reasons. It should record the reason for continued retention and remove the information when that reason no longer applies.

Grievance redressal

The website privacy notice should identify how a person can raise a privacy complaint. The process should route the complaint to someone responsible, rather than leaving it in a general inbox that nobody monitors.

Keep a simple register containing:

• Date of complaint
• Person or account involved
• Issue raised
• Systems checked
• Action taken
• Response sent
• Any unresolved point or escalation

The precise response requirements and process should be checked against the latest applicable Act provisions and notified rules.

Children’s Data and Education Websites

The DPDP Act treats a child as a person below eighteen years of age. This is particularly relevant to schools, coaching institutes, children’s activity providers, paediatric services, NGOs working with children and apps or websites directed at young users.

A business processing children’s personal data needs a stronger operating model. The Act provides for verifiable parental consent and restricts certain processing activities involving children, including tracking or behavioural monitoring directed at children and targeted advertising directed at children. The exact operational requirements should be checked against the rules and notifications in force.

A school website should distinguish between:

• General information pages that collect no personal data
• Parent enquiry forms
• Admission applications
• Student portals
• Event registration
• Photo and video publication
• Online fee or transport requests

Do not treat a parent’s checkbox as automatically sufficient for every possible use. The organisation should identify the parent or lawful guardian verification approach required for the specific activity and keep records.

Photographs, names, achievements and event videos also need careful handling. A school may have a legitimate reason to publish an event report, but it should consider whether public publication is necessary, whether consent or notice is required, and whether children’s identities can be reduced.

For an NGO, consent and safeguarding processes should be designed with vulnerability in mind. A beneficiary registration form should not expose personal details publicly or send them casually through multiple volunteer devices.

Security Measures and Data Breach Readiness

The DPDP Act requires reasonable security safeguards to prevent personal data breaches. A website compliance review should therefore include technical controls, not just written documents.

Basic safeguards include:

• HTTPS across the complete website
• Secure hosting and current software
• Strong administrator passwords
• Multi-factor authentication where available
• Restricted access to databases and dashboards
• Regular software and plugin updates
• Secure backups with controlled access
• Malware and vulnerability monitoring
• Protection against common form abuse
• Encryption or equivalent protection for sensitive transfers
• Logging of administrator and important user activity
• A process for removing former staff access
• Separate development and production environments where practical

Website forms should not send sensitive information in plain email without a reasoned assessment. If staff receive patient, student or identity documents, the business should review whether email is the right channel and who can access the files.

The business also needs an incident response plan. A suspected breach might involve a hacked WordPress administrator account, leaked spreadsheet, compromised cloud storage, exposed database, lost laptop or misdirected email.

The plan should state:

1. Who receives the initial report
2. How access is contained
3. Which systems and records are checked
4. How the business assesses affected individuals
5. Which vendors and advisers must be contacted
6. How required notifications are made
7. How evidence and decisions are recorded
8. What corrective action follows

The Act requires breach-related notifications in the manner and to the recipients prescribed by the applicable legal framework. Because implementation details may depend on notified rules, businesses should verify the current requirements at the time of an incident rather than relying on an old checklist.

Vendors, Processors and Third-Party Integrations

A website commonly depends on outside providers:

• Hosting and domain companies
• Form builders
• Cloud storage
• CRM software
• Email marketing platforms
• Payment gateways
• Booking systems
• Chat and WhatsApp tools
• Analytics and advertising services
• Security and backup providers
• Freelancers and maintenance agencies

The business should maintain a vendor list and understand what each provider does with the data. Check whether the provider offers contractual privacy and security commitments, access controls, breach assistance, deletion support and information about subprocessors.

Vendor contracts should address, as appropriate:

• Processing only on documented instructions
• Confidentiality
• Security safeguards
• Assistance with user requests
• Breach reporting and cooperation
• Return or deletion of data
• Restrictions on using customer data for the vendor’s own purposes
• Subcontractor controls
• Audit or assurance information

A provider’s standard terms may not answer every question. For a small business, the objective is not to create an impractical contract for every tool, but to identify higher-risk processing and obtain enough assurance before connecting the tool to real customer data.

Review overseas service providers carefully. Cross-border data issues under the DPDP framework may depend on government notifications and prescribed restrictions. Businesses should not make broad claims such as “data never leaves India” unless they have verified the provider’s hosting, support, backups and subprocessors.

Significant Data Fiduciaries and Higher-Risk Organisations

The Act allows the government to designate certain organisations as Significant Data Fiduciaries based on factors such as the volume and sensitivity of personal data, risk to sovereignty and integrity, security of the State, electoral democracy, and public order.

A designated organisation may face additional requirements, including appointing a Data Protection Officer based in India, appointing an independent data auditor and carrying out assessments or audits as prescribed.

Most small businesses should not assume that these enhanced obligations automatically apply to them. They should, however, assess whether their activities involve large-scale, sensitive or high-impact processing. A health platform, education technology provider, financial service or large consumer marketplace may need a more formal governance programme than a small brochure website.

Keep the compliance programme proportionate to the actual risk, but do not confuse a small website with a small data operation. A ten-page website connected to a CRM, marketing platform and online application workflow may process more personal data than its design suggests.

Common Website Mistakes to Avoid

Copying a generic privacy policy

A policy that names services the business does not use, omits actual vendors or makes unsupported promises can create confusion. It should reflect the real website and be reviewed when tools or purposes change.

Making all fields mandatory

Mandatory fields should be necessary for the stated purpose. Mark optional fields clearly and explain why additional information is requested.

Using one checkbox for everything

Service communication, marketing, profiling and third-party sharing may require different explanations and choices. Separate them where the purposes differ.

Treating WhatsApp as an informal exception

When staff collect leads through WhatsApp links or forward customer information to personal accounts, the same privacy and security questions remain. Use business accounts, access controls and retention rules.

Keeping data forever

Old enquiries, rejected applications and unused mailing lists increase the impact of a future incident. Set retention periods by purpose and delete or anonymise information when it is no longer needed.

Ignoring embedded tools

Maps, videos, chat widgets, fonts, social plugins and ad scripts may send information to third parties before the website owner realises it. Review the network calls and vendor documentation.

Failing to test deletion

A policy may promise deletion, but staff may not know how to remove data from the CRM, backup, email platform and spreadsheets. Test the process on a sample record.

A Practical Compliance Comparison

Frequently Asked Questions

Does every Indian website need a DPDP Act privacy policy?

A business that processes personal data through its website should provide clear information about that processing and maintain a suitable privacy notice. A static website with no forms, accounts, analytics or tracking may have a much narrower compliance requirement, but the business should still review hosting logs, contact links and third-party tools.

Is a cookie banner compulsory for every website in India?

The DPDP Act does not simply create one universal banner format for every cookie. The right approach depends on the data collected, the purpose, the technology used and whether consent is required. Businesses using analytics, advertising or remarketing should not assume that all tracking can run without review.

Can a small business use a standard privacy policy template?

A template can be a starting point, but it should be adapted to the business’s real forms, vendors, retention practices and user rights process. Remove statements that are not true, such as claims that the business does not share data when it uses email marketing, payment or CRM providers.

Does the DPDP Act apply to WordPress websites?

The technology platform does not decide whether the Act applies. A WordPress website can process personal data through forms, user accounts, plugins, analytics, comments and hosting logs, so the business should review its actual configuration and access controls.

What should a business do if it discovers a data breach?

First contain the incident, preserve evidence and identify the affected systems and data. Notify the responsible internal person and relevant vendors or advisers, assess the applicable legal notification requirements, and follow the current provisions and rules rather than relying on an outdated breach template.

Does a website need to store all consent records forever?

Not necessarily. Consent records should be retained long enough to demonstrate what was communicated and what the person agreed to, while following a documented retention policy. Records may need to be kept for different periods depending on the purpose, legal requirements and whether an ongoing relationship exists.

Where to Start

Begin with a website and data-flow audit. List every form, cookie, script, integration, storage location and staff access point. Then update the privacy notice, simplify collection, separate marketing choices, document retention and create a workable process for access, correction, withdrawal, deletion and grievances.

Next, review hosting, administrator accounts, backups and third-party vendors. If your website collects children’s data, health information, identity documents, donor records or large volumes of customer data, obtain legal and technical advice before making major changes.

Govindani Infotech can help review website forms, integrations, security settings and implementation requirements; contact the team on WhatsApp to discuss your website and receive pricing confirmed by the team.