Scope
This guide explains the CNIL Recommendation on session replay tools, which record or reconstruct a user's navigation path on a website or mobile app. It's designed for privacy officers and security engineers responsible for implementing these tools.
The CNIL addresses two groups: providers who design session replay tools and set their defaults, and publishers (website or app owners) who deploy them. This guide doesn't cover analytics tools that don't reconstruct individual journeys.
According to the CNIL, these tools can capture mouse movements, touch interactions, clicks, scrolling, and, in some configurations, form entries. The output is replayed as video-like sessions. The privacy risk is high because these tools can collect personal data unrelated to the analysis you're conducting.
Key Concepts and Definitions
Session replay tool. Software that uses trackers to record or rebuild a visitor's full journey. Lawful uses include detecting and fixing malfunctions and improving structure or ergonomics.
Terminal Equipment Access. These tools rely on trackers, so they fall under Article 82 of the Loi Informatique et Libertés, the French transposition of the ePrivacy rules.
Prior Consent. The CNIL states no exemption under Article 82 applies to session replay. Prior Consent is required, and collection must meet the rules the CNIL applies to cookies and other trackers. Session replay is a Non-Essential use; don't classify it as a Consent-Exempt Cookie.
Determined purpose. Purposes must be specified, explicit, and legitimate, and fixed before deployment, not invented after data collection.
Masking. A mechanism that obscures irrelevant data at capture time, before it leaves the user's device or reaches the provider.
Requirements Breakdown
1. Legal Framework and Role Qualification
Providers and publishers must define their roles under the applicable framework. Don't assume the vendor is "just a processor." The vendor's defaults and features can shape what gets collected, and your role analysis should reflect that.
2. Prior Consent (Article 82)
- No session replay tracker may activate before the user gives Valid Consent.
- Consent must be freely given, specific, informed, and unambiguous, with a Clear Affirmative Action.
- Refusal and Withdrawal of Consent must be as easy as acceptance, with Equal Prominence and Symmetry of Choice in the Consent Notice.
- Granularity matters: session replay needs its own purpose, not bundled with unrelated analytics.
3. Information at the First Level
The CNIL Recommendation distinguishes first-level and second-level information in Consent Management Platform (CMP) interfaces and proposes wording. It recommends that information on the use of session replay should appear at the first level of the interface so that consent is informed. Burying it in a second-layer vendor list doesn't meet that standard.
4. Purpose Disclosure
Define purposes before deployment and state them in the Consent Notice. Troubleshooting a broken checkout and optimizing page layout are different purposes from profiling individuals.
5. Technical and Organizational Measures
The CNIL recommends measures adaptable to your purposes:
- A masking tool that hides irrelevant data.
- Limiting the number of sessions collected in line with the purpose.
- Limiting the use of identifiers.
- Masking mouse movements in certain zones to avoid incidentally capturing authentication codes.
- For chatbots, masking conversation content (questions and answers), which may reveal potentially sensitive data.
Implementation Guidance
Gate the script in your CMP and your Tag Manager. Treat session replay as its own vendor and purpose. In the Tag Manager, bind the Container Tag to the specific consent signal so it can't load on a generic "analytics" grant. Test with a clean browser profile and confirm no network request or storage write occurs before consent.
Mask by default, unmask by exception. Data Protection by Default means configuring the tool so nothing is captured unless justified. Start from a mask-everything posture and selectively reveal elements you can defend. Review each unmasked element against your declared purpose.
Cover the obvious sensitive zones. Payment fields, login and credential inputs, and free-text boxes are the first targets. Add areas where mouse movement could trace out a PIN or one-time code, as the CNIL specifically recommends. If your app has a chatbot, mask message content in both directions.
Sample, don't record everything. If your purpose is detecting malfunctions, you probably don't need every session. Define a sampling rule tied to the purpose and document why that volume is sufficient.
Minimize identifiers. Don't join replays to account IDs, Hashed Email Identifiers, or Universal Identifiers unless your documented purpose requires it. Pseudonymous replays are easier to defend.
Document provider obligations in the contract. Require providers to ship masking capability, support consent-gated loading, and let you configure sampling and identifier handling. If a provider can't offer these controls, that's a procurement finding.
Keep your consent evidence. Log the consent state tied to the session replay purpose so you can show Prior Consent was obtained before collection.
Common Pitfalls
- Treating replay as a "performance" tracker. No Article 82 exemption applies. Loading it under an exemption claim is a compliance error.
- Declaring purposes after the fact. The purpose has to exist before the first session is recorded.
- Hiding the disclosure. Mentioning session replay only in a second-level list undercuts informed consent given the first-level recommendation.
- Trusting vendor defaults. Out-of-the-box settings may record form inputs. Verify what's actually captured.
- Forgetting chatbots. Conversation content can reveal sensitive data, and replay widgets embedded in chat interfaces are easy to overlook.
- Ignoring incidental capture. Mouse movement over an on-screen keypad can expose codes even when text fields are masked.
- Collecting everything "just in case." This contradicts data minimization under the GDPR.
Quick Reference Table
| Topic | Requirement | Action for your team |
|---|---|---|
| Legal basis for access | Article 82, Loi Informatique et Libertés | Treat replay as tracker deployment |
| Consent | Prior Consent; no exemption applies | Block script until Valid Consent |
| Consent quality | Unambiguous, Granular, Symmetry of Choice | Separate purpose in the CMP |
| Information | Specific mention at first level of interface | Put replay disclosure on layer one |
| Purposes | Determined, explicit, legitimate; set before deployment | Write purposes before go-live |
| Masking | Tool to hide irrelevant data | Mask by default, unmask by exception |
| Mouse movement | Mask in certain zones to avoid capturing codes | Cover keypads and code-entry areas |
| Volume | Limit sessions collected per purpose | Define and document sampling |
| Identifiers | Limit their use | Avoid linking replays to user IDs |
| Chatbots | Mask conversation content | Mask both questions and answers |
| Providers | Design tools and defaults with these controls | Verify capabilities in contracts |
| Status | Final after public consultation, February to May 2026 | Plan deployment review against it |
Check the full CNIL Recommendation and the consultation summary before finalizing your configuration, and watch for the CNIL's planned webinar for professionals.





