Cookie consent for a SaaS product means getting explicit permission for non-essential trackers on two surfaces. Those surfaces are the public marketing site and the logged-in app. Most teams handle the first and miss the second. That is exactly where session recordings, product analytics, and feature flags keep tracking users after they log in.
This guide covers eight steps. It runs from mapping every tracker to maintaining consent as your product grows, with a legal basis, a geo-aware banner, and audit evidence in between.
Why Cookie Consent Is Different for SaaS
Most SaaS companies put a cookie banner on the marketing site and stop there. Tracking continues after login through session recordings, heatmaps, and feature flags. SaaS also runs multi-domain architecture: www., app., and staging subdomains. B2B relationships add another layer, since one person often signs up for a whole team. Together, these make SaaS consent structurally different from a standard marketing website.
A cookie banner that only lives on the homepage misses the trackers that fire the moment a user logs in. These SaaS-specific triggers show up inside the authenticated product:
- Session recordings, which capture mouse movement, clicks, and scroll behavior and can record names, emails, and IP addresses
- Heatmaps, which aggregate click and scroll data across the dashboard
- Feature flags used for A/B testing, which use cookies to track which variant a user saw and how they responded
- Product analytics events, which log in-app actions tied to a user or account ID
Each of these needs the same consent treatment as a marketing-site tracker. Authentication is not consent.
The marketing site is not the whole story
Logging in does not exempt a SaaS product from consent requirements. A dashboard that fires session-recording or analytics cookies on every authenticated page load is processing personal data. That is true whether the visitor is anonymous or signed in. The ePrivacy Directive and GDPR apply regardless of login status. The fix is to treat app.yoursaas.com as its own consent surface, not an extension the marketing banner already covers.
B2B vs consumer SaaS: who consents, and how
B2B SaaS has a specific consent problem. One person signs the contract, but an entire team uses the product. A signed Terms of Service from the account owner does not cover the individual privacy consent of every employee who logs in afterward. Each authenticated user is a separate data subject. Each one needs their own consent choice recorded, not one inherited from whoever bought the license.
A "B2B is exempt" assumption is a myth. Whether consent applies depends on visitor location and cookie type, never on whether the buyer is a business. A marketing site running analytics or session recording needs a banner regardless.
Your legal role also splits in two, and this shapes everything downstream. You are the data controller for your own marketing site and your own subscribers, since you decide why and how that data is used. You are a data processor for the customer data your users load into the product, since you handle it on their instructions. That processor relationship requires a Data Processing Agreement under GDPR Article 28. This guide covers cookie consent on the surfaces you control; the customer-data side is governed by that DPA, not by a banner.
For consumer-facing tracking, consent is the correct legal basis. For internal B2B product-usage analytics, legitimate interest is often the stronger, cleaner basis. Document a legitimate interest assessment, use the data only to improve the product, and still offer an opt-out. Mixing consent and legitimate interest for the same processing purpose creates a legal contradiction. Pick one basis per tracker and stay consistent.
What You Need Before You Start
The prerequisite most teams miss is a complete inventory of every tracker across every property, not just the marketing site. You also need a clear picture of which jurisdictions your users actually sit in. A single EU or UK signup, even an unpaid trial account, pulls the whole product under GDPR. An email address alone counts as personal data under Article 3's territorial scope.
What you need before you start:
- Roles: usually a founder or engineer owns this, not legal. Legal basis decisions (Step 2) benefit from a quick legal review, but the mapping and implementation work is technical.
- Time: a focused day for a small SaaS app, once your domain list and tracker inventory are ready. Hand-coding a banner and blocking logic from scratch takes longer than using a consent management platform.
- Inputs: a list of every domain and subdomain (marketing site, app, staging, any funnel tool like Systeme.io). Add the analytics, session-recording, and ad tools currently running, plus a rough sense of where your users are located.
- Tools: a consent management platform, or any tool that can scan for trackers, serve a banner, and block scripts before consent.
How to Set Up Cookie Consent for Your SaaS: Step by Step
Setting up cookie consent for a SaaS product follows eight steps. They run from mapping every tracker to maintaining consent as your product changes.
Step 1: Map every tracker across your marketing site, app, and subdomains
A complete tracker map lists every cookie, script, and iframe running on www., app., and any other subdomain. That includes tools that only fire after a user logs in. Most scanners only see the public marketing site because they crawl from the sitemap. That means the logged-in dashboard, the exact place SaaS products under-scan, gets missed entirely.
Run an automated scan across your whole domain footprint first. Then manually add any authenticated or funnel routes a crawler cannot reach on its own. Examples include a dashboard behind a login wall or a Systeme.io funnel page not linked from the sitemap.
Consently's automatic full-site scan detects cookies, trackers, scripts, and iframes across a domain, and it scans subdomains in the same pass. Its manual URL scan list lets you add specific app or funnel pages that sit behind authentication. That is exactly the blind spot a sitemap-based crawler misses on a SaaS product.
Done: you have a single categorized list of every cookie, script, and iframe across www., app., and every subdomain, including tools that only fire post-login.
Step 2: Pick a legal basis for each tracker (consent vs legitimate interest)
Every non-essential tracker needs one documented legal basis, either consent or legitimate interest, and you cannot mix both for the same processing purpose. Consumer-facing trackers (marketing analytics, ad pixels, session recordings shown to public visitors) need consent. Internal B2B product-usage analytics, the kind that tells you which features get used, can often rely on legitimate interest instead.
Legitimate interest requires a documented legitimate interest assessment (LIA). Record what the processing is, why it is necessary, and how you weighed it against the user's privacy expectations. Even with legitimate interest as the basis, users still need a clear, working opt-out. Pick one basis per tracker at setup and keep it consistent as the product evolves. Switching bases later without re-documenting creates gaps an auditor or regulator will flag.
Done: every non-essential tracker on your list has one documented legal basis, either consent or legitimate interest with an LIA and an opt-out.
Step 3: Categorize cookies as essential or non-essential
Essential cookies (authentication, session management, security, language preference) are exempt from consent requirements. The product cannot function without them. Everything else, including analytics, advertising, functional, and session-recording cookies, needs a documented category and a consent requirement attached to it.
| Category | Example in a SaaS product | Consent required |
|---|---|---|
| Essential | Login session token, CSRF protection | No |
| Analytics | Product usage events, page-load timing | Yes |
| Session recording | Mouse movement, click and scroll capture | Yes |
| Advertising | Retargeting pixels on the marketing site | Yes |
| Functional | Remembered dashboard theme or layout preference | Yes, unless strictly necessary for the feature to work |
Getting this split wrong breaks the product in one of two directions. Block a login cookie and users cannot sign in. Wave everything through pre-consent and you are running "consent theater," a banner that displays but does not actually block anything.
Consently's cookie categorization sorts detected cookies into essential, analytics, advertising, performance, and functional categories. Custom categories are available when the defaults do not fit, so the preference center maps to how the product actually processes data.
Done: every cookie on your tracker map is tagged essential or non-essential, with non-essential cookies further split by category.
Step 4: Build a geo-aware consent banner
Visitor location determines which consent model a SaaS product must show. EU and UK visitors need an opt-in banner with granular accept, reject, and manage options before any non-essential tracker fires. US-state visitors, under CCPA and similar state laws, need an opt-out model instead. Tracking can start by default there, but a clear way to decline must stay visible.
The banner itself needs granular category-level control, not just accept-all or reject-all. It also needs plain language instead of legal jargon, and an easy way to withdraw consent later. Getting the model wrong in either direction is a real risk. Showing US visitors a heavy opt-in flow adds unnecessary friction. Showing EU visitors an opt-out model is a compliance failure.
Consently ships GDPR opt-in and CCPA/US opt-out templates with automatic geotargeting. The banner shows the right model based on visitor region without you building that logic yourself. Its preference center handles granular control. Custom CSS plus font inheritance let the banner match the product's existing UI, instead of looking like a bolted-on third-party widget.
Done: visitors from different regions see the legally correct consent model automatically, with granular controls and an easy way to change their choice later.
Step 5: Add in-app consent for the logged-in product
The banner cannot stop at the marketing site. The logged-in app is where the heaviest trackers actually fire, including session recording, product analytics, and any feature-flag-driven A/B tests. Place a consent prompt on first authenticated load. Give users a persistent "Manage cookies" entry point somewhere in the dashboard, not buried three clicks deep in a settings submenu.
Re-prompting a user who already made a choice on the marketing site is bad UX. It is also unnecessary if the same tracker categories apply on both properties. Carrying that choice from www. to app., or the reverse, avoids the double-banner problem entirely.
Consently's subdomain consent sharing carries a choice made on www. to app., or the reverse, so users are not asked twice for the same tracker categories. The floating revisit button, or a custom preference link placed in the dashboard, becomes the in-app "Manage cookies" control users expect to find.
Done: consent is captured on first authenticated load, carried across the marketing site and the app without re-prompting, and revocable from a visible dashboard control.
Step 6: Block non-essential trackers until consent and wire up Google signals
Consent is meaningless if the tracker already fired before the user made a choice. Non-essential scripts and iframes need to stay blocked until the visitor opts in. Once they do, that choice needs to reach Google so Analytics and Ads respect it.
Google Consent Mode v2 uses four signal parameters. ad_storage and analytics_storage control whether advertising and analytics cookies can be set. ad_user_data and ad_personalization control whether user data is sent to Google for advertising and personalization. These need to update automatically the moment a user's consent choice changes, not just at page load.
Consently auto-blocks non-essential cookies, scripts, and iframes until consent is given. It sets Google Consent Mode v2 automatically, updating ad_storage, analytics_storage, ad_user_data, and ad_personalization without any hand-written gtag('consent') code. For programmatic ad-tech, it also supports IAB TCF v2.3. One load-order detail matters regardless of tool. The consent script has to load first in the page <head>, ahead of any tracking script it needs to block.
Done: nothing non-essential loads before consent, and Google's consent signals update automatically to match the visitor's choice.
Step 7: Publish the policies and evidence your SOC 2 and DPA reviews need
A SaaS product needs three published documents: a cookie policy, a privacy policy, and terms and conditions. Beyond the policies, enterprise buyers and SOC 2 auditors will ask for three more things. They want a consent log that proves what visitors actually agreed to. They want a Data Processing Agreement (DPA) that names your subprocessors. They also want a Record of Processing Activities (RoPA) that documents what data you hold and why.
SOC 2 controls cover roughly 90 percent of what GDPR requires around technical and organizational security measures. The gap that remains is data-subject rights, specifically the right to erasure. A SOC 2 report alone does not prove you can delete a user's data on request. A consent log with an export function is what closes that gap for both SOC 2 and GDPR Data Subject Access Requests (DSARs).
Consently's three policy generators produce the cookie policy, privacy policy, and SaaS terms and conditions from a guided workflow. Its consent logs export as an audit trail for SOC 2 reviews and DSARs. A DPA with a subprocessor list and Standard Contractual Clauses is available on request. One honest limit applies: Consently provides the DPA between itself and the customer. It does not run the customer's own downstream DPA-request workflow with their end users or vendors, so that process still needs separate management.
Done: a cookie policy, privacy policy, and terms are live, consent logs export on demand, and a DPA with a subprocessor list is documented.
Step 8: Maintain consent as your product and the laws change
Cookie consent for a SaaS product is not a one-time setup. New features add new trackers. New markets add new laws. Users file deletion requests that need a working response process. Treat this as a recurring review, not a checkbox you tick once at launch.
Re-scan on a schedule so a new analytics integration or a newly added feature-flag tool does not go live untracked. Build a real process for honoring deletion requests, and keep policies current as the product or the regulatory landscape shifts.
Consently's weekly scheduled scans catch new trackers automatically as they appear. Consent log export supports the evidence side of DSAR and right-to-be-forgotten requests. Policies can be regenerated from the dashboard when the law or the business changes. Two honest limits are worth planning around. Generated policies do not auto-update based on a visitor's geolocation, and Consently supports explicit consent only, with no implied or scroll-based option. Global Privacy Control (GPC) signal detection is not yet supported either.
Done: trackers are re-scanned on a recurring schedule, deletion requests have a working process, and policies get updated when the product or the law changes.
Common SaaS Cookie-Consent Mistakes to Avoid
The single most damaging mistake is assuming the marketing-site banner already covers the logged-in app. It does not, and every tracker firing behind the login wall runs without consent, regardless of what the homepage banner says.
- Banner on the marketing site, no consent in the app: trackers fire on authenticated users with zero consent captured. Fix: extend both consent capture and blocking logic to the app subdomain, not just
www.. - A banner that displays but does not actually block trackers pre-consent: this is consent theater. The banner shows up, but scripts already fired before the user clicked anything. Fix: use auto-blocking that stops non-essential scripts and iframes until consent is given, not a banner that runs in parallel with unblocked tracking.
- No essential-versus-non-essential separation: without this split, teams either block login cookies, breaking the product, or let everything through, voiding the point of the banner. Fix: categorize every cookie before deciding what to block.
- Assuming "we only have US customers" means GDPR does not apply: one EU or UK signup, even a non-paying trial account, pulls the whole product into GDPR scope. An email address alone is personal data under Article 3's territorial reach. Fix: set the geo-aware consent model now, before the first international signup arrives.
- No deletion endpoint, indefinite session retention, or backups kept forever: this fails both DSARs and a SOC 2 review. Fix: add a working deletion flow, a defined retention policy, and exportable consent logs that prove what was agreed to and when.
FAQs
Does a B2B SaaS need a cookie banner?
Yes, if it uses any non-essential tracker, such as analytics, session recording, or marketing pixels, and has any EU, UK, or California users. Most SaaS products do once they have a handful of international signups. A B2B-only exemption does not exist. The requirement depends on visitor location and cookie type, not on whether the buyer is a business.
Do I need cookie consent inside the app after a user logs in?
Yes. Authentication is not consent. Session recordings, product analytics, and feature-flag-driven A/B tests inside the logged-in dashboard trigger the same consent requirements as marketing-site trackers. Tracking a user after login without their consent is a common and easily fixed compliance gap.
We only have US customers. Do we still need this?
Likely yes, and sooner than you would expect. A single EU or UK signup, even an unpaid trial, brings GDPR's territorial scope into play, because an email address counts as personal data. Setting up a lightweight, geo-aware consent flow now is far less work than retrofitting one after your first international customer.
Do product analytics tools like Amplitude or PostHog need consent?
Yes for consumer-facing use. It is often yes for B2B use too, though legitimate interest can serve as the legal basis for internal product-usage analytics. Document a legitimate interest assessment and offer an opt-out to use that basis. Watch each tool's default data-retention period, since some retain identifiable event data far longer than teams expect.
Is a cookie banner enough to be GDPR compliant?
No. A cookie banner is one piece of a larger compliance picture. You also need a documented legal basis per tracker, a privacy policy, a working deletion process, and consent records. A banner alone, without blocking, categorization, or proof of what was agreed to, does not meet GDPR's requirements.
How does cookie consent fit into a SOC 2 audit?
Consent logs function as audit evidence a SOC 2 review will ask for. SOC 2's technical and organizational controls cover roughly 90 percent of what GDPR requires. The remaining gap is data-subject rights, specifically the right to erasure, which a consent log with export functionality helps close for both frameworks.
How long does it take to set up cookie consent for a SaaS?
A focused day is realistic for a small SaaS app that already has a domain list ready and uses a consent management platform. Hand-coding the banner and blocking logic yourself takes longer. Products with many subdomains and a large tracker footprint take longer too.
Setting this up by hand across a marketing site and a logged-in app is where most SaaS teams stall. Consently scans every subdomain, blocks non-essential trackers until consent, and sends Google Consent Mode v2 signals automatically. It also keeps the consent logs your SOC 2 and DPA reviews ask for. Every feature ships on every plan, with five domains for $199 a year. Start a free 14-day trial, no credit card required.
If you are new to the category, how a consent management platform works is a good starting point before choosing one. Your obligations also shift by sector. See how cookie rules change by industry for the wider picture, and who Consently fits best for the audience-level view before diving deeper.
A health-adjacent SaaS handling patient data has stricter pixel rules than a standard product. If your SaaS also runs a content marketing blog, the consent rules for content sites and blogs apply there too. Agencies managing client SaaS sites handle this same setup across many domains at once, with their own multi-tenant wrinkles.
For the GDPR side specifically, see the full GDPR cookie consent requirements. If you are earlier in the company lifecycle, GDPR for startups covers the same ground at a smaller scale. The DPA piece of Step 7 gets a full treatment in what a DPA actually covers.
