Is session replay legal? GDPR for bug reporting tools

September 2, 2026 · 8 min read · by the Tracebird team

Session replay sits in one of the highest-risk categories of web privacy law, and also in most serious bug reporting stacks. Both things are true, and the difference between them is configuration. Here is what GDPR actually asks of you, and the setup that answers it. This is engineering guidance, not legal advice.

First, what replay is and is not

Session replay is not video. Tools in this space record DOM events, what changed in the page structure, where the pointer went, what got clicked, and reconstruct the session from those events. That distinction matters legally and technically: because the recording is structured data, you can decide, element by element, what never gets captured. A video cannot un-film a password field. A DOM recorder can simply never read one.

Why regulators care

An unconfigured replay tool captures whatever users type: names, emails, payment details, sometimes text typed and deleted before submitting. Under GDPR that is personal data processing, with everything that implies: a lawful basis, minimisation, disclosure, retention limits, and a data processing agreement with your vendor. In the US, session recording has attracted wiretapping-theory lawsuits under state laws like California's CIPA. The category earned its reputation through analytics deployments that record every visitor, silently, on marketing sites.

Replay for bug reports is a different animal

A bug reporting tool changes three variables that drive most of the risk. Recording happens in a beta or staging context with invited testers, not on the public internet. The subject knows: a tester who presses a “report bug” button is deliberately sending what they saw. And the volume is bounded, the test session behind a report rather than every session of every visitor. None of that makes GDPR stop applying. It makes compliance achievable with defaults instead of legal gymnastics.

The checklist that matters

• Mask inputs by default. Text fields should record as asterisks unless you explicitly unmask them, and passwords should never be recordable at all. Masking must happen on the tester's device, before anything leaves the page.
• Never capture network bodies. Method, URL, status and timing tell the debugging story; request and response bodies are where tokens and personal data live. Scrub auth headers too.
• Give testers agency. A blur tool in the report flow lets the reporter redact their own screen. Consent works better as a visible, deliberate act of sending than as a banner nobody reads.
• Bound retention. Beta recordings from last year serve nobody. Retention tied to your plan or project, enforced by deletion, is minimisation you can point to.
• Sign a DPA and know where data lives. Your replay vendor is a processor; the agreement and the hosting region are your responsibility to check, whoever you choose.
• Tell your testers. Your privacy notice should say what a report contains. It is also worth linking from the widget itself; honesty at the point of capture costs one sentence.

How Tracebird sets those defaults

We built our capture pipeline so the right thing requires zero configuration: inputs masked by default, passwords always, network bodies never captured, auth headers scrubbed, a tester-facing blur tool, and retention that follows your plan. The full inventory of what a report contains, with every cap, is public in our security and privacy docs and the captured context reference, because a privacy posture you cannot inspect is a promise, not a property. Whatever tool you use, hold it to that standard: if the vendor cannot enumerate exactly what leaves the page, assume everything does.