Is session replay GDPR compliant? (2026 plain-English guide)

Yes — session replay can be GDPR compliant, but only if you mask PII at the SDK level, have a documented lawful basis (consent or, more rarely, legitimate interest), keep a short and justified retention period, sign a Data Processing Agreement with your replay vendor, and can fulfil data subject access and deletion requests within the statutory deadlines. None of those are optional, and none of them are difficult once you've decided to take them seriously.

This post is a plain-English explainer aimed at marketing and product teams. It is not legal advice. For a binding interpretation of GDPR as it applies to your business, talk to a qualified data protection lawyer.

Is session replay data "personal data" under GDPR?

Almost always, yes. GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." A session-replay recording typically contains:

• The visitor's IP address (regarded as personal data by the EDPB and most DPAs).
• A device or session identifier that can be linked back to a person.
• Mouse movements, click patterns, and scroll behavior — which the European Data Protection Board has, in several opinions, treated as behavioral data sufficient to identify a returning visitor.
• Whatever the visitor typed into form fields, unless you mask it.

The consensus among GDPR practitioners is that you should treat session-replay data as personal data by default. Even if you strip the IP and the form values, the combination of behavioral signals can be enough to single out an individual — and Article 4(1) is explicit that "singling out" qualifies someone as identifiable.

That doesn't mean you can't capture replays. It means you have to follow the rules that apply to any personal data processing.

What is the legal basis: consent or legitimate interest?

GDPR Article 6 lists six lawful bases for processing personal data. For session replay, only two are realistic:

1. Consent (Article 6(1)(a)) — the visitor agreed, freely and specifically, after being informed.
2. Legitimate interest (Article 6(1)(f)) — your business need is real, the processing is proportionate, and the visitor's rights don't override it.

Most vendors and DPAs lean toward consent for session replay, for two reasons:

• The ePrivacy Directive (and the German TTDSG, the French Loi Informatique et Libertés, and the Italian Codice Privacy as implemented) generally requires opt-in consent before storing or accessing information on a user's device. Session replay scripts almost always store something — at minimum, a session ID in a cookie or localStorage. That triggers ePrivacy regardless of whether GDPR's legitimate interest basis would otherwise allow it.
• Several supervisory authorities (notably the CNIL in France) have publicly questioned legitimate interest as a basis for behavioral analytics and have been more comfortable with explicit consent.

That said, legitimate interest is defensible for narrowly scoped, error-debugging-only replay — for example, capturing only sessions where a JavaScript error fired, with strict retention and aggressive masking. Document the legitimate interest assessment (LIA) before you rely on it.

A quick decision tree:

Are you running session replay across all visitors?
├── Yes → consent is the safer basis
└── No, only on errors / specific events
    ├── Is replay aggressively masked and retained briefly? → LIA may support legitimate interest
    └── Otherwise → consent

What are the four mandatory configuration points?

Whatever your legal basis, four operational controls are non-negotiable. Treat these as the floor.

1. Mask PII at the SDK level

PII-masking must happen in the browser, before the replay event ever leaves the visitor's device. Server-side masking is too late — by then, the data is already on someone else's infrastructure. A modern replay SDK (built on rrweb or similar) supports:

• Masking all <input>, <textarea>, and <select> values by default.
• A data-private or data-mask attribute to mark arbitrary DOM nodes as redacted.
• A blocklist for entire DOM subtrees (e.g. the checkout summary, the user profile widget).
• Masking for canvas, video, and image elements where they could leak personal data.

If your replay vendor cannot show you all four of those controls, treat that as a red flag.

2. Set a short, justified retention period

GDPR Article 5(1)(e) requires that data be kept "no longer than is necessary." For session replay, "necessary" is rarely more than 30-90 days. Many vendors default to 30 days; some go to 12 months. A 12-month default is hard to justify for replay specifically.

Whatever you pick, write it down in your privacy notice and enforce it with an automated deletion job — not "we mean to delete it next quarter."

3. Sign a Data Processing Agreement (DPA) with the vendor

Your replay vendor is a processor under Article 28. You are the controller. The DPA is the contract that binds the processor to act only on your instructions, to implement appropriate security, and to delete data when you tell them to. Every reputable vendor publishes a DPA you can countersign in minutes. If yours doesn't, that is a serious problem.

Also check where the data is stored. If your vendor processes EU visitors' data outside the EEA, you need an appropriate transfer mechanism — Standard Contractual Clauses (SCCs) and a Transfer Impact Assessment, or hosting in an adequacy-approved jurisdiction.

4. Support DSAR and deletion requests

When a visitor exercises their right of access (Article 15) or erasure (Article 17), you have one month to respond. For session replay, that means:

• You can find every replay associated with a given visitor (typically by user ID, email, or session ID).
• You can export the relevant recordings for an access request.
• You can delete them, on demand and verifiably, for an erasure request.
• Your vendor supports these workflows in their dashboard or API. If you have to email support every time, you will miss the deadline.

What is the CIPA / wiretap angle for US visitors?

Briefly, because it matters for any site with US traffic: a wave of class-action lawsuits in California and other US states has invoked old wiretap statutes — including the California Invasion of Privacy Act (CIPA, Penal Code §631) — against site owners that deploy session replay without disclosure. The legal theory is that the replay script intercepts a "communication" between the visitor and the website without all parties' consent.

The case law is still developing. As of early 2026, several courts have allowed these claims to proceed past motions to dismiss, while others have rejected them. The neutral, conservative stance is:

• Disclose session replay clearly in your privacy notice.
• Consider a banner or interstitial for US visitors that mirrors your EU consent flow.
• Mask PII aggressively to reduce the "interception of contents" argument.
• Talk to US counsel if you have meaningful California traffic.

This is not a GDPR issue, but it is the second-most-common privacy question we hear about replay, so it belongs in any honest writeup.

A 6-step compliance checklist

Use this as the minimum bar before you turn on session replay in production.

1. Decide your lawful basis — consent for broad capture, documented legitimate interest only for narrow, error-only capture. Write it down.
2. Configure PII masking at the SDK — mask all inputs by default, add data-private to anything else that could leak personal data, and block sensitive subtrees entirely.
3. Set a retention period — 30-90 days is the safe band for marketing replay. Enforce it with automation.
4. Sign the vendor DPA — and verify data residency, sub-processors, and transfer mechanisms.
5. Wire up DSAR and deletion — make sure you can find and delete a visitor's replays within the one-month statutory window.
6. Update your privacy notice and consent banner — name the tool, name the categories of data captured, link to the vendor's privacy policy, and disclose retention.

A useful pattern is to add a tiny attribute-driven masking convention to your codebase so that engineers don't have to think about it:

<!-- Always masked -->
<input type="email" name="email" />

<!-- Explicitly masked because it contains user data -->
<div data-private>
  Welcome back, <span>{{ user.name }}</span>
</div>

<!-- Entire subtree blocked from replay -->
<section data-replay="block">
  <h2>Account details</h2>
  ...
</section>

The convention pays for itself the first time a customer asks "what does your replay tool record about me?" and you can answer with code, not with a hand-wave.

Frequently asked questions

Is session replay illegal in the EU?

No. Session replay is legal in the EU when implemented under a valid GDPR lawful basis with appropriate technical and organizational controls. The illegal version is the one without consent, without PII masking, without a retention policy, and without a DPA — which is unfortunately the version many sites still run.

Do I need a cookie banner for session replay?

In most EU member states, yes. Session replay typically reads or writes a session identifier on the visitor's device, which triggers Article 5(3) of the ePrivacy Directive (the "cookie law"). That requires informed consent before the script loads, regardless of GDPR's separate lawful-basis question. Your existing consent management platform should already gate analytics; add replay to the same category.

Does masking form fields automatically make replay GDPR compliant?

No. PII masking is necessary but not sufficient. You also need a lawful basis, a retention policy, a DPA with the vendor, and a working DSAR process. Masking alone reduces risk; it does not satisfy the principles of lawfulness, transparency, and accountability that GDPR requires.

Can I use legitimate interest instead of consent for session replay?

Possibly, for narrow use cases — for example, capturing only sessions where a JavaScript error occurred, with aggressive masking and short retention. You must document a Legitimate Interest Assessment (LIA) that weighs your interest against the visitor's rights. For broad, all-visitor session capture, most DPAs and practitioners recommend consent.

What is the safe retention period for session replays?

30 to 90 days is the band most replay vendors and EU practitioners treat as defensible for general marketing use. Longer retention is hard to justify under Article 5(1)(e)'s "storage limitation" principle unless you have a specific, documented purpose (e.g. an open dispute or fraud investigation).

How does this apply to form-abandonment-rate tracking and partial form data?

The same rules apply. Capturing partial form values is processing personal data. The conservative pattern is to capture field names and engagement events only, and treat any actual values as fully masked. If you do capture an email address before the visitor abandons the form, that becomes a lead record and inherits all your normal lead-data obligations. See how to track form abandonment in Contact Form 7 for the technical pattern.

What does CloseTrace do about GDPR specifically?

CloseTrace starts new self-serve accounts with replay masking enabled by default, supports data-private / data-mask style selectors for redaction, supports subtree blocking with data-lt-block / data-block, and exposes a privacy-request channel for access or deletion requests. None of that absolves you of your controller obligations — but it does reduce the structural ways replay deployments drift into risky territory.

Closing thought

Session replay is one of the most useful things a marketing or product team can deploy — and one of the easiest to deploy badly. The compliance work is not hard. It is mostly six decisions, written down, enforced in code, and disclosed honestly. Do those six things and you can use replay the way it was meant to be used: to understand your visitors well enough to build something that respects them.