Session Replay and GDPR: How to Stay Compliant

Session replay tools record what users actually do in your application: which screens they navigate, what text they type, which errors appear. When those users are logged in — or when the recordings contain visible personal information — that data qualifies as personal data under GDPR. This is not an edge case or a legal technicality; it's a straightforward reading of Article 4.

The good news is that GDPR compliance for session replay is achievable with the right configuration. The bad news is that most teams deploy session replay first and think about compliance later — sometimes only when preparing for an audit or responding to a data subject request. This guide covers what compliance actually requires, in practical terms.

This is not legal advice. Your specific obligations depend on your jurisdiction, the nature of your data, and your users' locations. Review your implementation with qualified legal counsel.

Why Session Replay Is Personal Data Under GDPR

GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." A session recording of a logged-in user is clearly covered — the recording can be attributed to a specific individual via their user ID, email address, or other identifiers visible in the UI.

Even anonymous sessions may qualify. A recording that captures a browser fingerprint, an IP address, or a combination of attributes that can be used to re-identify a person is still personal data under GDPR. The test isn't whether you know the person's name — it's whether they're identifiable.

The practical consequence: before you record sessions from EU users, you need a lawful basis for that processing, a plan for data minimisation, defined storage limits, and appropriate disclosures in your privacy policy.

Lawful Basis: Which One Applies?

GDPR requires that every act of personal data processing has a lawful basis. For session replay, three are typically considered:

Consent (Article 6(1)(a)). The user explicitly opts in before recording starts. This is the clearest legal basis — but it requires a consent mechanism before any recording begins, adds friction for users who just want support, and can be withdrawn at any time. For always-on recording tools, obtaining consent from every visitor before recording starts is operationally difficult.
Legitimate interests (Article 6(1)(f)). The most common basis used in practice. You assert that your interest in debugging and improving your product outweighs the user's privacy interests, after completing a balancing test. This is generally defensible for on-demand support recordings — the user sought help; you're recording to provide it. It's harder to justify for bulk always-on recording of users who never have any issues, where the "necessity" argument is weaker.
Contractual necessity (Article 6(1)(b)). Sometimes used in B2B SaaS contexts, where session recording is framed as necessary to perform support services under the terms of service. This has a narrower scope than legitimate interests and typically only covers recording in direct response to a support request.

On-demand recording — where a session is only captured when a user has explicitly activated a diagnostic link — is more naturally defensible under legitimate interests than always-on recording. The processing is narrower, more clearly necessary, and limited to users who are actively seeking help.

The Six GDPR Principles Applied to Session Replay

GDPR Article 5 sets out six data processing principles. Here's how they map to session recording in practice:

Purpose limitation. Record sessions for a specific, documented purpose — debugging and support. Don't repurpose session recordings for marketing, product analytics, or other uses without a separate lawful basis.
Data minimisation. Collect only the data necessary for your purpose. This argues directly against always-on recording of users who never need support, and in favour of aggressive PII masking to exclude data you don't need for debugging.
Storage limitation. Don't retain session recordings longer than necessary. For support debugging, recordings are typically no longer needed once the case is closed. Define a retention period (30–90 days is common) and ensure your tool enforces automatic deletion.
Integrity and confidentiality. Protect session recordings with appropriate access controls. Restrict access to support and engineering roles. Ensure recordings are encrypted at rest and in transit.
Accountability. Document your session recording practices in your Record of Processing Activities (RoPA) with the lawful basis, data categories, retention period, and third-party processors involved (your session replay vendor).
Accuracy. Less directly relevant to session recordings — recordings are captures, not editable records. But if a user exercises their right of access, ensure you can accurately identify and return all recordings associated with their account.

CCPA Obligations

Under CCPA, session recording data that can be associated with a California resident qualifies as "personal information." The key practical obligations are:

Disclosure. Your privacy policy must disclose that you collect session recordings, what categories of personal information they contain, and how you use them. This is a baseline requirement regardless of your scale.
Right to deletion. California residents can request deletion of their personal information. Session recordings linked to a specific user must be included in your deletion response process.
Do Not Sell / Do Not Share. If you share session recording data with third parties for cross-context behavioural advertising, opt-out rights apply. For support-oriented session recording, this is typically not relevant — you're not selling the data.

B2B SaaS products often have reduced CCPA exposure when session data is collected in the context of a business relationship rather than a consumer context — but verify this with counsel for your specific situation. Disclosure and deletion obligations are broadly applicable regardless.

Technical Compliance Checklist

PII masking

Password fields should be masked by default in any compliant session replay tool — if they aren't, that's a hard blocker before deployment. Beyond passwords, apply masking to: payment card inputs, government ID fields, health and medical data, and any other sensitive fields relevant to your application. Note that Stripe and similar providers render payment fields in iframes from their own domain, which won't be captured by your SDK — but verify this explicitly for your setup.

Clairvio uses the data-clairvio-mask attribute to exclude element content from recordings. Apply it to any element whose content should not appear in a replay. For a full treatment of masking approaches, see our guide to privacy-first session recording.

Network request filtering

Network request logs captured in session replay should have authentication headers stripped: Authorization, Cookie, X-API-Key, and any custom auth headers your application uses. Response bodies should be filtered to exclude personal data — log status codes and error codes rather than full response payloads wherever possible.

Data retention limits

Define a retention period that matches your support workflow and configure your tool to enforce it automatically. For most support use cases, 30–90 days is appropriate. Verify that deletion happens automatically — don't rely on manual cleanup, and don't wait until you receive a deletion request to test whether it works.

Right to erasure

When a user exercises their right to erasure under GDPR (or right to deletion under CCPA), session recordings associated with their account must be deleted. Build this into your user data deletion workflow before you receive your first request — retrofitting it under time pressure is entirely avoidable with a bit of planning.

Privacy policy disclosure

Your privacy policy must disclose that you use session recording, the categories of data captured, the lawful basis (for GDPR), the retention period, and how users can request deletion or access to their recordings. For always-on recording, consider a more prominent in-product disclosure. For on-demand recording via magic links, the mechanism is inherently transparent — users know they activated recording because they clicked the link.

Access controls

Restrict session replay access to roles that genuinely need it — typically support and engineering. Prevent access from marketing, sales, or other teams unless there's a documented purpose. Where your tool supports access logging, enable it. The principle of least privilege applies to session data as much as it does to production databases.

How Recording Model Affects Compliance Complexity

The recording model you choose has a direct effect on how complex your compliance posture becomes — and this is worth factoring into tool selection, not just implementation.

Always-on recording processes personal data from every visitor continuously. Your legitimate interests balancing test must cover all of those users, most of whom will never have a support issue — which makes the "necessity" argument harder to sustain. You need broad privacy policy disclosures, and in some jurisdictions, cookie consent flows before recording starts. Data volumes are higher, which increases the scope of any deletion obligation you receive.

On-demand recording only processes data from users who have actively sought support and clicked a magic link. The consent picture is cleaner — the user took a deliberate action to share their session. The data minimisation principle is satisfied structurally: you're only recording sessions where the data is needed. Retention obligations are narrower and easier to enforce.

This doesn't eliminate your compliance obligations — on-demand recording still processes personal data and the obligations still apply. But the practical compliance burden is meaningfully lower when you're not recording every visitor by default. For more on the privacy philosophy behind recording models, see our privacy-first session recording guide.

A Practical Compliance Checklist

Identify the lawful basis for session recording and document it in your RoPA
Update your privacy policy to disclose session recording: purpose, legal basis, retention period, and how users can request deletion or access
Verify that password fields are masked by default in your recording tool
Apply data-clairvio-mask (or equivalent) to all PII-containing elements in your application
Configure network request filtering to strip authentication headers and exclude sensitive response data
Set a retention period (30–90 days recommended for support use cases) and verify automatic deletion is enforced
Add session recording deletion to your user data erasure workflow; test it before you receive a request
Restrict session replay access to support and engineering roles with documented justification
If using always-on recording: evaluate whether your consent mechanism covers recording before any session starts
Review your tool vendor's Data Processing Agreement (DPA) to ensure it covers your obligations as a data controller