GDPR Art.6: Six Lawful Bases for Processing — Complete Developer Guide (2026)

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

Art.6 is the gateway to every lawful data processing activity. Without a valid lawful basis from Art.6(1) — or Art.9(2) for special categories — processing is unlawful under Art.5(1)(a) and constitutes a serious GDPR violation. Choosing the wrong basis is not a technicality: it determines what you can do with data, when data subjects can object, and whether you can ever change your processing purpose. The six bases are not interchangeable, and supervisory authorities actively challenge post-hoc basis substitution.

The Six Lawful Bases at a Glance

Critical rule: You must identify your lawful basis before processing begins and document it in your ROPA (Art.30). You cannot switch from one basis to another if challenged, nor can you stack bases as a fallback — each processing activity needs exactly one primary basis.

Art.6(1)(a) — Consent

Legal Requirements

Consent under Art.6(1)(a) must satisfy four cumulative requirements from Art.4(11):

1. Freely given — No genuine choice = no valid consent. Bundling consent with a service (take it or leave it) is invalid. Power imbalance (employer/employee) typically invalidates employment consent.
2. Specific — One consent per purpose. A single blanket "I agree to data processing" covering multiple purposes is invalid; each purpose needs separate consent.
3. Informed — Data subject must know the controller's identity, the processing purpose, and the right to withdraw before consenting (Art.13(2)(c)).
4. Unambiguous — Positive opt-in action required. Pre-ticked boxes, silence, or scrolling do not constitute consent (Recital 32).

Art.7 — Conditions for Consent

Art.7 adds four additional requirements when consent is the basis:

EDPB Guidance on Consent

The EDPB Guidelines 05/2020 on Consent clarify:

• Cookie walls that make website access conditional on consent are generally invalid (Recital 42: "clear indication that no disadvantage follows from refusing")
• Granularity: Where consent is used for multiple purposes, each must be separately consented to — one checkbox for "marketing emails AND product improvement analytics AND third-party sharing" is invalid
• Children: Art.8 requires parental consent for under-16s (or under-13 per Member State implementations); age verification mechanisms are required for services likely used by children

CJEU Case Law

Planet49 (C-673/17, 2019): Pre-ticked checkboxes for statistical cookies and third-party partner access do not constitute valid consent. The court confirmed that silence, pre-ticked boxes, or inactivity cannot constitute consent under the GDPR/ePrivacy Directive.

Orange România (C-61/19, 2020): Consent boxes pre-ticked by default in a customer contract for ID document copying were invalid. The controller had to prove freely given consent; the burden shifts to the controller.

When NOT to Use Consent

Consent is the wrong basis when:

• Processing is necessary for a contract — use Art.6(1)(b) instead (consent for necessary processing is invalid under Art.7(4))
• Processing is required by law — use Art.6(1)(c) (you cannot offer a "choice" over a legal obligation)
• You intend to rely on processing regardless of whether the data subject agrees — that is not freely given consent
• Processing involves employment data — power imbalance typically makes employee consent invalid

Anti-pattern: Using consent as a default "safety net" basis for all processing. Consent is the most fragile basis — it can be withdrawn at any time, triggering Art.17 erasure obligations. If processing is genuinely necessary for a contract, use Art.6(1)(b).

Art.6(1)(b) — Contract

Legal Test

Processing is lawful when it is objectively necessary for:

• Performance of a contract to which the data subject is a party, or
• Taking steps at the request of the data subject prior to entering into a contract (pre-contractual steps)

The key word is "necessary." This is a strict test — processing is not justified merely because it is convenient or makes the contract better for the controller. The EDPB Guidelines 2/2019 on Art.6(1)(b) state: "the processing must be necessary for the performance of the contract with the data subject, not just useful."

EDPB Necessity Test for Art.6(1)(b)

1. Identify the contract — What specific contractual obligation is being performed?
2. Is processing integral to contract performance? — Would it be impossible or fundamentally different without this processing?
3. Data subject as party — The contract must be with the data subject. Processing data about a data subject who is not a contract party (e.g., end-user of a B2B product) does not satisfy Art.6(1)(b).
4. Not substitutable — Is there a less privacy-invasive way to perform the contract?

Developer Use Cases for Art.6(1)(b)

CJEU / EDPB Guidance

EDPB Guidelines 2/2019 (Online Services): Mapping personal data for "personalised ads" or "improving the service" to Art.6(1)(b) is not valid when the core service (social network, search engine) could function without targeted advertising or profiling. These must be justified under Art.6(1)(a) or Art.6(1)(f).

Worked example: A SaaS team collaboration tool stores user name, email, avatar. Art.6(1)(b) covers name/email (necessary to create an account and identify users within the service). It does not cover storing browsing behaviour for building a usage-pattern ML model — that requires a separate basis.

Art.6(1)(c) — Legal Obligation

Legal Test

Processing is lawful when it is necessary to comply with a legal obligation to which the controller is subject. The obligation must be imposed by EU law or Member State law (Recital 41) — not by contract, industry standard, or the controller's internal policy.

Requirements for Art.6(1)(c)

1. Legal basis must exist in law — A specific EU regulation, directive implemented in national law, or Member State statute. "Industry practice" or "contractual obligation" are not Art.6(1)(c) sources.
2. Necessity — The specific processing must be required to fulfill the obligation; collecting more than the law requires is not justified.
3. Documentation — ROPA entry must identify the specific legal provision (e.g., "§ 147 AO — German Fiscal Code, 10-year retention for business records").

Common Legal Obligation Sources for SaaS

Art.6(1)(c) vs Art.6(1)(f) Confusion

A common mistake: using Art.6(1)(f) legitimate interests for processing actually required by law. If a law requires you to process, use Art.6(1)(c) — data subjects have no right to object to Art.6(1)(c) processing (unlike Art.6(1)(f) where Art.21 objection rights apply). This distinction matters operationally: if a tax authority requests data you processed under Art.6(1)(c), you have a strong compliance position; under Art.6(1)(f), you may face more scrutiny.

Art.6(1)(d) — Vital Interests

Legal Test

Processing is lawful when it is necessary to protect vital interests of the data subject or another natural person. Recital 46 clarifies this basis is intended to cover situations where consent cannot be given (e.g., the data subject is incapacitated) and where the processing is needed to protect life.

Scope and Limitations

Art.6(1)(d) is the narrowest basis in practice:

• It applies primarily to life-threatening emergencies — medical emergencies, disaster response, humanitarian operations
• Processing must be necessary to protect vital interests, not merely helpful
• Art.9(2)(c) mirrors this for special category health data in emergency processing
• For SaaS products, this basis is almost never applicable — do not use it as a fallback for "important" but non-life-threatening scenarios

Developer note: If you are building healthcare or emergency response applications, Art.6(1)(d) may be relevant for emergency record access. For standard SaaS, this basis can be documented as "not applicable."

Art.6(1)(e) — Public Task

Legal Test

Processing is lawful when it 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. The specific task and official authority must have a basis in EU or Member State law (Art.6(3)).

Applicability

Art.6(1)(e) applies to:

• Public authorities exercising their official functions (tax authorities, regulators, courts)
• Entities carrying out tasks of public interest under national law (public broadcasters, universities with public funding mandates, statistical offices)
• Research conducted in the public interest under national research privilege frameworks

For private SaaS companies: Art.6(1)(e) is generally not available unless you have a specific statutory mandate. Commercial interest, however beneficial, is not "public interest" for Art.6(1)(e) purposes.

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

The Three-Part Test

Art.6(1)(f) is the most flexible but complex basis. Processing is lawful only if all three conditions are met:

Step 1 — Purpose test: Is there a legitimate interest?

• The interest must be real and present — not speculative
• It can be the controller's own interest, a third party's interest, or a broader societal interest
• Commercial interests qualify, but must be weighed against data subject rights

Step 2 — Necessity test: Is processing necessary for that interest?

• Could the same interest be achieved with less intrusive processing or less personal data?
• Apply the data minimisation principle (Art.5(1)(c)) — if you can achieve the purpose with pseudonymised data, full personal data is not "necessary"

Step 3 — Balancing test: Are the controller's interests overridden by the data subject's interests or fundamental rights? Consider:

• Nature of the data (sensitive data tips the balance toward data subject)
• Reasonable expectations of the data subject (did they expect this processing?)
• Scale and impact of processing
• Whether safeguards (pseudonymisation, encryption, access controls) reduce impact on data subjects
• Power asymmetry between controller and data subject

Legitimate Interest Examples (Developer Focus)

Right to Object Under Art.21

When processing is based on Art.6(1)(f), data subjects have an absolute right to object to processing for direct marketing (Art.21(2)) — the controller must stop without any balancing. For other purposes (Art.21(1)), the controller can override the objection if it demonstrates compelling legitimate grounds, but the burden is on the controller.

Implementation implication: Systems relying on Art.6(1)(f) must implement an Art.21 objection mechanism and process objections within one month (Art.12(3)). This creates operational overhead compared to Art.6(1)(b) or (c) where no objection right applies.

CJEU Case Law on Legitimate Interests

Fashion ID (C-40/17, 2019): Facebook's social plugin embedded on Fashion ID's website transmitted user data to Facebook. Fashion ID was a joint controller for collection/transmission. The LI basis required Fashion ID's own LI assessment — they could not rely on Facebook's separate LI for downstream processing.

Schrems II (C-311/18, 2020): While primarily about international transfers, the court confirmed that surveillance-enabling transfers cannot be justified by controller LI because the interference with fundamental rights (Art.7/8 EU Charter) is too severe. US CLOUD Act/FISA 702 exposure is not a "safeguard" that can offset the balancing test.

RW (C-272/19, 2020): Name and contact details of public officials in their professional capacity may be published based on public task (Art.6(1)(e)) or LI (Art.6(1)(f)) given the transparency context — but only the capacity-relevant data, not personal home contact details.

Art.6(3) — Legal Basis for Art.6(1)(c) and (e)

For Art.6(1)(c) and Art.6(1)(e), Art.6(3) requires that the legal basis for processing be laid down in EU law or the law of the Member State to which the controller is subject. National law must meet the requirements of the EU Charter and must specify:

• The purposes of processing
• Scope of personal data processed
• Categories of data subjects
• Retention limits
• Processing operations
• Safeguards for exceptional cases

This means a company cannot invent an Art.6(1)(c) basis — they must identify the specific statutory provision. Consulting national data protection authorities' guidance for your Member State is essential.

Art.6(4) — Compatible Further Processing

Art.6(4) permits controllers to process personal data for a purpose compatible with the original collection purpose without needing a new lawful basis — but requires a compatibility assessment using five factors:

Art.6(4) use cases:

• Research/statistics/archiving: Art.89 provides a dedicated safeguard regime allowing secondary use under specific conditions
• Fraud detection: Processing originally collected for service delivery for fraud scoring may be compatible, depending on data subjects' reasonable expectations
• ML model training: Training a model on operational data for the same product purpose may be compatible; selling model outputs to third parties is likely incompatible

Art.6(4) is NOT available for consent-based processing — if you collected data based on consent, secondary processing for a different purpose requires new consent (or another basis), not just an Art.6(4) compatibility analysis.

Choosing the Right Basis: Decision Framework

Processing Activity: [describe specific activity]
│
├─ Required by EU/national law? → Art.6(1)(c)
│   └─ Document: specific legal provision + retention period
│
├─ Directly necessary to perform contract with data subject? → Art.6(1)(b)
│   └─ Test: Could contract be performed without this processing?
│   └─ Scope: Only data the data subject is party to the contract for
│
├─ Emergency life-threatening situation? → Art.6(1)(d)
│   └─ Very narrow — document why consent is unavailable
│
├─ Public authority exercising official function? → Art.6(1)(e)
│   └─ Requires statutory mandate in EU/national law
│
├─ Controller has legitimate interest that outweighs data subject rights?
│   → Art.6(1)(f) + conduct and document 3-part LI Assessment
│   └─ Note: data subject has Art.21 objection right
│
└─ None of the above → Art.6(1)(a) CONSENT required
    └─ Consent must be freely given, specific, informed, unambiguous
    └─ Art.7 conditions must be satisfied
    └─ Right to withdraw at any time

Python: LawfulBasisSelector

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional

class LawfulBasis(Enum):
    CONSENT = "Art.6(1)(a) — Consent"
    CONTRACT = "Art.6(1)(b) — Contract"
    LEGAL_OBLIGATION = "Art.6(1)(c) — Legal Obligation"
    VITAL_INTERESTS = "Art.6(1)(d) — Vital Interests"
    PUBLIC_TASK = "Art.6(1)(e) — Public Task"
    LEGITIMATE_INTERESTS = "Art.6(1)(f) — Legitimate Interests"


@dataclass
class ProcessingActivity:
    name: str
    description: str
    # Contract
    is_contract_party: bool = False
    contract_necessary: bool = False
    # Legal obligation
    specific_legal_provision: Optional[str] = None
    # Vital interests
    life_threatening_emergency: bool = False
    # Public task
    has_statutory_mandate: bool = False
    # Legitimate interests
    li_purpose_identified: bool = False
    li_necessary: bool = False
    li_balancing_favours_controller: bool = False
    # Special concerns
    involves_special_categories: bool = False
    children_data: bool = False


@dataclass
class BasisAssessment:
    activity: str
    recommended_basis: LawfulBasis
    rationale: str
    warnings: list[str] = field(default_factory=list)
    action_required: list[str] = field(default_factory=list)


def select_lawful_basis(activity: ProcessingActivity) -> BasisAssessment:
    warnings = []
    actions = []

    # Priority 1: Legal obligation (strongest — no data subject objection right)
    if activity.specific_legal_provision:
        return BasisAssessment(
            activity=activity.name,
            recommended_basis=LawfulBasis.LEGAL_OBLIGATION,
            rationale=f"Required by {activity.specific_legal_provision}",
            action_required=[
                f"Document provision '{activity.specific_legal_provision}' in ROPA",
                "Define exact retention period required by law",
                "Confirm Member State implementation applies to your entity",
            ],
        )

    # Priority 2: Contract (only if data subject is party AND processing is objectively necessary)
    if activity.is_contract_party and activity.contract_necessary:
        if activity.involves_special_categories:
            warnings.append(
                "Special categories require Art.9(2) basis in addition to Art.6(1)(b)"
            )
        return BasisAssessment(
            activity=activity.name,
            recommended_basis=LawfulBasis.CONTRACT,
            rationale="Objectively necessary for contract performance with data subject",
            warnings=warnings,
            action_required=[
                "Document which specific contractual obligation requires this processing",
                "Confirm data subject (not a third party) is party to the contract",
                "Apply necessity test: could contract be performed with less data?",
            ],
        )

    # Priority 3: Vital interests (very narrow)
    if activity.life_threatening_emergency:
        return BasisAssessment(
            activity=activity.name,
            recommended_basis=LawfulBasis.VITAL_INTERESTS,
            rationale="Life-threatening emergency where consent cannot be obtained",
            action_required=[
                "Document why consent is unavailable (e.g., incapacitation)",
                "Confirm life-threatening nature of situation",
                "Switch to another basis (consent, contract) as soon as possible",
            ],
        )

    # Priority 4: Public task (requires statutory mandate)
    if activity.has_statutory_mandate:
        return BasisAssessment(
            activity=activity.name,
            recommended_basis=LawfulBasis.PUBLIC_TASK,
            rationale="Performance of task in public interest under statutory authority",
            action_required=[
                "Identify specific statutory provision granting public task/official authority",
                "Confirm entity qualifies as public authority or public interest body",
                "Document Art.6(3) legal basis in ROPA",
            ],
        )

    # Priority 5: Legitimate interests (requires documented 3-part assessment)
    if (
        activity.li_purpose_identified
        and activity.li_necessary
        and activity.li_balancing_favours_controller
    ):
        if activity.children_data:
            warnings.append(
                "LI unlikely to be valid for children's data — stronger protections apply (Recital 38)"
            )
        if activity.involves_special_categories:
            warnings.append(
                "LI is NOT a valid basis for special category data (Art.9) — explicit consent or another Art.9(2) ground required"
            )
        return BasisAssessment(
            activity=activity.name,
            recommended_basis=LawfulBasis.LEGITIMATE_INTERESTS,
            rationale="Legitimate interest identified, processing necessary, balancing favours controller",
            warnings=warnings,
            action_required=[
                "Complete and document Legitimate Interests Assessment (LIA)",
                "Implement Art.21 objection mechanism (right to object to LI processing)",
                "Provide LI disclosure in privacy notice (Art.13(1)(d))",
                "Review LIA annually or when processing changes",
            ],
        )

    # Default: Consent required
    if activity.involves_special_categories:
        warnings.append(
            "Special category data requires explicit consent (Art.9(2)(a)) — 'explicit' is higher bar than standard consent"
        )
    if activity.children_data:
        warnings.append(
            "Children's consent: Art.8 requires parental consent for under-16 (or under-13 per Member State)"
        )
    return BasisAssessment(
        activity=activity.name,
        recommended_basis=LawfulBasis.CONSENT,
        rationale="No other lawful basis applies — consent is required",
        warnings=warnings,
        action_required=[
            "Design consent mechanism: positive opt-in, no pre-ticked boxes",
            "Separate consent per purpose (Art.4(11) specificity requirement)",
            "Implement Art.7(3) withdrawal: as easy as giving consent",
            "Log consent: timestamp, IP, consent text version shown",
            "Do NOT bundle consent with T&C acceptance (Art.7(4))",
        ],
    )


def print_assessment(assessment: BasisAssessment):
    print(f"\n{'='*60}")
    print(f"Processing Activity: {assessment.activity}")
    print(f"Recommended Basis: {assessment.recommended_basis.value}")
    print(f"Rationale: {assessment.rationale}")
    if assessment.warnings:
        print("\n⚠️  Warnings:")
        for w in assessment.warnings:
            print(f"  • {w}")
    print("\n📋 Actions Required:")
    for a in assessment.action_required:
        print(f"  → {a}")


# Example 1: Email marketing to existing customers
email_marketing = ProcessingActivity(
    name="Marketing emails to existing customers",
    description="Sending product update and promotional emails to registered users",
    li_purpose_identified=True,
    li_necessary=True,
    li_balancing_favours_controller=True,
)
print_assessment(select_lawful_basis(email_marketing))
# → Art.6(1)(f) LI (existing customer relationship per Recital 47)
# → BUT: Art.21(2) hard objection right applies; must offer unsubscribe

# Example 2: VAT record retention
vat_records = ProcessingActivity(
    name="Invoice and VAT record retention",
    description="Retaining customer invoices for 10 years for tax compliance",
    specific_legal_provision="§ 147 AO (German Fiscal Code) — 10-year commercial records",
)
print_assessment(select_lawful_basis(vat_records))
# → Art.6(1)(c) Legal Obligation — no data subject objection right

# Example 3: Account creation
account_creation = ProcessingActivity(
    name="User account creation — name, email, password hash",
    description="Processing name and email to create and manage user account",
    is_contract_party=True,
    contract_necessary=True,
)
print_assessment(select_lawful_basis(account_creation))
# → Art.6(1)(b) Contract — core service delivery

# Example 4: Optional analytics
analytics = ProcessingActivity(
    name="Optional product analytics (behaviour tracking)",
    description="Tracking user clicks and navigation for product improvement",
)
print_assessment(select_lawful_basis(analytics))
# → Art.6(1)(a) Consent — cannot rely on contract (not necessary) or LI without documented assessment

Sample output for Example 1 (email marketing):

============================================================
Processing Activity: Marketing emails to existing customers
Recommended Basis: Art.6(1)(f) — Legitimate Interests
Rationale: Legitimate interest identified, processing necessary, balancing favours controller

📋 Actions Required:
  → Complete and document Legitimate Interests Assessment (LIA)
  → Implement Art.21 objection mechanism (right to object to LI processing)
  → Provide LI disclosure in privacy notice (Art.13(1)(d))
  → Review LIA annually or when processing changes

Basis Selection: Common SaaS Scenarios

Interaction with Art.9: Special Categories

Art.9(1) prohibits processing special category data (health, genetic, biometric, racial/ethnic origin, political opinions, religious beliefs, trade union membership, sex life/orientation) unless an exception in Art.9(2) applies. Art.9 is an additional requirement on top of Art.6 — you need both a lawful basis under Art.6 and a ground under Art.9(2).

The most common Art.9(2) grounds for SaaS:

• Art.9(2)(a) — Explicit consent (higher bar than standard consent: must be explicit, not just unambiguous)
• Art.9(2)(b) — Employment/social security law (HR systems, payroll, occupational health)
• Art.9(2)(c) — Vital interests (emergency health processing)
• Art.9(2)(g) — Public interest (health research, disease monitoring with safeguards)
• Art.9(2)(j) — Research/statistics/archiving (with Art.89 safeguards)

Developer implication: If your product processes health data (e.g., a fitness app, HR system, medical records), identify both the Art.6 basis and the Art.9(2) exception, and document both in ROPA.

EU Hosting and Lawful Basis Integrity

The choice of infrastructure directly affects the enforceability of your lawful basis:

Art.6(1)(f) Legitimate Interests (IT Security): Under US CLOUD Act, a US-based controller or processor must disclose data to US authorities on a valid warrant — without notifying the data subject. This secret compelled disclosure is structurally incompatible with the transparency requirements underpinning any Art.6 basis. Data subjects who consented to processing by a EU-based controller cannot reasonably have consented to US law enforcement access.

Art.6(1)(a) Consent: If a data subject consents to analytics processing, that consent does not extend to processing by US intelligence services under EO 12333 (no judicial authorisation, no notification). Storing consent-based analytics data on US infrastructure creates a structural consent defect.

EU-native infrastructure (such as sota.io, hosted on European servers subject only to EU/EEA law) eliminates the CLOUD Act/FISA 702 structural risk. Controllers can document a clean Art.6 basis without a shadow transfer mechanism or FISA 702 rider undermining it. This is not a theoretical risk — the EDPB's Schrems II follow-up guidance explicitly notes that US cloud infrastructure creates a structural Art.5(1)(f) and Art.6 tension for data transfers.

Enforcement: Lawful Basis Violations

Key pattern: Supervisory authorities scrutinise Art.6 basis claims retroactively. Relabelling Art.6(1)(a) consent as Art.6(1)(b) contract or Art.6(1)(f) LI after consent rates drop is treated as bad faith and results in significantly higher fines.

Art.6 Compliance Checklist for Developers

• Every processing activity in ROPA has exactly one documented Art.6(1) basis
• Basis identified before processing begins, not post-hoc
• Art.6(1)(b) processing can pass the "objective necessity" test — contract impossible without it
• Art.6(1)(c) processing references specific statutory provision with citation
• Art.6(1)(f) has documented Legitimate Interests Assessment (LIA) on file
• Consent flows: positive opt-in, separate per purpose, no pre-ticked boxes
• Consent logs: timestamp, IP, consent text version stored
• Art.7(3) withdrawal mechanism: as easy as giving consent, one-click in account settings
• Art.21 objection mechanism implemented for all Art.6(1)(f) processing
• Art.21(2) direct marketing objection: process stops immediately, no conditions
• Special category data has both Art.6 basis AND Art.9(2) ground documented
• Privacy notice (Art.13/14) discloses basis for each processing activity
• No bundling of consent with T&C acceptance (Art.7(4))
• Art.8 age verification for services directed at children
• Art.6(4) compatibility analysis completed before secondary use of data
• Infrastructure assessed for CLOUD Act/FISA 702 exposure affecting basis integrity
• Annual review of LI Assessments when processing or risk profile changes
• Consent withdrawal triggers erasure process (Art.17(1)(b)) within 30 days

GDPR Chapter I Navigation

• Art.1–4 (Scope, Definitions, Territorial Reach): GDPR Art.1–4 Developer Guide
• Art.5 (Six Principles): GDPR Art.5 Developer Guide
• Art.6 (Lawful Bases): This post
• Art.7 (Consent Conditions): Coming next — Art.7 four-part validity test + withdrawal mechanics
• Art.9 (Special Categories): Enhanced obligations for health, biometric, genetic data

Related GDPR Posts:

• Art.12–14 Transparency Obligations & Privacy Notices
• Art.15–17 Access, Rectification & Erasure Rights
• Art.25 Privacy by Design
• Art.28 Processor Agreements
• Art.32 Security Requirements
• Art.83–84 Fines & Penalties