India's Digital Personal Data Protection Act (DPDP Act) treats a name, email address, and phone number typed into a website contact form as personal data, which means collecting it triggers the law's obligations. In practice, that means five concrete things for a typical business site: a real notice explaining what you collect and why, a lawful basis for collecting it, only asking for fields you actually need, a defined limit on how long you keep submissions, and a working process for someone to request access to or deletion of their data.
None of this requires a legal team to rebuild your website from scratch. But it does mean the contact form most companies have been running unchanged since 2019 probably needs a few specific, buildable changes.
Notice: your privacy policy has to actually say something
A lot of privacy policies on small and mid-size business websites are boilerplate pulled from a template years ago, sometimes never updated to reflect what the site actually does. Under the DPDP Act, the notice given to a person before or at the time you collect their data has to specify, in clear language, what personal data you're collecting and the specific purpose for collecting it.
For a contact form, that means the notice near or linked from the form should state, concretely:
- Which fields are collected (name, email, phone, company, message — whatever the form actually asks for)
- Why you're collecting each one (to respond to the inquiry, to route it to the right team, to follow up about a quote)
- Who within your organization or which vendor processes it (your CRM, your email provider, your support ticketing tool)
- How long you retain it and how someone can request deletion
A generic "we value your privacy" paragraph doesn't meet this bar. If your policy doesn't name the actual data fields your form collects, it needs to be rewritten to match the form, not the other way around.
Consent as your lawful basis
The DPDP Act requires a lawful basis for processing personal data, and for a contact form, that basis is almost always consent — there's no employment relationship, contract, or legal obligation making the collection mandatory the way there might be for, say, payroll data.
Practically, that means:
- The consent request has to be specific to the purpose (not bundled into a vague "I agree to terms" checkbox that also covers marketing, analytics, and three other things)
- It can't be pre-checked by default — the person has to take an affirmative action
- Withdrawing consent has to be as easy as giving it, which for a contact form usually means a clear unsubscribe or deletion path if you follow up by email afterward
If your form currently submits with no checkbox at all and just a small "by submitting you agree to our privacy policy" line under the submit button, that's a gray area worth flagging to counsel — it depends on how prominent and specific that language is. A separate, explicit checkbox is the safer, clearer implementation and it's a small change to make.
Data minimization: stop collecting fields you don't use
This is the one engineering teams can fix without waiting on anyone. Pull up your contact form and ask, honestly, whether every field is used downstream. Common offenders:
- A "company size" dropdown that populates a CRM field nobody has looked at in two years
- A phone number field marked required when your team only ever replies by email
- A "how did you hear about us" field that was added for one marketing report and never removed
- Address fields collected for a form that doesn't ship anything
Data minimization isn't just a compliance nicety — every field you collect is a field you now have to notice, secure, retain-manage, and be able to delete on request. Cutting a form from nine fields to four cuts your compliance surface area by more than half. If a field isn't feeding an active workflow, remove it.
Retention: define an end date for the data
"We keep it indefinitely because storage is cheap" is the default state of most contact form submissions, sitting in a database or a CRM with no expiry. The DPDP Act's data minimization and storage limitation principles mean you need a defined retention period tied to the purpose you stated in your notice — data shouldn't be kept longer than necessary for that purpose.
What this looks like in a real system:
- Decide a retention window with input from whoever owns the sales or support process (a common approach is something like 12–24 months from last contact, but the right number depends on your actual follow-up cycle)
- Build an automated job that deletes or anonymizes submissions past that window, rather than relying on someone remembering to do it manually
- Apply the same window to any downstream copies — the CRM record, the email thread, the spreadsheet someone exported for a campaign
If your form submissions flow into a CRM, this is usually a scheduled deletion rule you configure once, not a recurring manual task.
Access and deletion requests: build the process before you need it
The DPDP Act gives individuals the right to ask what data you hold on them and to request its deletion. For a contact form, this sounds simple in theory and is often messy in practice, because the submission doesn't live in one place — it's in the form's database, the email it triggered, the CRM it synced to, and maybe a Slack notification.
A workable process needs:
- A single intake point for these requests (a dedicated email address or form, monitored by someone who knows what to do with it)
- A documented list of every system a contact form submission actually lands in, so a deletion request can be fulfilled completely rather than partially
- A response time target, since the law sets expectations around timely response
- A log of requests received and how they were resolved, in case you need to demonstrate the process works
This is infrastructure work, not a policy document. It typically means an internal runbook plus a few minutes of scripted or manual cleanup across two or three systems per request.
This is not legal advice, but it is engineering work
None of the above is a substitute for advice from counsel qualified in Indian data protection law — the DPDP Act's rules around consent managers, breach notification, and cross-border transfer have real nuance that a blog post can't responsibly cover, and the right retention period or consent language for your business depends on facts a lawyer needs to review. Treat this as a map of the technical and product work, not a compliance certificate.
What we've described here — rewriting notice text to match actual form fields, adding an explicit consent checkbox, cutting unused fields, building a retention job, and standing up an access/deletion process — is exactly the kind of work that lands on an engineering team's desk once counsel has signed off on the policy. It's buildable in a sprint or two for most contact forms, and it's worth doing before a request or an audit forces the timeline.