The consent problem in SaaS
Consent is the most recognisable lawful basis in GDPR — and the most frequently misapplied. SaaS companies often default to consent for all processing because it feels safest. It isn't. When you rely on consent for processing that could be justified by a more stable lawful basis (like legitimate interests or contractual necessity), you create a serious operational problem: users can withdraw consent at any time, and you must stop processing immediately when they do.
The GDPR supervisory authorities — particularly the CNIL, ICO, APD, and German state DPAs — have published extensive enforcement records showing three recurring consent failures:
- Consent bundled with terms of service acceptance (invalid — not freely given)
- Pre-ticked boxes or inaction treated as consent (invalid — not an unambiguous indication)
- Relying on consent where legitimate interests would have been the correct basis, then failing to manage withdrawal properly
This guide covers what valid consent actually requires, when consent is and isn't the right basis, and how to build a consent management system that holds up to supervisory authority scrutiny.
What Art. 7 requires: the four validity elements
GDPR Art. 4(11) defines consent as "any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her."
Each element has specific requirements:
1. Freely given
Consent is not freely given if:
- It's a precondition of service when processing is not necessary for the service (bundled consent)
- There's a power imbalance between controller and data subject (employer-employee consent is particularly problematic)
- Refusing consent results in detriment — worse service, higher price, or denial of access
- Consent for one purpose is used to gatekeep an unrelated service
For SaaS: you cannot require users to consent to marketing emails as a condition of creating an account. You cannot require consent to analytics profiling as a condition of using the product. If the processing is necessary to provide the service, use contractual necessity (Art. 6(1)(b)) instead.
2. Specific
One consent request = one specific purpose. Blanket consent for "all marketing activities" or "analytics and personalisation" is not specific. You need separate consent for each distinct purpose:
- Newsletter and educational content: separate consent
- Promotional offers and discounts: separate consent
- Third-party sharing for their own marketing: separate consent
- Analytics cookies: separate from advertising cookies
3. Informed
Before consent is obtained, the individual must know:
- The identity of the controller
- The specific purposes of the processing
- What data will be processed
- Whether the data will be shared with third parties (and if so, who)
- Their right to withdraw consent at any time
- The consequences of withdrawing consent
This means the consent request itself must carry enough information, or link to a privacy notice that covers it. "I agree to the privacy policy" is insufficient — the user must be informed at the point of consent, not just have access to a document.
4. Unambiguous indication
An active opt-in is required. No exceptions:
- Pre-ticked boxes: not valid (CJEU Planet49, 2019)
- Implied consent from continued use or scrolling: not valid
- Silence or inaction: not valid
- Bundled acceptance of terms: not valid for processing that isn't strictly necessary for the contract
What is valid: an unchecked tick box with a specific label, a slider toggle in the off position by default, a signed consent form, a double opt-in email confirmation.
When consent is the wrong basis
Consent should not be your default lawful basis. For many SaaS processing activities, another basis is more appropriate and operationally simpler:
| Processing Activity | Wrong basis | Correct basis | Why |
|---|---|---|---|
| Account creation data | Consent | Art. 6(1)(b) — Contract | Processing is necessary to perform the contract |
| Transactional emails (receipts, invoices) | Consent | Art. 6(1)(b) — Contract | Necessary for contract performance |
| Fraud prevention and security | Consent | Art. 6(1)(f) — Legitimate interests | LIA supports security processing without consent dependency |
| Analytics for product improvement | Consent (often) | Art. 6(1)(f) — Legitimate interests (if anonymised or aggregated) | If truly anonymised, GDPR doesn't apply; if pseudonymised LIA possible |
| Marketing emails to existing customers | Consent (sometimes unnecessary) | ePrivacy "soft opt-in" for similar products/services | ePrivacy allows marketing to existing customers without fresh consent if they weren't opted out |
| Marketing to new subscribers | — | Consent (Art. 6(1)(a)) — correct basis | No other basis works for unsolicited marketing to new contacts |
| Advertising cookies | — | Consent (ePrivacy mandatory) | ePrivacy requires prior consent for non-essential cookies — no substitute |
| Special category data (health, biometric) | — | Explicit consent (Art. 9(2)(a)) or other Art. 9 condition | Explicit consent required — higher standard than Art. 7 |
Building a consent record that satisfies Art. 5(2)
Art. 5(2) accountability principle requires you to demonstrate compliance — which means your consent records must be sufficient to prove that consent was valid at the time it was obtained. Every consent record should capture:
- Who: data subject identifier (email, user ID)
- When: timestamp of consent (date and time, ideally with timezone)
- What: the specific purposes consented to
- How: mechanism used (tick box, double opt-in, consent form, verbal with record)
- Which version: version of privacy notice shown at time of consent (so you know what information the user was given)
- Current status: Active / Withdrawn (with withdrawal timestamp if applicable)
A typical consent record in a SaaS database should have columns for: user_id, email, consent_type, consented_at, consent_method, privacy_notice_version, withdrawn_at, withdrawal_method, ip_hash (where needed for proof of location).
Cookie consent and ePrivacy
Cookie consent is where most SaaS companies have the most visible compliance failures. The ePrivacy Directive (and UK PECR) require prior consent before placing any non-essential cookie. The key categories:
| Cookie Category | Consent Required? | Examples |
|---|---|---|
| Strictly Necessary | ❌ No | Session cookies, auth tokens, load balancer cookies, CSRF tokens |
| Functional / Preferences | ❌ No (usually) | Language preferences, UI settings (if only used for user benefit) |
| Analytics | ✅ Yes | Google Analytics 4, Mixpanel, Hotjar, Amplitude |
| Advertising / Retargeting | ✅ Yes | Meta Pixel, Google Ads, LinkedIn Insight Tag, Twitter Pixel |
| Social Media | ✅ Yes | Facebook Like buttons, Twitter share widgets (third-party embeds) |
The cookie consent banner must: present the options before cookies are set (not after); allow rejection as easily as acceptance (a single "Accept all" button with no equivalent "Reject all" button fails this test); and allow users to change preferences at any time. The ICO and Belgian APD have taken enforcement action against "dark pattern" cookie banners that make rejection difficult.
Withdrawal: Art. 7(3)
Withdrawal must be "as easy as giving consent" — this is an Art. 7(3) requirement, not a best practice. In practice:
- If consent was given via a tick box on a signup form, withdrawal must be available via account settings without contacting support
- Every marketing email must include a functional unsubscribe link (ePrivacy requirement — no grace period)
- Withdrawal must take effect immediately for marketing: sending one more email after opt-out is a PECR violation
- Withdrawal does not affect past processing — only future processing must stop
- After withdrawal, you can retain the contact on a suppression list (to honour the opt-out) but cannot send further marketing
Children's consent under Art. 8
If your service is directed at or accessible to children under 16 (or a lower national age — the UK, Germany, and Austria have set the age at 13; France at 15), Art. 8 requires you to obtain parental or guardian consent. "Information society services" — which covers virtually all SaaS products — are the scope.
The practical challenge: age verification. GDPR does not specify a verification method, but Recital 38 notes that "reasonable efforts" should be made. Common approaches:
- Self-declaration at signup (low friction, low assurance — acceptable for lower-risk services)
- Parental consent email (child provides parent email, parent receives and accepts consent request)
- Third-party age verification service (higher assurance, higher friction)
If your service is genuinely not targeted at children, document this in your privacy notice and DPIA, and implement a signup age gate. If a minor is identified after signup, suspend the account and delete data within 72 hours.
The GDPR Consent Management Policy Generator produces a complete Art. 7 consent management policy tailored to your consent types, collection methods, withdrawal mechanisms, and record-keeping approach. For downstream compliance, pair it with the GDPR Compliance Audit Checklist and the Privacy Policy Generator which covers the Art. 13 disclosures required at the point of consent collection.