Session Replay and GDPR: A Practical Privacy Guide

Session replay records what people do inside your product. Under the GDPR — and the laws modelled on it — that makes a recording personal data the moment it can be tied to a person, and a recorder something you have to be able to justify. This guide is not legal advice; it is the set of engineering decisions that determine whether a lawyer can sign off, and how AnyReplay makes each one.

Start from what is recorded

A web session recorder captures the page structure and its changes, mouse and scroll positions, navigation, and — unless stopped — anything typed into a form. The typing is where most of the risk lives: names, addresses, card numbers, health details and passwords all arrive through inputs. The second source of risk is text already on the page: an account screen that shows an email address or an order history is PII even though nobody typed it during the session.

Two principles follow. Personal data should be removed before it leaves the user's browser, not filtered on a server that has already received it. And somebody has to decide, field by field, what counts as personal data in your product — that decision is yours as controller, and once you opt out, a field nobody marked is a field that was recorded.

Masking at the source, and who decides

The browser SDK ships with maskAllInputs: true: every value in inputs, textareas and selects is replaced with asterisks before it leaves the browser. Recording what visitors type is a switch you turn on with maskAllInputs: false. maskAllTyping: true is the stricter option, covering form fields plus the text of every contenteditable region, which is otherwise recorded. Only a real boolean counts — the string 'false', which is what a tag manager variable usually hands over, is ignored, so fields stay masked. Under both options is a floor no configuration lifts: passwords and one-time codes; card numbers, security codes, expiry dates and cardholder names; IBANs, routing numbers and sort codes; any value of 13–19 digits that passes the card-number check, wherever it was typed; and a half-typed card number past its sixth digit. Those are replaced with asterisks in the browser before the event is serialised, so the original characters are never transmitted. type="email" and type="tel" are ordinary fields. For text that is not in an input, add the ar-mask class to any element and its text — and, on a form field, its value — is replaced; add ar-block and the element is not recorded at all — no box, no children, nothing. The React Native SDK matches it: maskAllInputs is true there too, while secureTextEntry, credential and payment fields and an ar-mask testID are always masked on the device.

How to mask sensitive data in session recordings covers the mechanics and the edge cases. The point for this guide is where responsibility sits. AnyReplay supplies the controls, enforces the credential and payment floor, and does all of it in the browser. Which of your fields carry personal data is a question only you can answer — the SDK cannot know that the field your checkout calls field-2 holds a date of birth — so once you opt out, deciding what stays masked, and writing that decision down, is part of your record of processing rather than a vendor default you can point at.

Consent, and recording nothing until you have it

Whether replay needs consent depends on your jurisdiction, your legal basis and what you record. Many teams conclude that it does, at least in the EU, because a recorder stores identifiers on the device and processes behaviour. What matters technically is that the recorder can be told to wait.

anyreplay('init', { projectKey: 'ar_pk_live_…', requireConsent: true });

// later, from your consent banner
anyreplay('consent', true);

With requireConsent: true the SDK loads but records nothing — no snapshot, no events, no network request — until anyreplay('consent', true) is called. Withdrawing consent stops it again. The React Native SDK has the same requireConsent option and consent(granted) call. See the consent entry for how this interacts with sampling.

Retention: recordings should expire

Storage limitation is one of the GDPR's core principles: keep personal data no longer than the purpose requires. A recording that helped reproduce a bug last week has no reason to exist next year. AnyReplay retains sessions for 14 days by default, configurable per organisation. Retention is enforced by the API on an interval, and deleting a session deletes the recording itself — the chunks in storage — not just the row that pointed at it. Data retention has the details.

Retention also shapes your data-subject request process. If someone asks what you hold about them, a 14-day window bounds the answer; if they ask you to erase it, deletion removes the recording and the deletion is written to the audit trail.

Who can watch, and proving it

Access control is part of privacy. AnyReplay organisations have five roles — owner, admin, moderator, member and viewer — governed by a permission matrix that is tested cell by cell, and no role may grant a role at or above its own rank. Permission changes, deletions and key rotation are written to an append-only audit trail. Tenant isolation is verified by test from a foreign tenant against every organisation-scoped route, and a foreign resource answers 404, never 403, so the API cannot be used to confirm that a session exists.

For regulated teams, session replay for fintech compliance walks through how these controls map onto an internal review.

Data residency and self-hosting

International transfer is the part of GDPR that has changed most often. The simplest answer is to not transfer: keep recordings on infrastructure you control, in the region you choose. AnyReplay is self-hostable — the deploy/ folder documents a single-host installation with PostgreSQL, the API, the ingest service and the dashboard behind nginx, with encrypted backups and a weekly restore test. Self-hosted session replay explains what it takes.

Self-hosting also simplifies your processor agreements: there is no third party holding the recordings, and translation — the one feature that calls a model — sends interface strings, not recordings, and caches every translation so a string is sent at most once per organisation.

The replay itself must be safe

A privacy review sometimes stops at collection and misses the player. A replay rebuilds a customer's page inside your dashboard; if that page could run code, a malicious or compromised site could attack every reviewer who opened it. AnyReplay strips script bodies at record time (rrweb replaces them with SCRIPT_PLACEHOLDER), rebuilds scripts as <noscript>, and renders the replay in an iframe sandboxed without allow-scripts — verified in a real browser as sandbox="allow-same-origin". A test fails the build if anyone enables the rrweb option that would add script permission. See sandbox iframe.

A checklist for your DPIA

1. Decide whether to record what people type at all. Form fields are masked by default and maskAllTyping: true covers rich-text editors too; if you set maskAllInputs: false, go field by field with ar-mask and document what stays visible and why.
2. Mark on-page PII with ar-mask or ar-block — account pages, order histories, chat transcripts.
3. Decide your legal basis. If it is consent, enable requireConsent and wire your banner to anyreplay('consent', true).
4. Set retention to the shortest period that serves the purpose. 14 days is the default.
5. Restrict who can watch: viewer roles for most people, admin for few. Review the audit trail periodically.
6. Decide where recordings live. If residency matters, self-host.
7. Update your privacy notice to say that sessions may be recorded, what is masked, and how long recordings are kept.

Where to go next

The privacy features page lists every control in one place. To see the defaults in action, the Free plan — one project and 500 sessions a month — is enough to install the SDK on a staging site and inspect what a recording contains. Plans are on the pricing page.

Frequently asked questions