DPDP Act Data Minimisation: How to Implement It
Practical guidance on implementing DPDP Act data minimisation obligations — what to collect, what to cut, and how to build minimisation into your product.
- Section 4(2) of the DPDP Act requires that only personal data "that is necessary" for the declared purpose may be collected — this is the data minimisation obligation.
- Data minimisation is both a collection-time and a retention-time obligation: collect only what you need, and delete it when you no longer need it.
- Registration and onboarding forms are the most common location of excess data collection and should be audited against actual business necessity.
- Minimisation reduces breach impact — less data means smaller penalties and fewer affected Data Principals if a security incident occurs.
- Product managers should sign off on a data necessity justification for every new field added to any user-facing form.
In this guide
What Is Data Minimisation Under the DPDP Act?
Data minimisation is the principle that organisations should collect and process only the minimum amount of personal data necessary to achieve their stated purpose. It is a direct corollary of purpose limitation: once you know why you are collecting data, you must assess whether each data element is genuinely required to fulfil that purpose, and avoid collecting anything beyond what is strictly necessary.
The DPDP Act 2023 codifies data minimisation in Section 4(2), which requires that personal data processed be "complete, accurate, and limited to what is necessary for the purpose for which it is processed." This is a binding legal obligation, not a best practice — Data Fiduciaries that collect unnecessary personal data are in breach of the Act even if they have obtained consent, because consent does not override the necessity requirement.
For Indian SaaS companies, data minimisation has immediate practical implications. Years of "collect everything, figure out the use later" product culture need to be replaced with a discipline of asking "do we actually need this field?" before adding it to any form, API, or analytics event. This shift requires both engineering and product leadership buy-in.
The Necessity Requirement in Section 4(2)
Section 4(2) introduces a proportionality test that regulators in Europe have applied strictly under GDPR — and India's Data Protection Board is likely to take a similarly rigorous view. "Necessary" means there is no less privacy-invasive way to achieve the same purpose. If you can verify a user's age without storing their full date of birth, storing the full date of birth is not necessary. If delivery can be completed with a district-level address, storing GPS coordinates is not necessary.
The necessity assessment must be documented. You should be able to explain, for each field in your data model, why that specific data element is required for the stated purpose. "It might be useful" or "competitors collect it" are not valid justifications. The test is: would omitting this data make it impossible or materially harder to achieve the purpose? Only if the answer is yes does collection pass the necessity test.
Note that necessity interacts with consent. A user can consent to provide more data than is strictly necessary — for example, voluntarily sharing their occupation for a personalisation feature — but the Data Fiduciary cannot require unnecessary data as a condition of service. Mandatory versus optional fields in forms are therefore a compliance question, not just a UX question.
Auditing Registration and Onboarding Forms
Registration and onboarding forms are where data minimisation violations are most visible. A common pattern in Indian B2B SaaS is collecting fields like company size, revenue band, phone number, and designation during free trial registration — data that benefits the sales team but is not required to provide the software service. Under the DPDP Act, making these fields mandatory without a clear necessity justification is a compliance risk.
Conduct a field-by-field audit of every form in your product: registration, onboarding, profile, payment, support, and any survey or feedback form. For each field, document: (a) is it mandatory or optional? (b) what purpose does collecting this data serve? (c) is that purpose declared in the privacy notice? (d) can the purpose be achieved without collecting this field? Mark any field that fails question (d) as a candidate for removal or making optional.
After the audit, present findings to product and sales leadership. Some fields that serve sales qualification purposes can be moved to a separate, voluntary step with a clear explanation ("We'd love to learn more about your team to personalise your experience — this is optional"). This approach respects data minimisation while retaining the business value of that data where users choose to share it.
Minimising Analytics and Telemetry Data
Analytics and telemetry pipelines are often the most significant source of excess data collection in SaaS products. Event tracking tools like Mixpanel, Segment, and Amplitude can be configured to capture essentially every user interaction, and many engineering teams implement broad event capture with the intention of querying specific insights later. The result is a data warehouse full of personal data collected far beyond what any declared purpose requires.
Audit your analytics event schemas. For each event, identify: (a) what personal or personally linkable data is included (user ID, IP address, device fingerprint, free-text inputs), (b) what analysis this event supports, and (c) whether the analysis could be achieved with less granular data. Consider pseudonymisation at the point of collection — hashing user IDs before they reach analytics systems — or aggregating events rather than storing individual-level records.
Review your analytics vendor contracts as well. Tools like Google Analytics 4 and similar platforms operate as Data Processors under the DPDP Act. Ensure your configuration settings minimise data collection (e.g., IP anonymisation, data retention limits set to minimum), and that the vendor has signed a DPDP-compliant DPA with you.
Building Minimisation Into Product Design
The most effective way to implement data minimisation is to embed it into your product development process rather than treating it as a post-launch audit activity. This means adding a "data necessity review" step to your product specification and design workflow. Before any new form field, data model attribute, or analytics event is approved, someone should ask: is this data element necessary for the declared purpose?
Create a simple checklist for product managers and engineers to complete whenever a new data collection point is proposed: (1) What personal data will be collected? (2) What is the specific purpose? (3) Is this purpose declared in our current privacy notice? (4) Why is this specific data element necessary to achieve that purpose? (5) What is the retention period? This checklist takes five minutes but creates a documented justification trail.
Designate a data protection champion in the product and engineering organisation — someone who understands the DPDP Act obligations and can flag minimisation concerns in sprint planning and design reviews. This does not need to be a full-time role in smaller companies; a trained senior engineer or product manager can perform this function alongside their primary responsibilities.
Retention Limits as Data Minimisation
Data minimisation is not only about what you collect — it is also about how long you keep it. Section 8(7) of the DPDP Act requires Data Fiduciaries to erase personal data when the purpose for which it was collected is no longer being served and the Data Principal has not approached the Fiduciary for goods or services. Retaining data indefinitely "just in case" violates the minimisation and storage limitation obligations.
Establish a data retention schedule that specifies, for each category of personal data, the maximum period for which it will be retained after the purpose is fulfilled. Common retention periods for Indian SaaS companies: active user account data — retained for the duration of the subscription plus a short period for billing disputes (typically 30-90 days post-termination); support tickets — 12 months after resolution; marketing analytics — 24 months from collection; financial records — as required by law (typically 7 years under Indian accounting rules).
Implement automated deletion or anonymisation workflows to enforce these retention periods. Manual deletion is error-prone and does not scale. Configure your databases, data warehouses, and backup systems to delete data according to the schedule. Note that backups present a particular challenge — ensure your backup rotation policy is aligned with your retention schedule so that deleted records are not restored from old backups.
Why Less Data Is Better for Your Business
Data minimisation is sometimes perceived as a constraint on business intelligence capabilities, but it delivers concrete commercial benefits. Every additional data element you collect and store increases your storage costs, your security attack surface, and your breach notification obligations. Smaller data sets mean smaller blast radius in a security incident and potentially lower penalties under the DPDP Act's Schedule 1.
Customer trust is increasingly a commercial differentiator in the Indian market. Enterprise buyers, especially those in regulated industries (BFSI, healthcare, government), are conducting vendor due diligence that includes data handling practices. A demonstrable data minimisation programme — with documented purpose registers, minimal mandatory fields, and clear retention schedules — is a competitive advantage in procurement processes.
Finally, leaner data models are technically better. Databases with fewer irrelevant fields are faster to query, cheaper to replicate, and easier to maintain. The engineering discipline of "collect what you need, delete what you don't" produces cleaner architectures and reduces technical debt over time. Frame data minimisation as a quality engineering practice, not just a compliance burden.
Frequently Asked Questions
Does data minimisation mean we cannot collect phone numbers during registration?
We use ML models trained on historical user data. Does minimisation require us to delete that training data?
Can we anonymise data instead of deleting it to satisfy minimisation?
How do we handle minimisation for data in backups and disaster recovery systems?
Does minimisation apply to data we receive from third parties (e.g., enrichment vendors)?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free