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 is not just selecting the right basis once. It is ensuring every entity, every processing activity, and every business unit has documented their lawful basis correctly — and that those records 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. In a post-Schrems II landscape, where cross-border data transfers face 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–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
In a post-Schrems II landscape, 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.
