Purpose limitation: when a new use of personal data needs a fresh decision
A practical guide to purpose limitation under the GDPR: how to define the original purpose, test secondary uses, and document decisions before data is reused.
A privacy team is often asked a deceptively simple question: “We already have the data. Can we use it for this too?” Purpose limitation is the rule that stops the answer from being “yes” by default.
Under Article 5(1)(b) of the EU General Data Protection Regulation, personal data must be collected for specified, explicit and legitimate purposes and must not later be processed in a way that is incompatible with those purposes. The rule has two parts: describe the original reason clearly enough to constrain later use, then test any new use against that reason. 1
That makes purpose limitation a design and governance control, not just a privacy-notice requirement. It affects what a product team may add to an existing dataset, what a procurement team may let a vendor do, and whether an analytics or machine-learning project can proceed without a fresh decision.
What the principle actually limits
A purpose is the outcome the organisation is trying to achieve with the processing. “Customer support,” “fraud prevention,” and “sending a requested invoice” are purposes. “The CRM database” and “all information we hold about the customer” are not. The first set describes a reason for use; the second describes a container or a volume of data.
The three adjectives in Article 5(1)(b) do practical work:
- Specified means the purpose is concrete enough to guide a decision about what data may be used and what later uses are out of bounds.
- Explicit means the organisation has stated the purpose rather than leaving it implicit in a system design or an internal assumption.
- Legitimate means the purpose is not unlawful or contrary to applicable legal requirements.
The original purpose is not a permanent licence for every use that might be convenient later. A support address collected to resolve a ticket may be useful for a service announcement, product analytics, identity verification, or marketing. Those uses are different questions, even when the same team owns the system and the same email field is involved.
Purpose limitation is also not a substitute for the other principles. A new use can be compatible with the old one and still fail because the data is excessive, inaccurate, kept too long, processed without a lawful basis, or insufficiently secured. The ICO describes the principles as the foundation of the UK GDPR and notes that accountability requires the controller to be able to demonstrate compliance, not merely assert it. 2
The workplace decision: reuse, or start again?
When a team proposes a secondary use, do not begin with the question “Which lawful basis can we attach to it?” Begin by writing down the old and new purposes in plain language.
For example:
Original purpose: deliver a customer’s order and provide support about that order.Proposed new purpose: build a model that predicts which customers are likely to buy a premium accessory.
The second purpose is not automatically compatible with the first. It changes the business objective, the customer expectation, the likely effect on the person, and possibly the people who can access the data. A lawful basis is necessary, but it does not make every new objective fit inside the first one.
Article 6(4) gives controllers the factors to consider when processing for a purpose other than the one for which the data was collected, unless the further use is based on the data subject’s consent or on qualifying Union or Member State law. The list is explicitly non-exhaustive, so it is a decision framework rather than a mechanical scorecard. 1
Five questions to answer
- How close are the two purposes? Is the new use a necessary step in delivering the original service, or does it create a new commercial, security, research, or profiling objective? A receipt generated from a purchase is close to the purchase. A behavioural advertising profile built from the same purchase is a different proposition.
- What did the person reasonably expect? Consider the relationship, the place and context of collection, and what the service appeared to promise. A person who submits an address to receive a parcel may expect delivery updates; they may not expect that address to enter a marketing audience or a general-purpose AI training set.
- What is the nature of the data? The risk rises when the reuse involves special-category data, criminal-offence data, precise location, children’s data, financial information, or data that becomes sensitive when combined with other fields. The fact that the organisation already possesses the data does not make its nature less sensitive.
- What could happen to the person? Ask what a wrong inference, disclosure, denial, ranking, or contact could mean in practice. A new use that changes a person’s access to credit, employment, insurance, housing, healthcare, or essential services deserves more caution than a low-impact internal report.
- What safeguards are actually in place? Encryption and pseudonymisation are examples named in Article 6(4), but a safeguard is not a magic compatibility pass. Record who can access the reused data, whether identifiers are removed, how outputs are tested, how long the copy exists, and how a person can exercise their rights. 1
The quality of the answer matters more than the existence of a template. “Same controller, same database, low risk” is not an analysis of these five questions.
Where the rule appears in real product work
Account creation is a good boundary test. The EDPB’s recommendations on mandatory user accounts distinguish the purpose of buying something from optional account features such as order history, easier repeat purchases, loyalty programmes, or personalised offers. The recommendations state that guest mode and voluntary account creation are not purposes in themselves, and describe guest checkout as a way to avoid creating a personal digital environment when authentication is not needed. 3
That is a practical design lesson: do not make a secondary purpose look necessary by putting it in the core flow. If a customer can complete a purchase without an account, the account’s extra uses should be presented as extra uses. They should not be smuggled into “checkout” as though they were part of delivery.
The same EDPB recommendations say that tax and accounting records may need to be stored separately with restricted access, rather than leaving all data used to create an invoice in the main customer-relationship system. They also say guest-purchase data should not enter the general CRM unless a relevant purpose and valid legal basis justify that storage. 3
The pattern applies beyond ecommerce:
- A support dataset may be reused to measure response quality, but that does not automatically authorise employee surveillance or customer marketing.
- A security-log dataset may support incident detection, but a proposal to use it for productivity scoring is a new purpose with different expectations and consequences.
- A research dataset may support the study for which it was collected, but a request to train a general-purpose model should be described separately and assessed on its own facts.
- A vendor-held dataset does not become unrestricted because the vendor is already a processor. The contract, instructions, role allocation, transparency, and purpose must still match the proposed processing.
These are decision prompts, not automatic legal conclusions. The facts, sector rules, national law, and the lawful basis may change the answer.
Common mistakes that look like compliance
“Business purposes” is not a purpose
A phrase such as “to improve our services and for business operations” is too broad to do useful boundary work. It cannot tell an engineer whether a new feature is in scope or tell a reviewer why a proposed reuse is compatible. Write the operational outcome instead: “identify duplicate support tickets,” “send shipment updates,” or “detect account takeover attempts.”
A privacy notice cannot repair an undefined decision
Adding a new sentence to a notice after a project has already chosen the data is not the same as deciding whether the reuse is compatible. The organisation still needs to examine the relationship between purposes, context, data, consequences, and safeguards. Notice is part of transparency; it is not a substitute for purpose limitation.
A new lawful basis is not a universal reset button
If the organisation relies on fresh consent or a specific law for the further processing, Article 6(4)’s compatibility wording works differently. But the rest of the GDPR does not disappear. The new processing still needs to meet the applicable principles, lawful-basis conditions, transparency and rights requirements, and any extra rules for sensitive data. Recital 50 also says that people must be informed about the other purposes and their rights. 1
“We already have it” hides the real change
The expensive part of a reuse is often not copying the data. It is changing who can see it, what is inferred from it, how long it remains available, and what decisions it may influence. Treat the proposed purpose as a new processing activity even when the storage location does not change.
Security controls do not make an incompatible purpose compatible
Access restrictions, encryption, and pseudonymisation reduce risk. They do not turn marketing into customer support or employment monitoring into security logging. First decide whether the purpose fits; then use safeguards to reduce the impact of the processing that remains.
A compact record to keep
Before approving a secondary use, record these fields in the project’s privacy or data inventory:
- the original purpose, collection context, and notice shown to the person;
- the proposed new purpose and the business decision it enables;
- the link between the two purposes and the expectation the person would reasonably have;
- the exact data fields, including any sensitive data or meaningful combinations;
- likely consequences for people and the controls that reduce them;
- the lawful basis, retention period, access boundary, processor instructions, and rights path;
- the decision, its reasoning, the owner, and the date for review.
This record is useful even when the answer is “compatible.” It makes the boundary visible to product, engineering, procurement, security, and audit teams. It also makes a later change easier to spot: if the objective, dataset, audience, or impact changes, the purpose decision should be reopened.
Purpose limitation is therefore best understood as a refusal to let data acquire new meaning silently. The practical question is not whether the organisation can technically reuse a field. It is whether the new objective still fits the reason the person was asked to provide it—and whether the organisation can show its work.
References
- 1Regulation (EU) 2016/679, Article 5(1)(b)
eur-lex.europa.eu
- 2
- 3
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.