Every processing activity under the GDPR needs a lawful basis, and the basis has to be chosen before the processing starts. Most teams know this. Fewer can say, for a given activity, which basis they rely on, why, and what that choice commits them to.
The choice is not cosmetic. It decides which rights a data subject can exercise, what your privacy notice must say, and whether you can keep processing after an objection or a withdrawal. It is also hard to fix later. The EDPB's position is that you cannot swap to a different basis after the fact to rescue processing that no longer fits the first one.
This article walks through the six bases in Article 6(1), says which ones a commercial SaaS company realistically relies on, and sets out a short method for choosing and recording one.
What Article 6 actually says
Article 6(1) lists six conditions. Processing is lawful only if at least one applies:
Consent (6(1)(a)): the data subject has consented to processing for one or more specific purposes.
Contract (6(1)(b)): processing is necessary to perform a contract with the data subject, or to take steps at their request before entering one.
Legal obligation (6(1)(c)): processing is necessary to comply with a legal obligation the controller is subject to.
Vital interests (6(1)(d)): processing is necessary to protect the vital interests of the data subject or another person.
Public task (6(1)(e)): processing is necessary for a task carried out in the public interest or in the exercise of official authority vested in the controller.
Legitimate interests (6(1)(f)): processing is necessary for the controller's or a third party's legitimate interests, except where those interests are overridden by the data subject's interests or fundamental rights and freedoms.
Note the word that recurs in five of the six: necessary. It is read strictly. Processing that is useful, convenient, or common practice is not necessary for that reason alone. If a reasonable, less intrusive way would achieve the same purpose, the processing is unlikely to be necessary.
No basis ranks above another. Consent is not the "safest" choice, and in many business contexts it is the weakest.
The bases most SaaS companies use
Vital interests and public task rarely apply to a private software company. Vital interests is meant for genuine emergencies, and Recital 46 says reliance on another person's vital interests should in principle be a last resort. Public task needs a task laid down in EU or Member State law. That leaves four, and three of them carry most of the load.
Contract
Contract covers processing that is objectively necessary to deliver what the individual signed up for. Creating their account, authenticating them, billing the person who pays you, and sending service emails about their account usually qualify.
Two limits catch people out. First, the contract must be with the data subject. If your customer is a company and the individual is one of its employees using your product, your contract is with the company, not the employee. Second, the EDPB's guidelines on Article 6(1)(b) for online services say that processing for service improvement, fraud prevention, or behavioral advertising is generally not necessary for the contract, even when your terms mention it. Writing a purpose into your terms does not make it necessary.
Legal obligation
This applies when a law requires the processing: keeping invoices for tax purposes, for example, or responding to a binding order. Article 6(3) requires the obligation to be laid down by EU or Member State law. A requirement under non-EU law does not, on its own, give you a basis under 6(1)(c). Name the specific law in your record. "Regulatory requirements" is not an answer.
Legitimate interests
Legitimate interests is the most flexible basis and the one that needs the most work. The recitals give examples that may qualify: fraud prevention and direct marketing (Recital 47), transmission within a corporate group for internal administrative purposes (Recital 48), and network and information security (Recital 49).
Relying on it means running a three-part test and writing it down, usually as a legitimate interests assessment:
Purpose. Is there a legitimate interest, yours or a third party's? State it specifically.
Necessity. Is the processing necessary for that interest, or would a less intrusive approach work?
Balancing. Do the individual's interests, rights, and freedoms override yours? Consider their reasonable expectations, the nature of the data, and the safeguards you apply.
Individuals can object to processing based on legitimate interests under Article
You must then stop unless you can demonstrate compelling legitimate grounds that override theirs. For direct marketing, the right to object is absolute.
When consent is the right answer, and when it is not
Consent under Article 4(11) must be freely given, specific, informed, and unambiguous, expressed by a statement or a clear affirmative action. Article 7 adds that you must be able to demonstrate it, that a written request for consent must be clearly distinguishable from other matters, and that withdrawing must be as easy as giving it.
Consent fits when the individual has a real choice and the processing is optional: a newsletter, a research panel, a beta program that shares usage recordings. It is a poor fit in three common situations:
Employment. The imbalance of power between employer and employee means consent is rarely freely given. The EDPB's consent guidelines say so directly.
Processing you would do anyway. If you would carry on under another basis after a withdrawal, asking for consent misleads the individual. Use the other basis from the start.
Bundled conditions. Making a service conditional on consent to processing that the service does not need undermines "freely given" (Article 7(4)).
What the choice commits you to
The basis you pick changes your obligations downstream. Keep this next to your record of processing.
| Basis | Right to object (Art. 21) | Data portability (Art. 20) | What you must be able to show |
|---|---|---|---|
| Consent | No, but withdrawal at any time | Yes, if processing is automated | Who consented, when, and what they were told |
| Contract | No | Yes, if processing is automated | Why the processing is necessary for the contract |
| Legal obligation | No | No | The specific law that requires it |
| Legitimate interests | Yes | No | The legitimate interests assessment |
Erasure under Article 17 interacts with the basis too. Withdrawal of consent and a successful objection are both grounds for erasure, while processing required by law is an exception to it. Article 17 has several other grounds and exceptions, so treat this as a pointer rather than the full rule.
Articles 13(1)(c) and (d) require your privacy notice to state the legal basis for each purpose, and, for legitimate interests, the interests pursued.
Special category data under Article 9, such as health data or biometric data used to identify someone, needs both an Article 6 basis and an Article 9 condition. That is a separate analysis, and the conditions are narrower.
A method for choosing
Work per purpose, not per system or per data type. "Customer support" is a purpose. Your helpdesk is a system. "Email addresses" is a data category. One system often serves several purposes, each with its own basis.
Write the purpose in one specific sentence. "Send product update emails to account administrators" rather than "communications".
Ask whether a law requires it. If yes, the basis is legal obligation. Name the law.
Ask whether you could deliver what the individual asked for without it. If you could not, and your contract is with them, the basis is contract.
Otherwise, run the legitimate interests test. If it passes, keep the assessment.
If it fails, or the processing is optional and intrusive, ask for consent. Build the consent record and the withdrawal path before launch.
Record the result against the activity in your record of processing, and reflect it in your privacy notice.
Revisit the choice when the purpose changes. Article 6(4) allows further processing for a compatible purpose in some cases, but a new, unrelated purpose needs its own basis.
Where your customers decide, not you
If you are a B2B SaaS company, much of the personal data in your product sits inside your customers' processing. For that data you are typically a processor, and the lawful basis is your customer's decision as controller. Your obligation is to process on their documented instructions.
You still need bases for what you do as a controller: your own marketing, billing contacts, sales pipeline, product analytics you run for your own purposes, and your employees' data. Keep those in your own record. The GDPR framework page shows how these obligations fit together, and the glossary defines the terms used here.
Lawful basis questions turn on facts and, at the edges, on interpretation that varies with national law and regulator guidance. Confirm your conclusions with counsel, particularly legitimate interests assessments for marketing and analytics.
How TrustLynce helps
TrustLynce's data privacy workflows keep your record of processing with the lawful basis recorded per activity, next to the DPIAs and transfer assessments that depend on it. Policy management versions the privacy notice that tells individuals which basis applies.