GDPR Lawful Basis for B2B SaaS: How to Choose and Document the Right Article 6 Basis

What is a lawful basis under GDPR Article 6?

A lawful basis is the legal justification for processing personal data. Article 6(1) of the GDPR makes it a threshold requirement: processing is lawful only if at least one of the six bases applies. There is no seventh option and no “we needed the data” catch-all. If you cannot point to a specific sub-paragraph of Article 6(1), the processing is unlawful — regardless of how carefully you secure the data afterwards.

Three obligations follow from that. First, you must identify the basis before processing starts, not reverse-engineer it after a complaint. Second, you must record which basis applies to each processing activity in your Article 30 Records of Processing Activities (RoPA). Third, you must tell data subjects which basis you rely on in your privacy notice under Articles 13 and 14. For US-first teams entering the EU, this is the single most common gap we see in a GDPR readiness assessment: strong security controls, but no documented, activity-level mapping of lawful bases.

A quick jurisdiction note. This article addresses EU GDPR. The UK operates a near-identical UK GDPR enforced by the ICO, whose guidance we cite because it is clear and freely published — but for EU processing the governing authorities are the European Data Protection Board (EDPB) and national supervisory authorities (CNIL, the Irish DPC, Germany's DPAs, and others). Where marketing is concerned, national implementing laws also apply (for example the UK's PECR, or Germany's UWG). And note for context: US privacy laws such as the CCPA/CPRA have no lawful-basis concept — the Article 6 model is specific to the GDPR.

The six lawful bases at a glance

All six are equal under the law — none is “better” than another — but they are not interchangeable, and each carries a different rights profile and administrative burden. The table maps each Article 6(1) sub-paragraph to a plain-English test and the most common B2B SaaS fit.

(a) Consent — Articles 4(11) and 7

Consent under Article 7 must meet the Article 4(11) definition: “freely given, specific, informed and unambiguous” and expressed through “a clear affirmative action.” Pre-ticked boxes, silence, and bundled acceptance do not qualify. It must be as easy to withdraw as to give (Art.7(3)), and — critically — consent is not valid where the processing is a precondition of a service that does not actually require it. That last point is why consent is the wrong basis for core service delivery: you should not condition access to your product on marketing opt-in.

(b) Contract — Article 6(1)(b) and its limits

Contract covers processing that is objectively necessary to perform a contract with the data subject, or to take pre-contractual steps at their request. The trap is over-reading “necessary.” The EDPB's Guidelines 2/2019 on Article 6(1)(b) make clear that necessity is judged against what the service genuinely requires — not what you wrote into the terms. Behavioural advertising, generic “service improvement,” and fraud prevention generally cannot ride on contract; they need a separate basis, usually legitimate interests. When you engage a processor to carry out contract-based processing, the basis and its limits must flow down through your Article 28 data processing agreement.

(c) Legal obligation, (d) vital interests, (e) public task

These three rarely anchor SaaS processing. Legal obligation (c) fits statutory duties — keeping invoices for tax law, responding to a valid law-enforcement request — but not commercial choices dressed up as obligations. Vital interests (d) is limited to protecting someone's life and is realistically confined to emergency or health scenarios. Public task (e) applies to bodies exercising official authority, so it is relevant only to public-sector or gov-tech vendors. Most B2B SaaS teams will use (c) narrowly for compliance record-keeping and never touch (d) or (e).

(f) Legitimate interests — Article 6(1)(f) and Recital 47

Legitimate interests is the most flexible basis and the most misused. Article 6(1)(f) permits processing “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 … in particular where the data subject is a child.” That final clause is the built-in balancing test — the reason an LIA is mandatory. Recital 47 confirms that direct marketing “may be regarded as carried out for a legitimate interest” and ties legitimacy to the reasonable expectations of the data subject. Recital 48 adds that intra-group transmission for internal administrative purposes may be a legitimate interest — but it is not a standalone basis and does not switch off the balancing test, so group companies still cannot freely share personal data.

Legitimate interest vs consent — the decision B2B SaaS teams get wrong

The most common error is defaulting to consent because it “feels safer.” It often is not: consent that can be withdrawn at any moment is fragile for processing you actually need, and invalid consent (bundled, coerced, or a precondition of service) is worse than no consent. Legitimate interest is frequently the more honest and more robust basis — provided you do the assessment. Use the matrix to choose deliberately rather than by habit.

The rule of thumb: if the processing is something a reasonable business customer would expect and is not a preference the user should get to switch off, legitimate interest is usually the right home. If it is genuinely optional and unexpected, use consent — and evidence it properly.

How to run a Legitimate Interests Assessment (LIA)

Before you rely on Article 6(1)(f), you must complete and document a three-part test. The framing below follows the ICO's legitimate-interests guidance (UK), which mirrors the analysis in the former Article 29 Working Party's Opinion 06/2014 that remains a reference for EU controllers. Keep the completed LIA on file; if a supervisory authority asks, the assessment is your defence.

Two caveats on that example. The LIA settles the Article 6 question only — the electronic-marketing rules under ePrivacy/PECR are a separate layer, covered next. And where processing is large-scale, high-risk, or involves systematic monitoring, the same activity may also trigger a Data Protection Impact Assessment under Article 35, which goes further than an LIA.

Mapping common B2B SaaS processing activities to the right basis

This is the table to bookmark. It maps the processing activities almost every SaaS company runs to a defensible basis, names the kind of tool involved, and flags the watch-outs — including where a choice flips to consent.

Where ePrivacy and PECR change the answer (cold outreach and cookies)

This is the part most US SaaS founders get wrong, because Article 6 is only half the picture. Under the ePrivacy Directive 2002/58/EC (Art.5(3)) and its national implementations (such as the UK's PECR), two things sit on top of — and independent of — your Article 6 basis:

The corporate-subscriber point matters. The ePrivacy/PECR electronic-marketing consent rules do not bite on corporate subscribers (limited companies, LLPs) the same way they do on individuals and sole traders. So a role-relevant cold email to [email protected] can often proceed on legitimate interest without ePrivacy opt-in, while emailing a named individual's personal-style address may require consent. This is national-law-specific — Germany's UWG, for instance, is stricter — so confirm per market. The soft opt-in lets you market similar products to existing customers without fresh consent, provided you gave an opt-out when you collected the address and include one in every message.

Two currency points a 2026 guide must cover. The EDPB Opinion 08/2024 on “consent or pay” (17 April 2024) tightened when consent is genuinely “freely given” for large online platforms offering a pay-or-consent choice — relevant if you gate features behind tracking. And the practical mechanics of consent remain an audit item: capture the timestamp, the exact wording shown, and the version, so you can evidence valid consent later. If you are still weighing whether GDPR reaches your US operation at all, start with GDPR for US SaaS companies.

Special-category and healthtech data — you need Article 6 and Article 9

If you process special-category data — health, biometric, racial or ethnic origin, and the other categories in Article 9 — an Article 6 basis is not enough on its own. You need both an Article 6 lawful basis and a separate Article 9(2) condition (for example explicit consent, or provision of health care under 9(2)(h)). Healthtech SaaS handling patient data hits this constantly: contract may cover the Article 6 leg, but you must still name the Article 9(2) condition alongside it. Teams that also fall under US health rules should read this together with our HIPAA compliance guidance, since the two regimes overlap but do not map one-to-one.

How your lawful basis changes which rights users get

The basis you choose is not just paperwork — it determines which data-subject rights are triggered. This surprises teams who assume every right applies to every processing activity.

The portability caveat is the one to get exactly right: Article 20 applies only to consent- or contract-based processing carried out by automated means, and only to data the subject provided — not to analytics you inferred or scores you generated. Stating “portability always applies” is a common and quotable error.

Documenting and defending your basis

Choosing a basis is worthless if you cannot show it. Three artefacts turn a defensible choice into an auditable one. First, the Article 30 RoPA must log the lawful basis for every processing activity. Second, the Article 13/14 privacy notice must disclose the basis (and, for legitimate interests, the interest itself) to data subjects. Third, for legitimate-interest processing, the completed LIA sits behind the RoPA entry as your evidence.

Then there is the “you can't swap bases” rule. Regulators are consistent that you determine the basis before processing and should not switch later without good reason — moving away from consent is treated with particular suspicion, because it looks like retrofitting a justification after opt-ins failed. If circumstances genuinely change, you generally must re-inform data subjects. For a CPA firm running an audit, this is exactly the sort of control we test: is there a current RoPA, does each entry name a basis, and is there an LIA on file where the basis is legitimate interest?

Enforcement reality — the fine tier and the Meta cases

Getting the lawful basis wrong is a top-tier infringement. Under Article 83(5), breaches of the basic principles for processing — including having a valid lawful basis under Article 6 — can attract fines of up to €20 million or 4% of total worldwide annual turnover, whichever is higher. Cumulative GDPR fines across the EEA have run into the billions of euros since 2018, and lawful-basis failures feature prominently among the largest.

The Meta cases are the cautionary example, and the dates matter. Following EDPB Binding Decisions 3/2022 and 4/2022, the Irish DPC announced final decisions on 4 January 2023 fining Meta a combined €390 million (€210M for Facebook, €180M for Instagram) — for wrongly relying on the contract basis (Art.6(1)(b)) for behavioural advertising. Separately, the CJEU's judgment in C-252/21 (Meta v Bundeskartellamt), 4 July 2023, confirmed that behavioural advertising could not readily be justified on contract or on legitimate interest. That fed into an EDPB urgent binding decision of 27 October 2023 (implemented by the Irish DPA in its 10 November 2023 final decision) effectively banning the use of contract and legitimate interest for behavioural advertising by Meta across the EEA. The lesson for SaaS: neither contract nor legitimate interest is a catch-all, and regulators will unwind a mislabelled basis after the fact.

Common mistakes B2B SaaS teams make

The first mistake is reaching for consent where contract fits. Conditioning core service delivery on consent produces invalid consent and fragile processing; use contract for what the service genuinely needs. The second is treating legitimate interest as blanket permission — relying on 6(1)(f) with no LIA on file means you have no defence when challenged. The third is forgetting the ePrivacy layer: a valid Article 6 basis does not exempt you from cookie or electronic-marketing consent rules. The fourth is over-reading contract necessity to cover analytics, advertising, or product improvement, contrary to EDPB Guidelines 2/2019. And the fifth is documentation drift — a RoPA that was accurate at launch but no longer reflects the tools and flows you actually run. Each of these is exactly what surfaces in a GDPR readiness assessment, and each is inexpensive to fix before an enterprise buyer's legal team finds it.