Session Recording Under GDPR: Lawful, but Only If You Do the Work

Session recording is not banned under GDPR. There is no article that says “thou shalt not record sessions,” and regulators have never claimed there is. What GDPR does say is that recording a user’s screen interactions is processing of personal data, and every requirement that applies to processing personal data applies to your replay tool. That is the entire session recording GDPR question in one sentence: it’s lawful if you do the work that lawfulness requires, and most teams deploying a replay snippet have not done that work.

This article walks through what the work actually is. One sentence of housekeeping: I’m an engineer who has sat on the technical side of GDPR audits, not a lawyer, so treat this as engineering guidance and run your specific setup past counsel.

First, accept that recordings are personal data

Some teams try to argue their way out at this step. Don’t bother.

A session recording ties together an IP address, a device fingerprint of sorts (viewport, browser, OS), behavioral data (every click and scroll), and frequently the actual content of the page — which for a logged-in app means names, emails, order histories. Under Art. 4, personal data is any information relating to an identifiable person. A recording of an authenticated user’s session is about as identifiable as data gets.

Even with aggressive masking, the recording is still linked to a user or at minimum to an IP and session identifier. Pseudonymized data is still personal data under GDPR. So the question is never “does GDPR apply?” — it’s “which lawful basis am I processing under, and can I defend it?”

Lawful basis: consent vs. legitimate interest

Art. 6 gives you six lawful bases. Two are realistically available for session recording.

Consent (Art. 6(1)(a))

Consent is the safe answer and the one most European DPAs would nod at, especially because the ePrivacy Directive layers on top of GDPR here: a replay script stores and reads information on the user’s device, which in most EU member states’ implementations requires consent regardless of what GDPR alone would say. This is the same mechanism that makes analytics cookies consent-gated.

The cost of consent is data loss. Depending on your audience and banner design, expect a meaningful fraction of users to decline, and those sessions simply don’t exist for debugging. If your primary use case is “reproduce the bug this specific user reported,” a consent gate means the user who hit the bug may be exactly the one you can’t see.

Legitimate interest (Art. 6(1)(f))

Legitimate interest is the basis many vendors quietly assume, and it’s more defensible than privacy absolutists claim — but only in a narrow configuration. To rely on it you need a documented Legitimate Interest Assessment showing that your interest (diagnosing defects, securing the service) outweighs the user’s rights and freedoms. That balancing test tilts in your favor when:

• All text input is masked at capture, before anything leaves the browser.
• The recording is used for debugging and security, not marketing, ad targeting, or individual behavioral profiling.
• Retention is short and enforced.
• The processing is disclosed plainly in your privacy notice, and users can object (Art. 21).

Here’s the honest complication, and where “the law says” diverges from “lawyers commonly advise”: even if your GDPR Art. 6 analysis lands on legitimate interest, the ePrivacy consent requirement for accessing the terminal equipment doesn’t go away. Lawyers commonly advise consent for exactly this reason. My engineering opinion is that a masked, short-retention, debugging-only deployment under legitimate interest is a risk many small teams knowingly accept — but you should know you’re accepting it, not stumble into it because the vendor’s onboarding flow never mentioned it.

Masking is your data minimization argument

Art. 5(1)(c) requires that processing be limited to what’s necessary. For session replay, masking is how you comply with that principle, and it’s the single strongest technical control you have.

The default posture should be: mask all text inputs, mask any element containing user-generated content, and record structure rather than content wherever content isn’t needed to debug. Modern replay SDKs (anything in the rrweb lineage) support attribute-based masking, so you can annotate sensitive regions in your markup and have them replaced client-side before transmission. The critical property is where masking happens — in the browser, before the data is sent. Server-side redaction means the sensitive data already crossed the wire and touched the vendor’s infrastructure; from a GDPR standpoint that processing already occurred.

We covered the mechanics in detail in our guide to masking PII in session replay, but the compliance-relevant summary: an unmasked deployment makes both your lawful basis analysis and your data minimization story fall apart simultaneously. Mask first, then argue about legal bases.

Retention: pick a number and enforce it

Art. 5(1)(e) — storage limitation — says keep personal data no longer than necessary for the purpose. If your purpose is debugging, ask honestly: when did you last watch a replay older than 30 days? For most teams the real answer is “never,” and that answer defines your retention period.

A defensible setup:

Whatever numbers you pick, they must be automatic. A retention policy that requires someone to remember to delete things is not a retention policy — it’s a wish. And remember Art. 17 erasure requests apply to recordings: when a user asks for deletion, you need a way to find and purge their sessions, which means your replay tool needs to support lookup by user identifier.

The vendor question: DPA, transfers, or neither

If a third-party vendor stores your recordings, that vendor is a processor and Art. 28 requires a Data Processing Agreement. Every serious vendor offers one; if yours doesn’t, that’s disqualifying. But the DPA is the easy part.

The harder part is data transfers. If your vendor stores recordings on US infrastructure, you’re in Chapter V transfer territory — Standard Contractual Clauses, transfer impact assessments, and the ongoing legal uncertainty that has followed every EU–US adequacy arrangement so far. For a recording that contains masked-but-still-personal data of EU users, this is genuine legal surface area, and it’s surface area you carry for a debugging tool.

There is a configuration that deletes this entire section: self-hosting. If recordings are captured by a script served from your own domain and stored on your own infrastructure in your own region, there is no processor, no DPA to negotiate, and no international transfer to assess. This is the honest reason self-hostable tools like LogReplay exist in this niche — not because self-hosting is fun (it isn’t, particularly), but because “the data never leaves our EU servers” is a one-sentence answer to what is otherwise a multi-page annex in your records of processing.

A session recording GDPR checklist

Working through an audit, these are the items that actually get checked. No legalese, in the order I’d do them:

1. Mask by default. All inputs, all user-generated content, client-side, before transmission. Verify in the network tab, not in the vendor dashboard.
2. Choose and document a lawful basis. Consent if you want the quiet life; legitimate interest with a written LIA if you accept the ePrivacy tension. Write it down either way.
3. Disclose it. Privacy notice names the tool, what’s captured, retention period, and lawful basis. Plain language.
4. Wire consent (or objection) into the recorder. If consent-based, the script must not record before opt-in. If LI-based, an objection must actually stop recording and trigger deletion.
5. Set automatic retention. 30 days or less for recordings unless you have a documented reason otherwise.
6. Handle Art. 17. Confirm you can locate and delete all sessions for a given user identifier, and test it once.
7. Sign the DPA — or eliminate the processor. Third-party vendor: DPA plus transfer assessment. Self-hosted: neither, but you own backups and access control instead.
8. Restrict internal access. Recordings are personal data; “everyone in the company can watch any session” fails the integrity-and-confidentiality principle (Art. 5(1)(f)). Role-gate it and log access.

None of this is exotic. It’s a few days of configuration and documentation, most of it work you’d want for security reasons anyway. The teams that get into trouble aren’t the ones who did this list imperfectly — they’re the ones who pasted the snippet, masked nothing, told no one, and kept everything forever.