Session replay records what your users do: their mouse movements, their clicks, and the contents of the page as they interact with it. That last part is the problem, because the page contains whatever they typed.
The tools ship masking for exactly this reason. Masking is configuration, it is applied by selector or by heuristic, and it covers the fields somebody remembered to cover. Everything else is recorded, sent to a third party, and stored for as long as their retention says.
This post is what actually ends up in those recordings, and what to do about it. For whoever owns the frontend or answers the privacy questionnaire.
What gets captured that people do not expect
Fields the masking rules missed. Password inputs are usually masked by default. A custom component that is not an <input type="password">, a one-time code split across six boxes, a card number in an iframe that your configuration does not reach, a free-text support box where a user pastes their credentials: each of these depends on your rules rather than on a default.
Data rendered on the page. Masking focuses on inputs, and the recording captures the DOM. A page displaying a customer's address, order history or medical information is recorded as displayed. The user did not type it and it is in the recording.
Responses visible in the interface. Anything the application renders after a fetch. If the screen shows it, the replay shows it.
URLs and their parameters. Tokens in query strings, identifiers, search terms.
Text copied in and then deleted. Some implementations capture input events, so a value typed and removed before submitting can still be in the recording.
The general principle: the recording is a reconstruction of the rendered page, so anything that reached the browser is a candidate, not just what the user typed.
The compliance position
It is personal data processing. A recording of one identified person's behaviour is personal data under GDPR, and in most analyses it needs consent rather than legitimate interest, because it is intrusive and the user would not expect it.
The vendor is a subprocessor. They belong on your published list, with the notice obligations that carry, and they are in scope for data subject requests. A user asking for their data or for erasure is asking about the recordings too, and you need a way to find and delete a specific person's sessions.
Special categories raise the bar. If your product shows health, financial or similar data on screen, recording that screen is processing that category, and the requirements are stricter.
Cross-border transfer applies wherever the recordings are stored.
The practical failure is that session replay is enabled by a product or growth team through a tag manager, and never reaches the privacy assessment, so none of the above happens.
What to do
Block by default, allow by exception. Most tools support this inversion: mask everything, then explicitly unmask the elements you need to see. It is more work to set up and it fails safe, which is the opposite of the default configuration.
Exclude sensitive routes entirely. Checkout, account settings, anything showing another person's data, anything behind an identity verification step. A per-route allowlist is coarse and it is reliable.
Verify by watching your own recordings. This is the step nobody takes and it is the only one that tells you the truth. Record yourself completing a signup, a password reset, a payment and a support request, then watch them back and read every field. You will find something your configuration missed.
Check what the recording contains after a product change. A new component, a redesigned form, a new page: each can introduce an unmasked field, and nothing alerts you. Put it on the release checklist for pages that handle sensitive input.
Shorten retention. These files are useful for days and often retained for months. Retention is a setting, and reducing it is the cheapest risk reduction available.
Get consent properly, before recording starts rather than after, and make sure declining actually stops the recorder rather than just hiding the banner.
The same argument applies to error tracking
Error tracking tools capture the state of the application when something broke, which usually includes request bodies, local variables, user context and sometimes headers. They have scrubbing, it is configured by patterns, and it misses what the patterns do not name.
The check is the same: trigger an error on a page handling sensitive data, then read the captured event in full. Teams are routinely surprised by what is in it.
Decide whether you need it
Worth asking directly, because the answer is sometimes no.
Session replay earns its place when you are diagnosing a specific usability problem or an error you cannot reproduce. It is frequently enabled permanently, across the entire product, by default, and watched by nobody. That configuration carries the full risk and delivers almost none of the value.
Turning it on for a defined investigation, on specific routes, for a limited period, gets most of the benefit with a fraction of the exposure. It is also much easier to justify in a privacy assessment than continuous recording of everything.
The concession
The tools are genuinely useful. Watching a real user fail to complete a flow tells you things no analytics funnel will, and for a team trying to fix a conversion problem or reproduce a reported bug, it is often the fastest route to an answer.
So this is not an argument against the category. It is that the default configuration, everything recorded everywhere forever with opt-out masking, is the wrong shape, and almost nobody changed it because it worked on day one and nothing has complained since.
The implication
You can find out exactly where you stand in twenty minutes: complete a sensitive flow in your own product, then watch the recording and read it.
Whatever is visible there is in a third party's systems today, is subject to data subject requests, and belongs on your subprocessor list. Most teams have never looked.
