Purpose limitation
Data collected for support cannot be reused for outbound marketing without a new lawful basis, so each workflow declares its purpose.
Data collected for support should not be reused for outbound marketing without a new lawful basis. Each workflow should declare its purpose.
Data collected for support should not be reused for outbound marketing without a new lawful basis. Each workflow should declare its purpose.
All glossary terms
The short version
- Purpose limitation means personal data collected for one stated purpose may not be quietly reused for another. Under the DPDP Act, the purpose has to be specified in the notice and the consent has to be limited to it.
- It is a design constraint, not a policy sentence. If the purpose is not stored next to the data, every downstream query is unaudited reuse by default.
- It is not data minimisation, although the two are neighbours: minimisation limits how much you collect, purpose limitation limits why you may use it. Nor is it retention, which limits how long you keep it.
- India’s Act does not contain a general compatible-purpose balancing test. Processing is either within the consented purpose, required by another law, or covered by a listed legitimate use. There is no self-certified legitimate interest to fall back on.
- Enforce it in the schema: a purpose code on every row, a purpose-bound token at the API, and views that cannot join across purposes without a declared relationship.
- When a new use appears, the honest options are fresh consent with a new notice, a legitimate use that actually applies, or de-identified aggregate data. Repurposing the existing consent is not one of them.
What purpose limitation means in the DPDP Act
Purpose limitation is the principle that personal data may be processed only for the purpose for which it was collected and consented to, or for another purpose the law specifically permits. In the Digital Personal Data Protection Act 2023 it appears twice. Section 5 requires the notice to state the purpose, itemised, in clear and plain language. Section 6 requires consent to be specific and limited to the personal data necessary for that purpose. The two together mean the purpose is not a paragraph in a privacy policy, it is an identifier that attaches to data and to consent.
The Act’s structure is worth stating because it differs from what many teams learned under GDPR. There is no general compatibility assessment in which a company weighs necessity, safeguards and reasonable expectations to justify a secondary use. Processing is lawful because consent was given for that purpose, because another law requires it, or because the use falls inside the legitimate uses listed in Section 7. That list is specific: legal obligations, employment, medical emergencies, safety during a disaster, certain public functions, and research or statistics under conditions. It is not an open-ended balancing test.
What it is not: purpose limitation is not a ban on ever using data again. It is not a requirement to delete after one use, and it is not the same as consent. A company can hold a valid consent for a purpose and still breach the principle by using the data for a different one, because the defect is in the use, not in the permission.
Four neighbours that get confused with it
Data minimisation asks how much you collect and whether each field is necessary for the stated purpose. Purpose limitation asks why you are using what you already hold. A form can be perfectly minimal and still be misused later, and a dataset can be broad but used strictly within its purpose. The two controls fail in different places, which is why a privacy review that only asks about form fields misses the more common problem.
Retention limits ask how long you keep data. A retention schedule that deletes marketing records after twenty-four months says nothing about whether those records may be used to build a lookalike audience in month six. Storage limitation and purpose limitation are often implemented in the same policy document and enforced by entirely different code, and the code for purpose is usually the one that is missing.
Consent is the permission, not the boundary. Security is a separate obligation about unauthorised access, and a system can be perfectly secure while processing data for a purpose nobody agreed to. Legitimate use is the statutory exception, not a synonym for business convenience. Each of these has its own test, and collapsing them produces a privacy programme that can pass a security audit and still fail a purpose review.
The chain: notice, consent, purpose code
A workable implementation has three links. The notice names the purpose in language a person can understand. The consent record stores a purpose code that maps to that notice version. The data written as a result of that consent carries the same code. If any link is missing, the chain breaks and you cannot answer the only question that matters in a review: for this row, what was the person told, and what did they agree to.
The purpose code is the join key and it should be boring. Something like marketing.email.newsletter, support.ticket.resolution, payments.invoice.retention. Codes should be stable, documented, owned by someone, and mapped to a notice version and a lawful basis. They should not be campaign names or internal project codes, because those change every quarter and no auditor or successor system will be able to follow them.
The link most often skipped is the write. A consent is captured, a record is created, and the row has no purpose because the table was designed before the privacy work happened. Backfilling is possible when the collection point is unambiguous, and dishonest when it is not. A nullable purpose column with a default of unknown is an honest state; a backfilled value invented to make a dashboard green is a false record that will be discovered later.
Secondary use: the moment the principle is tested
Secondary use is any processing that was not the reason the data was collected. It is rarely dramatic. A support transcript used to train a tone model. A delivery address used to infer neighbourhood affluence. A churn model that reads billing data collected under a contract. A marketing team that exports the customer list to build a lookalike audience on an ad platform. Each is a new purpose, and each needs a basis that is not the original consent.
The honest options are three. Obtain fresh consent with a notice that describes the new purpose, which is what the Act contemplates and what a Consent Manager is designed to make practicable. Identify a legitimate use that genuinely applies, which for most commercial analytics it will not. Or transform the data so that it no longer identifies a person, in which case the Act’s protections for personal data stop applying, provided the transformation is real and not a pseudonym swap.
The dishonest option is the one that happens most. A team decides the new use is broadly consistent with the old one, writes a memo, and proceeds. That reasoning borrows the GDPR compatibility test that the Indian Act does not contain. If the purpose was not stated, the person was not told, and no listed legitimate use applies, the memo is a record of the decision to proceed without a basis.
Enforcing purpose in the schema
A principle that lives only in a policy document is enforced by memory. Memory fails at the first sprint deadline. The minimum technical control is a nullable purpose code on every table that holds personal data, written at insert time from the request context rather than from a client-supplied field. Nullable is deliberate: it distinguishes not yet classified from deliberately none, and it lets you run a report on coverage instead of pretending completeness.
The second control is a purpose registry, a small table with one row per code describing the notice version, the lawful basis, the owner, the allowed downstream systems and the retention rule. Every purpose code in the data must exist in the registry, and a foreign key enforces that. This is unglamorous and it is the difference between a dataset you can defend and a dataset you can only describe.
The third is derived data. When a table is built from two sources with different purposes, the derived table inherits the intersection, which is usually the narrowest purpose, not the union. A warehouse table that joins support tickets with order history can only be used for the purposes both allow. Most warehouses do the opposite by default, because the join is convenient and nobody wrote the rule down. Write it down, and enforce it in the transformation layer where the join happens.
Enforcement at query time, not just at rest
Tagging rows is necessary and insufficient. The failure mode is a well-tagged table read by an analyst who joins it to something else and exports the result to a dashboard with no purpose at all. Enforcement has to follow the data through the read path. The practical mechanism is a purpose claim in the session: the application authenticates a user, resolves the purpose of the task they are performing, and sets that purpose for the duration of the request.
In a database with row-level security, the policy can compare the row’s purpose code against the session’s allowed purpose set. In a warehouse, a policy engine or a governed view can do the same. Where neither exists, a service layer that only exposes pre-approved queries is the fallback, and it is weaker because it depends on everyone using the service. Any of these is better than the default, which is a shared read-only role with access to everything.
Deny by default on cross-purpose joins. If a join between two purpose domains is legitimate, register it explicitly with a name, an owner and a justification, and let the query layer permit that specific join. The register becomes the map of where purposes legitimately meet, which is exactly the artefact a reviewer wants when they ask how support data ended up in a marketing model.
Processors, vendors and the purpose that leaks downstream
Under the Act the data fiduciary remains responsible for how a processor handles data, and the processor may only act on the fiduciary’s instructions. That makes the purpose a contract term and a technical constraint. A support tool that is permitted to process tickets for resolution is not thereby permitted to train a general model on them, and a clause that says the vendor may use data to improve its services is exactly the kind of clause that turns a processor into a secondary user.
Read the sub-processor list before the security questionnaire. The question is not whether the vendor is ISO certified. It is which entities receive the data, in which countries, for which purposes, and whether any of those purposes include model training, benchmarking or product analytics. If the answer is yes to model training on customer content, and your notice did not say so, the purpose has already leaked and no amount of encryption at rest repairs it.
The same discipline applies internally. A data catalogue entry that says owner: marketing, contains: email, phone does not describe a purpose. An entry that says purpose: marketing.email.newsletter, notice: v3, basis: consent, retention: 24 months, shared with: ESP and analytics does. The catalogue is where the purpose register becomes visible to people outside the privacy team, which is the only way it gets used.
De-identification is not a magic word
Aggregation and de-identification are legitimate ways to widen use, and they are frequently claimed without being done. Replacing a name with a customer identifier is pseudonymisation, not anonymisation: the mapping still exists, so the data still relates to a person and the Act still applies. Removing a phone number but keeping a precise address, a timestamp and a basket is not anonymisation either, because the combination re-identifies.
A defensible de-identification has three properties. It removes or generalises the quasi-identifiers that make linkage possible, including timestamps, pin codes and rare combinations. It is evaluated against a plausible attacker with access to other datasets, not against a colleague’s intuition. And it is re-tested when new data sources are joined, because anonymity is a property of a dataset in a context, not a permanent label.
The practical output is usually a small number of aggregate tables with minimum cell sizes, published internally as the only approved route for secondary analytics. Everything else stays purpose-bound. That is less convenient than a free warehouse and it is what makes the answer to a secondary use request a clear yes or no rather than a debate.
Evidence: what to keep and what to show
The purpose register, the notice versions, the consent events and the query audit are the four artefacts that answer a purpose question. Together they let you say: this row was collected under notice v3 for purpose marketing.email.newsletter, the person consented on this date from this source, the row was read only by systems registered for that purpose, and here are the reads. That is a complete answer, and it is rare enough to be a competitive advantage in enterprise procurement.
A records-of-processing register is the natural home for the summary. Under the Act, significant data fiduciaries carry additional obligations including impact assessment and audit, but the register is useful at any size because it forces the purpose list to be finite. A company with sixty purpose codes has forty too many, and the exercise of writing them down usually reveals that half are the same purpose named by different teams.
Keep the evidence long enough to be useful. A consent event that is deleted by the retention job protecting the marketing data is its own small tragedy. Consent records, notice versions and deletion receipts belong in a compliance store with a retention rule derived from limitation periods, not from campaign cycles. That store is small, structured and cheap, and it is the one place where keeping data longer is the correct answer.
The mistakes that recur in Indian teams
The first is improve our services. A notice that permits processing to improve services is broad enough to cover almost anything, which is why it fails the specificity test and why nobody can say what it authorised. The second is analytics as a default. Product analytics on customer behaviour is a purpose, and it needs to be named, not assumed as part of using the product.
The third is training data. Support transcripts, call recordings and chat logs are the richest source of language data a company owns, and using them to fine-tune a model is a new purpose that almost no notice mentions. The fourth is the acquired list. A company buys another company and inherits its contacts, and the purposes do not transfer because the notice named a different entity.
The fifth is the spreadsheet. An export created for a board deck, emailed to a consultant, and stored in a personal drive has left every control you built. Purpose limitation at the database layer counts for nothing if the last mile is a CSV attachment. The fix is not technical alone: it is a rule that exports are themselves a purpose, with an owner, a retention period and a deletion date.
Measuring purpose hygiene
Four numbers are enough to start. Purpose coverage, the share of personal data rows with a non-null code that exists in the register. Orphan purposes, codes present in data but absent from the register, which should be zero. Cross-purpose reads, the count of queries that joined domains without a registered relationship, which should trend down. And review latency, the median time between a new purpose being proposed and a decision being recorded, which tells you whether the governance is real or ceremonial.
Add one qualitative measure: the number of purposes on the register. If it grows every quarter and never shrinks, the business is accumulating permissions it cannot explain. A healthy register is small, stable and occasionally pruned when a product is retired. The pruning is the sign that someone owns it.
Report the coverage number to the same committee that sees the security dashboard. Purpose is a data governance control with a technical enforcement path, and it competes for engineering time with encryption and access reviews. A number on the same page as those is the only way it gets scheduled.
Worked example: the transcript that became training data
A D2C brand on the Growth plan, paying ₹7,999 a month plus 18% GST, runs a support agent that handles WhatsApp queries. The transcripts are stored in a warehouse table called support_messages, tagged with purpose support.ticket.resolution, notice v2. Six months later the growth team wants a model that recommends products based on what customers complain about, and the easiest path is to fine-tune on those transcripts.
The fine-tune is a new purpose. The notice said resolution, not product personalisation, and no Section 7 legitimate use covers it. The team has three options. Re-consent a subset with a notice that names model training, which will produce a smaller and more motivated dataset. Build the recommender from order and catalogue data, which has its own purpose and probably already covers personalisation if the notice said so. Or use aggregate complaint categories with small cells suppressed, which supports prioritisation without individual records.
Whichever route is chosen, the schema makes the decision visible. A purpose claim on the training job that says support.ticket.resolution should fail the policy check, and the failure should be logged. That log entry is the control working. A system where the job succeeds because the service account has read access is the control that was never built, and the incident, when it comes, will be a question about why the exports exist rather than whether the model is any good.
Frequently asked questions
Does DPDP have a compatible purpose test like GDPR?
No. The Indian Act does not set out a general balancing exercise for secondary use. Processing is lawful because consent was given for that purpose, because another law requires it, or because the use falls within the legitimate uses listed in Section 7. A team that justifies a new use by arguing it is consistent with the original has imported a test the Act does not contain.
Can we use support transcripts to train a model?
Only if the purpose was declared or a fresh consent is obtained, or the data is genuinely aggregated. Training is a distinct purpose from resolving a ticket, and most notices do not mention it. The practical route is a consented subset, or an aggregate of complaint categories that contains no individual records. Check the processor terms too, since many tools train on customer content by default.
Is pseudonymised data still personal data?
Yes, if the mapping or the combination of remaining fields can re-identify a person. Replacing a name with an identifier while keeping the mapping, or keeping a precise address and timestamp, leaves the data personal and the purpose obligation intact. Anonymisation requires that re-identification is not reasonably possible in the context, including by linkage with other datasets.
How do we enforce purpose in a warehouse?
Three layers: a purpose code on every row written at ingest, a registry that defines each code with a notice version and basis, and a query layer that carries a purpose claim and filters or refuses rows outside it. Derived tables inherit the narrowest purpose of their inputs. Cross-purpose joins require a registered relationship. Coverage and orphan counts are reported monthly.
What counts as a new purpose?
Any use that a person would not recognise from the notice they were shown. Analytics, personalisation, model training, lookalike audiences, partner sharing and secondary marketing are the usual candidates. A useful test is whether the notice would have to change to describe it honestly. If yes, it is a new purpose, whatever the internal framing calls it.
Does purpose limitation apply to employee data?
Yes, with the Section 7 legitimate use for employment covering specified employment purposes. That does not authorise unlimited reuse. Monitoring, biometric attendance and performance analytics each need their own assessment, and the employment exemption is not a blanket permission to process anything about a member of staff for any reason.
How long should consent records be kept?
Longer than the marketing data they justify, because they are the evidence that the processing was lawful and the record that a withdrawal happened. Derive the period from limitation and audit needs rather than from campaign cycles, store them append-only, and exclude them from the retention sweep that deletes the campaign data.
What is a purpose code and how many do we need?
A stable identifier for a declared purpose, mapped to a notice version and a lawful basis, owned by a named person. Most mid-market companies need between ten and twenty. Sixty codes usually means four teams named the same purpose differently. Fewer, clearer codes are easier to enforce and much easier to explain to a customer or a reviewer.
Can we rely on legitimate use for analytics?
Rarely. Section 7 lists specific situations such as legal obligations, employment, medical emergencies, safety and certain public functions, plus research and statistics under conditions. General product analytics or marketing measurement is not on that list. If the notice did not cover it and consent was not taken, the analytics use needs a new basis rather than a reinterpretation.
How does purpose limitation interact with retention?
They are separate clocks. The purpose says why you may process, the retention says how long you may keep. When the purpose ends, the data should be erased or anonymised even if the retention period has not expired. When the retention period ends first, the data goes regardless of purpose. Both are enforced by different jobs, and both need an audit trail.