Under the GDPR, processing personal data requires more than a useful business purpose. Controllers need a lawful basis under Article 6, and the choice should reflect what the processing actually requires rather than whichever label seems easiest. Consent is only one option. Contract, legal obligation, vital interests, public task, and legitimate interests can also apply, but each has boundaries and consequences.
This is a foundational topic for IAPP CIPP/E and the European privacy side of the IAPP certifications. The practical skill is to connect purpose, relationship, necessity, expectations, and data-subject rights. A lawful basis should be identified before processing begins, documented, reflected in the privacy notice, and revisited when the purpose or context changes.
Article 6 provides six different legal paths
Article 6(1) lists six lawful bases for processing personal data. Consent applies when the data subject has given valid permission for one or more specific purposes. Contract applies when processing is necessary to perform a contract with the individual or to take steps at the individual’s request before entering a contract. Legal obligation applies when processing is necessary to comply with a legal duty that binds the controller.
Vital interests can justify processing necessary to protect someone’s life or another fundamental interest in an emergency-type context. Public task covers processing necessary for a task carried out in the public interest or in the exercise of official authority. Legitimate interests can apply when processing is necessary for the legitimate interests of the controller or a third party, provided the individual’s interests or fundamental rights and freedoms do not override those interests.
These bases are not interchangeable labels. The facts determine which basis fits. A company should not choose consent merely because it is familiar, or legitimate interests merely because it seems flexible. The choice affects transparency, objection rights, withdrawal, and how the controller must justify necessity.
Consent requires genuine choice and control
GDPR consent must be freely given, specific, informed, and unambiguous. In situations involving sensitive categories of data or certain other contexts, explicit consent may be required under a separate legal rule. Consent must also be demonstrable, and individuals must be able to withdraw it as easily as they gave it.
The most common operational mistake is using consent where there is no realistic choice. If a service refuses to perform its core function unless a person agrees to unrelated processing, the consent may not be freely given. Employment relationships and other power imbalances can create similar concerns. Bundled purposes are another problem: agreeing to one necessary activity should not silently authorize unrelated advertising, profiling, or data sharing.
Consent can be appropriate for optional features, marketing in certain contexts, or genuinely elective uses. But it creates lifecycle obligations. Systems need to record the scope and version of consent, propagate withdrawal, stop future processing where required, and ensure downstream systems honor the change. A checkbox without operational enforcement is not a meaningful consent control.
Contract is narrower than “mentioned in the terms”
Contractual necessity applies when the processing is objectively necessary to perform a contract with the data subject or to take requested pre-contractual steps. A retailer needs an address to deliver a purchased product. A payment service needs transaction information to execute a payment. Those processing activities are closely tied to the service the person requested.
Putting a processing purpose into contractual terms does not automatically make it necessary. Behavioral advertising, broad analytics, or unrelated profiling may benefit the company without being required to perform the contract. The controller should be able to explain why the service cannot reasonably be delivered without the processing.
This distinction matters because the lawful basis is tied to necessity, not drafting technique. If an organization could provide the contracted service without the processing and the processing serves a separate objective, another basis may be more appropriate. Treating every clause in a terms-of-service document as “contract necessity” risks turning the basis into a loophole.
Legal obligation and public task depend on an external legal foundation
Legal obligation applies where EU or member-state law requires the controller to process personal data. Examples can include employment, taxation, financial-record, or regulatory reporting duties depending on the jurisdiction and organization. The controller should identify the relevant legal requirement rather than state vaguely that “compliance” makes the processing necessary.
Public task and official authority likewise require a basis in law. They commonly apply to public authorities and organizations carrying out functions established in the public interest. The law should define the task or authority sufficiently for the processing to be grounded in it.
These bases demonstrate an important GDPR principle: necessity is contextual. A controller should process what is needed for the legal duty or public task, not treat the basis as unlimited permission for adjacent uses. Purpose limitation and data minimization continue to apply even when the lawful basis is strong.
Vital interests are important but comparatively narrow
Vital interests are associated with protecting life or similarly fundamental interests when processing is necessary. The basis can be relevant in medical emergencies, disasters, humanitarian situations, or circumstances where a person cannot provide consent and urgent action is required.
It is not a general safety exception for ordinary business convenience. Where another lawful basis can reasonably govern routine processing, organizations should not stretch vital interests merely because the processing has some connection to well-being. The recitals and regulatory guidance treat the basis as important but exceptional.
When vital interests are used, the organization should document the emergency context, why the processing was necessary, and why another basis was not practical. That record helps show that the basis was chosen because of the circumstances rather than because normal governance was bypassed.
Legitimate interests require purpose, necessity, and balancing
Legitimate interests is often the most misunderstood basis. It is not “we have a legitimate business.” The analysis asks three connected questions. First, what legitimate interest is being pursued? Second, is the processing necessary for that interest, meaning the purpose cannot reasonably be achieved in a less intrusive way? Third, do the individual’s interests, rights, or freedoms override the controller’s interest?
That balancing stage considers reasonable expectations, relationship, data sensitivity, scale, impact, safeguards, and whether the individual is in a vulnerable position. Children receive particular protection. Transparency, data minimization, pseudonymization, access controls, easy objections, and other safeguards can reduce impact, but safeguards do not rescue a processing activity whose basic balance is unfavorable.
The European Data Protection Board’s published Guidelines 1/2024 (Version 1.0) on Article 6(1)(f) reinforce the need for a structured assessment. Many organizations document this reasoning in a legitimate interests assessment. The document is not a magic form; its value comes from showing the purpose, alternatives considered, expected impact, safeguards, and final balance.
Purpose limitation can change the answer later
A lawful basis is evaluated in relation to a purpose. Collecting customer contact information to deliver a service does not automatically authorize every later use. When a controller wants to process the same data for a new purpose, it must determine whether the new use is compatible with the original purpose or whether a new legal analysis is required.
Compatibility assessment can consider the link between purposes, the context in which data was collected, the nature of the data, possible consequences for people, and safeguards. A surprising secondary use is more difficult to justify than one a person could reasonably expect from the original relationship.
This is where governance must connect legal analysis to system architecture. Data warehouses, analytics platforms, AI pipelines, and shared customer profiles can make reuse technically easy. Technical availability is not the same as legal compatibility. Personal data in machine-learning workflows shows how a new technical purpose can create a new privacy analysis even when the underlying records already exist.
Special-category data requires an additional condition
Article 6 is not the whole analysis when processing involves special categories of personal data such as certain health, biometric, genetic, political, religious, or trade-union information. Article 9 generally prohibits that processing unless a specific exception applies. In practice, a controller normally needs both an Article 6 lawful basis and an applicable Article 9 condition.
That two-layer structure is easy to miss. An organization might have a legitimate interest in preventing fraud, for example, but that does not automatically authorize processing biometric or health information. The special-category condition must be analyzed separately, along with any national law that adds requirements.
Criminal-offence data has its own rules under Article 10. Sector-specific rules, ePrivacy requirements, employment law, and member-state provisions can also affect the analysis. CIPP/E-level reasoning therefore requires more than memorizing the six Article 6 labels; it requires recognizing when another legal layer changes what is permitted.
Document the basis and make the system enforce it
Controllers should record the purpose, lawful basis, reasoning, and relevant safeguards before processing begins. Privacy notices should accurately describe the basis, and systems should support the rights that follow. If consent is withdrawn, the organization needs a way to stop consent-based processing. If legitimate interests is used, objection handling becomes particularly important.
Lessons from GDPR privacy enforcement show why a lawful-basis decision cannot live only in a spreadsheet. Retention, access, purpose restrictions, marketing preferences, deletion, and downstream sharing all need technical and operational controls.
A good lawful-basis analysis therefore has a simple test: could the organization explain the purpose, why the selected basis fits, what limits apply, and how those limits are enforced in production? If the answer depends on vague language such as “business needs” or “users agreed to our terms,” the analysis probably needs more work.