Is Session Replay Legal? A GDPR Compliant Session Recording Tool Checklist

At Pintelly, we build session replay, so we spend a lot of time thinking about exactly where GDPR and CIPA draw the line — and about being upfront on where our own implementation still has gaps. This guide is that walkthrough, disclaimer included.

This article is not legal advice. Your obligations under CIPA, WESCA, GDPR, and CCPA/CPRA depend on your specific data flows, jurisdictions, and contracts. Confirm any decision with counsel before you ship a session recording tool to production.

A product team turns on session replay to debug a checkout flow. Three months later, legal forwards a class-action demand letter: a California visitor alleges their mouse movements, clicks, and form interactions were recorded from the moment they landed on the page — before any banner, before any choice, before any notice. This is not a hypothetical. Since two 2022 federal appellate rulings, website session-recording tools have become one of the most litigated categories of wiretapping and privacy claims in the United States, and GDPR regulators in the EU have separately flagged the same technology for the same underlying reason: it can capture more than the site operator intended to collect.

This guide does two things. First, it lays out — without exaggeration — what actually creates legal exposure when you run session replay, under both US wiretapping statutes and GDPR/CCPA. Second, it walks through what to verify in a vendor's actual architecture (not its marketing page) before you trust it with this problem, using our own session replay module as a worked, code-verified example, limitations included.

Why Session Replay Became a Target for CIPA and Wiretapping Suits

Session replay libraries (rrweb and similar) reconstruct what a visitor saw and did — DOM mutations, cursor movement, form interactions — into a playable recording. In the US, a handful of state wiretapping statutes written for phone-tap-era surveillance have been read by courts to cover this kind of website recording, because most of them require two-party consent: everyone being recorded has to agree, not just the party doing the recording.

Three rulings shaped the current litigation landscape:

• Javier v. Assurance IQ (9th Cir., 2022): The Ninth Circuit held that under California's Invasion of Privacy Act (CIPA), consent to be recorded has to be obtained before the recording starts — consent collected retroactively, after a visitor has already been interacting with the page, doesn't satisfy the statute. This is the ruling that made timing the central technical question for every session-replay vendor. It's worth noting the underlying case itself was later dismissed with prejudice in 2023, on an unrelated statute-of-limitations ground — but the Ninth Circuit's prior-consent holding remains standing precedent and is what subsequent suits rely on.
• Popa v. Harriet Carter Gifts (3d Cir., 2022, 52 F.4th 121): The Third Circuit rejected a broad "party exception" under Pennsylvania's Wiretapping and Electronic Surveillance Control Act (WESCA) — a marketing/analytics vendor receiving visitor data isn't automatically exempt just because it's technically a recipient of the communication. This ruling is credited with triggering a wave of new WESCA filings against site operators using third-party session-recording and chat tools.
• Yoon v. Lululemon / Quantum Metric (C.D. Cal., 2021): This case is more nuanced than it's often summarized. The court dismissed the direct CIPA and federal Wiretap Act claims against the vendor (Quantum Metric) — a private right of action under CIPA didn't reach the vendor directly, and Quantum Metric's role as a technology provider wasn't itself an unlawful interception. But a separate claim, that Lululemon (the site operator) was aided and abetted by Quantum Metric in the alleged wiretapping, survived. The practical reading: liability centers on the company that deployed the tool on its site, with vendor exposure typically indirect rather than eliminated.

The pattern across all three: the party at risk is usually the website operator, not the session-replay vendor — which means "our vendor is GDPR/CIPA compliant" is the wrong question. The right question is whether your deployment starts recording before consent, and whether it captures raw form content that shouldn't have been collected in the first place.

GDPR and CCPA/CPRA: A Different Framework, the Same Two Questions

In the EU, the legal basis question is separate from the US wiretapping angle, but it converges on the same practical facts.

• Under GDPR Article 6, every processing activity needs a lawful basis. For session replay, teams generally argue either explicit consent (Art. 6(1)(a)) or legitimate interest (Art. 6(1)(f)). Legitimate interest requires a genuine balancing test — purpose, necessity, and whether the visitor's rights override the business interest — and that balance shifts hard toward "you need consent" the moment the recording can capture raw personal data like names, emails, or payment details typed into a form.
• If input fields are masked by default — meaning what's recorded is screen structure, clicks, and scroll behavior rather than raw form values — the legitimate-interest argument becomes more defensible. It is still not an automatic pass; it's a factor your DPO or counsel weighs, not a guarantee a vendor's marketing copy can hand you.
• On the US side, CCPA/CPRA imposes an opt-out logic rather than an opt-in one: California residents have the right to opt out of "sale" or "sharing" of their personal information, and California regulations recognize Global Privacy Control (GPC) as a valid, browser-level opt-out signal that businesses are expected to honor.
• If a vendor stores or processes EU personal data outside the EEA, that's a separate GDPR issue from the consent question — it requires a valid Article 46 transfer mechanism (typically an adequacy decision or Standard Contractual Clauses, with supplementary measures where needed), documented in a Data Processing Agreement. This is easy to overlook when the buying decision focuses only on masking and consent UX.

The common thread across CIPA/WESCA, GDPR, and CCPA is the same two questions: does recording start before the visitor has a real choice, and what does the recording actually contain?

What to Verify Before You Trust a "GDPR Compliant" Session Recording Tool

Don't take a vendor's compliance badge at face value. Check these five things directly against the product's actual behavior:

1. Does recording start before a consent decision, or does it wait? Some tools buffer recording in the background before the visitor answers a consent prompt and only decide whether to keep it afterward — which is close to the exact timing problem Javier v. Assurance IQ flagged. You want a tool where the recording pipeline itself doesn't start until consent is affirmatively granted.
2. Does "opt out" actually stop recording in the browser, or just filter it out of your dashboard? A visitor who declines should stop being recorded client-side — not just get excluded from reports while the data still gets collected.
3. Are form inputs masked by default, or do you have to mark every sensitive field yourself? A manual, field-by-field masking model means one missed field — a newly added payment or health-intake form — is a real leak, not a hypothetical one.
4. Can it defer to a consent management platform you already run (OneTrust, Cookiebot, etc.), instead of forcing you to run two separate consent systems side by side?
5. Where is the data stored, and is there a signed DPA covering the transfer mechanism if the vendor's infrastructure sits outside your users' jurisdiction? This is a contract question, not something a product feature can solve on its own.

Our Approach, Verified Against the Codebase

Our session replay module is built on rrweb. We checked our own source code — not our marketing copy — against the checklist above. Here's what holds up, and where the honest limits are.

Recording is gated on explicit, granted consent — with one exception you need to know about. In the SDK, session replay and cursor tracking live in what the code calls the "sensitive tier": unlike basic page-view tracking, this tier only turns on when consent is explicitly granted. A denied or still-undecided visitor is never recorded. If your project has Require Consent turned on in the dashboard, a visitor sees a consent prompt and recording only begins after they accept; a decline or a pending decision keeps replay off entirely.

Here's the exception, stated plainly because burying it would defeat the point of this checklist: requireConsent defaults to false for new projects. When it's off, the SDK auto-grants consent immediately on page load (unless a visitor has already explicitly declined in a prior session) and session replay can start right away, with no banner shown. In practice, this means the consent gate only does its job if you deliberately turn Require Consent on — or wire up your own cookie banner and call Pintelly.setConsent(false) (or true) yourself, which our SDK documents as an explicit override that takes precedence over the dashboard setting regardless of which way Require Consent is set. We also auto-recognize Cookiebot and CookieYes consent cookies out of the box; other consent management platforms need a small config mapping (externalConsentKey) to plug in.

Form inputs are masked unconditionally, not opt-in. rrweb's record() call in our codebase is configured with maskAllInputs: true as a fixed setting — not a dashboard toggle you might forget to flip. That means input field values, across all form fields (not just fields explicitly typed as password), are never captured as raw text in the DOM snapshot; only the masked representation is recorded. There is currently no dashboard control to selectively unmask specific fields, which is a limitation for teams that specifically want to see redacted-but-partial input (e.g., last four digits of a phone number) — today it's all-or-nothing masking.

Session replay data is retained on a tiered schedule, not a flat window. Per our published privacy documentation (updated September 2026), a replay that's never opened is deleted 7 days after its last recorded chunk; a replay that is opened is retained for up to 30 days. A replay an authorized dashboard user explicitly saves is exempt from automatic deletion until we ship a separate saved-item retention policy. That's a concrete, publicly stated behavior — not a marketing claim — and it's worth confirming against the current privacy policy before you rely on it for a data-minimization argument to your DPO.

A signed DPA with Standard Contractual Clauses is available for cross-border transfers. Our infrastructure and databases are described in our own marketing content as hosted in Türkiye, which is a third country under GDPR — it does not have an EU adequacy decision. Our published Data Processing Agreement addresses this directly: where personal data leaves the EEA, it states reliance on an adequacy decision where available, or Article 46 safeguards such as the European Commission's Standard Contractual Clauses, with supplementary measures where required. If your legal basis analysis depends on where data physically sits, get the current DPA and subprocessor list from us directly rather than assuming from this article — infrastructure details change.

Two limitations we found and want to be direct about, rather than let a feature page gloss over them:

• Global Privacy Control (GPC) is not automatically detected. If you want us to honor a visitor's browser-level GPC opt-out signal, you need to read that signal yourself and call Pintelly.setConsent(false) in your own code — our SDK doesn't do this out of the box today.
• Revoking consent stops future recording; it doesn't retroactively delete past recordings. When a visitor's consent is withdrawn, replay stops immediately going forward, but any session already uploaded before that point isn't automatically erased. Deleting previously collected data requires a separate deletion request through our standard data-subject-request process.

Frequently Asked Questions

Is session replay illegal under GDPR? No — session replay itself isn't unlawful. The risk comes from missing or weak legal basis (no valid consent, and a legitimate-interest argument that doesn't hold up) and from recording more than necessary, particularly raw form content. Default masking and consent-gated recording reduce that risk; they don't eliminate the need for your own legal basis assessment.

Who's liable in a CIPA session-replay lawsuit — the vendor or the website owner? Based on how these cases have actually played out, primary liability tends to fall on the website operator that deployed the tool. In Yoon v. Lululemon, direct CIPA and federal Wiretap Act claims against the vendor (Quantum Metric) were dismissed, while an aiding-and-abetting theory against the vendor, tied to the operator's use of the tool, survived. That's a reason to scrutinize your own deployment configuration, not just the vendor's compliance page.

If a visitor declines consent, is their previously recorded session deleted automatically? Not in our current implementation. Declining or withdrawing consent (via setConsent(false)) stops future recording immediately, but data already uploaded before that point requires a separate deletion request — it isn't purged automatically.

No, not yet. We don't detect the signal automatically in the current version — if GPC compliance matters for your CCPA/CPRA posture, you need to detect it on your own and call Pintelly.setConsent(false) when it's present.

Next Step

Before enabling session replay, decide with your legal team which basis you're relying on — consent or legitimate interest — and for which jurisdictions. Then verify, technically, that your chosen tool actually supports that decision: consent-gated recording (and confirm the "Require Consent" toggle matches your intent), default masking, and a signed DPA that covers wherever the vendor's infrastructure actually sits.

Try Pintelly free and check our consent-gated recording and default input masking against your own site before you decide. See pricing for plan and quota details, and our privacy practices for how we handle visitor data overall.

A deeper, field-by-field PII masking checklist for session replay would belong in its own article — not yet published, so not linked here.