Every processing activity under GDPR must be built on a foundation of lawfulness. Article 5(1)(a)’s requirement that personal data be processed lawfully is not satisfied by good intentions, privacy notices, or security measures — it requires a specific, documented legal ground from the closed list in Article 6. Without that ground, the processing is unlawful, and no level of operational excellence in other areas can remedy that fundamental deficiency.
This article examines what makes processing lawful in detail: how to analyse and select the correct basis for each processing activity, the heightened standards that apply to consent, the interaction between lawful basis and data subject rights, and the practical documentation requirements that satisfy the accountability principle. It also addresses the most consequential mistake in lawful basis management — changing the stated basis after processing has begun.
The Six Bases: A Comparative Overview
Article 6(1) provides an exhaustive list. One — and only one — must apply to each distinct processing activity. If none of the six applies, the processing cannot be made lawful by any other means. No contractual arrangement, no internal policy, no business necessity can substitute for an Article 6 basis.
ARTICLE 6 — LAWFUL BASES COMPARISON
| Basis | When It Applies | Data Subject Can Object? | Portability Right? | Right to Erasure? |
|---|---|---|---|---|
| (a) Consent | Freely given, specific, informed choice | N/A — can withdraw | Yes | Yes — on withdrawal |
| (b) Contract | Necessary to perform or prepare a contract | No | Yes | No — unless processing ends |
| (c) Legal obligation | Required by EU/member state law | No | No | No — law requires retention |
| (d) Vital interests | Protect life; no other basis available | No | No | Limited |
| (e) Public task | Official authority / public interest task | Yes | No | Limited |
| (f) Legitimate interests | Proportionate commercial/org interests | Yes (Art. 21) | No | Yes — if objection upheld |
Consent: The Most Misunderstood Basis
Consent is frequently chosen by organisations as the ‘default’ lawful basis, on the assumption that asking permission is always the safest approach. This assumption is wrong, and it creates operational and compliance problems that are difficult to unpick. Consent is the appropriate basis for a narrow category of processing — genuinely optional activities where individuals have a real choice — not a universal solution for any processing where another basis has not been identified.
GDPR’s consent standard under Article 7 and Recital 32 is significantly more demanding than pre-GDPR consent practices. The gap between what many organisations collected as ‘consent’ before 2018 — pre-ticked boxes, bundled terms, conditional service access — and what GDPR requires is substantial. Many organisations that relied heavily on consent as their primary lawful basis had to rebuild their entire consent infrastructure from scratch when GDPR came into force.
The Seven Conditions for Valid GDPR Consent
Valid consent under GDPR requires all seven of the following conditions to be satisfied simultaneously. Failure to meet any single condition invalidates the consent for the purpose it relates to.
GDPR CONSENT — SEVEN VALIDITY CONDITIONS
| Condition | What It Requires | Common Failure |
|---|---|---|
| 1. Freely given | Genuine choice; no detriment for refusing; not bundled with terms | Consent tied to service access; take-it-or-leave-it interfaces |
| 2. Specific | Separate consent per distinct purpose; no blanket coverage | Single checkbox covering multiple unrelated processing activities |
| 3. Informed | Clear explanation of who, what, why before consent is given | Vague or post-hoc consent notices; links buried in terms |
| 4. Unambiguous | Clear affirmative action — no silence, inactivity, or pre-ticked boxes | Pre-checked consent boxes; scroll-to-agree mechanisms |
| 5. Withdrawable | As easy to withdraw as to give; no penalty for withdrawal | No visible opt-out; complex multi-step withdrawal process |
| 6. Demonstrable | Controller can prove consent was given, when, and to what | No consent records; consent captured without audit trail |
| 7. Explicit (for special categories) | Explicit, active confirmation for Art. 9 special category data | Generic consent covering health/biometric data processing |
Power Imbalance and Freely Given Consent
Recital 43 of GDPR raises a specific concern about consent in situations of clear imbalance between the data subject and the controller. It states that consent should not provide a valid legal ground for processing where there is a clear imbalance between the data subject and the controller, in particular where the controller is a public authority and it is therefore unlikely that consent was freely given in all the circumstances of that specific situation.
This imbalance concern extends to employment relationships. The EDPB’s Guidelines on Consent (05/2020) state that it is highly unlikely that public sector employees and many private sector employees can freely give, refuse, or revoke consent given the dependency resulting from the employer-employee relationship. Consent from employees for processing that the employer could otherwise justify under contract or legal obligation is generally not valid GDPR consent. Organisations that use employee consent as the basis for standard HR processing — payroll processing, performance management, workplace monitoring — are typically on the wrong basis.
| IMPORTANT | The employer-employee power dynamic makes employee consent unreliable for most HR processing. If an employee’s refusal of consent could have negative employment consequences — even implicitly — the consent is not freely given. Most employment-related processing should be based on contract (necessary for the employment relationship), legal obligation (statutory employment and tax law), or legitimate interests (legitimate HR management purposes), not on consent. |
Consent in Digital Interfaces: Common Failures
The vast majority of consent-related enforcement actions relate to the way consent is requested in digital interfaces — websites, apps, and connected products. DPAs have investigated and sanctioned a consistent set of design patterns that fail to meet GDPR’s consent standard.
DARK PATTERNS — CONSENT INTERFACE FAILURES IDENTIFIED BY DPAs
| Pattern | Why It Fails | DPA Action |
|---|---|---|
| Pre-ticked consent boxes | Inaction is not affirmative action (Recital 32) | Prohibited across all EU jurisdictions |
| Accept all / Reject all asymmetry | ‘Reject’ requires more clicks than ‘Accept’ — nudges consent | Google €150M (France, 2022); IAB cases |
| Consent bundled with terms of service | Consent not freely given if tied to service access | Widespread DPA enforcement 2019–2024 |
| No reject option on cookie banner | Must be as easy to refuse as to accept | French CNIL; Belgian DPA findings |
| Consent notice appears after processing begins | Consent must precede processing, not follow it | Identified in multiple national investigations |
| Consent notice in illegible or ambiguous language | Consent must be informed; plain language required | Routine finding in DPA investigations |
| Withdrawal buried in account settings | Withdrawal must be as easy as consent was to give | Identified in EDPB consistency opinions |
Consent Records: What Must Be Captured
Article 7(1) places the burden of demonstrating consent on the controller. This means that for every processing activity based on consent, the controller must be able to produce evidence that valid consent was obtained from each individual whose data is processed on that basis. A statement in a privacy policy that ‘we rely on consent for X’ is not evidence of actual consent — it is a statement of policy. What is required is an individual-level record.
MINIMUM CONSENT RECORD FIELDS
| Field | Purpose | Retention |
|---|---|---|
| Data subject identifier | Link consent record to individual | Duration of processing + 3 years |
| Timestamp of consent | Establish when consent was given | Duration of processing + 3 years |
| Version of consent notice shown | Prove individual saw the correct notice | Duration of processing + 3 years |
| Purpose(s) consented to | Scope of consent — prevents overreach | Duration of processing + 3 years |
| Method of consent (checkbox, signature, etc.) | Evidence of affirmative action | Duration of processing + 3 years |
| IP address / session identifier (where relevant) | Technical evidence of consent action | Duration of processing + 3 years |
| Withdrawal timestamp and method (if withdrawn) | Demonstrate withdrawal was processed | 3 years post-withdrawal |
Legitimate Interests: The Balancing Assessment in Practice
Legitimate interests under Article 6(1)(f) is the most analytically complex basis to apply correctly, but it is also the most practically useful for commercial organisations. It covers a wide range of processing activities that do not fit cleanly into contract, consent, or legal obligation — fraud prevention, direct marketing to existing customers, intra-group data sharing, network security, and many analytics and operational activities.
Applying legitimate interests requires completing a three-stage Legitimate Interests Assessment (LIA) before processing begins. The LIA is not a formality — it is the analytical and evidential foundation for the lawful basis. A poorly constructed LIA, or one that is created retrospectively after a data subject rights request, provides thin protection in enforcement proceedings.
LEGITIMATE INTERESTS ASSESSMENT — THREE-STAGE FRAMEWORK
| Stage | Question | Key Considerations |
|---|---|---|
| 1. Purpose test | Is there a legitimate interest? | Must be real and lawful; not merely commercially convenient; covers controller’s own interests and third parties’ interests |
| 2. Necessity test | Is the processing necessary for that interest? | Less intrusive means must have been considered and found inadequate; processing must be targeted and proportionate |
| 3. Balancing test | Do the data subject’s interests override? | Nature of data; reasonable expectations; impact of processing; whether safeguards (pseudonymisation, opt-out) reduce the impact |
The LIA must be documented in writing before processing begins. If a data subject subsequently exercises their right to object under Article 21, the documented LIA is the basis on which the controller assesses whether compelling legitimate grounds override the objection. Without a pre-existing LIA, the controller has no analytical foundation from which to respond to the objection.
Legal Obligation: What Counts
Article 6(1)(c) applies where processing is necessary for compliance with a legal obligation to which the controller is subject. The legal obligation must be based on EU or EU member state law — legal obligations imposed by non-EU law do not qualify as a basis under Article 6(1)(c), though they may be relevant to the legitimate interests analysis.
This basis covers: anti-money laundering (AML) record-keeping; tax record retention requirements; occupational health and safety reporting; mandatory breach notifications to sector regulators; employment law record-keeping; statutory document retention requirements. It does not cover contractual obligations with private parties — a contract term requiring retention of data does not make retention a legal obligation for GDPR purposes.
| KEY IDEA | Legal obligation as a basis fixes both the fact of processing and its scope. The processing is lawful only to the extent required by the legal obligation — not to a broader extent that might be convenient. An organisation required by tax law to retain transaction records for seven years cannot use the legal obligation basis to justify using those records for marketing purposes during the retention period. The purpose of retention is tax compliance; any other use requires a separate basis. |
Why Basis Selection Cannot Be Reversed
Article 5(1)(b)’s purpose limitation principle and the transparency requirements in Articles 13 and 14 together create a constraint that organisations frequently discover too late: the lawful basis selected for a processing activity cannot simply be swapped for a more convenient basis after the fact.
When an organisation tells data subjects in its privacy notice that it processes their data on the basis of legitimate interests, it has communicated a specific legal framework for the relationship: the individual has the right to object under Article 21; the organisation must conduct a balancing assessment if they do; and the processing will stop if the balance favours the individual. Switching to consent as the basis after the fact would require: re-notifying all data subjects; obtaining fresh consent meeting GDPR’s standards; and deleting data from any individual who does not provide fresh consent. In practice, this is rarely operationally viable.
Conversely, an organisation that begins processing on the basis of consent and then attempts to switch to legitimate interests when consent rates decline faces a different but equally serious problem: the data was collected on the basis that the individual had a choice. Switching to legitimate interests retrospectively eliminates that choice without the individual’s knowledge or agreement — which is a transparency and fairness failure as well as a potential purpose limitation violation.
| BITLION INSIGHT | The basis selection decision should be made by a qualified privacy professional — not a product manager, marketing team, or legal department alone — before any processing design is finalised. Building basis selection into the product intake process, rather than treating it as a post-launch compliance review, prevents the expensive and operationally disruptive problem of having to change bases retroactively across live processing activities. |
Documentation Requirements: What Must Be Recorded
The accountability principle requires the lawful basis for every processing activity to be documented before processing begins. At minimum, this means the RoPA entry for each processing activity must specify the Article 6 basis being relied on. For legitimate interests, the LIA must also be documented. For consent, the consent records must be maintained. For legal obligation, the specific legal provision imposing the obligation should be identified.
Beyond the RoPA, the lawful basis must be communicated to data subjects in the privacy notice. The notice must state not just which basis is relied on, but the specific purpose for which it is relied on. Generic statements like ‘we process your data in our legitimate interests’ without specifying what those interests are do not satisfy Article 13(1)(d)’s requirement to provide information about the legitimate interests pursued by the controller or third parties.
LAWFUL BASIS DOCUMENTATION — MINIMUM REQUIREMENTS BY BASIS
| Basis | RoPA Entry | Additional Documentation | Privacy Notice Content |
|---|---|---|---|
| Consent | Art. 6(1)(a) | Consent records per individual; consent notice versions; withdrawal log | Purpose; right to withdraw; how to withdraw |
| Contract | Art. 6(1)(b) | Contract reference; necessity analysis | Purpose; necessity for contract performance |
| Legal obligation | Art. 6(1)(c) | Specific legal provision reference | Nature of legal obligation (general terms) |
| Vital interests | Art. 6(1)(d) | Documented circumstances justifying use | Purpose and circumstances |
| Public task | Art. 6(1)(e) | Legal basis for the public task | Nature of the public task |
| Legitimate interests | Art. 6(1)(f) | Full LIA document; evidence of balancing | Specific legitimate interests pursued; right to object |
The intersection of lawfulness and the accountability principle is where many organisations’ compliance programmes are most vulnerable. Asserting that all processing is lawful in a policy document, without the per-activity documentation that demonstrates it, satisfies neither the Article 6 requirement nor the Article 5(2) accountability requirement. The next article in this section addresses the special rules that apply to the most sensitive categories of personal data — where the lawfulness analysis is even more demanding.