Purpose limitation and data minimisation answer different questions about the same processing. Under GDPR Article 5(1)(b), why is the controller collecting the data, and is a later use compatible with that reason? Under Article 5(1)©, which data is adequate, relevant and limited to what that reason actually needs? The European Commission’s explanation of the GDPR principles and the Regulation on EUR-Lex are the official starting points. A form can have a lawful basis and still collect too much information or silently use it for a different purpose.
These principles are practical design constraints. A controller should be able to trace a field on a form to a defined purpose, explain who receives it, and decide what happens when someone proposes a new use. The answer may require changing the field, the workflow, the notice, the legal analysis or the proposed use itself. The purpose-limitation explainer examines the legal concept; this guide shows how to apply it alongside data minimisation to a working process.
Define a purpose that can guide decisions
Article 5(1)(b) requires collection for specified, explicit and legitimate purposes, and forbids further processing in a manner incompatible with them. “Business operations” is too broad to decide whether a customer address may be used for delivery, marketing, fraud screening or sale to another company. “Deliver the order and handle returns” gives staff a more useful boundary. A single service can have several purposes, but they should be separated when their lawful basis, recipients, data or retention differ.
A purpose should describe the result of an activity, not just a database or department. “CRM” describes a tool; “respond to a prospect’s requested quotation” describes a purpose. “Improve services” may hide several distinct operations, such as testing a new feature, measuring failures and training a recommendation model. Each may need different data. Write purposes at a level that allows a reader to predict the use and allows the team to reject an unrelated use. The Article 6 lawful-basis guide then helps establish the ground for each defined activity.
Make the purpose visible to people through the appropriate Article 13 or 14 information. An internal record that says “target advertising” while the notice says only “provide our service” is a warning that the use has not been described transparently. The notice should reflect the real workflow, and the workflow should remain within the notice and the legal analysis. The GDPR information-notice guide helps test whether purposes are intelligible to the people concerned. The ROPA field guide can hold the same purpose in the controller’s processing record without substituting for information owed to individuals.
Test each category and field against the purpose
Article 5(1)© uses three linked terms. Data must be adequate: enough to achieve the purpose. It must be relevant: connected to it. It must be limited to what is necessary: remove information that is merely interesting or convenient if the task works reasonably without it. These tests operate at collection and throughout use. A controller cannot justify collecting excessive data because it promises not to look at it often.
Consider a webinar registration. A contact address and an accessibility request volunteered by the attendee may be relevant to sending access details and arranging participation; a compulsory home address and full birth date ordinarily need a separate explanation. If a minimum age rule applies, perhaps an eligibility confirmation is enough. If invoicing applies to a paid course, billing details may serve that specific purpose, but they should not automatically be copied into the attendance list. A single form can expose where purposes were combined for convenience rather than necessity.
Test source fields, derived fields and hidden collection. An analytics SDK may gather device identifiers the visible form never asks for. A support platform may copy every attachment to an external search index. A deletion request may remove a row while keeping the same data in an export. Map the operation end to end. Where an anonymous or less precise answer can serve the purpose, consider that option. The Commission guidance explicitly recommends using anonymous data where possible and assessing the amount needed; it does not impose one universal “fewest fields” number for every service.
Separate minimisation from storage limitation and security
The principles reinforce one another but are not identical. Article 5(1)(e) addresses how long identifiable data is kept. Article 5(1)(f) and Article 32 concern security. A field may be necessary to complete an order but unnecessary to keep indefinitely. A secure, encrypted copy of an unnecessary field is still unnecessary. Conversely, deleting a field immediately can make a service unusable when a lawful warranty or claim process genuinely requires it for longer. The storage-limitation guide helps define retention triggers after the collection decision.
Document a separate period or review trigger where purposes diverge. A paid order may require records for accounting under applicable national law, while a support transcript may be needed only while the issue is open and for a justified follow-up period. Do not choose the longest period for the whole dataset merely because one field has a legal retention duty. Configure access so that information retained for accounting does not remain in a marketing list. If the team proposes deletion exceptions, identify the legal or operational reason for each one and the copy to which it applies.
Special-category data under Article 9 deserves particular attention. Health or biometric data may be necessary in some services, but its collection needs an Article 9 condition in addition to the ordinary Article 6 basis and other GDPR duties. If an open-text box invites such information unexpectedly, change the prompt or handling route. The special-categories guide helps distinguish deliberate use from accidental overcollection. Do not infer that sensitive data can never be processed; determine whether the purpose, condition and safeguards justify it.
Assess a proposed new use before moving the data
A controller may later want to reuse existing information. Article 6(4) identifies factors for assessing compatibility when the new processing is not based on consent or a Union or Member State law meeting its conditions. Examine the link between the original and new purposes; the context of collection and relationship with the person; the nature of the data, including Article 9 or 10 information; the possible consequences for people; and safeguards such as encryption or pseudonymisation. The Commission’s official principles page describes these factors and gives examples.
The factors are not a simple numerical score. A close relationship between purposes cannot erase severe consequences or surprising disclosure. Conversely, a modest internal analysis may be compatible where the original relationship, clear notice, data minimisation and safeguards support it. Record the original collection notice and basis before deciding. A compatibility finding is not permission to ignore transparency, special-category conditions or the rights of the people concerned. The proposed new operation must be described and governed in its own right.
Imagine a repair company collecting a customer’s address to send a technician. It proposes to analyse neighbourhood demand using broad geographic areas without names; that may be possible with much less personal data than its original service record. Later it proposes giving identifiable addresses and repair histories to an advertising partner. The different recipient and commercial purpose materially change the compatibility analysis. Do not treat “both uses are about customers” as sufficient. Consider whether genuine anonymisation can answer the business question before seeking a new basis for a more intrusive use.
The original article treated every incompatible use as curable by picking another Article 6 basis, “typically consent.” That is too quick. Where the reuse is incompatible, the controller must examine whether consent or qualifying Union or Member State law permits it under the Regulation, and whether any other applicable rule allows the processing. A convenient newly selected basis does not automatically defeat the purpose-limitation principle. If there is no proper route, do not perform the reuse. Seek case-specific advice where the proposed use is important and the relationship between purposes is disputed.
Research and statistics have a conditional rule
Article 5(1)(b) states that further processing for archiving in the public interest, scientific or historical research, or statistical purposes is not considered incompatible with the initial purposes in accordance with Article 89(1). Article 89 requires appropriate safeguards for people’s rights and freedoms, particularly measures ensuring data minimisation; pseudonymisation is one possible measure when the purpose can be met that way. This is a conditional compatibility rule, not a blanket permission to label a marketing project “research” and reuse all customer records.
Determine whether the proposed operation truly has the stated research, statistical or archiving purpose. Ask whether identifiable data is needed, who can access it, whether outputs could reveal individuals, how data will be separated from operational records and what applicable national rules require. Check legal basis, Article 9 conditions where relevant, transparency and retention separately. If the data can be anonymised for the purpose, keeping direct identifiers may be hard to justify. The Commission guidance explains the compatibility treatment and emphasises safeguards; it does not remove the rest of the GDPR.
Turn the assessment into a field and purpose map
Begin with one ordinary workflow and list purposes as distinct rows. For each, record the person category, inputs, generated data, legal basis, Article 9 condition if applicable, recipients, access roles, retention trigger and the notice text that describes the activity. Then pick one field at a time: what breaks if this field is removed, made optional, generalised or collected later? The answer may reveal that an apparently required field serves a different purpose than the form title suggests.
Review real examples, not only the approved schema. Inspect the public form, mobile app, APIs, event logs, exports, vendor integrations and the operational instructions used by staff. A field could be optional on screen but mandatory in an API; a support agent might paste identity documents into notes because no safer verification process exists. Address the cause instead of simply deleting the example record after an audit. Record the owner and next action for unresolved fields so that “to be assessed” does not become an indefinite exception.
For a proposed new use, write a short compatibility note before deployment. Describe the old and new purpose, facts for each Article 6(4) factor, likely impact on people, safeguards, conclusion, decision owner and any additional legal basis or notice work. This need not be a lengthy template for every minor change. Its value is that the team can later explain why data moved, and can reopen the decision if the recipient, dataset or analytic method changes. Link the note to the privacy-by-design review where defaults or architecture are affected.
Common questions in a review
Can one lawful basis cover all uses of a dataset? A lawful basis attaches to a specified processing purpose; the fact that the same database holds several activities does not merge them. Separate collection, delivery, support, fraud prevention and marketing where their legal and practical conditions differ. Must every field be the smallest technically possible value? The test is whether the data is adequate, relevant and limited to what is necessary for the particular purpose, considering feasible less intrusive methods. An emergency contact service may need more detail than a newsletter form.
Does encryption justify collecting more? It can reduce risk but cannot make an unrelated field necessary. Can the team keep information “for future use”? A speculative future benefit is not a specified purpose. Define the use before collecting or retaining data for it. Does a research label make reuse automatically lawful? No; the Article 5(1)(b) rule depends on Article 89 safeguards and leaves other GDPR requirements in place. Who should approve a compatibility assessment? Assign a person with authority over the processing decision and involve the DPO where designated. The record should show the facts and reasoning, not only a signature; the accountability principle asks the controller to be able to demonstrate compliance.
Article 83(5)(a) places infringements of basic processing principles, including Article 5, in the higher statutory fine tier. That is a maximum framework, not a predicted penalty for a particular form field. Earlier versions of this page attached unrelated headline fines to specific purpose or minimisation findings without case-specific proof. The practical reason to do the analysis is simpler: it prevents surprising reuse and unnecessary data collection, and lets a controller demonstrate why its workflow processes the information it does. Revisit the official GDPR principles when changing a purpose or field, rather than relying on a generic checklist alone.