GDPR Article 6 — Lawful Basis for Processing: The Complete SaaS Developer Decision Tree 2026

Post #871 in the sota.io EU Cyber Compliance Series

GDPR Article 6 is the gateway provision of the entire Regulation. Without a valid lawful basis for each processing activity, everything else — your privacy notice, your DPA with your cloud provider, your data retention policy — is built on sand. A technically perfect security posture does not cure an unlawful basis.

Yet Article 6 is routinely misunderstood by SaaS developers. The most common mistake is treating consent as the default. Consent is the last resort basis — appropriate only when no other basis fits — and it comes with the heaviest compliance burden. Choosing it unnecessarily creates problems you cannot easily fix.

This guide covers all six lawful bases, the decision logic for matching each to specific SaaS processing activities, enforcement patterns from DPA decisions, and the practical steps for documenting your basis selection in a way that survives an audit.

The Article 6 Framework

Article 6(1) states that processing of personal data is lawful only if, and to the extent that, at least one of the following conditions applies:

The bases are not ranked in priority. You must identify the basis that genuinely applies to each processing purpose. Picking the "most convenient" basis and then reverting to another when challenged is a documented DPA red flag.

The critical principle: one purpose, one basis. If you process personal data for three different purposes (account management, analytics, and marketing), each purpose needs its own identified and documented lawful basis.

The Six Bases in Detail for SaaS Developers

Article 6(1)(a) — Consent

Definition: The data subject has given consent to the processing for one or more specific purposes.

Requirements under Article 7:

• Freely given (no bundling with service terms, no consent barriers to core features)
• Specific (separate consent for each distinct purpose)
• Informed (linked to a privacy notice that explains what data, for what purpose, for how long)
• Unambiguous (affirmative action — pre-ticked boxes do not count)
• Withdrawable at any time (withdrawal must be as easy as giving consent)

When it applies in SaaS:

• Marketing emails to prospects who are not yet customers
• Optional analytics or telemetry that goes beyond service improvement
• Third-party advertising pixels on your marketing site
• Cookie consent for non-essential cookies (governed by ePrivacy Directive, but layered on top of GDPR consent requirements)

When it does NOT apply:

• Processing necessary to deliver the contracted service (use 6(1)(b) instead)
• Processing required by law (use 6(1)(c) instead)
• Processing you would do anyway based on legitimate interests (use 6(1)(f) instead)

Consent is not a universal fallback. If you could use contract or legitimate interests, using consent instead creates a fragile basis. Once a user withdraws consent, you must stop the processing immediately — even if that breaks a core workflow. CJEU Case C-61/19 (Orange Romania) established that consent obtained as a precondition for service delivery is not "freely given" and is therefore invalid.

DPA enforcement: The Austrian DPA (DSB) in 2024 found that bundled consent for analytics and service delivery was unlawful. The Irish DPC fined Meta €390M in January 2023 for treating behavioral advertising as necessary for contract performance — effectively deciding that Meta was relying on the wrong basis (6(1)(b)) but that basis did not apply, and they had not validly obtained consent under 6(1)(a).

Article 6(1)(b) — Contractual Necessity

Definition: Processing is necessary for the performance of a contract to which the data subject is party, or to take steps at the request of the data subject prior to entering into a contract.

The "necessity" test: Processing is necessary only if the contract could not be performed without it. "Useful," "convenient," or "improving the service" does not meet the necessity threshold. The EDPB Guidelines 2/2019 on Article 6(1)(b) establish a strict interpretation: you must demonstrate that the processing is objectively necessary to deliver the specific contractual service the user signed up for.

When it applies in SaaS:

• Storing the user's email address to authenticate them and deliver the service
• Processing payment card data to charge for subscriptions
• Logging user actions for core functionality (e.g., audit trails required to provide the service)
• Account recovery workflows that require storing a recovery email or phone number
• Pre-contractual processing to provide a free trial or respond to a sales inquiry

When it does NOT apply:

• Analytics on how users interact with your product (beyond what's necessary for service delivery)
• Processing for product improvement or feature prioritization
• Sending feature announcements or product newsletters (even transactional-feeling ones)
• Sharing user data with business partners or third parties for their own purposes

The Meta/DPC ruling context: The Irish DPC's €390M fine was specifically about Meta claiming that behavioral advertising was "necessary" for the contract with users. The CJEU and EDPB rejected this: users contracted for a social network, not for personalized advertising. The processing must be necessary for the specific contract the user agreed to, not for the business model surrounding that contract.

Practical test: Ask: "If we stopped this processing, could we still deliver the contracted service to this user?" If yes, 6(1)(b) does not apply.

Article 6(1)(c) — Legal Obligation

Definition: Processing is necessary for compliance with a legal obligation to which the controller is subject.

Requirements:

• The obligation must be established in EU or EU member state law
• The law must require the specific processing (not just make it possible)
• You must identify the specific legal provision

When it applies in SaaS:

• Retaining invoice data for the statutory accounting/tax retention period (typically 7-10 years in EU member states)
• Providing user data in response to a valid court order or law enforcement request
• Anti-money-laundering (AML) customer due diligence if you are a regulated financial services provider
• Employment data processing required by labor law
• Retaining records required by the eIDAS Regulation if you are a trust service provider

Common mistake: Developers sometimes use 6(1)(c) to justify retaining data "in case we need it for legal disputes." Future potential legal claims are not a current legal obligation. Speculative litigation preparedness does not create a lawful basis. The legal obligation must exist and require the processing now.

Interaction with retention periods: Processing under 6(1)(c) for tax retention purposes only justifies retention for the specific purpose of meeting that legal obligation. If you retain data for tax compliance, you cannot use the same retained data for product analytics. Repurposing data collected under one basis for a different purpose requires either a new compatible basis or a separate original basis.

Article 6(1)(d) — Vital Interests

Definition: Processing is necessary to protect the vital interests of the data subject or of another natural person.

Applicability: Vital interests means life-or-death situations. This basis applies in genuine emergencies where data processing is necessary to prevent a serious threat to life or physical safety and consent cannot be obtained.

Relevance for SaaS developers: Effectively none in normal operations. This basis applies to medical providers, emergency services, and crisis response systems — not to commercial SaaS platforms. If you are considering 6(1)(d) as a lawful basis for any standard SaaS processing activity, you are using the wrong basis.

Article 6(1)(e) — Public Task

Definition: 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.

Applicability for SaaS: Almost always inapplicable to private-sector SaaS businesses. This basis covers government bodies, public health authorities, academic research with a public mandate, and similar public-sector activities. A private SaaS company cannot generally claim the public task basis.

Edge cases: Research institutions, public universities, and government-contract SaaS providers may have legitimate grounds here. The legal basis must be established in EU or member state law. You cannot self-declare a public interest basis.

Article 6(1)(f) — Legitimate Interests

Definition: 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 which require protection of personal data, in particular where the data subject is a child.

The three-part test (EDPB Guidelines 1/2024 on LIA):

Step 1 — Purpose test: Is there a genuine legitimate interest? Commercial interests qualify if they are lawful, clearly articulated, and real (not speculative). Security, fraud prevention, network integrity, and business analytics are recognized legitimate interests.

Step 2 — Necessity test: Is the processing necessary to achieve that interest? Could a less privacy-invasive alternative achieve the same result? You must demonstrate that the processing is not excessive relative to the purpose.

Step 3 — Balancing test: Do the data subject's interests or rights override the legitimate interest? Factors:

• Nature of the data (sensitive data raises the threshold)
• Reasonable expectations of the data subject
• Relationship between controller and data subject
• Impact of the processing (embarrassment vs. financial harm vs. physical safety risk)
• Whether the data subject can object (and the controller will honor it)

When it applies in SaaS:

• Product analytics for improving user experience (where the user has reasonable expectations of monitoring within the service)
• Fraud detection and security monitoring across your platform
• Sending transactional communications that are not strictly necessary for the contract but which the user would reasonably expect (e.g., "your trial is expiring in 3 days")
• B2B marketing to existing customers about related products
• Network and security logging for abuse prevention
• Sharing data with group companies for shared IT infrastructure (with appropriate DPIA if high-risk)

When it does NOT apply:

• Direct marketing to new prospects (use consent)
• Profiling for third-party advertising networks
• Processing children's data (Article 6(1)(f) is explicitly unavailable where the data subject may be a child)
• High-impact processing where the data subject would not reasonably expect it

The "reasonable expectation" anchor: The EDPB consistently uses the data subject's reasonable expectations as the central balancing factor. A B2B SaaS user expects that their usage patterns will be monitored for product improvement — this is within their reasonable expectations. A consumer user who signed up for a fitness app does not reasonably expect their location data to be sold to insurance companies.

Documentation requirement: Unlike consent (which has a specific mechanism), legitimate interests require a Legitimate Interests Assessment (LIA) — a documented analysis of the three-part test. This does not need to be published, but it must be recorded and available to demonstrate compliance. Undocumented claims of legitimate interests will not survive DPA scrutiny.

The Decision Tree: Matching SaaS Processing Activities to Lawful Bases

The following decision logic applies to the most common SaaS processing scenarios:

User Registration and Authentication

Processing: Name, email, password hash, registration timestamp.

Basis: 6(1)(b) — Contract. The user signed up for a service. Authentication and account management are objectively necessary to deliver it. No consent required.

Watch out: Do not ask for consent during the registration flow for core account data. It implies consent is the basis when it is not, creating confusion about withdrawal rights.

Payment Processing

Processing: Payment method data, billing address, transaction history.

Basis: 6(1)(b) — Contract for processing during the transaction. 6(1)(c) — Legal obligation for retaining invoice data for tax compliance periods.

Watch out: Payment processors like Stripe operate as data processors under your DPA. Their retention of payment data for fraud prevention may rely on their own legitimate interests — document this clearly in your privacy notice.

Product Analytics (Usage Data)

Processing: Feature usage, click streams, session duration, error logs.

Basis: 6(1)(f) — Legitimate interests if the analytics are clearly for product improvement and the user has a reasonable expectation of being monitored within the service. Requires LIA documentation.

Alternatively: 6(1)(b) — Contract for basic operational data necessary to deliver the service (e.g., error logs necessary to maintain uptime). Do not stretch this to cover product analytics.

Watch out: If you share analytics data with third-party analytics platforms (Google Analytics, Mixpanel, Amplitude) that process data for their own purposes, each third party's processing requires its own basis — you cannot extend your lawful basis to them. This is why many EU developers have moved to self-hosted analytics (Plausible, Matomo, PostHog).

Transactional Email

Processing: Email address, usage context, account status.

Basis: 6(1)(b) — Contract for emails directly necessary for service delivery (password reset, account suspension notice, security alert). 6(1)(f) — Legitimate interests for operationally-adjacent emails the user would reasonably expect (trial expiry notice, invoice generated, new feature critical to their workflow).

Watch out: Product newsletters, new feature announcements, and upsell emails are not contractually necessary. Use 6(1)(a) — Consent for marketing communications to users, with a clear opt-out mechanism. Bundling marketing email opt-in with service terms is invalid consent.

Marketing to Prospects (Non-Customers)

Processing: Email address, company, role, inferred intent from website behavior.

Basis: 6(1)(a) — Consent for B2C marketing. 6(1)(f) — Legitimate interests for B2B cold outreach to business email addresses (with a meaningful opt-out), provided you have reasonable grounds for the outreach — but this is a contested area and varies by member state.

Watch out: ePrivacy Directive requirements overlay GDPR for direct marketing by electronic means. Some EU member states (Germany, Austria, Spain) take a stricter approach to B2B cold email. GDPR Article 6 lawful basis does not supersede ePrivacy rules.

Security Logging and Fraud Detection

Processing: IP addresses, user agent, behavioral patterns, failed login attempts.

Basis: 6(1)(f) — Legitimate interests. Security and fraud prevention are recognized legitimate interests. The processing is typically proportionate provided you apply appropriate retention limits and access controls.

Watch out: Behavioral profiling that goes beyond security purposes (e.g., using security logs to infer commercial intent) requires a separate basis assessment.

Invoice and Tax Retention

Processing: Customer identity, transaction records, billing address, VAT number.

Basis: 6(1)(c) — Legal obligation. EU member states require retention of accounting records for 7-10 years. This justifies retention even after the customer has requested deletion.

Interaction with erasure: Article 17(3)(b) creates an explicit exemption from the right to erasure where retention is necessary for compliance with a legal obligation. You can and should retain invoice data despite deletion requests — but only the specific data legally required, only for the retention period mandated, and only for the legal compliance purpose.

The Special Category Processing Overlay

Article 9 GDPR imposes an additional layer for special categories of personal data: health data, genetic data, biometric data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life, and sexual orientation.

If your SaaS processes any special category data — even incidentally (a user voluntarily entering health information in a notes field) — you need both:

1. A valid Article 6 lawful basis
2. A specific Article 9(2) exemption (typically explicit consent under 9(2)(a), or necessity for health care under 9(2)(h))

Article 9 failures are among the most heavily fined GDPR violations. If your product can receive special category data — even if you do not actively solicit it — your privacy notice and data handling procedures must address it.

Documenting Your Lawful Basis

Article 30 — Records of Processing Activities (RoPA): Article 30 requires controllers with more than 20 employees (and all processors regardless of size for any processing that is not occasional) to maintain a record of processing activities. The RoPA must include, for each processing activity:

• Name and contact details of the controller
• Purposes of the processing
• Categories of data subjects and personal data
• Categories of recipients
• International transfer mechanisms
• Retention periods
• Security measures

Critically: the lawful basis is not explicitly listed in Article 30's required fields, but DPAs universally expect it to be documented in your RoPA or in a linked privacy impact assessment. The Article 30 RoPA is the first document a DPA requests in an investigation.

Legitimate Interests Assessment: For each processing activity relying on 6(1)(f), maintain a written LIA covering the three-part test. The EDPB's Guidelines 1/2024 provide a standardized template. The LIA must be reviewed and updated when the purpose or context changes.

Privacy Notice Requirements (Article 13/14): Your privacy notice must state the lawful basis for each processing purpose. Vague statements like "we process data in accordance with applicable law" are insufficient. The Berlin DPA has issued reprimands specifically for privacy notices that fail to specify lawful bases.

Changing Your Lawful Basis

You cannot retroactively change a lawful basis once processing has started. If you told users in your privacy notice that you process analytics data under consent, you cannot later switch to legitimate interests without notifying users, updating your privacy notice, and documenting why the change is appropriate.

The EDPB position (Guidelines 05/2020 on consent) is clear: a controller who initially chose consent as their lawful basis cannot switch to legitimate interests if users start withdrawing consent. This effectively locks you into the basis you document from the outset — which is why choosing the correct basis at the design stage matters so much.

The Repurposing Test

Article 6(4) allows processing for a purpose other than the original purpose, but only where the new purpose is compatible with the original. The compatibility assessment considers:

• Link between the original and new purposes
• Context of collection and reasonable expectations
• Nature of the data
• Possible consequences for data subjects
• Existence of appropriate safeguards

If the new purpose is incompatible with the original, you need a fresh lawful basis (or explicit consent) before repurposing the data.

SaaS example: You collected user emails under 6(1)(b) for contract performance. You cannot repurpose those emails for marketing under 6(1)(f) without a separate LIA and a clear mechanism for the user to object. Most privacy lawyers advise obtaining explicit consent for repurposing marketing use cases.

Enforcement Pattern: Wrong Basis vs No Basis

DPA enforcement against Article 6 violations falls into two patterns:

No basis: The controller had no documented lawful basis at all. This is the clearest violation and typically results in the highest fines. The TikTok UK fine (£12.7M, 2023) included findings about insufficient lawful basis for processing children's data.

Wrong basis: The controller documented a basis that did not actually apply. The Meta/DPC decisions (January 2023, €390M combined) were explicitly about relying on 6(1)(b) for processing that was actually 6(1)(a) territory — behavioral advertising is not "necessary for the contract" when the user contracted for a social network. The Court of Justice in Cases C-252/21 and C-446/21 confirmed this.

The practical lesson: the distinction between bases is not semantic. DPAs examine whether the stated basis is genuinely the basis under which the controller operates, not whether the controller has written a lawful-sounding label in their privacy notice.

EU Hosting and Data Localisation

Article 6 determines whether you can process data at all. But even with a valid Article 6 basis, international data transfers require separate authorization under Chapter V of the GDPR (Standard Contractual Clauses, adequacy decisions, or BCRs for intra-group transfers).

The most secure position — eliminating Chapter V transfer analysis entirely — is to process data using EU-based infrastructure under a provider that is not subject to US CLOUD Act jurisdiction. When your lawful basis is legitimate interests under 6(1)(f), the balancing test includes data subject reasonable expectations about where their data is processed and who can access it under foreign law. Processing on EU-exclusive infrastructure strengthens the balancing test outcome.

Checklist: Article 6 Compliance for SaaS Developers

• Map every processing activity in your product to a specific Article 6(1) basis
• Document the basis in your Article 30 RoPA
• Write an LIA for every 6(1)(f) basis, signed and dated
• Update your privacy notice to state the basis for each purpose
• Separate consent flows from service enrollment (never bundle marketing consent with account creation)
• Implement consent withdrawal mechanisms that work within a reasonable timeframe
• Document the necessity analysis for each 6(1)(b) basis (what specifically cannot be performed without this processing?)
• Check whether special category data (Article 9) is present — if so, add the 9(2) exemption analysis
• Set up a review schedule: revisit LIAs when product features change materially
• Ensure your DPA agreements with sub-processors reference the correct lawful basis chain

Summary

GDPR Article 6 is not an administrative formality — it determines whether your processing is lawful in the first place. For SaaS developers:

• Core service delivery: Article 6(1)(b) — contract. Do not ask for consent for what is necessary.
• Tax and invoicing retention: Article 6(1)(c) — legal obligation. Survives deletion requests.
• Analytics, security, fraud prevention: Article 6(1)(f) — legitimate interests, documented via LIA.
• Marketing communications: Article 6(1)(a) — consent with proper withdrawal mechanism.
• Never use consent as a default. It is the most burdensome basis and the only one that can be unilaterally revoked.

The wrong basis is not a technicality. It is the foundation on which DPAs have issued nine-figure fines.

This post is part of the sota.io EU Cyber Compliance Series — practical GDPR and EU tech regulation guides for developers and SaaS founders. Previous posts in this series: GDPR Article 82 — Data Breach Liability, GDPR Article 28 — Data Processing Agreements, GDPR Article 33/34 — Breach Notification.