Data Minimisation
Collecting only the personal data that is needed for the stated purpose.
Data minimisation means collecting and keeping only the personal data you truly need for a stated purpose, and nothing extra just in case it becomes useful later.
Meaning of Data Minimisation
Consent is limited to the personal data necessary for the specified purpose, and the Second Schedule standards require data minimisation for State processing. Collecting less data reduces risk, cost and the size of any breach.
Data minimisation is the discipline of asking, for every piece of personal data, whether the purpose can be met without it. A delivery app needs an address but not a date of birth. A newsletter needs an email address, not a phone number and occupation. The principle applies when you design a form, when you buy or accept data from partners, when you decide how long to store it, and when you share it.
The DPDP Act builds the idea into its structure. Section 6(1) says consent must be limited to such personal data as is necessary for the specified purpose. Section 5 requires a notice describing the personal data and the purpose, and Rule 3 asks for an itemised description of the data and of the goods, services or uses enabled by it, so the notice itself exposes unnecessary items. Section 8(7) requires erasure when the purpose is served or consent withdrawn, unless law requires retention. For State processing, the Second Schedule standards under Rule 5 expressly include data minimisation.
Minimisation has limits and neighbours. It is not the same as purpose limitation, which controls what you may do with data once collected, or storage limitation, which controls how long you keep it. Together they form a three-part discipline: collect only what is needed, use it only for the stated purpose, and delete it when done. It also does not prevent legal retention. Where tax, financial or sector rules require records to be kept, that obligation can justify keeping specific data for the required period.
Optional data is allowed, but it must be really optional and explained. Section 6(1) requires consent to be free, so you may not make service conditional on data that is not necessary, and the Act's own illustrations reject bundling unnecessary permissions. Hoarding data for possible future analytics, with no stated purpose, cannot be covered by a valid consent and enlarges the target for attackers.
Examples of Data Minimisation
A newsletter sign-up asks for an email address only, not a phone number or date of birth.
A retailer removes mandatory date of birth and gender fields from its checkout, keeping only name, address, phone and email for delivery. It asks for date of birth only in an optional birthday-offer sign-up, with its own clear notice.
A hospital reception desk used to photocopy every patient's ID card. It now records only the type and last four digits of the ID presented, and stores the full details only when an insurance claim requires them.
An HR team collecting job applications stops asking for caste, religion and family details at the application stage. It collects bank and identity documents only from candidates who accept an offer, and deletes unsuccessful applicants' data on a set schedule.
Why Data Minimisation matters
Every extra field is a liability. It must be notified, protected, kept accurate, searched when a request arrives and deleted on time. If it leaks, it enlarges the harm and the exposure: penalties can reach ₹250 crore for security failures, and ₹50 crore for other breaches of the Act, including processing beyond what consent covers. Smaller datasets are cheaper to secure, easier to govern and simpler to explain to customers.
Minimisation also builds trust. Forms that ask only for what they need convert better, create fewer complaints and give the Data Protection Board less to question. Customers notice when an app demands contacts, location or an ID document for a function that does not need it, and they walk away or complain.
How it works in practice
- 1Run a data inventory by purpose. For each purpose, list the data items collected and mark each as necessary, useful or unused. Remove or make optional anything that is not necessary.
- 2Redesign forms and APIs. Ask for the minimum at each step, collect further data only when a feature needs it, and avoid free-text fields that invite sensitive details. Do not pre-tick optional boxes.
- 3Reduce identifiability. Where you can serve the purpose with less, use masking, truncation, ranges instead of exact values, pseudonymous IDs or aggregated statistics, particularly for analytics and testing.
- 4Control inbound and shared data. Challenge partners and processors that send you more than you need, and give processors only the fields required for their task.
- 5Set retention and deletion rules. Define a period for each category, automate deletion or anonymisation, and include backups and logs in the schedule while respecting legal retention needs such as the one-year log minimum in Rule 6.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Collecting extra data for a future use not yet defined. If the purpose is not stated in the notice, consent will not cover it, so collect when a real purpose arises.
Asking for broad app permissions, such as contacts or location, when the feature does not need them. Request each permission only when its feature is used.
Minimising collection but keeping everything forever. Combine minimisation with retention limits and erasure.
Copying production data into test and analytics systems. Use masked or synthetic data for those purposes.
Compliance tips
Ask "what would break if we did not collect this?" before adding any field. If the answer is nothing, leave it out.
Review data fields yearly, since products drift and fields that were once needed may become unused.
Make the itemised list in your Rule 3 notice match the form exactly. Mismatches reveal collection that is not justified.
Common questions about Data Minimisation
Does the DPDP Act require data minimisation?
The word is not used for private organisations, but Section 6(1) limits consent to personal data necessary for the specified purpose, and Section 8(7) requires erasure once the purpose is served. For State processing, the Second Schedule standards under Rule 5 expressly list data minimisation.
Can we collect extra data if users agree?
Optional data can be collected if it is really optional, explained in the notice and not a condition of service. Consent must be free and specific under Section 6(1). Bundling unnecessary data into a required consent is likely to be invalid.
What is the difference between data minimisation and storage limitation?
Minimisation limits how much and which data you collect. Storage limitation limits how long you keep it. Under the Act, the second shows up in Section 8(7) and Rule 8 on erasure and retention. Both reduce risk and work best together.