Session Replay and GDPR: Consent, Masking and the Digital Omnibus

Session replay GDPR questions used to have a boring answer: get consent, mask the forms, move on. That changed when the European Commission proposed the Digital Omnibus on 19 November 2025, a package that, among other things, rewrites the cookie rule behind every consent banner. On 21 October 2026 EU member states agreed the Council's negotiating position. Product teams are now asking whether session recording will finally run without a banner. Short answer: probably not. Here is why, and what to do instead.

New to the technology itself? Start with what session replay is and how it works, then come back here for the privacy side.

Two laws, two questions

Session recording privacy in the EU is governed by two different rules, and teams often mix them up:

• The ePrivacy rule (Article 5(3) of the ePrivacy Directive) covers storing or reading anything on the visitor's device: cookies, localStorage, session IDs. A replay script does this to stitch page views into one session, so this rule decides whether you need consent before the script runs.
• The GDPR covers what you do with the data you collect. A recording of clicks, scrolls, typed text and page content tied to one visit is personal data whenever it can be linked to a person, for example a logged-in user or an IP address. You need a lawful basis, transparency, minimisation, security and a retention limit.

The Digital Omnibus touches both, which is why it matters for replay.

What the Digital Omnibus changes (and when)

The Commission's November 2025 proposal wanted to move the cookie rule into the GDPR itself (new Articles 88a and 88b), keep consent as the default, add a short list of purposes that would not need consent, require sites to respect a refusal for six months, and make websites honour automated privacy signals from browsers.

The Council's mandate of 21 October 2026 (document ST 14756/26) took a different route. According to reporting on the published text, it:

• keeps the cookie rule in the ePrivacy Directive instead of moving it into the GDPR;
• keeps consent as the default, with refusal possible in a single click;
• lists six purposes that would not need consent, including anonymous, aggregated audience measurement;
• shortens the "do not ask again" period after a refusal from six to four months;
• drops the Commission's obligation to honour automated browser signals;
• keeps the current GDPR definition of personal data and adds a separate article on pseudonymised data.

What it does not do is become law. The European Parliament has not adopted its position, so trilogue negotiations have not started, and the final text still has to be voted by both institutions and then applied. Until then, the GDPR and national ePrivacy laws apply unchanged.

Does session replay need consent under the new rules?

Compare session replay with the six consent-free purposes in the Council text:

The interesting one is the third row. The analytics exemption is for anonymous and aggregated statistics that are not reused, shared or combined with other data. A page-view counter fits. A session recording is, by design, the detailed story of one visitor, which is what makes it useful for debugging frontend bugs and what keeps it outside the exemption. Our reading, and that of most commentators, is that session replay will still need opt-in consent on public websites. If your aggregated dashboards and your recordings use the same script, you may end up with two modes: consent-free counts, and replay only after consent.

One change does help replay vendors and their customers: once consent is asked and refused, the four-month rule means fewer re-prompts and less banner fatigue. It also means your opt-in rate is the number to optimise, because you will not get a second chance next week.

Lawful basis under the GDPR

For the recording itself, consent is the simplest basis for consumer sites, and since you need it for the device access anyway, one clear consent purpose ("session recording to improve the product") covers both. Some B2B and internal tools rely on legitimate interest for authenticated users, backed by a documented balancing test and, for large-scale recording, a DPIA. Legitimate interest does not remove the ePrivacy consent step, so check with your DPO before going that way.

Masking: collect less in the first place

Consent answers whether you may record. Masking answers what ends up in the recording, and it is where most real incidents happen. Mask on the client, before data leaves the browser, so a misconfigured dashboard cannot leak what was never sent:

• Form inputs: mask everything by default and allow-list the few fields you need. Never record passwords, card data or free-text fields where people type health or financial details. The LogNroll logger excludes password inputs from form tracking out of the box.
• Rendered personal data: names, emails, addresses and account numbers shown in the UI. Exclude whole components (account pages, invoices) rather than chasing single elements. In LogNroll, DOM changes inside an element marked data-lnr-ignore are not recorded.
• URLs: tokens, emails and IDs in query strings are easy to miss.
• Network and console data: request and response bodies and log lines often carry user data. Drop or sanitise them before they are stored, for example with a requestSanitizer.

For selector strategies that survive refactors and a longer list of what to hide, see privacy-first session recording for EU teams.

Implementing consent-gated replay

The rule is simple: the recorder is a downstream consumer of your consent signal. Nothing loads, and nothing is buffered "just in case", before the visitor opts in. A minimal pattern:

// Load the recorder only after the visitor opts in.
let started = false;

export function startReplay() {
  if (started) return;
  started = true;
  import('@lognroll/lib').then((LognRoll) => {
    LognRoll.default.initSession('YOUR_PROJECT_ID', {
      network: {
        // Drop requests that carry personal data before they are stored.
        requestSanitizer: (req) =>
          req.url.includes('/api/account') ? null : req,
      },
    });
  });
}

// Wire it to your consent manager (the API differs per CMP).
consentManager.on('change', (choices) => {
  if (choices.sessionReplay === true) startReplay();
});

A few details that auditors check: the refuse button is as easy to hit as accept; withdrawing consent stops the recorder in the same session; the consent record (time, version of the notice, choice) is stored; and the four-month quiet period after a refusal is respected once the new rules apply.

Retention, access and vendors

• Retention: pick a fixed period that matches the job, such as 30 or 90 days, publish it and enforce it automatically, including for exports.
• Access: limit who can watch recordings, log access, and avoid sharing raw session links in public channels.
• Data subject rights: be able to find and delete one person's sessions on request.
• Vendor: sign a data processing agreement, know where data is stored and which sub-processors are involved, and check the legal basis for any transfer outside the EU. Our session replay tools comparison covers hosting options.
• AI tooling: if you feed recordings to an AI agent for debugging, the same rules apply to that processor. Running the model locally keeps sessions in-house; see local LLMs for private replay debugging.

Pre-launch checklist

• Recorder loads only after opt-in; refusal takes one click.
• Privacy notice names session recording, the purpose, retention and the vendor.
• All inputs masked by default; sensitive pages excluded; URLs and network bodies sanitised.
• Retention period configured and tested; deletion on request works.
• DPA signed; hosting region and sub-processors documented.
• DPIA done if you record at scale or on sensitive flows.
• A calendar reminder to revisit this when the Digital Omnibus is adopted.

Where LogNroll fits

LogNroll records sessions together with console errors and network calls, loads only when you call it, and gives you hooks to drop sensitive requests and DOM regions before anything leaves the browser. That makes the consent-gated setup above a few lines of code rather than a project. See pricing or start with the free plan.

Frequently asked questions