GDPR Consent Management: Requirements and Best Practices

Consent is one of the most misunderstood aspects of GDPR. Many SaaS companies default to consent as their lawful basis for everything — every form, every email, every data processing activity gets a checkbox. This approach creates unnecessary friction for users and unnecessary risk for your business.

The reality is that consent is just one of six lawful bases under GDPR, and it’s often not the right one. Contract performance, legitimate interest, and legal obligation cover the majority of processing that SaaS companies need to do. Consent should be reserved for processing where the individual genuinely has a free choice — primarily marketing communications and non-essential cookies.

But when consent is the right basis, GDPR sets a high bar. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes, bundled consent, and dark patterns don’t count. And once you rely on consent, you need to be prepared for people to withdraw it at any time.

This guide covers when consent applies, what makes it valid, how to implement it properly, and how to manage consent records across your SaaS platform.

When Is Consent the Right Lawful Basis?

Use Consent For

Marketing communications. Emails, SMS, push notifications, and other direct marketing to individuals require consent in most EU jurisdictions (the ePrivacy Directive reinforces this). The exception: you can rely on legitimate interest for marketing to existing customers about similar products, under certain conditions.

Non-essential cookies and tracking. The ePrivacy Directive (and its national implementations) requires consent for cookies and similar technologies that aren’t strictly necessary for your service. This includes analytics cookies, advertising trackers, A/B testing scripts, and social media plugins. Strictly necessary cookies (session cookies, authentication cookies, security cookies) don’t require consent.

Special category data processing. If you process sensitive data — health data, biometric data, data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership, or sexual orientation — explicit consent is one of the few lawful bases available. The bar for explicit consent is higher than standard consent.

Processing that goes beyond what’s needed for the contract. If you want to use customer data for purposes beyond delivering your service — enriching profiles with third-party data, sharing data with partner companies, using data for research — consent gives the data subject genuine control over these optional uses.

Don’t Use Consent For

Processing that’s necessary to deliver your service. If someone signs up for your SaaS product, you don’t need consent to store their account data — that’s contractual necessity. Asking for consent when you’ll process the data regardless (because the service won’t work without it) makes the consent invalid. It’s not “freely given” if saying no means they can’t use the product.

Processing you’d do regardless of consent. If you plan to process data whether the person consents or not, consent is the wrong basis. Choose legitimate interest or another basis instead. Using consent as a facade while relying on a different basis in practice is deceptive and non-compliant.

Employer-employee relationships. Because of the power imbalance, consent from employees is rarely considered “freely given.” Use contractual necessity, legal obligation, or legitimate interest for most employee data processing.

What Makes Consent Valid Under GDPR?

Article 4(11) defines consent as “any freely given, specific, informed and unambiguous indication of the data subject’s wishes.” Article 7 adds conditions for demonstrating consent. Let’s unpack each requirement:

Freely Given

The person must have a genuine choice. Consent is not free if:

• Refusing consent has negative consequences. If refusing consent means losing access to a service that doesn’t require the consented processing, the consent isn’t free. Example: requiring consent to marketing emails as a condition of using a project management tool — the marketing has nothing to do with the service.
• There’s a power imbalance. An employer asking an employee for consent to share their data with a third party — the employee may feel they can’t say no.
• Consent is bundled. Asking for a single consent that covers multiple, unrelated processing purposes. Each purpose should be separately consentable.

Best practice for SaaS: Use granular consent options. Let users opt in to marketing separately from analytics. Don’t gate access to your product on consent to processing that isn’t necessary for the service.

Specific

Consent must relate to one or more specific processing purposes. “I consent to the processing of my personal data” is not specific. “I consent to receiving product update emails from GRCTrail” is specific.

Best practice for SaaS: Create separate consent mechanisms for each purpose: marketing emails, product newsletters, partner communications, analytics tracking, research participation. Don’t bundle them.

Informed

Before giving consent, the person must know at minimum:

• Who is asking for consent (your organization’s identity)
• What data will be processed
• For what purpose(s)
• Their right to withdraw consent at any time
• If applicable, that data will be used for automated decision-making
• If applicable, that data will be transferred internationally

Best practice for SaaS: Place clear, concise information next to each consent mechanism. Link to your full privacy notice for details, but provide the essential information in-line. No one should need to read a 10-page document to understand what they’re consenting to.

Unambiguous

Consent must involve a clear affirmative action. This means:

• Opt-in, not opt-out. Pre-ticked checkboxes are not valid consent. The checkbox must start unchecked, and the user must actively tick it.
• Silence is not consent. Inactivity, scrolling through a page, or continuing to browse a website does not constitute consent.
• No dark patterns. Making the “accept” button large and colorful while hiding the “decline” option in small gray text is not unambiguous consent — it’s manipulation.

Implementing Consent Mechanisms

Cookie Consent

Cookie consent is the most visible consent implementation for most SaaS websites. The requirements:

Before cookies are set: Display a clear consent banner that:

• Lists the categories of cookies (functional, analytics, marketing)
• Explains what each category does
• Provides a way to accept or reject each category independently
• Does not set non-essential cookies until consent is given (no “consent by browsing”)
• Does not use pre-selected categories

Granular controls: Users should be able to accept analytics cookies but reject marketing cookies, or vice versa. An “accept all” button is fine as long as granular options are equally accessible.

Persistence and withdrawal: Store the user’s consent preferences and honor them. Provide a way to change preferences at any time (commonly through a “Cookie Settings” link in the footer).

No cookie walls: Blocking access to your website entirely if the user doesn’t accept cookies is generally not permitted in the EU, as consent given under such conditions is not “freely given.”

Email Marketing Consent

Double opt-in: Best practice is to use double opt-in (also called confirmed opt-in). The user enters their email, and you send a confirmation email with a verification link. Only after they click the link is consent recorded. This provides strong evidence that the person actually consented and that the email address belongs to them.

Clear description: At the point of sign-up, describe what the person will receive: “Monthly product updates and GDPR compliance tips” — not “communications from us.”

Easy unsubscribe: Every marketing email must include a clear, one-click unsubscribe mechanism. Don’t require the user to log in, fill out a form, or explain why they’re unsubscribing.

In-App Consent

For consent collected within your SaaS application (opting in to beta features, enabling integrations that share data with third parties, participating in research):

• Use clear modal dialogs or inline consent forms
• Explain what the user is opting in to
• Provide immediate confirmation of their choice
• Allow withdrawal through account settings

Managing Consent Records

Article 7(1) states: “Where processing is based on consent, the controller shall be able to demonstrate that the data subject consented.” You need to maintain records that prove:

• Who consented (identifiable person, not just a cookie ID)
• When they consented (timestamp)
• What they consented to (the specific purpose and the exact language they saw)
• How they consented (the mechanism — checkbox, double opt-in, cookie banner)
• The version of the consent text at the time (if you update your consent language, you need to know which version each person saw)

These records must be accessible and organized. If a supervisory authority asks you to demonstrate that a specific individual consented to marketing emails, you need to produce the evidence — not guess based on whether they’re in your mailing list.

Withdrawing Consent

Article 7(3) states: “It shall be as easy to withdraw as to give consent.” This is frequently violated. Common failures:

• Requiring a phone call to unsubscribe when consent was given with a single click
• Multi-step withdrawal processes that require logging in, navigating to settings, and confirming multiple times
• Processing delays where data continues to be processed for days or weeks after withdrawal

When someone withdraws consent:

• Stop the processing based on consent immediately
• Don’t use withdrawal as an opportunity to re-request consent
• Don’t penalize the person (e.g., by reducing service quality)
• Keep a record that consent was withdrawn (and when)
• Note that withdrawal doesn’t affect the lawfulness of processing that occurred before withdrawal

Consent vs. Other Lawful Bases

A common question: “Can I switch lawful bases if someone withdraws consent?”

The answer is generally no. If you’ve been processing data based on consent and the person withdraws it, you can’t retroactively claim you had a legitimate interest all along. The European Data Protection Board has been clear: choosing consent as your basis and then switching when it becomes inconvenient undermines the integrity of consent as a mechanism.

This is why it’s critical to choose the right lawful basis from the start. If legitimate interest genuinely applies, use it. Don’t default to consent because it seems easier — consent comes with strings attached.

How GRCTrail Helps with Consent Management

GRCTrail integrates consent management into your broader compliance program:

Consent tracking in your ROPA. Each processing activity in your Record of Processing Activities records the applicable lawful basis. When consent is the basis, GRCTrail links to your consent records and mechanisms.

Evidence management. Maintain auditable records of consent collection, the consent language used, and withdrawal events. Demonstrate compliance to supervisory authorities with structured evidence, not a pile of email screenshots.

Connected to your privacy notices. Your consent mechanisms should align with what your privacy notice says. GRCTrail helps ensure consistency between what you tell people and what you do.

Manage consent with confidence →

Related Guides

• The Six Lawful Bases for Processing — Understanding all your options
• Privacy Notice Requirements — What to tell data subjects
• GDPR Compliance Checklist — The full compliance framework
• Records of Processing Activities (ROPA) — Documenting your processing

Get started with GRCTrail →