Lawful Basis for Processing

Every processing activity involving personal data must have a lawful basis under GDPR Article 6. There are six options, and choosing the wrong one creates real compliance risk: some of the largest GDPR fines on record — including nine-figure penalties against major ad-funded platforms — were fundamentally lawful-basis cases, where the regulator concluded the company had built its business on a basis that did not fit the processing.

Two rules frame everything in this lesson. First, you must determine and document your lawful basis before processing begins. Second, you cannot swap bases retroactively when the first one becomes inconvenient — regulators treat basis-shopping (consent failed, so now we claim legitimate interests for the same processing) as evidence of unfairness. Get the decision right up front, per processing activity, and write it down.

The Six Lawful Bases

1. Consent — Article 6(1)(a)

The individual has given clear, affirmative consent for a specific purpose. GDPR's standard (Articles 4(11) and 7) is high:

• Freely given — no bundling consent with service access ("consent or leave" generally fails), and no imbalance of power (employee consent is rarely valid).
• Specific and informed — per purpose, not a blanket "we may use your data."
• Unambiguous, by affirmative act — pre-ticked boxes and inactivity do not count.
• Withdrawable — as easy to withdraw as to give, and when withdrawn you must stop that processing.

Consent is the right basis when the individual genuinely has a free choice and you can live with them saying no: marketing emails, optional analytics cookies, optional data enrichment. It is the wrong basis for anything your business depends on.

2. Contractual Necessity — Article 6(1)(b)

Processing necessary to perform a contract with the individual, or to take pre-contractual steps at their request. This covers the core mechanics of delivering a paid or agreed service: account creation, authentication, billing, providing the features the customer signed up for, support on their tickets. The keyword is necessary — regulators read it narrowly. Personalized advertising is not "necessary" to deliver a social network, as EU decisions against major platforms established; the processing must be objectively required for the contract's core purpose, not merely mentioned in your terms.

3. Legal Obligation — Article 6(1)(c)

Processing required by EU or member state law: tax and accounting records, employment law filings, anti-money-laundering checks, responses to valid legal orders. The obligation must be a genuine legal requirement, not a business preference, and it should be identifiable — cite the law in your ROPA.

4. Vital Interests — Article 6(1)(d)

Processing necessary to protect someone's life or physical integrity. Practically limited to emergencies — sharing medical data about an unconscious patient, disaster response. Almost never relevant to commercial products; if you find yourself reaching for it, you have probably mischosen.

5. Public Task — Article 6(1)(e)

Processing necessary for a task in the public interest or exercise of official authority vested in the controller. This is the workhorse basis for public authorities and bodies exercising statutory functions. Private companies rarely use it unless performing delegated public functions.

6. Legitimate Interests — Article 6(1)(f)

Processing necessary for legitimate interests pursued by the controller or a third party, unless overridden by the individual's interests, rights, and freedoms. This is the most flexible basis and the default for much routine business processing — but the flexibility is paid for with a documented three-part test, the Legitimate Interests Assessment (LIA):

1. Purpose test — is the interest legitimate? (Fraud prevention, network security, direct marketing, product improvement, and B2B prospecting are all recognized as potentially legitimate interests, some explicitly in GDPR's recitals.)
2. Necessity test — is this processing necessary for that interest, or is there a less intrusive way?
3. Balancing test — do the individual's interests and reasonable expectations override yours? Consider the data's sensitivity, the relationship, whether they would expect this processing, and available safeguards (minimization, pseudonymization, opt-outs).

Keep the LIA on file. Remember also that legitimate-interests processing is always subject to the Article 21 right to object, and public authorities cannot use this basis for their official tasks.

Comparison: Choosing at a Glance

Mapping Common SaaS Activities

For a typical B2B SaaS company, a defensible mapping looks like this:

• Delivering the product to signed-up users — contractual necessity
• Billing and invoicing — contractual necessity; retention of records afterward — legal obligation
• Security logging, fraud and abuse prevention — legitimate interests (recital 49 supports network security)
• Product analytics and improvement — legitimate interests with minimization, or consent where tracking is intrusive (and remember: non-essential cookies need ePrivacy consent regardless of your GDPR basis)
• Marketing emails to prospects — consent in most cases; legitimate interests may support B2B outreach in some member states, but national e-marketing rules (ePrivacy implementations) vary — check the target market
• Marketing to existing customers about similar products — often the "soft opt-in" under national ePrivacy rules, paired with legitimate interests
• Sharing data with processors (hosting, email delivery) — inherits the basis of the underlying purpose; the DPA governs the relationship
• Employee payroll — contract and legal obligation; employee monitoring — legitimate interests with a careful LIA, almost never consent

Special Category Data Needs More

If you process special category data (health, biometrics for identification, religion, sexual orientation, and so on — Article 9), an Article 6 basis is not enough. You also need an Article 9 condition, most commonly explicit consent, or conditions such as employment law obligations, vital interests, or substantial public interest under member state law. A wellness app, an HR system recording sick leave, or a product using facial recognition all live here. Criminal offense data (Article 10) has its own restrictions. If special category data is central to your product, expect a DPIA as well.

Documentation and Transparency

Your lawful basis decisions must show up in three places:

1. Record of Processing Activities (ROPA) — each processing activity listed with its purpose, data categories, recipients, retention, and lawful basis (plus Article 9 condition where relevant).
2. Privacy notice — Articles 13–14 require you to state the lawful basis for each purpose, and for legitimate interests, to name the interest.
3. LIAs and consent records — the accountability evidence behind the claims. For consent, you must be able to demonstrate who consented, when, to what wording, and through what mechanism (Article 7(1)).

Lifecycle Events: When the Basis Analysis Changes

Lawful basis is not a launch-day decision you make once. Several predictable events force a re-analysis:

• New feature, same data. Using existing customer data for a genuinely new purpose (say, benchmarking across customers, or model training) requires a compatibility assessment under Article 6(4) — is the new purpose compatible with the original one? If not, you need a fresh basis and fresh notice before the feature ships. Building the check into product review is far cheaper than retrofitting it.
• Consent fatigue or failure. If a consent-based flow gets poor opt-in rates, the temptation is to reframe the processing under legitimate interests. Sometimes that is analytically defensible for a redesigned, less intrusive version of the processing; it is never defensible as a relabeling of the identical processing, and the paper trail will show which one you did.
• Contract ends. When a customer churns, contractual necessity evaporates for ongoing processing. What remains is legal-obligation retention (billing records) and narrowly scoped legitimate interests (defense of legal claims) — each with defined retention periods, not indefinite storage.
• Acquisitions and data purchases. Data acquired in an asset deal arrives with the basis (and the promises) under which it was originally collected. Buying a list does not launder its consent problems; Article 14 notice duties are triggered within a month.
• Regulatory shifts. Guidance and case law keep tightening specific bases — consent standards for cookies, contract-necessity limits for ads, legitimate interests for AI training. Assign someone to watch EDPB output and revisit affected ROPA entries annually.

Treat the ROPA as a living register with a review date per activity, and these events become routine maintenance instead of emergencies.

Lawful Basis Checklist

• Every processing activity in your ROPA has exactly one primary lawful basis recorded
• "Necessary for the contract" claims map to genuinely core service functions
• An LIA is on file for every legitimate-interests activity, with the balancing reasoning written out
• Consent flows use unticked boxes, granular purposes, and plain language
• Consent withdrawal is as easy as giving it, and actually stops the processing
• Consent records (timestamp, wording version, mechanism) are retained
• Special category data has an identified Article 9 condition
• Cookie/tracking consent is handled under ePrivacy rules in addition to GDPR
• Privacy notice states the basis for each purpose and names your legitimate interests
• Marketing objections and consent withdrawals feed a durable suppression list
• No processing activity has silently switched basis since launch

Frequently Asked Questions

Can I rely on more than one lawful basis for the same processing?

Different purposes can each have their own basis, and that is normal. But for a single purpose, pick one primary basis and stand behind it. Presenting stacked bases ("consent, or failing that, legitimate interests") for the same processing signals to regulators that you doubt your own analysis, and it misleads users about their rights — someone told they consented expects withdrawal to work.

What happens if a user withdraws consent?

You must stop the consent-based processing promptly and, if consent was your only basis, delete or anonymize the data unless another lawful ground (like a legal retention duty) applies to keeping it. You cannot fall back to legitimate interests for the identical processing after withdrawal — that is the basis-switching regulators have explicitly condemned.

Is legitimate interests just a loophole to avoid asking for consent?

No — it is a legitimate, often more honest choice, but it carries its own obligations: a documented LIA, naming the interest in your privacy notice, and honoring Article 21 objections. It also cannot be used where law requires consent (non-essential cookies, most e-marketing to individuals) and it fails the balancing test for intrusive processing people would not expect.

Can employers rely on employee consent?

Rarely. Because of the power imbalance, EU regulators presume employee consent is not freely given except where refusal genuinely carries no consequences (an optional photo in the company directory, perhaps). Use contract, legal obligation, and legitimate interests for employment processing instead.

Do B2B contacts get less protection?

The data of a named business contact ([email protected], her role, her mobile number) is still personal data with full GDPR protection. B2B context matters in the balancing — professional-capacity outreach is more likely within reasonable expectations — and some national ePrivacy laws are more permissive for corporate subscribers. But "it's B2B" is a factor, not an exemption.

What lawful basis applies to training AI models on user data?

There is no special AI basis — the same six options apply, and regulators have scrutinized this heavily. Contractual necessity rarely fits (training is not necessary to deliver the current service). That leaves legitimate interests with a rigorous LIA, strong minimization, and workable opt-outs, or consent. If the training data includes special category data, Article 9 makes the analysis considerably harder. Document the assessment before you train, not after.

In the next lesson, we will cover the Data Protection Officer — when Article 37 requires one, and how to structure the role.

Keeping ROPAs, LIAs, and consent records current is exactly the kind of work compliance tooling accelerates. AuditXYZ helps you compare compliance automation platforms and find auditors to fit your program and budget.