Choosing the right lawful basis GDPR requires for each processing activity is one of the first decisions every data controller must make. One of the first and most important questions that arises when implementing GDPR is: what legal basis are we using to process this data? This is not a formality — the choice of legal basis determines what rights the data subject has, what obligations the controller carries, and how the organisation must respond to an audit or complaint.
Choosing the wrong legal basis is a GDPR violation — even if the data is processed for a legitimate purpose and with full respect for privacy.
In this article we cover:
- all six legal bases under Article 6 GDPR,
- when to apply each one,
- the most common mistakes when selecting a legal basis,
- and why consent is not the default answer.
Lawful basis GDPR recognises — the six options under Article 6
Article 6 GDPR sets out a closed list of six legal bases. Processing personal data is lawful only when it rests on at least one of them. There is no seventh option — if none of the six applies, processing is not permitted.
1. Consent (Article 6(1)(a))
The data subject has given consent to the processing of their personal data for one or more specific purposes.
When to use it: Consent is the appropriate basis when processing is not necessary for the performance of a contract, fulfilment of a legal obligation, or any other purpose covered by the remaining bases — and when the person has a genuine, consequence-free ability to refuse.
Typical use cases: newsletters, marketing cookies, promotional communications, sending commercial offers.
What valid consent requires:
- freely given — no negative consequences for refusing,
- specific — tied to a defined purpose, not a general catch-all,
- informed — the person understands what they are agreeing to,
- unambiguous — an active act, not silence or a pre-ticked box.
When NOT to use it: Consent is the wrong basis if refusing it means the person cannot access a service or enter into a contract — because it is then not freely given. It should also not be used for processing that is necessary to perform a contract or required by law.
2. Performance of a contract (Article 6(1)(b))
Processing is necessary for the performance of a contract to which the data subject is party, or to take steps at the data subject’s request prior to entering into a contract.
When to use it: When the data is genuinely necessary to deliver what has been agreed with that specific person. Examples: name, surname, and delivery address in an online shop; data needed to issue an invoice; employee data required for payroll processing.
When NOT to use it: This basis cannot be stretched to cover processing that is merely convenient or useful for the controller but not actually required to perform the contract. Example: collecting a customer’s date of birth simply to send birthday greetings — that is not necessary for a sales transaction.
3. Legal obligation (Article 6(1)(c))
Processing is necessary for compliance with a legal obligation to which the controller is subject.
When to use it: When a specific law — a statute or regulation — explicitly requires the controller to collect or retain certain data. Examples: retaining employment records for legally prescribed periods, reporting to social security and tax authorities, issuing and archiving invoices.
Important: The legal obligation must be traceable to a specific legal provision — general industry practice or custom is not sufficient. The controller should be able to point to the exact rule that imposes the obligation.
4. Vital interests (Article 6(1)(d))
Processing is necessary in order to protect the vital interests of the data subject or of another natural person.
When to use it: This basis applies only in situations involving a threat to life or physical safety — where other legal bases cannot be applied in time. Examples: disclosing medical data to emergency responders at an accident scene, sharing a missing person’s data with rescue services.
When NOT to use it: This is not a basis for routine business operations. Its scope is narrow and should be interpreted strictly — only a genuine, immediate threat to life or health justifies its use.
5. Public interest or official authority (Article 6(1)(e))
Processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.
When to use it: Primarily by public bodies and government institutions performing statutory tasks. Examples: processing by public authorities, courts, state schools, universities, and public hospitals in the course of their legally assigned functions.
When NOT to use it: Private organisations generally cannot rely on this basis unless they have been formally entrusted with public tasks by law.
6. Legitimate interests (Article 6(1)(f)) — LIA
Processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject.
When to use it: This is the most flexible basis, but also the one that requires the most careful assessment. It applies when the controller has a genuine interest in processing the data, that processing is necessary to achieve it, and the data subject’s interests do not override the controller’s.
Typical use cases: direct marketing to existing customers, fraud prevention, network and information security, pursuing or defending legal claims, limited-scope profiling.
What a LIA is and when it is required: Before relying on this basis, the controller should carry out a Legitimate Interest Assessment (LIA). This is a three-part test examining: whether the interest is genuine and legally recognised, whether processing is necessary to achieve it, and whether the data subject’s rights and interests are overridden. The outcome of the LIA should be documented.
When NOT to use it: Public authorities cannot rely on legitimate interests for the performance of their public tasks. It is also inappropriate where the data subject could not reasonably expect their data to be used in this way.
Consent versus legitimate interest — how to choose
This is the question that arises most often and causes the most errors in practice.
The key distinction is this: consent gives the data subject full control — they can withdraw it at any time and the controller must stop processing. Legitimate interest does not require consent, but the controller must demonstrate that the interest is genuine, that processing is necessary, and that the data subject’s rights are not overridden.
The choice between these two bases has practical consequences:
If you choose consent: you must obtain it before processing begins, document it, enable withdrawal, and cease processing when consent is withdrawn.
If you choose legitimate interests: you must carry out and document a LIA, inform the data subject of this basis in your privacy notice, and respect the right to object (Article 21 GDPR).
A frequent mistake is defaulting to consent whenever there is any doubt — because it feels like the safer option. In practice, consent is one of the most difficult bases to maintain over time, because every withdrawal requires action from the controller.
The most common mistakes when selecting a legal basis
Using consent as the default for everything. Many organisations collect consent even where a contract or legal obligation would suffice. The result: an unnecessarily complex consent management system, risk of losing the legal basis when consent is withdrawn, and legal confusion.
Citing multiple bases for the same purpose. Processing for a given purpose should rest on one appropriate legal basis. Listing several alternatives signals that the controller is unsure which one actually applies.
No documented LIA. Relying on legitimate interests without a completed and recorded assessment is a breach of the accountability principle.
Extending the contract basis to additional purposes. Collecting data under a contractual basis and then using it for marketing without a separate legal basis is one of the most commonly identified violations.
Failing to update the basis when the purpose changes. If the purpose of processing changes, the legal basis may need to change or be extended — and the data subject must be informed.
Connecting legal bases to the record of processing activities
Every processing activity in the record of processing activities should specify the applicable legal basis under Article 6 GDPR. Where special category data is involved, an additional basis under Article 9 GDPR is also required.
A record without stated legal bases is an incomplete record — and one that will not hold up during a supervisory authority inspection.
Properly managing legal bases also extends to privacy notices — the data subject must be informed of the basis for processing before their data is collected. The EDPB Guidelines on legitimate interest provide detailed guidance on how to carry out and document a LIA correctly.
Summary
Selecting the right legal basis is the foundation of GDPR compliance. There is no single default basis — every processing purpose requires its own assessment.
A practical decision guide:
- data necessary to perform a contract → Art. 6(1)(b)
- data required by law → Art. 6(1)(c)
- marketing to new recipients, optional cookies → Art. 6(1)(a) — consent
- marketing to existing customers, security, legal claims → Art. 6(1)(f) — legitimate interests
- immediate threat to life → Art. 6(1)(d)
- public authority performing statutory tasks → Art. 6(1)(e)
Every selected basis should be documented in the record of processing activities and stated in the privacy notice provided to the data subject.
Manage legal bases and your GDPR record in one place
iGDPR lets you assign a legal basis to every processing activity, carry out a Legitimate Interest Assessment (LIA), and maintain a complete record ready for a supervisory authority inspection. See how it works in practice.
START FREE TRIAL — 21 days, no commitment





