Skip to main content
Compliance

GDPR-compliant session replay.

Updated 2026-05-26 Relyv.ai Editorial Team

Session replay can be GDPR-compliant — but only if the SDK masks PII before bytes leave the browser, the controller-processor contract is signed, and the data-protection impact assessment is on file. Here's the exact list, with the legal articles cited.

Try Relyv free See our DPA

The one-sentence answer

Session replay is GDPR-compliant when the SDK masks personal data on-device before transmission, the controller has a documented lawful basis under Article 6, a signed Article 28 Data Processing Addendum is in place with the replay vendor, and a Data Protection Impact Assessment (Art. 35) covers the processing. If any one of those four is missing, you are exposed to ICO/CNIL enforcement and to data-subject complaints.

The four requirements, with the articles cited

These are the legal mechanics — not a vendor-marketing checklist.

1. On-device PII masking — Art. 5(1)(c) data minimisation

GDPR Article 5(1)(c) requires processing to be "adequate, relevant and limited to what is necessary." For session replay, this means personal data (names, emails, phone numbers, addresses, payment data, free-text input) must be masked before the SDK transmits anything to the replay vendor. Server-side masking after upload technically violates data minimisation because the unredacted data has already been processed by the vendor. Look for: regex-based masking on standard PII patterns (email, SSN, credit card via Luhn), attribute-selector masking (data-relyv-mask), and optional on-device ML for free-text fields. Verify by recording a session that includes a credit-card form and inspecting the raw payload before upload — the digits should be redacted at source.

2. Lawful basis — Art. 6

You need one of six lawful bases under Article 6(1). For session replay the practical choices are: legitimate interest (6(1)(f)) — the most common; balance test required against the data subject's rights — or consent (6(1)(a)) — opt-in via your cookie banner; cleaner legally but reduces sample size. Most engineering-tool deployments use legitimate interest with a clear privacy notice and opt-out mechanism. If you process special-category data (Art. 9 — health, biometrics, religion, etc.), legitimate interest is not sufficient; explicit consent or another Art. 9(2) basis is required.

3. Article 28 Data Processing Addendum (DPA)

GDPR Article 28 requires the controller (you) and processor (the replay vendor) to have a written agreement covering: subject matter, duration, nature and purpose of processing, types of personal data, categories of data subjects, and the processor's obligations (confidentiality, security, sub-processor engagement, audit rights, breach notification, deletion at end of service). Reputable replay vendors publish a standard DPA you can sign electronically (Relyv's is here). If the vendor doesn't publish a DPA, you have a problem — there's no GDPR-compliant deployment path without one.

4. Data Protection Impact Assessment — Art. 35

Article 35 requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The ICO's guidance explicitly lists "systematic monitoring of publicly accessible areas" and "innovative use of new technology" as DPIA triggers. Session replay typically qualifies. The DPIA documents: the nature of processing, necessity + proportionality, identified risks, and the mitigation measures (on-device masking, retention limits, access controls). Keep it on file; data-protection authorities can ask for it.

Sub-processor disclosure — Art. 28(2)

Your DPA must list every sub-processor the replay vendor uses (typically: cloud provider for storage, CDN for SDK delivery, possibly an AI provider for transcripts/summarisation). Article 28(2) requires prior consent or general authorisation for sub-processor engagement; the vendor must notify the controller of changes. Sub-processors are the most common gap in real-world deployments because vendors add new ones without updating the DPA. Audit annually.

Data residency — Art. 44–50

If your data subjects are in the EU/EEA, personal data leaving the EEA needs a transfer mechanism under Articles 44–50. After Schrems II (2020), Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment (TIA) is the dominant path. EU-data-residency (data stored exclusively in EU regions) avoids the transfer question entirely; many replay vendors offer this as a paid tier. If you process UK data, the UK equivalent (UK GDPR) accepts SCCs plus IDTA (International Data Transfer Agreement).

Retention + deletion — Art. 5(1)(e), Art. 17

Session recordings should have a defined retention period (90 days is a common default; some vendors offer 30/180/365). Document the period in your privacy notice. Article 17 ("right to erasure") requires the vendor to delete a specific data subject's sessions on request — typically by user ID. Confirm the vendor exposes a deletion API or admin UI; verify the deletion completes within the SLA (usually 30 days for GDPR).

The compliance checklist

A practical compliance review can be done in an afternoon. Walk this list:

  • ✅ The SDK masks email, phone, credit-card, SSN and free-text fields on-device by default. Verified by inspecting raw upload payload.
  • ✅ Your privacy notice mentions session replay, the lawful basis, and the retention period.
  • ✅ A signed DPA is on file with the replay vendor; it lists all current sub-processors.
  • ✅ A DPIA exists and identifies session replay as a processing activity, with on-device masking listed as the mitigation.
  • ✅ If you have EU data subjects: SCCs are in place OR data is stored in EU regions only.
  • ✅ Documented retention period (e.g. 90 days); auto-deletion confirmed working.
  • ✅ Deletion-on-request API or admin tool tested end-to-end against a real user ID.
  • ✅ Cookie banner integration: the SDK respects consent (opt-out or opt-in depending on legal basis).
  • ✅ Access controls: replay viewer requires authentication; per-user audit log of who watched which session is enabled.

What ICO and CNIL have actually fined for

A few real-world enforcement signals worth knowing:

  • The <strong>French CNIL fined Google €50M in 2019</strong> partly for insufficient transparency around the lawful basis for personalised advertising. The principle applies to replay: lawful basis must be specific and discoverable in the privacy notice.
  • The <strong>UK ICO issued enforcement notices to clothing retailer Easylife (£130K, 2022)</strong> for legitimate-interest misuse on behavioural data. Replay vendors with insufficient documentation of the LIA (legitimate interest assessment) are exposed.
  • Multiple <strong>noyb.eu complaints</strong> against EU operators of replay-bundled tooling for lacking Art. 13/14 transparency. Compliant deployment requires the privacy notice to mention the replay vendor by name.

How Relyv handles each requirement

For the record (and because compliance pages without vendor specifics are useless):

  • <strong>On-device masking:</strong> Regex + Luhn validation for email/phone/credit-card by default; <code>data-relyv-mask</code> attribute for custom selectors; optional on-device GLiNER LLM (via the browser extension) for free-text PII detection.
  • <strong>DPA:</strong> Published at <a routerLink="/dpa">/dpa</a> with all current sub-processors listed.
  • <strong>Data residency:</strong> EU and US regions available on Business + Enterprise tiers.
  • <strong>Retention:</strong> 90 days default; configurable to 30/180/365 per workspace.
  • <strong>Deletion API:</strong> <code>DELETE /v1/sessions?user_id=...</code> with same-day execution; audit-logged.
  • <strong>Access controls:</strong> SSO + SAML on Business+; per-session view audit log on all tiers.

Frequently asked questions

Is session replay legal under GDPR?

Yes, when the SDK masks personal data on-device before transmission, a documented lawful basis exists (typically legitimate interest under Art. 6(1)(f) or explicit consent), an Article 28 Data Processing Addendum is signed with the vendor, and a Data Protection Impact Assessment per Art. 35 is on file. Without those four, you are exposed to enforcement.

Do I need consent to record sessions?

It depends on the lawful basis you choose. Legitimate interest (Art. 6(1)(f)) does not require consent but requires a balance test, a clear privacy notice, and an opt-out mechanism. Explicit consent (Art. 6(1)(a)) is required if you process special-category data or if your jurisdiction's e-Privacy implementation requires it for storage access (some EU member states interpret PECR more strictly).

Does masking PII server-side count as GDPR compliance?

Technically no. Server-side masking means the unredacted PII was transmitted to the vendor before redaction — which violates Article 5(1)(c) data minimisation. The compliant pattern is on-device masking that happens in the browser before any bytes leave for the vendor.

How long can I keep session recordings?

GDPR doesn't set a fixed limit; the test is "no longer than necessary" (Art. 5(1)(e)). Industry practice is 30–90 days for debugging use cases, 180–365 days for compliance-archive use cases. Whatever you choose, document it in your privacy notice and ensure the vendor auto-deletes on schedule.

What's the difference between a DPA and a DPIA?

A DPA (Data Processing Addendum) is a contract between you (controller) and the vendor (processor) covering Art. 28 obligations. A DPIA (Data Protection Impact Assessment) is an internal document you produce per Art. 35 to assess the risk of the processing activity. You need both — the DPA from the vendor; the DPIA written by your data-protection team.

Does the user have a right to see their own session recording?

Yes — Article 15 ("right of access") gives data subjects the right to obtain a copy of personal data being processed about them. In practice, replay vendors typically respond via the data controller (you), who can extract the session via the vendor's admin tools and send the user a download. Most vendors also support outright deletion under Art. 17 via API.

What about CCPA / California — is it the same?

CCPA is a different framework but the practical requirements overlap. CCPA gives California residents a right to know, delete, and opt out of "sale" of personal information. Session replay typically isn't "sale" under CCPA, but the right-to-delete and right-to-know obligations apply. The same on-device masking, retention controls, and deletion APIs that satisfy GDPR also satisfy CCPA.

Related reading

Ready to record your first session?

Free 1,000 sessions/mo. No credit card. Cancel anytime, no refunds.

Try Relyv free