The Six Lawful Bases for Processing Under GDPR: What They Mean and How to Get Them Right
Every processing activity in your organization needs a lawful basis. Choosing the wrong one, or failing to document it, is the single most common GDPR compliance gap auditors find. This guide breaks down all six bases, explains when each applies, and shows how organizations with complex entity structures keep them documented and defensible.
Why Lawful Basis Selection Is the Foundation of GDPR Compliance
Article 6(1) of the GDPR states that processing personal data is lawful only if, and to the extent that, at least one of six conditions applies. This is not optional, not flexible, and not something you can backfill after a supervisory authority comes knocking.
For organizations managing multiple subsidiaries across jurisdictions, the challenge goes beyond selecting the right basis once. Every entity, every processing activity, and every business unit has to document its lawful basis correctly, and those records have to stay current as processing evolves.
The scale of the problem
78% of multi-entity organizations still manage Records of Processing Activities in spreadsheets. When lawful bases live in column G of a shared Excel file, they do not get reviewed, updated, or challenged. They decay silently until an audit exposes the gap.
What goes wrong in practice
The most common failure pattern is not choosing the wrong lawful basis. It is never explicitly choosing one at all. Processing activities get created, data flows are established, and the lawful basis field remains blank or defaults to "consent" because someone assumed that was always the safe choice.
The second most common failure: choosing a lawful basis at the start of a processing activity and never reviewing it, even as the purpose, scope, or data categories change over time. A basis that was valid when a processing activity was designed may no longer apply two years later.
Lawful Basis 1 of 6
Consent
Article 6(1)(a): The data subject has given consent to the processing of their personal data for one or more specific purposes.
When consent applies
Consent is the right basis when you are offering the data subject a genuine choice and control over how their data is used. It works well for marketing communications, optional analytics, newsletter sign-ups, and non-essential cookies. The key word is "genuine": if the data subject has no realistic ability to refuse without negative consequences, consent is not freely given.
What GDPR requires for valid consent
- Freely given: no bundling consent with acceptance of terms, no imbalance of power that undermines free choice
- Specific: consent must be granular, covering distinct processing purposes separately
- Informed: the data subject must know who the controller is, what processing will occur, and for what purpose
- Unambiguous: requires a clear affirmative action (opt-in, not pre-ticked boxes)
- Withdrawable: must be as easy to withdraw as to give, and the data subject must be told this before consenting
Practical examples
A software company sends a monthly product newsletter. Subscribers actively opt in via a checkbox during account creation. The checkbox is not pre-ticked. The privacy notice clearly states what the subscriber will receive, how often, and how to unsubscribe. This is valid consent.
A hospital asks patients to consent to data processing for treatment. This is problematic: the patient has no genuine choice because they need treatment. Contract or legal obligation would be more appropriate bases here.
Common mistake
Using consent as the default basis for employee data processing. The employer-employee relationship creates an inherent power imbalance that makes consent virtually never "freely given." Most employee data processing should rely on contract performance (Article 6(1)(b)) or legal obligation (Article 6(1)(c)).
Multi-entity complexity
When you operate across multiple subsidiaries, consent management becomes exponentially harder. Each entity may be a separate data controller, meaning consent collected by your German subsidiary does not automatically authorize processing by your Swiss parent company. Consent records must be entity-specific, auditable, and linked to specific processing activities, not buried in a shared spreadsheet.
Lawful Basis 2 of 6
Contract
Article 6(1)(b): 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.
When contract applies
This basis covers processing that is genuinely necessary to fulfil your contractual obligations to the data subject, or to take pre-contractual steps they requested. The emphasis is on "necessary": just because data processing is mentioned in a contract does not make it necessary for the contract's performance.
Practical examples
- Processing a customer's shipping address to deliver a product they ordered: necessary for contract performance
- Processing an employee's bank details to pay their salary: necessary for the employment contract
- Running a credit check on a loan applicant at their request: pre-contractual steps
- Sending marketing emails to existing customers: not necessary for the contract, so this basis does not apply
The "necessity" test
The European Data Protection Board (EDPB) has made clear that this basis cannot be used to justify processing that is merely useful or mentioned in the contract. The processing must be objectively necessary: meaning the contract cannot be performed without it. Adding a clause to your terms of service that says "we process your data for profiling" does not make profiling necessary for contract performance.
Common mistake
Stretching Article 6(1)(b) to cover all processing mentioned in terms of service. If you include behavioural advertising in your terms, that does not make it "necessary" for the service. The EDPB specifically addressed this in Guidelines 2/2019, finding that many online services were improperly relying on contract performance for processing that should require consent or legitimate interests.
Multi-entity complexity
In group structures, the contracting entity and the processing entity are often different. If your customer's contract is with your UK subsidiary but data processing happens at the group level in Switzerland, you need to be clear about which entity is the controller, what basis applies to each stage of processing, and whether a data processing agreement or joint controller arrangement is needed.
Lawful Basis 3 of 6
Legal Obligation
Article 6(1)(c): Processing is necessary for compliance with a legal obligation to which the controller is subject.
When legal obligation applies
This basis applies when you are required by EU or member state law to process personal data. The obligation must be established by law, not by contractual obligations, industry standards, or self-regulatory codes. You do not need consent when processing is legally mandated, and in fact, relying on consent here would be inappropriate because the data subject cannot meaningfully refuse.
Practical examples
- Employers processing employee tax information to comply with tax legislation
- Financial institutions reporting suspicious transactions under anti-money laundering regulations
- Companies retaining accounting records for the legally mandated retention period
- Healthcare providers sharing patient data with public health authorities during disease outbreaks, as required by law
Key requirements
You should be able to identify the specific legal provision that creates the obligation. "We think we're probably required to" is not sufficient. Document the law, the specific provision, and the scope of processing it mandates. The processing must not go beyond what the legal obligation requires.
Common mistake
Confusing regulatory guidance or industry best practices with legal obligations. A recommendation from a supervisory authority is not the same as a legal obligation. Similarly, contractual obligations owed to other companies (like a data processing agreement) do not create a "legal obligation" under Article 6(1)(c): that basis requires an obligation under law.
Multi-entity complexity
Legal obligations vary by jurisdiction. Your German subsidiary may face different retention requirements than your Swiss entity for the same category of records. When managing compliance across a group, each entity needs to identify the specific laws applicable in its jurisdiction. A one-size-fits-all approach leads to either over-processing or non-compliance.
Lawful Basis 4 of 6
Vital Interests
Article 6(1)(d): Processing is necessary to protect the vital interests of the data subject or of another natural person.
When vital interests applies
This is the narrowest lawful basis. "Vital interests" means life-or-death situations, literally. It applies when processing is necessary to protect someone's life and no other lawful basis can be relied upon. The GDPR explicitly states this basis should only be used where processing "cannot be manifestly based on another legal basis."
Practical examples
- Sharing a patient's medical records with emergency services when the patient is unconscious and cannot give consent
- Processing personal data during a natural disaster to help locate and assist victims
- Sharing an employee's blood type with paramedics after a workplace accident
Why this basis is rarely appropriate
In the vast majority of commercial data processing scenarios, vital interests does not apply. If you can plan ahead and obtain consent, if you have a contractual relationship, or if another basis fits, use that instead. Vital interests is a last resort, not a convenience.
For most organizations
If you are documenting vital interests as a lawful basis for routine processing activities, something has gone wrong. This basis should appear rarely, if ever, in a typical organization's Record of Processing Activities. Its inclusion in your ROPA should raise a review flag, not pass unnoticed.
Lawful Basis 5 of 6
Public Task
Article 6(1)(e): 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.
When public task applies
This basis is primarily relevant to public authorities and organizations performing functions of a public nature. The task or authority must have a clear basis in law; it is not enough to claim that your processing serves the public interest in a general sense. There must be a specific legal foundation for the function you are performing.
Practical examples
- A government agency processing citizen data to administer social security benefits
- A public university processing student data for degree administration and educational research
- A regulatory body processing data as part of its supervisory functions
- A private company contracted by government to process census data, acting under delegated public authority
Relevance for private-sector organizations
Most private companies will not rely on this basis for their core processing activities. However, it can be relevant when private entities perform functions delegated by public authorities, or when processing is carried out under a specific statutory power. If you are a private organization considering this basis, identify the specific legal provision that vests you with the relevant function or authority.
Common mistake
Private companies claiming public task because their processing has some indirect public benefit. Running a health app that "improves public health outcomes" does not mean you are performing a public task. The basis requires a specific legal mandate or delegated authority, not a general claim of societal benefit.
Lawful Basis 6 of 6
Legitimate Interests
Article 6(1)(f): Processing is necessary for the purposes of the legitimate interests pursued by the controller or a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject.
When legitimate interests applies
This is the most flexible lawful basis, and consequently the most frequently misapplied. It can cover a wide range of processing activities, from fraud prevention and network security to direct marketing to existing customers and intra-group data transfers. But flexibility comes with a requirement: you must conduct a balancing test before relying on it.
The three-part test
Every legitimate interest assessment must address three questions:
- Purpose test: Is there a legitimate interest? Is it real and clearly articulated, not hypothetical or vague?
- Necessity test: Is the processing actually necessary to achieve that interest? Could you reasonably achieve the same purpose with less data or less intrusive processing?
- Balancing test: Do the individual's interests, rights, and freedoms override your legitimate interest? Consider the nature of the data, the expectations of the data subject, the impact on them, and what safeguards you have in place.
Practical examples
- Processing employee data for IT security monitoring: legitimate interest in protecting company networks, balanced against employee privacy expectations with clear policies
- Sending direct marketing to existing customers about similar products: legitimate interest recognized in Recital 47, subject to opt-out rights
- Sharing customer data within a corporate group for internal administrative purposes: explicitly recognized in Recital 48 as a legitimate interest
- Fraud prevention and detection: a well-established legitimate interest
Recital 48: "Controllers that are part of a group of undertakings or institutions affiliated to a central body may have a legitimate interest in transmitting personal data within the group of undertakings for internal administrative purposes, including the processing of clients' or employees' personal data."
GDPR Recital 48: relevant for multi-entity organizations
Common mistake
Relying on legitimate interests without documenting the balancing test. If you cannot produce a written Legitimate Interest Assessment (LIA) that walks through all three parts of the test, you have not properly established this basis. Many organizations claim legitimate interests verbally but have no documented assessment, which means they have no evidence for a supervisory authority.
Multi-entity complexity
Legitimate interests is particularly important, and particularly complex, for corporate groups. Intra-group data transfers often rely on this basis, but each entity needs its own assessment. The legitimate interest of the parent company in centralizing HR data does not automatically override the privacy rights of employees in a subsidiary operating in a jurisdiction with stricter protections. Each transfer needs its own documented balancing test.
How Priverion helps
Priverion's AI-assisted DPIA and LIA drafting pre-populates the three-part legitimate interest assessment based on your processing activity details, data categories, and data subject types. Your DPO reviews and finalizes, cutting assessment time from days to hours while maintaining full human oversight. All assessments are linked to the corresponding processing activity in your ROPA for complete audit traceability.
How to Choose the Right Lawful Basis: A Practical Decision Process
Choosing a lawful basis is not a one-time exercise. It should happen at the design stage of every new processing activity and be reviewed whenever the purpose, scope, or context of processing changes. Here is the decision process we recommend:
Step 1: Define the purpose precisely
Before you can select a basis, you need absolute clarity on why you are processing personal data. "For business purposes" is not a purpose. "To process monthly payroll for employees of our German subsidiary" is. The more specific your purpose, the easier it is to identify the correct basis.
Step 2: Eliminate bases that clearly do not apply
Most processing activities can immediately rule out vital interests (not a life-or-death situation) and public task (not a public authority or delegated function). This typically leaves four candidates: consent, contract, legal obligation, and legitimate interests.
Step 3: Check for a legal obligation first
If specific legislation mandates the processing, use legal obligation. This is the clearest basis: there is no balancing test, no consent withdrawal risk, and the documentation is straightforward: cite the law and the provision.
Step 4: Check for contractual necessity
If processing is genuinely necessary to perform a contract with the data subject, use contract. Remember the necessity test: the contract could not be performed without this specific processing.
Step 5: Assess whether consent is appropriate
Consent works when you can offer genuine choice, when withdrawal will not cause problems, and when there is no power imbalance. If any of these conditions are not met, consent is not the right choice, even if it feels like the "safest" option.
Step 6: Consider legitimate interests last
If no other basis fits naturally, legitimate interests may apply, but only if you can pass the three-part test and document it. Do not use legitimate interests as a catch-all default. Use it when you have a real, specific interest that can withstand scrutiny.
For multi-entity organizations
Every subsidiary may need to make this determination independently for processing activities they control. A group privacy policy is a good starting point, but it does not replace entity-level documentation. Priverion enables each entity to document their lawful basis selections within a unified platform, giving group DPOs visibility across all entities while maintaining the specificity that supervisory authorities expect.
Common decision traps to avoid
- Defaulting to consent for everything: consent is not always the safest basis, especially when withdrawal would disrupt legitimate processing
- Choosing a basis retrospectively: the basis must be determined before processing begins, not after an audit request
- Switching bases after the fact: while not explicitly prohibited, switching your lawful basis is a red flag for regulators and suggests your original assessment was inadequate
- Ignoring special category data: Article 9 requires an additional condition on top of your Article 6 basis when processing sensitive data (health, biometric, racial/ethnic origin, etc.)
- Failing to review: a basis that was appropriate when processing started may no longer apply if the purpose, scope, or context has changed
What Lawful Basis Management Actually Requires at Scale
Identifying the right lawful basis is only the beginning. Documenting it, linking it to every processing activity, and keeping it defensible across every entity in your group: that is where most privacy programs break down.
Lawful Basis Linked to Every Processing Activity
Every entry in your Record of Processing Activities automatically requires a lawful basis selection. No orphaned records. No undocumented processing. Auditors see a complete, structured mapping from Article 6 basis to the specific activity it authorizes, across every subsidiary in your group.
100% ROPA recertification rate, fully automated
AYA, achieved through Priverion's automated recertification workflows
AI-Assisted Lawful Basis Recommendations
When business units create new processing activities, Priverion's AI suggests the most appropriate lawful basis based on the processing description, data categories, and data subject types involved. Your DPO reviews and approves: the AI assists, humans decide. No customer data is used for model training. All processing stays within Swiss infrastructure.
60% reduction in compliance admin time
Aircraft manufacturer, first 6 months after implementation
Automated DPIA Triggering for High-Risk Bases
Select legitimate interest or consent for special category data and the platform automatically flags the activity for a Data Protection Impact Assessment. AI-assisted DPIA drafting pre-populates risk scoring, proportionality checks, and safeguard recommendations, reducing the time from trigger to completed assessment from weeks to hours.
200+ hours saved in compliance preparation
Medtec, ISO 27001 preparation with Priverion
Group-Wide Visibility Across All Entities
One dashboard shows which lawful basis each subsidiary relies on for every processing activity. Spot inconsistencies instantly: if your German entity uses consent for employee monitoring while your Swiss entity uses legitimate interest for the same activity, you will see it before the auditor does. Board-ready reporting shows compliance posture at a glance.
24/7 DPO support across multiple entities
Trapeze, continuous oversight enabled by Priverion
Audit-Ready Evidence Packages on Demand
When a supervisory authority requests documentation of your lawful basis decisions, generate a complete evidence package in minutes, not the weeks it takes when lawful bases are tracked across 47 spreadsheets. Every record includes the basis selected, the rationale, the reviewer, the date, and any associated legitimate interest assessments or DPIAs.
100% vendor risk assessment coverage
Zurzach Care, full vendor documentation through Priverion
Swiss Data Sovereignty by Default
Your lawful basis records, processing activity documentation, and compliance evidence never leave Swiss infrastructure. Since Schrems II, cross-border data transfers have faced ongoing legal uncertainty. Swiss-hosted is not a checkbox: it is a structural safeguard. Your compliance records are protected by some of the strongest data protection laws in the world.
Swiss-built, Swiss-hosted, European data residency
Priverion infrastructure, all data processed within Switzerland
200+
Hours saved on ROPA management
Medtec recovered 200+ hours during ISO 27001 preparation by replacing manual record-keeping with automated recertification workflows, first 6 months
60%
Lower total cost vs. OneTrust
Based on comparative pricing analysis for multi-entity deployments (10 to 50 subsidiaries): entity-based pricing with no per-user or per-module expansion traps
3 mo
Ahead of schedule on ISO 27001
Medtec accelerated their ISO 27001 certification timeline by 3 months using Priverion's audit-ready evidence packages and automated documentation
Why mid-market teams switch from OneTrust to Priverion
OneTrust was built for Fortune 500 complexity, and Fortune 500 budgets. If you're managing privacy across 5 to 50 subsidiaries, you need enterprise-grade capabilities without the enterprise overhead.
The OneTrust experience
Per-user, per-module pricing
Costs escalate unpredictably as you add users or modules. CFOs can't forecast annual spend because every new team member triggers a pricing conversation.
US-headquartered, US-hosted
Since Schrems II, US-based data hosting creates additional legal complexity for European organizations managing cross-border data transfers.
Designed for Fortune 500
Feature-rich to the point of overwhelming. Mid-market teams end up paying for ESG, ethics hotlines, and cookie consent modules they never use.
Months-long implementation
Typical enterprise rollout requires dedicated implementation consultants, custom professional services, and 6+ months before you see value.
200+ shallow integrations
A long connector list looks good on paper but creates maintenance overhead. Many integrations are surface-level, requiring ongoing custom work to keep functional.
The Priverion experience
Predictable, per-company pricing
Based on number of entities and organizational size, not per-user or per-module. Add as many users as you need without triggering a pricing surprise.
Swiss-built, Swiss-hosted
European data residency is not a marketing checkbox: it's a legal advantage. All data processing within Swiss infrastructure, offering the strongest data protection jurisdiction in Europe.
Purpose-built for mid-market groups
Every feature exists because a DPO managing multi-entity compliance needed it. No bloat, no modules you'll never touch. We don't cover ESG, ethics hotlines, or cookie consent, and that's by design.
Operational in weeks
Aircraft manufacturer reduced compliance admin time by 60% within their first 6 months. Implementation is measured in weeks, not quarters, with guided onboarding, not a consulting engagement.
Aircraft manufacturer, first 6 months post-deployment
Deep integrations where they matter
We integrate deeply with the systems that drive privacy workflows (HR, procurement, IT asset management) rather than offering 200 shallow connectors that create maintenance overhead.
Considering a switch? Most teams are fully migrated within 4 weeks.
Book a 30-min walkthroughDownload the Lawful Basis Decision Framework
A structured, one-page decision tree that walks your team through lawful basis selection for any processing activity, designed for DPOs managing multi-entity compliance.
- Step-by-step decision tree covering all six Article 6(1) bases
- Documentation checklist for each basis
- Red flags that signal you have chosen the wrong basis
- Special category data overlay: Article 9 conditions
- Multi-entity considerations for group-wide consistency
No registration wall. Direct PDF download. If you would like a walkthrough of how Priverion automates lawful basis tracking across your group, book a 30-minute session.
Stop managing privacy in spreadsheets
See what group-wide privacy management looks like when it actually works
In 30 minutes, we will walk through your specific multi-entity setup and show you how teams like Aircraft manufacturer cut compliance admin time by 60%, and how your DPOs can spend their time on strategic work instead of chasing recertifications.
Weeks, not months
Average time to go live
No per-user pricing
Predictable costs that scale with entities
100% Swiss-hosted
European data residency guaranteed
No commitment required. We will tailor the session to your entity structure and compliance priorities.
▸ About this page: references, definitions, and FAQs
Key Takeaways: GDPR Lawful Bases in 2026
Every processing activity under the GDPR must rely on one of six lawful bases defined in Article 6(1). Selecting the wrong basis, or failing to document one at all, is the most common compliance gap found during supervisory authority audits. Organizations operating across multiple legal entities face additional complexity because each controller must independently justify and record its lawful basis. A centralized, Swiss-hosted GRC platform like Priverion enables entity-specific ROPA management, automated lawful-basis tracking, and cross-entity audit trails.
Definitions
What is a lawful basis under GDPR?
Lawful basis refers to one of six legal grounds listed in GDPR Article 6(1) that a data controller must identify and document before processing personal data. The six bases are: consent, contract performance, legal obligation, vital interests, public task, and legitimate interests. [EDPB Guidelines]
What is a Record of Processing Activities (ROPA)?
A Record of Processing Activities is a mandatory register under GDPR Article 30 that documents each processing activity, its purpose, categories of data subjects and personal data, recipients, transfers, retention periods, and the lawful basis relied upon.
What is a Legitimate Interest Assessment (LIA)?
A Legitimate Interest Assessment is a structured, documented evaluation required when relying on Article 6(1)(f). It comprises three steps: (1) identifying the legitimate interest, (2) demonstrating necessity, and (3) balancing the interest against the data subject's rights and freedoms. The EDPB expects LIAs to be recorded and available for supervisory authority review.
What is a Data Protection Impact Assessment (DPIA)?
A Data Protection Impact Assessment is required under GDPR Article 35 when processing is likely to result in a high risk to the rights and freedoms of natural persons. DPIAs must document the lawful basis, necessity, proportionality, and risk-mitigation measures for the processing activity.
Statistics and Enforcement Context
According to the IAPP-EY 2023 Privacy Governance Report, 78% of multi-entity organizations still manage Records of Processing Activities in spreadsheets rather than dedicated GRC platforms. The GDPR Enforcement Tracker (maintained by CMS Law) recorded over €4.5 billion in cumulative GDPR fines by the end of 2024, with "insufficient legal basis for data processing" ranking as the single most frequently cited infringement category. The European Data Protection Board noted in its 2023 contribution to the GDPR evaluation that lawful-basis documentation remains a systemic weakness across EU member states. A 2024 Gartner forecast projected that by 2026, 75% of the world's population will have personal data covered by modern privacy regulations, increasing the urgency of lawful-basis compliance for multinational organizations.
Frequently Asked Questions
What are the six lawful bases for processing personal data under GDPR?
Article 6(1) of the GDPR defines six lawful bases: (a) Consent, (b) Contract performance, (c) Legal obligation, (d) Vital interests, (e) Public task, and (f) Legitimate interests. Every processing activity must rely on at least one of these bases, and the chosen basis must be documented before processing begins. The full text is available at EUR-Lex.
How do I choose the correct lawful basis for a processing activity?
Start by identifying the purpose of processing. If the data subject has genuine choice, consent may apply. If processing is necessary to fulfil a contract with the data subject, use contract performance. Legal obligation applies when EU or member-state law mandates the processing. Vital interests cover life-threatening emergencies. Public task applies to official authority functions. Legitimate interests requires a three-part balancing test documented via a Legitimate Interest Assessment. The EDPB guidelines provide detailed decision criteria.
Can I change the lawful basis after processing has started?
The EDPB advises that switching lawful bases after processing has begun is generally not permissible. As stated in Recital 40, the lawful basis must be identified and documented before processing starts. If the purpose of processing changes materially, a new lawful basis assessment is required.
Why is consent often the wrong default for employee data?
The employer-employee relationship creates an inherent power imbalance. Because employees may fear negative consequences for refusing, consent is rarely considered "freely given" under GDPR Article 7 and Recital 43. Most employee data processing should rely on contract performance (Article 6(1)(b)) or legal obligation (Article 6(1)(c)).
What is a Legitimate Interest Assessment (LIA) and when is it required?
A Legitimate Interest Assessment is a documented three-part test required when relying on Article 6(1)(f). It evaluates: (1) whether the controller or third party has a legitimate interest, (2) whether the processing is necessary to achieve that interest, and (3) whether the data subject's rights and freedoms override that interest. The EDPB and national supervisory authorities expect LIAs to be recorded and available for inspection.
How do multi-entity organizations manage lawful basis documentation?
Each legal entity acting as a data controller must independently document its lawful basis for every processing activity in its ROPA under Article 30. In corporate groups, consent collected by one subsidiary does not automatically extend to another. A centralized GRC platform enables entity-specific ROPA management with inherited templates and cross-entity audit trails.
What are the GDPR fines for failing to document a lawful basis?
Infringements of Article 6 fall under the higher tier of GDPR administrative fines: up to €20 million or 4% of total worldwide annual turnover, whichever is greater, per Article 83(5)(a). According to the GDPR Enforcement Tracker, lawful-basis violations have been among the most frequently fined infringement categories since 2018.
Does the Swiss FADP use the same lawful bases as the GDPR?
No. The revised Swiss Federal Act on Data Protection (FADP/nDSG), effective since 1 September 2023, follows a different model. Under Swiss law, data processing by private persons is lawful unless it violates data protection principles: there is no requirement to identify a specific lawful basis as under GDPR Article 6. The full text is available at fedlex.admin.ch. However, organizations subject to both GDPR and FADP must still document GDPR lawful bases for EU/EEA data subjects.
Comparison: GDPR Lawful Bases at a Glance
| Lawful Basis | GDPR Article | Typical Use Cases | Key Requirement | Common Pitfall |
|---|---|---|---|---|
| Consent | Art. 6(1)(a) | Marketing emails, optional analytics, cookies | Freely given, specific, informed, unambiguous | Using consent for employee data despite power imbalance |
| Contract | Art. 6(1)(b) | Order fulfilment, salary payments, pre-contractual steps | Processing must be objectively necessary for the contract | Stretching to cover behavioural advertising in ToS |
| Legal Obligation | Art. 6(1)(c) | Tax reporting, AML/KYC checks, employment law | Must cite specific EU or member-state law | Relying on vague "regulatory requirements" without citing the law |
| Vital Interests | Art. 6(1)(d) | Medical emergencies, disaster response | Life-threatening situation; no other basis available | Using for routine health data processing |
| Public Task | Art. 6(1)(e) | Government services, public-authority functions | Task carried out in the public interest or official authority | Private companies claiming public-task basis without mandate |
| Legitimate Interests | Art. 6(1)(f) | Fraud prevention, network security, direct marketing | Three-part balancing test (LIA) must be documented | Failing to conduct or document the balancing test |
