The mistake most SaaS founders make
When founders first read GDPR, they assume the answer to "what's our lawful basis?" is always "consent." It's intuitive — you're asking users to trust you with their data, so you get their permission. Simple, right?
Wrong. Consent is actually one of the weakest lawful bases under GDPR — it can be withdrawn at any time, it must be freely given and specific, and it creates ongoing management obligations. Reaching for consent when you don't need it makes your product more fragile, not more compliant.
Article 6 provides six lawful bases. Most SaaS products rely primarily on contract, legal obligation, and legitimate interests — with consent reserved for the specific cases where it's actually required.
The six lawful bases under GDPR Article 6
| Basis | Article | When it applies |
|---|---|---|
| Consent | 6(1)(a) | Data subject has given clear, specific, freely given, unambiguous consent |
| Contract | 6(1)(b) | Processing is necessary to perform a contract with the data subject, or to take pre-contractual steps at their request |
| Legal obligation | 6(1)(c) | Processing is required to comply with EU or member state law (e.g., tax records, AML) |
| Vital interests | 6(1)(d) | Necessary to protect someone's life; rarely relevant for SaaS |
| Public task | 6(1)(e) | Processing by public authorities; rarely relevant for private SaaS |
| Legitimate interests | 6(1)(f) | Necessary for the legitimate interests of the controller or a third party, unless overridden by the data subject's rights |
What is legitimate interests (Article 6(1)(f))?
Legitimate interests (LI) is the most flexible lawful basis. It applies when:
- You have a legitimate interest (a real, lawful purpose that benefits you or a third party).
- Processing is necessary for that interest (not just useful — necessary).
- The interest is not overridden by the data subject's rights and freedoms (the balancing test).
You must document this analysis in a Legitimate Interests Assessment (LIA) before processing begins. The LIA does not need to be published, but you must be able to produce it if your DPA asks.
What legitimate interests covers in practice (SaaS examples)
- Security and fraud prevention: logging IP addresses, failed login attempts, rate limiting, abuse detection. LI is the standard basis here — no consent required.
- Product analytics: tracking feature usage, session duration, funnel analysis with pseudonymized user IDs. LI is appropriate where the data is used to improve the product for users.
- B2B marketing to existing customers: emailing customers about related products/services. The "soft opt-in" under ePrivacy Directive aligns with LI in many EU member states.
- Anti-spam and content moderation: automated scanning of user-generated content for illegal material.
- Network and IT security monitoring: SIEM, intrusion detection, access logs. LI is the correct basis.
- Internal business operations: customer success data, sales pipeline tracking, support ticket data.
- Intra-group data sharing: sharing data between group companies for legitimate administrative purposes, provided an LIA is done.
When consent is actually required
Consent is mandatory (not just an option) in these specific situations:
- Marketing cookies and non-essential tracking: under the ePrivacy Directive (the "Cookie Law"), storing or accessing information on a user's device for non-essential purposes requires prior consent. This is separate from GDPR's lawful basis requirement.
- Email marketing to prospects who haven't bought from you: cold email marketing requires consent or a legitimate prior relationship in most EU member states.
- Special category data (Article 9): health, religious beliefs, sexual orientation, biometric data, racial/ethnic origin, political opinions, trade union membership, genetic data. These require explicit consent (or another Art. 9(2) derogation). LI is not available for special category data.
- Automated decision-making with legal/significant effects (Article 22): consent is one route to legitimize solely automated decisions; human oversight is another.
- Children's data (under 16 in most EU states): parental consent required for information society services directed at children.
How to do a Legitimate Interests Assessment (LIA)
A LIA is a three-part test:
Step 1: Purpose test
Is your interest legitimate? Ask: is it lawful? Does it reflect a real and present business need? Is it recognized as legitimate by GDPR Recitals (71, 47, 48, 49) or DPA guidance?
Examples of legitimate interests recognized in GDPR Recitals: preventing fraud, ensuring network security, direct marketing to existing customers, intra-group data transfers for administrative purposes.
Step 2: Necessity test
Is processing necessary to achieve your interest? "Helpful" or "convenient" is not enough. If you can achieve the same result without processing personal data (or with less data), you must take that route.
Step 3: Balancing test
Does the data subject's right to privacy override your interest? Consider:
- Nature of the data (more sensitive = harder to justify)
- Reasonable expectations of the data subject (would they expect this processing?)
- Whether the processing causes harm (financial, emotional, reputational)
- Whether there are safeguards in place (pseudonymization, access controls, retention limits)
If the balance tips in favor of the data subject, legitimate interests doesn't apply — you need consent or another basis.
Documenting your LIA
A minimal LIA for a SaaS product looks like this:
| Field | Example |
|---|---|
| Processing activity | Product analytics — tracking feature usage per user session |
| Purpose / legitimate interest | Understanding which features are used to improve product quality and user experience |
| Data categories | User ID (pseudonymized), event name, timestamp, IP (truncated) |
| Necessity justification | Analytics requires individual-level data to identify usage patterns; aggregate data alone is insufficient. Data is pseudonymized to minimize impact. |
| Balancing test | Data is pseudonymized; no sensitive categories; users can reasonably expect analytics in a SaaS product; retention limited to 26 months; opt-out available via account settings. Interest outweighs data subject rights. |
| Safeguards | Pseudonymization, limited retention, data minimization, no cross-device fingerprinting |
| Date of assessment | 2026-01-15 |
| Reviewer | CTO / DPO |
One LIA per processing activity (or group of similar activities). Keep them in a folder alongside your RoPA.
Consent vs legitimate interests: quick decision guide
| Processing activity | Correct basis |
|---|---|
| Running the product, storing user data to deliver the service | Contract (6(1)(b)) |
| Sending transactional emails (receipts, password resets) | Contract (6(1)(b)) |
| Security logging, fraud detection | Legitimate interests |
| Product analytics (pseudonymized) | Legitimate interests |
| B2B email marketing to existing customers | Legitimate interests (soft opt-in) |
| Cold B2C email marketing | Consent |
| Marketing cookies / third-party tracking pixels | Consent (ePrivacy Directive) |
| Essential cookies (session, security) | No GDPR basis needed (not personal data processing) — ePrivacy essential exemption |
| Processing health/biometric/sensitive data | Explicit consent (or Art. 9(2) derogation) |
| Keeping tax records | Legal obligation (6(1)(c)) |
What to disclose in your privacy policy
For each processing activity, your privacy policy must state the lawful basis. Where you rely on legitimate interests, you must also disclose what that interest is. You don't need to publish the full LIA, but you need enough detail for a user to understand why you're processing their data.
For example: "We analyze product usage data to improve our service, based on our legitimate interest in understanding how our product is used and improving its performance for our users."
Users also have a right to object to processing based on legitimate interests (Article 21). Your privacy policy must mention this right and provide a way to exercise it.
👉 Generate your Privacy Policy free — includes lawful basis disclosures, legitimate interests language, and right to object provisions, pre-filled for your company and jurisdiction.
Key takeaways
- Consent is not the default GDPR lawful basis — it's one of six.
- Legitimate interests is appropriate for security logging, product analytics (pseudonymized), B2B marketing, and fraud prevention.
- Consent is required for marketing cookies, cold marketing to consumers, and special category data.
- Document your lawful basis choice in your RoPA and, where LI is used, in a Legitimate Interests Assessment.
- Disclose your lawful basis in your privacy policy; mention the right to object where LI is used.