Session replay can be lawful, and frequently is not, for a reason most teams miss: two separate legal requirements apply and they are usually confused for one. Placing the recording script on a visitor's device requires consent under ePrivacy rules, because session replay is not strictly necessary to deliver the service. Processing the recordings afterwards requires a lawful basis and transparency under GDPR. Satisfying one does not satisfy the other.
This article covers the two-question structure and why the order matters, what a session recording actually captures compared with what teams assume, why masking has to be built the opposite way round from how most people build it, the rights that attach to a recording once it exists, and the specific problem faced by B2B products recording logged-in users.
Two Questions, Not One
The first question is about the visitor's device. Placing or reading information on someone's terminal equipment requires their consent unless it is strictly necessary in order to provide a service the user has explicitly requested. Session replay is analytics and product research. It is useful, it is not strictly necessary, and so the consent requirement applies. Practically, that means the script does not run until the visitor has agreed, and a script that loads on page one and waits for a consent signal afterwards has already done the thing that required permission.
The second question is about the data. Once you have recordings, you are processing personal data and you need a lawful basis under Article 6, plus the transparency that Articles 13 and 14 demand — visitors should be able to find out that sessions are recorded, why, for how long, and who else sees them.
The order matters because teams often get the second right and the first wrong. A privacy notice that describes session recording accurately, on a site where the recorder fires before any consent interaction, is a well-documented breach. Getting the sequencing right is the cheapest fix available and the one most often skipped.
Legitimate interests is sometimes proposed as the basis for the second question. It can work for the processing limb where the analysis is genuinely proportionate and the recordings are well controlled. It does not help with the first limb at all, because the consent requirement for device storage comes from a different instrument and is not displaced by a balancing test.
What A Recording Actually Contains
The gap between what teams think session replay captures and what it captures is where most of the risk sits.
A session recording is not a heatmap or an event stream. It is a reconstruction of what was rendered on that person's screen. That includes everything the page displayed and, unless specifically prevented, everything they typed. In practice that means free-text fields, search queries, partially completed forms that were never submitted, error messages containing account identifiers, and any personal data your own application rendered onto the page.
Three consequences follow, none of them hypothetical.
Special category data arrives without anyone deciding to collect it. A support form where someone explains why they need an accommodation, a booking flow where someone types a medical detail — these are Article 9 categories, and Article 9 restricts processing regardless of your Article 6 basis. Nobody chose to collect them, which is precisely the problem.
The recording may contain other people's personal data. If your product displays a customer's contacts, patients or employees on screen, a recording of that screen contains their data too, and they have no relationship with you at all.
And a replay is far more identifying than the events it replaces. Analytics might tell you an anonymous session clicked three things. A replay shows the account, the name on the screen and the text being typed.
Masking Has To Be Built The Other Way Round
The standard approach is a block-list: identify the sensitive fields, apply suppression to those, ship it. It fails predictably, and it fails at the worst possible moment.
The failure mode is change. A developer adds a field. A new page reuses an old component. Someone renames a CSS class during a refactor. None of these look like privacy events, and each silently drops a field out of the suppression rules. The recorder does not error. It just starts capturing something it should not, and nobody finds out until an access request makes someone go and look.
An allow-list inverts the default: nothing is captured unless it has been explicitly permitted. New fields are suppressed automatically because suppression is the default state, and adding a field to the recorder becomes a deliberate act. This is Article 25's data protection by design and by default applied to a specific problem — the default must be the protective setting, and with a block-list it is not.
Two related points. Most recording tools suppress some input types by default and offer controls for the rest; the defaults are a starting position and not a configuration, and the tool's own documentation is where you find out what it actually does. Where a tool sits in the relationship is a vendor question rather than a legal one — our article on whether Hotjar is GDPR compliant works through where one vendor's contract sits, what it covers and what stays yours, and the piece on PostHog does the same for a product where session recording is one feature among several.
And masking does not anonymise the recording. A masked replay still shows a specific person's session in a specific account, which is singling out — the line between reducing identifiability and actually leaving the scope of the regulation is set out in our guide to anonymisation versus pseudonymisation, and masking sits well on the near side of it.
The Problem Nobody Plans For: Recording Logged-In Users
For a B2B SaaS company this is the sharpest issue, and it is contractual before it is regulatory.
When you record an anonymous visitor on your marketing site, you are the controller of that person's data and the analysis is yours to justify. When you record a logged-in session inside a customer's account, the data on screen is largely your customer's data, and for that data you are usually their processor. Article 28 says a processor acts only on documented instructions from the controller.
So: does your customer's DPA instruct you to make video reconstructions of their users' sessions and share them with a third-party analytics provider? Most do not. Many list permitted processing purposes that do not obviously extend to it, and some prohibit onward disclosure without authorisation. Adding a session recorder to an authenticated application can therefore put you outside your own contract with your customers, and the exposure is a breach-of-contract claim from a paying customer rather than a regulatory one.
It also adds a subprocessor. The recording vendor now receives your customers' personal data, which means the vendor belongs on your subprocessor list, needs to go through your normal notification process, and gives customers something to object to.
The Rights That Attach Once A Recording Exists
A recording is personal data about the person recorded, which puts it in scope for an access request under Article 15 and an erasure request under Article 17. That sounds unremarkable until you try to service one.
The operational question is whether you can find every recording featuring one individual, across whatever retention window you set, and delete them. Recordings are typically indexed by session rather than by person, and the identifying detail sits inside the video rather than in a queryable field. Many teams discover this at the moment someone asks, which is the worst time to find out: the response clock is already running.
Test it before you need it. Pick a user, try to retrieve everything, and time it.
Common Mistakes With Session Replay And GDPR
Loading the script before consent. The recorder either runs or it does not, and running it is the act that needed permission. A consent banner that appears while recording is already underway documents the breach rather than preventing it.
Masking with a block-list. Suppressing named fields means every field added afterwards is captured by default. Allow-list the fields you want and let everything else stay suppressed.
Assuming your customers' DPAs permit it. Recording authenticated sessions in a multi-tenant product processes your customers' data. If their agreement does not cover it and your subprocessor list does not name the vendor, the problem is contractual and it belongs to you.
Keeping recordings indefinitely. Storage limitation applies. Recordings are unusually rich personal data and there is rarely a purpose that survives past a few months, so set a retention period and enforce it in the tool rather than in a policy document.
Calling masked recordings anonymous. A masked session still shows one identifiable person's journey through one identifiable account. It is reduced-risk personal data, in scope, and subject to every right that attaches to it.
FAQ
Do we need consent before running session replay?
For the script itself, yes. Storing or accessing information on a visitor's device requires consent unless it is strictly necessary to provide the service requested, and session replay is not. That means the recorder should not fire until consent is given, which is a technical sequencing requirement rather than a banner-copy one.
Can we rely on legitimate interests instead?
Not for placing the script — the consent requirement for device storage comes from ePrivacy rules and is not displaced by a balancing test. Legitimate interests can serve as the Article 6 basis for processing the recordings once lawfully obtained, provided the analysis is proportionate, controlled and disclosed.
Does masking make session recordings anonymous?
No. Masking suppresses field content; it does not prevent the recording from being linked to an identifiable person, particularly in an authenticated session where the account itself identifies them. The data stays in scope, with access and erasure rights attached.
Can we record sessions inside customer accounts in our B2B product?
Only if your agreement with that customer supports it. In an authenticated multi-tenant product you are typically the processor for customer data, acting on documented instructions. Check whether those instructions cover session recording, and add the recording vendor to your subprocessor list before you switch anything on.
Closing Thought
Session replay is unusual among analytics tools in that its value and its risk come from the same property: it captures things you did not anticipate. That is why it finds the bug nobody could reproduce, and it is why it collects the health detail somebody typed into a support form. You cannot keep the first and design out the second, because they are the same capability. What you can do is decide, deliberately and in advance, how much of the screen you are willing to record — and most teams have never made that decision at all. It was made for them by a default.
ComplyDog handles the paperwork that a tool like this generates: a subprocessor list that updates as your stack changes, a cookie consent banner, data subject request handling, and a compliance portal on your own domain where customers can check what you use before they ask. You can try it free for 14 days, no credit card required.
