DPDP Act25 May 2026 8 min read

DPDP Act Purpose Limitation: Collecting Only What You Need

How the DPDP Act 2023 purpose limitation obligation works, what it means for Indian SaaS companies, and how to implement compliant data collection.

Key Takeaways

Section 4 of the DPDP Act requires that personal data be processed only for a specific, clear, and lawful purpose that was disclosed to the Data Principal at collection.
Repurposing data for a new use without fresh consent or a valid lawful basis is a direct breach of the Act and can attract penalties up to ₹250 crore.
Every product feature that uses personal data should be mapped to a declared purpose before it is built.
Purpose limitation applies even to data held by Data Processors — the Data Fiduciary is responsible for ensuring processors stay within scope.
Annual reviews of data purpose registers help catch scope creep before it becomes a compliance liability.

In this guide

What Is Purpose Limitation Under the DPDP Act?
Section 4 and the Lawful Purpose Requirement
Common Purpose Limitation Violations in Indian SaaS
Building a Data Purpose Register
Linking Consent to Specific Purposes
Keeping Data Processors Within Purpose Scope
Auditing Purpose Compliance Annually

What Is Purpose Limitation Under the DPDP Act?

Purpose limitation is the principle that personal data collected from an individual may only be used for the specific purpose for which it was collected — and not for any other purpose without a fresh legal basis. It is one of the foundational data protection principles adopted by modern privacy laws worldwide, and the DPDP Act 2023 codifies it as a core obligation for every Data Fiduciary operating in India.

In practical terms, purpose limitation means that if you collected a user's email address to send transactional receipts, you cannot later use that email address to send marketing campaigns unless you have a separate consent or another valid lawful basis. Similarly, if you collected location data to enable delivery tracking, you cannot repurpose that data to build user behaviour profiles for advertising without explicit disclosure and fresh consent.

For Indian B2B SaaS companies, purpose limitation has immediate implications for product analytics, AI/ML model training, cross-product data sharing, and any secondary monetisation of data. Many companies have historically operated on the assumption that data collected is data available — the DPDP Act replaces that assumption with a specific legal obligation.

Section 4 and the Lawful Purpose Requirement

Section 4(1) of the DPDP Act states that a Data Fiduciary may process the personal data of a Data Principal only for a lawful purpose — either with the consent of the Data Principal, or for certain legitimate uses identified in Section 7 (such as state functions, compliance with law, medical emergencies, and certain employment-related processing). Every processing activity must be anchored to one of these lawful bases.

Section 4(2) further requires that processing must be limited to personal data "that is necessary for such purpose." This necessity requirement sits alongside purpose limitation and imports a proportionality test: even within a valid purpose, you cannot collect more data than is actually needed to achieve that purpose. The combination of Sections 4 and 5 (privacy notice) means you must both define the purpose clearly and disclose it to the Data Principal before or at the time of collection.

The Act does not define "purpose" further, and the Rules will likely provide guidance. In the meantime, companies should follow best practice: purposes should be specific (not generic phrases like "to improve services"), documented, disclosed in the privacy notice, and linked to specific data categories. Vague or catch-all purpose statements are unlikely to satisfy the Board in an inquiry.

Common Purpose Limitation Violations in Indian SaaS

The most frequent purpose limitation issue in SaaS products is analytics scope creep. A company collects usage event data (ostensibly to improve product performance) and then, over time, that data is used to build churn prediction models, score accounts for upsell targeting, and feed sales intelligence dashboards — all uses that were never disclosed to the user. Each of these secondary uses is a potential violation.

Another common pattern is cross-product data sharing within a corporate group. Company A collects user data under its privacy notice. Subsidiary B, which operates a different product, gets access to that data to seed its own user base. Unless the original privacy notice specifically disclosed this sharing and the user consented to it, the transfer breaches purpose limitation even if both entities are part of the same group.

Employee data misuse is also prevalent: HR systems collect personal data for payroll, but the same data is later analysed for performance scoring, productivity surveillance, or used in third-party background check platforms beyond the original scope. With the DPDP Act applying to employee data, these practices will need to be reviewed against the declared purpose at collection.

Building a Data Purpose Register

A data purpose register (sometimes called a Record of Processing Activities) maps every category of personal data to: (a) the purpose for which it was collected, (b) the lawful basis under the DPDP Act, (c) the data categories involved, (d) retention period, (e) processors who receive the data, and (f) any cross-border transfers. This document becomes the authoritative reference for your compliance programme.

To build the register, start with a data discovery exercise. Interview product managers, engineering leads, and the sales/marketing team to understand what personal data flows through each system. For each flow, ask: "Why was this data collected? What did we tell users at the time?" Any gap between the answer to those two questions is a potential compliance issue.

Once built, the purpose register should be treated as a living document — updated whenever a new feature is launched, a new vendor is onboarded, or an existing data use changes. In platforms like AuditPath, you can link each processing activity to specific DPDP controls so your compliance posture updates automatically when the register changes.

Under Section 6 of the DPDP Act, consent must be free, specific, informed, unconditional, and unambiguous. The "specific" requirement means consent must be tied to a particular purpose — bundled consent for multiple purposes in a single checkbox is unlikely to be valid. Each distinct processing purpose should have its own consent item, clearly described.

When a product adds a new feature that uses existing personal data for a new purpose, you need to go back to users and obtain fresh consent for that new purpose — you cannot rely on the original, broader consent. This has significant implications for product roadmaps: privacy review should be part of the feature specification process, not a post-launch checkbox.

Consent records must be maintained and must be retrievable. The DPDP Rules are expected to specify the format and retention period for consent records, but as a baseline, companies should log the timestamp, version of the privacy notice in effect at the time, the specific purposes consented to, and how consent was obtained (e.g., checkbox, API call). This log is essential evidence if a Data Principal later disputes what they consented to.

Keeping Data Processors Within Purpose Scope

Under the DPDP Act, the Data Fiduciary bears responsibility for ensuring that Data Processors (vendors, subprocessors, analytics platforms) process personal data only within the scope of the declared purpose. Section 8(2) requires the Data Fiduciary to enter into a valid contract with each Data Processor that specifies the processing to be performed on its behalf.

In practice, this means your vendor contracts must include: (a) a clear description of the processing activities authorised, (b) a prohibition on the processor using data for its own purposes or sharing it with sub-processors not approved by you, (c) a requirement to delete or return data when the contract ends, and (d) cooperation obligations for audits and Data Principal rights requests.

Review your existing SaaS vendor agreements — most standard vendor contracts are written from the vendor's perspective and do not contain adequate DPDP-compliant Data Processing Agreement (DPA) terms. You should issue DPA addenda to all vendors who process personal data on your behalf before enforcement begins.

Auditing Purpose Compliance Annually

Purpose limitation is not a one-time setup exercise — it requires ongoing monitoring. Product features change, analytics integrations are added, and data flows evolve. An annual purpose compliance audit should review: (1) whether the purpose register reflects current reality, (2) whether any new processing activities have been started without a documented lawful basis, and (3) whether any data is being retained beyond its declared purpose.

During the audit, specifically check analytics and telemetry data flows. Tools like Mixpanel, Segment, Amplitude, and custom data warehouses are common locations where data is collected broadly and then used for purposes that were not originally declared. Review the event schemas and downstream use cases against the privacy notice.

Document the audit findings and any remediation actions taken. For Significant Data Fiduciaries, Section 10 requires periodic Data Protection Impact Assessments, which will incorporate purpose limitation review as a key element. Even companies not yet classified as Significant Data Fiduciaries benefit from conducting DPIA-style reviews as a proactive compliance measure.

Frequently Asked Questions

Can we use customer data collected during a free trial for marketing after they become a paying customer?

Only if your privacy notice at the time of the free trial clearly disclosed that data would be used for marketing and the user consented to it. If the trial consent was scoped only to providing the trial service, you need fresh consent before sending marketing communications to converted customers.

Does purpose limitation apply to anonymised data?

Truly anonymised data — where re-identification is not reasonably possible — falls outside the DPDP Act's scope entirely, so purpose limitation does not apply. However, pseudonymised data (where re-identification is possible with a key) is still personal data and is subject to purpose limitation. The anonymisation must be irreversible to be outside scope.

What happens if we want to use existing user data to train an AI model?

This is a secondary purpose that requires a fresh lawful basis. If the original collection purpose was providing a service, using that data for AI model training requires either new explicit consent from each user or a valid legitimate use under Section 7. Most companies will need a consent-based approach for this. Document the basis clearly.

Does purpose limitation apply to employee data in India?

Yes. Employee data is personal data under the DPDP Act. The data collected for payroll cannot be used for performance surveillance, the data collected for emergency contact cannot be shared with insurers, and so on — unless those uses were disclosed and consented to, or fall within a Section 7 exemption for employment-related processing.

How specific does a "purpose" need to be in a privacy notice?

The Act requires the purpose to be specified. Generic phrases like "to improve our services" are unlikely to satisfy this requirement. Purposes should describe the actual processing activity: "to send you transactional emails about your account", "to analyse usage patterns for product improvement", "to fulfil your delivery order." Each distinct activity should be listed separately.