· Last updated: October 14, 2026
Yes, if you have users in the EU or UK and your site or app sets non-essential cookies or loads third-party trackers, you need prior consent. That applies to B2B SaaS too, and to your logged-in app, not just your marketing site. Strictly necessary cookies, such as login and security, don't need consent. In the US you generally need an opt-out mechanism, and you must honor opt-out signals like Global Privacy Control where state law requires it.
A SaaS product doesn't have one website. It has a marketing site, an app, a docs site, a status page and a support widget. A dozen scripts from analytics, chat and ad tools load at different times, for people who are sometimes logged in and sometimes not. Standard cookie banner advice assumes one domain and a visitor who browses and leaves. SaaS breaks both assumptions.
This guide shows how to set up consent so a user is asked once and the answer sticks. It also covers the cases generic guides skip: logged-in users, Safari, Global Privacy Control and session replay. It is general information, not legal advice.
Why SaaS cookie consent is harder than a normal website
Consent has to travel. A visitor reads your blog at www.example.com, signs up on app.example.com, and opens help articles at docs.example.com. If each property asks separately, people get three banners and three chances to be recorded inconsistently. If none of them share a decision, you may load trackers on the app for someone who refused them on the website.
Logged-in users are a different situation. In the product, most cookies are strictly necessary (session, authentication, security). But product analytics, session replay, in-app chat and A/B testing tools run there too, and many of those need consent.
You run more third-party code than you think. Marketing adds a pixel, engineering adds an error tracker, support adds a chat widget. Each one can set cookies or send data to another company, often without anyone updating the banner.
Your users are global. The same signup page serves visitors under GDPR and the ePrivacy rules, US state laws, and Brazil's LGPD.
B2B vs. consumer SaaS: who is consenting?
A common assumption is that B2B products are exempt because the customer is a company. They aren't. The ePrivacy rules on storing or reading information on a device protect the person using it, whether they browse as a consumer or at work. Your customer signed the contract, but each team member who opens your app is a separate user and data subject.
That has practical consequences:
- Consent is per person, not per account. An admin accepting analytics doesn't consent on behalf of their colleagues.
- If you record sessions or track events by user, the consent decision has to follow that user.
- For freemium and product-led growth, anonymous visitors see the banner on your marketing site. When they sign up, carry the choice over to the account (see logged-in users below) rather than asking again.
What the law requires, in SaaS terms
- EU: Storing or reading information on a user's device, such as setting a cookie or reading local storage, requires prior consent under Article 5(3) of the ePrivacy Directive, unless it is strictly necessary for a service the user asked for. Consent must be freely given, specific, informed and unambiguous, and withdrawing it must be as easy as giving it (GDPR Art. 7(3)). Keep records of who consented to what and when.
- UK: The same device-access rule sits in PECR regulation 6, as amended by the Data (Use and Access) Act 2025. Since February 5, 2026 the UK also has a statutory exception for statistical purposes (see the table below).
- United States: There is no general opt-in rule for cookies. State privacy laws give users the right to opt out of the sale or sharing of personal data and targeted advertising, and about a dozen require honoring opt-out preference signals like Global Privacy Control (see below). Several states also require opt-in consent for sensitive data such as precise geolocation. California's Invasion of Privacy Act (CIPA) is being used in lawsuits against session replay and similar tools.
- Brazil (LGPD): You need a legal basis for processing, and consent, where you rely on it, must be specific and documented. Notices must be clear and easy to access (Art. 9), which in practice means Portuguese for Brazilian users.
If you operate in more than one region, build to the strictest rule you're subject to and adjust by region where the law allows less. That is easier than maintaining several separate systems.
What needs consent in a SaaS product, and what doesn't
| Technology | Typical SaaS use | Consent needed (EU/UK)? |
|---|---|---|
| Session/auth cookie, CSRF token | Keeping users logged in, protecting forms | No, strictly necessary |
| Load balancer, security and fraud cookies | Infrastructure | No, if limited to that purpose (security and fraud prevention are examples of "strictly necessary") |
| Consent cookie itself | Remembering the user's choice | No |
| Product analytics (event tracking inside the app) | Funnels, feature usage | Usually yes in the EU, unless a narrow exemption applies, such as the CNIL's limited audience-measurement exemption. In the UK, a statistical-purposes exception applies if the sole purpose is improving your own service, visitors get clear information and a simple, free way to object |
| Session replay / heatmaps | UX research | Yes, and see CIPA risk below |
| Chat and support widgets | Customer support | Depends on whether the widget sets non-essential cookies or loads third-party trackers before the user opens it |
| Marketing pixels, retargeting | Ads, attribution | Yes |
| A/B testing | Experimentation | Usually yes, unless it's purely functional (the UK has a narrow exception for website appearance and functionality, with the same notice and objection conditions) |
"Strictly necessary" is narrow: it covers what the user explicitly asked for, such as logging in, and nothing you added for your own benefit. When in doubt, ask for consent or don't load the script. Your cookie scan should produce this table for your own stack.
Pick one legal basis per tracker and be consistent. Don't treat the same analytics tool as consent-based in one place and legitimate-interest in another. Mixing them makes your records and your privacy notice hard to defend. In the EU and UK, the device-access step still needs consent (or a recognized exception) even if you have a separate lawful basis for the later processing.
Setting up consent across subdomains
The simplest case: one registrable domain
If www.example.com, app.example.com and docs.example.com share a registrable domain, you can share a consent cookie across them by scoping it to the parent domain (.example.com).
Set it from your server rather than in the browser. A server-set cookie avoids the Safari expiry problem described below and gives you one place to control the attributes.
// Express example: save the consent decision from the banner
app.post('/consent', express.json(), (req, res) => {
const record = {
v: 3, // banner/policy version
ts: Date.now(),
analytics: !!req.body.analytics,
marketing: !!req.body.marketing,
gpc: req.get('Sec-GPC') === '1',
};
// Express URL-encodes the cookie value once by default, so pass plain JSON.
// Encoding it yourself as well would double-encode it.
res.cookie('consent', JSON.stringify(record), {
domain: '.example.com', // shared across subdomains
maxAge: 1000 * 60 * 60 * 24 * 180, // milliseconds: 180 days
secure: true,
sameSite: 'lax',
httpOnly: false, // the banner script must read it
path: '/',
});
res.sendStatus(204);
});If the banner posts to an API on a different subdomain, allow credentialed cross-origin requests (CORS) on that endpoint. Then gate every non-essential script on that cookie, on every property:
function getConsent() {
const m = document.cookie.match(/(?:^|; )consent=([^;]*)/);
return m ? JSON.parse(decodeURIComponent(m[1])) : null;
}
const c = getConsent();
if (c?.analytics) loadAnalytics();
if (c?.marketing) loadMarketingPixels();
// No cookie means no non-essential scripts, and the banner is shown.Set an expiry that matches your re-consent policy, and re-ask whenever you add a new category or vendor (the v field above). Regulators differ here. The CNIL treats about six months as good practice for re-asking consent, and it sets a 13-month maximum lifetime for the trackers it exempts from consent (25 months for the data they collect). Check the guidance for the regulators you answer to.
Different registrable domains
Cookies can't be shared between example.com and example.io, or between your site and a customer's white-labeled domain. In those cases you need a consent lookup that doesn't depend on cookies: a central consent API each property calls, or a signed token passed on redirect. See our guide to cross-domain cookie consent for the patterns, and consent management API integration for the server side.
Safari and other browsers that clear script-written storage
Safari's tracking prevention deletes cookies and storage written by JavaScript, including document.cookie and localStorage, after seven days of Safari use without the user interacting with your site. This applies whatever expiry you set. A consent cookie set only from the browser can therefore disappear, and the user sees the banner again.
Ordinary server-set first-party cookies aren't subject to that limit, which is another reason to set the consent cookie from your server. There is one exception: Safari caps even server-set cookies at seven days when they come from CNAME or IP cloaking. If your consent endpoint sits on a subdomain that points to a hosted CMP, test it in Safari. Treat any JavaScript-written copy as a fallback, and re-prompt when it's missing. Apple's tracking-prevention documentation changes, so check the current version.
Different rules for different regions
One global opt-in banner is the simplest approach, but also the most restrictive. If you vary by region:
- EU/UK/Switzerland: opt-in, with non-essential scripts blocked until consent.
- US: opt-out and notice, honoring GPC and any opt-out of sale/sharing or targeted advertising.
- Brazil and others: apply the local rule. Where unsure, use the opt-in default.
- Unknown location: fall back to the strict setting.
Detect region on the server (IP geolocation) and decide the banner before scripts load, not after. Expect errors: VPNs, mobile networks and corporate proxies misplace users, which is another reason to default to strict when in doubt. Log which rule set was applied with each consent record.
Logged-in users
Once someone has an account, you can do better than a cookie. Remember that logging in is not consent: signing in or accepting your terms doesn't switch on analytics, replay or marketing tools.
- Store the decision against the user, not just the browser. Save the consent record server-side keyed to the user ID, with timestamp, banner version, the choices made, the region and the source domain. See linking consent to custom user IDs.
- Apply it on login. When the user signs in on a new device, fetch their saved record and set the local consent cookie from it, so they aren't asked again.
- Handle conflicts deliberately. If the browser says "refused" and the account says "accepted", the most recent decision wins. Never apply the broader consent over a more recent refusal.
- Make withdrawal easy. Put a "Cookie settings" link in the app footer or account settings that reopens the preference center.
- Don't confuse consent with a contract. The cookies needed to run the product don't need consent. Analytics, replay and marketing inside the app still do, even though the user has an account.
Global Privacy Control
Global Privacy Control (GPC) is a browser signal (the Sec-GPC: 1 header and navigator.globalPrivacyControl) that tells you the user opts out of the sale or sharing of their data. California requires businesses to treat it as a valid opt-out request. Law-firm tables also list Colorado, Connecticut, Montana, Texas, Oregon (from January 2026), New Hampshire, New Jersey, Nebraska, Delaware, Minnesota and Maryland. Effective dates differ and a few rest on secondary sources, so confirm each statute for the states where you have users. Louisiana, from January 2027, is reported to require recognizing universal opt-out mechanisms. Oklahoma has no such provision.
Practical steps:
- Detect the signal on the server and in the browser.
- When it's on, treat the user as opted out of sale/sharing and targeted advertising, and don't load the related scripts.
- Record that GPC was the source of the choice.
- Don't make users re-confirm an opt-out the signal already expressed.
More detail: Sec-GPC explained and the US state privacy law tracker.
Session replay, heatmaps and chat widgets
These are where SaaS companies most often get into trouble, because engineers and product teams add them for good reasons and compliance finds out later.
- Session replay and heatmaps record what users type and click, and can capture personal or sensitive information on screen. Under GDPR and ePrivacy they need consent. In the US, they have been the subject of lawsuits under California's CIPA, usually pleaded as wiretapping (Penal Code 631) and sometimes under the pen-register provision (638.51). California's SB 690, signed September 30, 2026, ends private pen-register claims over website and app tracking from January 1, 2027. It leaves the wiretapping claims in place. See our CIPA compliance guide.
- Mask by default. Configure the tool to mask all input fields and sensitive page areas, and only unmask what you've reviewed.
- Chat widgets often load third-party scripts and set cookies on page load, before anyone opens the chat. Load them after consent or on first interaction. Where the widget is a processor, make sure a data processing agreement is in place.
- Tools with their own consent requirements need their consent signal wired up. Microsoft Clarity, for example, has enforced consent signals for visitors from the EEA, UK and Switzerland since October 31, 2025. See Microsoft Clarity consent mode. For Google tags, see our Google Consent Mode guide.
Scanning: keeping the banner in line with what actually loads
A consent banner is only accurate if it reflects the scripts and cookies your properties set today.
- Scan every domain and subdomain, including the app (in a logged-in state if you can), docs, status page, any customer-facing portals, and staging or preview environments that are publicly reachable.
- Categorize each finding as necessary, analytics, functional or marketing. Keep an "unclassified" bucket that blocks release until someone reviews it.
- Rescan on a schedule and after releases. New tags appear whenever marketing adds a tool or engineering adds a dependency. Monthly is a reasonable minimum.
- Treat a new third-party script like a code change. Require review before it ships. See third-party SDK compliance.
- Test by behavior, not just by the list. Open the site with consent refused and check in the browser that no non-essential cookies are set and no tracker requests fire.
You can run a first scan with the Secure Privacy cookie scanner.
Banner design for a product, not a brochure
- Equal-prominence choices. "Reject" must be as easy to find and click as "Accept". See the dark pattern checklist.
- Don't interrupt critical flows. Avoid a banner covering the signup form or an in-app action in progress. Show it where it can be answered without losing work.
- Granular but short. Offer categories, with a one-line explanation each and a link to the full vendor list.
- Test carefully. Every variant you test must still produce valid consent. See cookie consent A/B testing.
- Accessible and responsive. Keyboard-operable, screen-reader labelled, and usable on mobile.
Choosing a consent management platform for SaaS
Many teams searching this topic are really choosing a tool. The criteria that matter for SaaS differ from those for a brochure site, so start from them rather than from a feature list. Run every shortlisted tool, including ours, against these questions in a real demo on your own app:
- Multi-domain support: can one configuration and one consent record cover your marketing site, app and docs?
- Logged-in user support: can it store and retrieve consent by user ID through an API?
- Framework fit: does it work cleanly with your front end (see consent for Next.js and React apps)?
- Region rules and GPC: does it apply different rules by region and honor opt-out signals automatically?
- Vendor signals: are there ready integrations for the tools you use (Google, Meta, Microsoft Clarity, your tag manager)?
- Audit evidence: does it log consent with timestamp, banner version, choices and source, and can you export it for a regulator?
- Performance: how much does it add to page load, and can it load without blocking rendering?
- Your own stack: refuse consent and confirm nothing non-essential fires.
Score each shortlisted tool pass, partial or fail on these eight points. Then weigh them by what your product actually does. A tool that is perfect for a marketing site but can't read consent inside your logged-in app will fail you where the risk is highest.
An open-source banner is fine for a simple, single-domain site. Multi-domain sync, regional rules, signal handling and audit logs are where homegrown setups fall behind.
EU cookie rules are in flux: what to do now
The EU's Digital Omnibus proposal, published on November 19, 2025, would change the cookie and device-access rules. As of early October 2026 it was still in negotiation. EU ambassadors were due to decide the Council's negotiating mandate on October 11 (the outcome was not confirmed when this was written), and the European Parliament had not adopted a position. Reports say the Council's text would keep the cookie rules in the ePrivacy Directive rather than moving them into the GDPR.
Keep complying with the current rules, and keep your consent setup flexible: versioned banner text, a consent log you control, and signals handled centrally. Then any change can be rolled out in one place.
What changes for SaaS cookie compliance in 2026 and 2027
Several dates land in the next twelve months. None of them changes the basics above, but they affect how you set up and maintain consent.
- UK reforms. The Data (Use and Access) Act 2025 changed the UK cookie rules (PECR) from February 5, 2026. It added exceptions for statistical purposes, website appearance and functionality, and emergency assistance, each with notice and objection conditions. See our UK DUAA and PECR guide.
- More US state laws start in 2027. Oklahoma and Louisiana take effect January 1, 2027, and Alabama on May 1, 2027. Alabama has no standalone opt-out-signal duty. Delaware's HB 380 amendments also take effect January 1, 2027. Check each statute, and track them in our US state privacy law tracker.
- India's DPDP Rules. The consent-manager framework starts on November 13, 2026, and the main obligations follow around May 13, 2027. The rules have no cookie-specific provision, but they apply to personal data you process from users in India, so plan a compliant consent mechanism. See DPDP cookie banner requirements.
- Accessibility of your banner. If your service falls within the European Accessibility Act, your banner is part of what is assessed. The referenced standard is built on WCAG 2.1 AA. A WCAG 2.2-based version (EN 301 549 V4.1.1) was published on September 2, 2026 and takes legal effect once cited in the Official Journal, expected around the end of 2026. Building to WCAG 2.2 AA covers both. See WCAG cookie banner requirements.
- Vendors enforcing consent signals. Microsoft began enforcing consent signals for Clarity on October 31, 2025, and Google made Consent Mode in Google Ads the single control for Ads data collected by Analytics tags on June 15, 2026. Re-check every third-party tool's requirements at least yearly.
Broader obligations beyond cookies (DSARs, vendor contracts, privacy policies) are in our SaaS privacy compliance requirements guide.
Implementation checklist, with "done when" tests
The logged-in app and cross-domain pieces usually take the most effort. Each step has a test, so you know when it's finished.
- Inventory every domain and subdomain (marketing, app, docs, status, support, staging). Done when: you have a written list owned by someone.
- Scan each one and categorize every cookie and script. Done when: nothing is left "unclassified".
- Assign one legal basis per tracker. Done when: each tracker has a documented basis.
- Block all non-essential scripts until consent. Done when: with consent refused, the browser's network and storage tabs show no non-essential requests or cookies.
- Share one decision across your registrable domain (server-set cookie) and plan a lookup for domains you can't share cookies with. Done when: accepting on the website carries to the app and docs without a second banner.
- Save consent to the user's account and apply it on login. Done when: signing in on a new device doesn't re-prompt.
- Apply region rules and honor Global Privacy Control. Done when: a test with the Sec-GPC: 1 header turns off sale/sharing and ad scripts.
- Mask session replay; load chat and similar widgets after consent. Done when: recordings show masked fields, and the chat widget doesn't set cookies until allowed.
- Log each decision: ID, timestamp, banner version, choices, region, source. Done when: you can export the record for any user.
- Give "Reject" equal weight; add "Cookie settings" in the footer and the app. Done when: a person can withdraw in the same number of clicks it took to accept.
- Re-prompt on new vendors or purposes and on your chosen schedule; rescan monthly and after releases. Done when: these are calendar items or CI checks, not good intentions.
FAQ
Is cookie consent required for SaaS, including B2B?
If you have EU or UK users and set non-essential cookies or load third-party trackers, yes. It doesn't matter that your product is B2B: the rules protect each person using the site, and every team member in a customer's account is a separate user. Strictly necessary cookies are exempt. In the US the focus is opt-out rights and honoring signals like GPC.
We only sell to US customers. Do we need cookie consent?
GDPR can still apply. Its territorial rule covers data subjects in the EU when you offer them goods or services or monitor their behavior, so a US-only SaaS that tracks EU visitors can be caught without targeting them. Check for EU or UK visitors in your analytics. For US-only audiences, state privacy laws generally require notice, opt-out rights and signal handling (GPC) where mandated, and session replay carries CIPA risk.
What software can I use to manage cookie consent?
A consent management platform (CMP) handles the banner, script blocking, regional rules and consent logs. For SaaS, check multi-domain support, logged-in user handling and audit logging, as listed above.
Are cookies GDPR compliant?
Cookies themselves aren't compliant or non-compliant: the way you use them is. Under GDPR and ePrivacy, non-essential cookies need prior, informed, specific and freely given consent, and strictly necessary ones don't.
Why does my banner keep reappearing in Safari?
Safari deletes cookies and storage written by JavaScript after about seven days of Safari use without an interaction on your site. Setting the consent cookie from your server avoids this, unless it is served through a CNAME or IP-cloaked third-party setup.
Is product analytics strictly necessary?
Usually not. In the EU, some regulators allow a narrow audience-measurement exemption under strict conditions. In the UK, a statistical-purposes exception has applied since February 2026 if the sole purpose is improving your own service and users can object easily. If the data is used for anything beyond that, consent is the safe route.
Do I need to honor Global Privacy Control?
California requires it, and about a dozen other states have similar rules. Confirm the requirements for each state where you have users. Honoring it everywhere is the simplest policy.
How often should consent be refreshed?
There's no single legal rule. The CNIL treats about six months as good practice for re-asking consent, and it sets a 13-month maximum for the trackers it exempts from consent. Always re-ask when your cookies, vendors or purposes change.
Next step
Find out what your domains set before a regulator or a customer does: run a free cookie scan on your marketing site, app and docs, then compare it to your banner.
