A processing purpose explains what an organisation is trying to achieve with personal data. It is the starting point for deciding which information is necessary, who should receive it, how long it should remain available and whether a later use is justified. A lawful basis answers a different question: which condition in data protection law permits that processing?
Under the EU General Data Protection Regulation, purposes must be specified, explicit and legitimate. This guide explains how to define them and assess changes, using the rules checked on 28 September 2026. The shorter purpose-limitation explainer introduces the principle; the task here is to turn it into a documented decision before collecting or reusing data.
Begin with the outcome, not the software
A system name is rarely a sufficient purpose. A CRM can support responding to enquiries, administering contracts, analysing service quality and selecting people for advertising. These activities may use overlapping records but involve different expectations, recipients and retention decisions. Recording only the software name obscures those differences and makes it difficult to explain why a particular field is needed.
Describe the intended outcome in relation to the people affected. For example, investigating disputed payments differs from using purchase histories to predict a customer’s income. Both may involve transaction records, but one does not follow automatically from the other. The fact that data are already available is a practical circumstance, not an independent justification for a new use.
The definition of personal data also matters at this stage. Removing a name does not necessarily take a dataset outside the GDPR if people remain identifiable through account numbers, combinations of attributes or information held elsewhere. A purpose assessment should therefore begin with the actual records and identifiability, rather than assuming that an internal label such as aggregated or de-identified settles the question.
Assign the decision to the right organisation. The controller and processor distinction identifies who determines purposes and essential means. A processor’s technical suggestion does not authorise a new purpose, and a supplier that wants to reuse customer data for its own product development needs a separate role and lawfulness analysis. Contractual permission alone is not a GDPR lawful basis.
Specified, explicit and legitimate are connected requirements
A specified purpose is defined with enough precision to assess the processing against it. The right degree of detail depends on context. A description can cover a coherent activity without listing every technical operation, but it should not bundle unrelated uses under phrases such as business improvement or any future services. Ask whether the wording helps decide if an additional field or recipient is within scope.
An explicit purpose is clearly expressed rather than left as an assumption known only to the organisation. Document it in the appropriate internal records and communicate it where required. A privacy notice saying something different from the operational record is a warning sign: either the processing has drifted or the explanation is incomplete. Both require investigation before the organisation relies on the wording.
Legitimacy is not confined to a profitable business objective. Public bodies, charities and researchers can pursue legitimate purposes, but the processing must comply with applicable law and the GDPR’s other requirements. A commercial benefit does not by itself make processing lawful. Conversely, a public-interest label does not remove the need to establish the applicable basis and safeguards.
The binding starting points are Articles 5 and 6 of the GDPR. Article 5 supplies purpose limitation alongside fairness, transparency, minimisation and storage limitation. Article 6 supplies lawful bases and the compatibility framework. Keeping these questions distinct prevents a common mistake: treating a convincing explanation of the objective as if it proves every processing operation is permitted.
Link each purpose to the appropriate lawful basis
Contractual necessity concerns a contract with the individual or steps taken at their request before entering one. A business cannot make an unrelated advertising use necessary simply by inserting it into general terms. Nor is an employee of a corporate customer automatically the contracting individual. Check the relationship and necessity of the processing rather than using contract as a default category for all commercial records.
A legal obligation must actually bind the controller and require the relevant processing. Record the provision, covered records and purpose rather than saying only compliance. A legitimate-interest basis requires identification of the interest, necessity and balancing against the person’s interests, rights and freedoms. These assessments can constrain the purpose even where the organisation considers the activity commercially useful.
Consent must be specific, informed, freely given and unambiguous, with additional requirements where explicit consent is relied upon. A broad statement about any future use cannot supply meaningful choice. The guide to valid consent and consent wording examples can help distinguish the consent decision from the separate privacy information. Withdrawing consent has consequences for that processing, so it should not be selected casually for operations that the organisation says it cannot stop.
Special-category data require an applicable Article 9 exception as well as the relevant Article 6 basis. Criminal-conviction data have their own Article 10 restrictions. A purpose that is compatible with an earlier activity does not dispense with those additional conditions. This is particularly relevant when a proposed analysis would reveal health, religious beliefs or other protected characteristics from otherwise ordinary records.
Make necessity visible in the data design
Once the purpose is clear, map the data needed to achieve it. For booking an appointment, a contact method and availability may be necessary, while a complete employment history probably is not. The reasoning should address fields, document contents and access permissions, not merely whole databases. A form can be redesigned to avoid collecting an unnecessary attachment in the first place.
Data minimisation asks whether the same objective can be achieved with less personal information or a less intrusive method. If a service-quality analysis only needs totals, giving analysts identifiable customer files needs further justification. If identity is needed to investigate a particular complaint, that does not imply it is needed for every management report derived from complaint statistics.
Set retention criteria at the same time. A purpose that ends after resolving an enquiry may not support retaining its full contents for years. A separate legal obligation or necessary claims-related purpose might support keeping selected records longer, but should be identified and restricted. A broad original purpose should not be used to conceal a later archive with no realistic deletion decision.
The official-source guide to minimisation and purpose limitation connects these principles. In practice, their interaction is useful: a precise purpose makes excess collection easier to identify, and a limited dataset makes it harder for an unrelated project to quietly appropriate old records.
Document purposes at the point of change
A record of processing activities helps connect purposes with data categories, recipients, transfers, retention and security. It should describe the processing that actually happens. If several departments share a system, each meaningful purpose should be traceable without pretending that every click is a separate activity requiring an independent entry.
Article 30’s exemption for organisations employing fewer than 250 people is qualified. It does not cover processing that is non-occasional, likely to result in a risk to rights and freedoms, or includes Article 9 or Article 10 data. The assessment concerns the relevant processing activities, not a general small-company exemption. Even when a formal record requirement does not apply to a particular activity, accountability still requires a defensible understanding of its purpose.
For a proposed change, record the original purpose and basis, the new objective, affected data and people, intended recipients, expected effects and the decision-maker. Keep the evidence on which the assessment rests, such as the original notice or consent wording. Otherwise, a later review may compare the new activity with a rewritten description that did not exist when the data were collected.
Change approval should involve the person who owns the activity, alongside the relevant legal, privacy and security expertise. This is a recommended governance method, not a prescribed committee structure. What matters is that an authorised person considers the legal and practical consequences before implementation, while someone can explain why the change was accepted or refused.
Apply the compatibility test to the actual new use
Article 6(4) addresses further processing for a different purpose where it is not based on the person’s consent or on Union or Member State law constituting a necessary and proportionate measure to safeguard the objectives in Article 23(1). Its listed factors guide the compatibility assessment. They are not a scoring exercise in which a favourable answer to one question automatically authorises the project.
First consider the link between the original and proposed purposes. Reusing delivery records to investigate a specific delivery failure has a closer connection to providing the service than selling those records to an unrelated advertiser. A connection is relevant but not decisive. The next questions concern the context, the data, possible consequences and safeguards.
The collection context includes the relationship between the individual and controller. Consider what people could reasonably expect when they provided the data and whether they had a meaningful choice. Employment, dependency and confidentiality can materially change the assessment. A person’s willingness to disclose information to obtain assistance does not imply willingness to have it repurposed for performance scoring or commercial targeting.
The nature of the data is another factor, with particular attention to special categories and criminal-conviction data. Assess the possible consequences as well: exclusion from an opportunity, unexpected disclosure, discrimination, distress or loss of control may matter even when the controller expects financial savings. Document plausible effects on people rather than restricting the analysis to technical security risks.
Finally, consider safeguards, including encryption or pseudonymisation where appropriate. Restricted access, reduced granularity and effective separation can alter the risk and support the assessment. They do not turn an incompatible purpose into a compatible one merely by being listed in a policy. Pseudonymised data remain personal data where re-identification is possible, so the legal analysis continues to apply.
A test database illustrates the distinction
In Digi, Case C-77/21, decided on 20 October 2022, the Court of Justice considered copying customer data into a database used for tests and correcting errors. The Court’s answer allowed compatibility to be assessed through Article 6(4)’s criteria, rather than treating every test copy as automatically incompatible. Its separate storage-limitation holding concerned keeping data longer than necessary for the testing and correction purpose.
The practical lesson is that authorising the creation of a test environment does not authorise indefinite retention. Identify the test objective, whether real data are necessary, who can access them and when the environment will be cleared. Synthetic or anonymised data may be suitable alternatives, depending on what is being tested. If real records are needed, safeguards and deletion decisions should be part of the approval.
The same approach applies to an internal analytics proposal. A project manager should explain the precise question and required records before data are copied. If the project later expands to a different objective, reassess that change. An approved experiment should not become a permanent production dataset simply because removing it would require coordination between teams.
Compatibility does not cure an unlawful starting point
Recital 50 explains that compatible further processing does not require a separate legal basis from the one permitting the original collection. That does not legitimise data that were unlawfully collected, override other conditions or authorise an unannounced expansion of consent. The original basis, its limits and the actual further use must be considered together.
Where consent is relied upon for the new purpose, obtain consent that actually covers it before beginning. A controller should not expand a narrowly consented purpose through an internal compatibility memo and continue as though the individual had agreed. Nor should withdrawal be neutralised by switching retrospectively to a different basis simply to keep the same processing going.
For incompatible further processing, Article 6(4)’s routes of new consent or qualifying Union or Member State law require careful examination. Merely assigning the label legitimate interests, vital interests or public task to the new project does not automatically override purpose limitation. Where legislation is relied upon, identify the actual measure and its conditions, including the necessary and proportionate character required by the provision.
This is also relevant to AI development. A proposal to use support messages to train a model needs assessment of its real purpose, data, people, basis and consequences. A technology label, claimed innovation benefit or legislative proposal does not itself authorise the processing. The decision must use the rules applicable to that activity when it starts, including any additional conditions for sensitive data.
Tell people before the further processing
Articles 13(3) and 14(4) require information about another intended purpose before the further processing, together with relevant additional information. Review which provision applies, including any applicable statutory exceptions, and explain the changed activity in a form the person can understand. Updating a notice after deployment does not satisfy a requirement that applies beforehand.
The information-notice guide covers the content, while Article 12’s transparency rules govern clarity and accessibility. The EDPB-endorsed transparency guidelines explain why material changes need to be brought effectively to people’s attention. A sentence instructing users to check a website periodically is not a reliable method of explaining a new purpose.
Notice and permission are different. Telling someone about a new use cannot make incompatible processing lawful. Equally, a compatible use can still breach transparency obligations if the required information is omitted. Where people have choices or a right to object, the communication should make those routes usable and the internal process should be able to honour them.
Research and statistics require their own safeguards
Article 5(1)(b) provides that further processing for archiving in the public interest, scientific or historical research, or statistical purposes is not considered incompatible when carried out in accordance with Article 89(1). This is a conditional rule, not a blanket exemption for anything an organisation calls research. The nature of the activity and safeguards must support the classification.
Article 89(1) requires appropriate technical and organisational safeguards, particularly to respect minimisation. These may include pseudonymisation where the purpose can be achieved that way; where the purpose can be fulfilled without permitting identification, it must be fulfilled in that manner. The lawful basis, special-category conditions and applicable transparency duties remain relevant.
A business dashboard used to decide how to treat identified customers should therefore not be assumed to qualify merely because it contains statistics. Distinguish producing statistical results from making individual decisions using those results. Any longer retention also needs the conditions of storage limitation and the research or archival provisions, rather than an indefinite research label attached to an ordinary customer database.
What happens when the decision is wrong?
A supervisory authority can require processing to stop or change, order other corrective measures and, where appropriate, impose a fine. Infringements of the GDPR’s basic principles fall within Article 83(5)’s upper tier: up to €20 million or, for an undertaking, 4% of worldwide annual turnover for the preceding financial year, whichever is higher. These are legal ceilings, not automatic penalties or predictions for a particular project. The GDPR fines guide explains the assessment context.
If an unapproved use is discovered, identify its scope, recipients and ongoing effects, then assess how to stop or regularise future processing lawfully. Do not rewrite the original purpose to make the history look consistent. Preserve the evidence needed to understand what happened, consider the person’s rights and assess separately whether any security incident also constitutes a reportable personal-data breach.
Can we write a purpose broadly enough to cover anything?
No. It must be sufficiently specified and explicit to guide the processing and inform the individual. A coherent activity may cover several necessary operations, but undefined future opportunities do not provide that boundary.
Does every new marketing use require GDPR consent?
Not invariably: the applicable basis depends on the processing, and electronic marketing can involve separate channel-consent rules. The new use must still satisfy purpose limitation, transparency and the relevant right to object. Neither marketing nor consent should be treated as a shortcut around that analysis.
Does a compatible purpose mean the data can be kept forever?
No. Compatibility and storage limitation are separate requirements. Define when the purpose ends, identify any justified further retention and remove or appropriately anonymise records that are no longer needed.