The 6 Lawful Bases for Processing Under GDPR

Every time your SaaS company processes personal data — every database record, every analytics event, every email sent, every log entry — you need a lawful basis for that processing. This isn’t a formality. Article 6 of the GDPR requires that every processing activity is grounded in one of six specific legal bases. Without a valid basis, the processing is unlawful — full stop.

Choosing the right lawful basis for each activity has cascading consequences. It determines what you must tell people in your privacy notice, whether data subjects can object to the processing, whether you can transfer the data internationally, and what happens if your lawful basis is challenged.

This guide explains all six bases, when to use each one, and the practical implications for SaaS companies.

The Six Lawful Bases

1. Consent — Article 6(1)(a)

What it means: The data subject has given clear, affirmative agreement to the processing of their personal data for one or more specific purposes.

When to use it:

• Marketing emails and newsletters
• Non-essential cookies and tracking technologies
• Processing that goes beyond what’s needed to deliver your service
• Optional features that involve new types of data processing
• Research or surveys

When NOT to use it:

• Processing that’s necessary to deliver your service (use contractual necessity instead)
• Processing you’ll do regardless of whether the person consents
• Situations where the person can’t realistically refuse (power imbalance)

Requirements: Consent under GDPR has strict requirements — freely given, specific, informed, and unambiguous. Pre-ticked checkboxes don’t count. Bundled consent covering multiple purposes doesn’t count. And you must make withdrawal as easy as the original consent. See our consent management guide for the full requirements.

Key implication: If consent is your basis and someone withdraws it, you must stop the processing. You cannot switch to a different lawful basis retroactively.

SaaS example: A project management SaaS wants to send users a monthly newsletter about productivity tips. This is separate from the service they signed up for. Consent is the right basis — the user actively opts in, and the newsletter stops if they unsubscribe.

2. Contractual Necessity — Article 6(1)(b)

What it means: Processing is necessary for the performance of a contract with the data subject, or to take steps at their request prior to entering into a contract.

When to use it:

• Storing and managing user accounts for your SaaS product
• Processing payment information to bill for your service
• Delivering the core features of your product
• Providing customer support related to the service
• Pre-contractual steps like processing a demo request or free trial sign-up

When NOT to use it:

• Processing that’s useful but not necessary for the contract (analytics, marketing, product improvement)
• Processing that serves your interests more than the service delivery
• Processing for features the user hasn’t activated or purchased

The “necessary” test: The processing must be genuinely necessary to perform the contract — not merely useful or desirable. Storing a user’s name and email to let them log in is necessary. Tracking their mouse movements for a heatmap is not necessary for the contract, even if it helps you improve the product. The EDPB has been clear: contractual necessity must be interpreted narrowly.

SaaS example: A CRM SaaS stores customer contact records, deal pipeline data, and activity logs because the entire purpose of the service is to manage those records. Processing this data is directly necessary to perform the contract.

3. Legal Obligation — Article 6(1)(c)

What it means: Processing is necessary to comply with a legal obligation to which the controller is subject.

When to use it:

• Retaining financial records for tax reporting (typically 7–10 years)
• Reporting to financial regulators (anti-money laundering)
• Complying with court orders or legal proceedings
• Employment law requirements (payroll, social security, workplace health and safety records)
• Regulatory reporting obligations

When NOT to use it:

• “Just in case” retention — the obligation must be specific and current
• Industry best practices that aren’t legally mandated
• Contractual obligations (use contractual necessity instead)

The specificity requirement: You must be able to point to a specific law, regulation, or legal obligation that requires the processing. “We might need this for legal reasons” doesn’t qualify. The obligation must be real, current, and applicable to your organization.

SaaS example: A SaaS company retains customer invoices and payment records for 10 years to comply with German tax law (Abgabenordnung). The specific statute and retention period are documented in the ROPA.

4. Vital Interests — Article 6(1)(d)

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

When to use it: Essentially only in life-or-death situations — medical emergencies, natural disasters, humanitarian crises.

Relevance for SaaS: This basis is almost never applicable to SaaS companies. If you’re building a health monitoring or emergency response product, it might apply in extreme cases. For standard business operations, look to the other five bases.

5. Public Interest / Official Authority — Article 6(1)(e)

What it means: 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 to use it: Government agencies, public bodies, and organizations performing functions of public interest (public health, research, archiving).

Relevance for SaaS: Rarely applicable unless you’re contracted by a government agency to perform a public function. If you’re a private SaaS company, this basis is unlikely to apply to any of your processing activities.

6. Legitimate Interest — Article 6(1)(f)

What it means: Processing is necessary for the purposes of legitimate interests pursued by the controller or a third party, except where those interests are overridden by the interests, rights, or freedoms of the data subject.

When to use it:

• Product analytics and usage tracking (aggregated, non-intrusive)
• Fraud prevention and security monitoring
• Network and information security (including logging and monitoring)
• Internal administration and business operations
• Direct marketing to existing customers (in some jurisdictions, with appropriate safeguards)
• Customer satisfaction surveys
• Bug tracking and error reporting

When NOT to use it:

• Processing that’s primarily for your benefit with significant impact on individuals
• Large-scale profiling without transparency
• Processing that people wouldn’t reasonably expect
• Where consent or another basis is more appropriate

The balancing test: Legitimate interest is the most flexible basis, but it requires a documented balancing test — the Legitimate Interest Assessment (LIA). You must weigh your interests against the data subject’s rights and expectations. If the data subject’s interests override yours, legitimate interest doesn’t work.

The LIA process:

1. Identify the legitimate interest. What specific interest are you pursuing? It must be real, not hypothetical.
2. Is the processing necessary? Could you achieve the same goal without the data, or with less data?
3. Balance against data subject interests. Consider: Would people expect this processing? How intrusive is it? Could it cause harm? What safeguards are in place?
4. Document the assessment. Record your analysis and conclusion.

SaaS example: A SaaS company uses product analytics to track which features are used, how often, and by how many users. The data is pseudonymized and aggregated for analysis. The legitimate interest is product improvement; the impact on users is minimal (no individual profiling, no sensitive data, aligned with user expectations). A documented LIA supports this basis.

How to Choose the Right Basis

Decision Framework

For each processing activity, work through this order:

1. Is there a legal obligation? If law requires the processing, use legal obligation. This is the clearest basis.

2. Is the processing necessary for a contract? If the processing is genuinely required to deliver the service the person signed up for, use contractual necessity.

3. Does legitimate interest apply? If the processing serves a real business interest, is proportionate, and wouldn’t surprise the data subject, conduct a balancing test. If it passes, legitimate interest may be the right basis.

4. Is consent appropriate? If none of the above apply — the processing is optional, serves your interests more than the user’s, or the person should have genuine choice — use consent.

Common SaaS Processing Activities and Their Bases

Processing Activity	Recommended Basis	Rationale
User account creation and management	Contractual necessity	Required to deliver the service
Payment processing	Contractual necessity + Legal obligation	Contract for billing; tax law for records
Core product functionality	Contractual necessity	What the user signed up for
Customer support	Contractual necessity	Part of service delivery
Product analytics (pseudonymized)	Legitimate interest	Product improvement, low impact
Security monitoring and logging	Legitimate interest	Network security, fraud prevention
Marketing emails to prospects	Consent	Not an existing customer relationship
Marketing emails to customers (similar products)	Legitimate interest (varies by country)	Soft opt-in permitted in some jurisdictions
Newsletter to non-customers	Consent	No existing relationship
Non-essential cookies	Consent	ePrivacy Directive requirement
Employee payroll processing	Contractual necessity + Legal obligation	Employment contract and tax law
Job applicant data	Consent or Legitimate interest	Depends on jurisdiction and context
Financial record retention	Legal obligation	Tax and accounting law
Product improvement research	Legitimate interest or Consent	Depends on data used and methodology

Common Mistakes

Defaulting to consent for everything. Consent seems like the safest choice — “we asked, they agreed.” But relying on consent when it’s not the right basis creates problems. If consent isn’t freely given (because refusing means losing the service), it’s invalid. And if you wouldn’t actually stop the processing when consent is withdrawn, you’re not being honest about your lawful basis.

Not documenting the chosen basis. Your ROPA should record the lawful basis for every processing activity, along with the justification. Supervisory authorities will ask for this. “We thought legitimate interest was fine” without a documented LIA doesn’t demonstrate accountability.

Using one basis but communicating another. Your privacy notice must accurately state which lawful basis applies to each processing purpose. If your notice says “consent” but you actually rely on legitimate interest, there’s a disconnect that creates both legal and trust problems.

Trying to switch bases when challenged. If someone withdraws consent, you can’t retroactively claim you had a legitimate interest all along. The EDPB has made clear that switching bases to avoid the consequences of the original choice is not permitted. Choose carefully from the start.

Confusing legitimate interest with “we have a reason.” Every organization has reasons for processing data. Legitimate interest requires more — a documented assessment showing that your interest is real and specific, the processing is necessary for that interest, and the data subject’s rights don’t override it.

How GRCTrail Supports Lawful Basis Documentation

GRCTrail helps you document and maintain your lawful basis choices:

ROPA with lawful basis tracking. Each processing activity in your Record of Processing Activities includes the documented lawful basis, linked to supporting assessments (LIAs for legitimate interest, consent records for consent).

Consistency checks. GRCTrail flags inconsistencies between your documented lawful basis and your published privacy notice, helping ensure what you tell data subjects matches your internal documentation.

LIA templates. Conduct and document Legitimate Interest Assessments using structured templates that cover all required elements.

Document your lawful bases systematically →

Related Guides

• Consent Management — When consent is the right basis
• Records of Processing Activities (ROPA) — Documenting your processing and bases
• Privacy Notice Requirements — Communicating your lawful bases to data subjects
• GDPR Compliance Checklist — The full compliance framework

Get started with GRCTrail →