Session Replay Privacy Checklist for B2B SaaS

How to read this checklist

A privacy configuration is not one switch. It is a combination of controls with different purposes.

A technical control may help satisfy a legal obligation, but the control is not itself a legal conclusion. Likewise, masking sensitive text does not remove the need for authorization, retention, deletion, notice, or legal review.

Why session replay requires special attention

A standard analytics event might state that a user opened a report or completed a setup step. Session replay can provide much richer evidence. Depending on the tool and configuration, a replay system may capture, derive, or reconstruct combinations of:

• page content and visual structure;
• form fields and changes to them;
• clicks, scrolling, pointer movement, touch interaction, and keyboard-related events;
• the sequence of pages and product areas visited;
• URL paths, query parameters, and fragments;
• user, account, workspace, or project identifiers;
• timestamps, duration, viewport, browser, and device context;
• page titles, referrers, element attributes, and event properties;
• console messages and JavaScript errors;
• network URLs, headers, request bodies, response bodies, or GraphQL variables;
• application state exposed in the DOM or telemetry;
• canvas, media, iframe, or rich-text content; and
• recordings connected to identified users and customer companies.

The exact capture depends on the product, SDK, enabled plugins, browser environment, and configuration. Some systems reconstruct the page from DOM snapshots and incremental changes; others may use screenshots or additional observability channels. A team must inspect its own implementation rather than assume that a generic description applies.

The risk also comes from combination. A company name may be ordinary account metadata. A page path may be ordinary product telemetry. A timestamp and a sequence of actions may be ordinary behavioral data. Combined with a name, email address, support message, report title, or account role, those fields can form a detailed record of what an identifiable person did inside a confidential customer workspace.

That richer context is why replay can be useful—and why session recording privacy needs more than a password-field masking rule.

Begin with a documented purpose

Do not enable replay and decide what it is for later. Start with a product question that can be answered more effectively with session evidence than with lower-context analytics alone.

Reasonably specific questions include:

• Why did measured workflow completion fall after a release?
• How do successful and unsuccessful onboarding Visits differ?
• What visible interface state preceded a reproducible defect?
• Where do selected users abandon a setup workflow?
• Does session evidence support or contradict a product hypothesis?
• Which part of a grouped page appears to create repeated navigation changes for a defined account segment?

These questions have a population, scope, decision, and end point. They can be investigated with a constrained set of sessions.

Vague purposes are harder to justify and govern:

• Capture everything in case it becomes useful.
• Monitor customers or employees continuously.
• Keep every recording indefinitely.
• Let anyone in product, engineering, or support browse identified users.
• Collect all available telemetry because the SDK supports it.
• Use replay as a substitute for a defined research plan.

Before rollout, create a purpose record containing at least:

This record should be approved before production capture begins. If the purpose changes, reassess the capture configuration rather than silently extending the old data to a new use.

Inventory the data before choosing masking rules

The following inventory is a review worksheet, not a claim that every replay tool captures every category. Mark each category as technically impossible, disabled, allowed, masked, blocked, excluded, or still unverified for the actual implementation.

Review worksheet

The inventory should include every route and component, not only top-level pages. A page considered safe may open an account-specific modal, render a filename in a toast, place an email address in an accessibility attribute, or expose a token in an error message.

Minimize capture before applying redaction

The strongest privacy control is not collecting data that the investigation does not need.

Use capture minimization to:

1. Record only selected product areas or an explicit route allowlist.
2. Exclude billing, authentication, administrator, secret-management, private-document, employee-record, and other high-risk sections.
3. Capture only sessions needed for a defined investigation rather than every session.
4. Use sampling when a representative subset is sufficient.
5. Trigger recording around a defined condition, such as a selected workflow or reproducible error, when the implementation supports it.
6. Reduce captured event types and sampling frequency.
7. Avoid network request and response bodies.
8. Avoid console logs unless a documented debugging question requires them.
9. Omit identity properties that are not required for selection or follow-up.
10. Disable recording in anonymous or unauthorized contexts where appropriate.
11. Stop recording before the user enters a protected workflow.
12. Retain structured analytics events without retaining a full replay when aggregate evidence is enough.

Collection-time minimization is stronger than depending entirely on later redaction. If a raw value reaches an ingestion endpoint or storage layer before the viewer masks it, the organization still has to secure, retain, delete, and account for that value. Ask whether each control operates:

• in the browser before transmission;
• at the ingestion edge;
• during storage;
• during indexing; or
• only when the replay is displayed.

Viewer-only redaction is an access-presentation control. It is not equivalent to preventing collection.

Masking, blocking, exclusion, and allowlisting

These terms are often used inconsistently between replay products. Confirm the exact semantics in the selected SDK and test the outcome.

Input fields

Start by masking every input rather than trying to predict where users may type sensitive data. Review:

• text, email, password, search, number, date, and hidden inputs;
• textareas;
• contenteditable elements;
• custom select, combobox, and autocomplete components;
• rich-text editors;
• payment widgets;
• pasted content; and
• validation messages and value previews.

An input labeled “Project name” can still receive a person’s name, contract term, or customer secret. Field labels describe intended use, not actual content.

Rendered text and account content

Rendered text can contain more sensitive information than form inputs. Review tables and lists, report names, workspace and account names, user names and email addresses, saved searches, dashboard cards, modal dialogs, toast notifications, inline errors, imported data, comments and messages, and empty states that echo prior input.

A “mask all inputs” setting does not protect text that the application later renders elsewhere.

Dynamic components

Masking and blocking rules must cover content rendered after the initial page snapshot. Test client-side route changes, lazy-loaded components, virtualized tables, dropdown menus and popovers, modals rendered through portals, error boundaries, notification centers, account switchers, permission changes, and temporary loading and authentication states.

Do not assume a selector applied at initial page load will permanently protect a changing component tree.

Shadow DOM, iframes, canvas, and rich media

These surfaces require explicit testing:

• Selector behavior may differ inside open or closed shadow roots.
• A cross-origin iframe has a separate origin boundary, and replay support may require separate instrumentation.
• Embedded payment or support widgets may have their own data flows and processor relationships.
• Canvas content can contain chart labels, document previews, signatures, or other data that ordinary DOM-text masking does not cover.
• Rich-text editors may store content across nested DOM nodes, hidden structures, or application state.
• Media and screen images can expose content even when text nodes are masked.

For example, rrweb documents separate options for blocking, ignoring input events, masking text, masking inputs, recording canvas, recording cross-origin iframes, sampling, and plugins. That separation is a useful reminder: one default does not govern every data channel. It is an implementation example, not a guarantee about every rrweb version or every product built with it.

Filenames, errors, and temporary states

Uploaded filenames may appear in a native file input, a drag-and-drop zone, progress toast, validation error, attachment list, or recent-activity panel. Authentication codes may appear briefly in a confirmation component. An API key may be visible only after creation. Account data may be rendered for a fraction of a second while permissions update.

Replay captures state over time. Test every temporary state, not only the final settled page.

Exclude or strongly protect high-risk content

The conservative starting point is to exclude workflows that can contain:

• passwords;
• authentication and recovery codes;
• session tokens;
• API keys, webhook secrets, and private credentials;
• payment-card information;
• bank and financial details;
• health information;
• government identifiers;
• confidential customer communications;
• private documents and document previews;
• customer secrets;
• employee records;
• administrator impersonation workflows; and
• security settings that reveal recovery or access information.

The exact handling must reflect the product, sector, user population, contracts, and applicable law. The existence of a masking feature is not a reason to collect these categories. For many high-risk workflows, route exclusion plus structured analytics is safer and still answers the product question.

An API Keys page, for example, may retain a safe event such as “key-creation workflow completed” without retaining the page reconstruction, generated key, clipboard content, or error payload.

Protect URLs and metadata separately

Masking page text does not automatically protect URL paths, query parameters, URL fragments, page titles, referrers, DOM attributes, uploaded filenames, account identifiers, search terms, element labels, analytics event properties, replay names, or tags.

Unsafe URL designs include:

/reset-password?token=...
/customers/[email protected]/
/search?q=confidential-customer-name

A fragment can also contain sensitive state visible to client-side code even though fragments are not sent in the ordinary HTTP request:

/oauth/callback#access_token=...

Secrets should not appear in URLs in the first place. URLs are frequently copied into browser history, logs, monitoring systems, support messages, referrers, and replay metadata.

Safer approaches include:

• normalize dynamic paths before transmitting them;
• replace raw record identifiers with route templates such as /customers/:customer_id/reports/:report_id;
• remove all query parameters by default and allowlist only those required for the analytical purpose;
• strip secrets and personal data before the replay SDK can read or transmit them;
• avoid putting names or email addresses in path segments;
• use stable, non-sensitive internal IDs when a relationship must be retained;
• review page titles and route names;
• remove sensitive values from data-*, title, aria-label, and custom attributes;
• avoid sending raw search terms unless the exact term is necessary and reviewed;
• store a safe categorical event such as search_submitted instead of the query text; and
• test redirects, error pages, account switching, and deep links.

URL normalization should occur before the value enters the replay pipeline. Replacing the URL only in the replay viewer leaves other copies unresolved.

Treat console and network capture as separate systems

Some replay and observability products optionally capture console messages, uncaught exceptions, JavaScript error details, network URLs, request methods and status codes, request and response headers or bodies, and GraphQL operation names and variables.

These channels can contain sensitive data even when visible page content is masked. A developer may log an entire user object. A failed form request may include every submitted value. A GraphQL request may use one harmless-looking endpoint while its variables contain names, messages, or financial data.

Use disabled-by-default handling unless there is a documented need.

When network context is necessary, prefer an explicit allowlist of lower-risk metadata such as:

• normalized endpoint category;
• HTTP method;
• status class;
• duration;
• safe error category; and
• GraphQL operation name without variables.

Do not collect Authorization, Cookie, Set-Cookie, session tokens, CSRF tokens, API keys, or equivalent secrets. Review whether request headers, query strings, error objects, and response previews are captured by default or through a plugin.

Sanitize console output in the application itself. A replay-specific filter should be defense in depth, not permission to leave secrets or personal data in production logs.

Minimize identified-user and account context

Connecting replay to a user and company makes B2B investigation more useful. It also increases privacy impact because employees can move from an account-level signal to an identifiable person’s behavior.

Potential identity fields include user ID, name, email, company or workspace, account ID, plan, role, lifecycle stage, account owner, and custom account attributes.

Use stable internal IDs rather than email addresses as primary identifiers. Email addresses change, expose direct identity, and are often copied into URLs, search indexes, and exports.

Recommended controls include:

• collect the minimum identity fields required for the investigation;
• use pseudonymous user and account IDs in replay metadata;
• keep the mapping to direct identifiers in a separately controlled system;
• avoid duplicating company attributes into each replay unless required;
• restrict access to names and email addresses more tightly than aggregate account analytics;
• separate permission to view account-level analytics from permission to open identified replays;
• audit access to identified sessions; and
• support deletion or pseudonymization by stable identifiers.

Apply least privilege to replay access

Masking does not remove the need for access control. Replay data remains rich behavioral evidence even when obvious text is hidden.

A production access model should cover:

• role-based access and least privilege;
• separate permissions for product, UX research, support, security, and engineering;
• server-side authorization for every replay request;
• single sign-on and multifactor authentication where appropriate;
• time-limited or investigation-specific access;
• production and non-production environment separation;
• audit logs for search, view, export, share, unmask, and delete actions where supported;
• session-level access logging for identified recordings;
• periodic permission reviews;
• employee offboarding and role-change procedures;
• controls on vendor support access; and
• approval for exports or clips.

An opaque or hard-to-guess replay URL is not authorization. The application must validate the viewer’s permission on every request.

Avoid public or broadly shared replay links. A copied URL should not continue to expose a recording after the viewer loses access, leaves the organization, or switches to a different customer account.

Support teams may need access to a recording tied to a specific customer request. That does not justify unrestricted browsing of every account. Use scoped, case-linked, and time-limited access where the product supports it.

Set purpose-based retention

Replay usually contains more context than a low-cardinality analytics event. Its retention should therefore be shorter and more deliberate than indefinite raw analytics retention.

Do not begin by choosing a popular number of days. Use a retention decision process:

1. Restate the purpose and the decision that replay supports.
2. Estimate when relevant sessions become too old to answer that question.
3. Add only the review time genuinely required by the team.
4. Set automatic expiry at the shortest workable period.
5. Define whether different projects, environments, or workflows require different rules.
6. Document any investigation hold, who can approve it, and when it expires.
7. Map every replay copy and index covered by deletion.
8. Reassess the period after the first investigation cycle.
9. Review retention when the purpose or legal requirements change.

Consider separately raw replay events or snapshots, compressed replay objects, search and metadata indexes, account and user associations, cached copies, generated clips, exports, annotations and derived findings, replicas, and backups.

A derived product finding may be useful after a raw replay expires, but it should contain only the minimum evidence needed and follow its own retention policy. Do not preserve screenshots or copied text in a research note merely to bypass replay expiry.

Backups require a documented policy. Depending on the architecture, immediate item-level deletion may not be technically possible in immutable backup sets. Define when deleted data becomes unavailable to ordinary use, how restoration procedures avoid reintroducing it, and when backup copies expire or are securely replaced.

Design deletion and data-subject workflows before launch

The system should be able to locate replay data by the identifiers actually used in support, privacy, and account-management processes. Depending on the product, that may include user ID, account or company ID, session or Visit ID, project ID, workspace ID, and date range.

Deletion or anonymization design should cover primary replay storage, event and metadata indexes, account and user lookup tables, caches, replicas, exports, generated clips, research attachments, and backups according to the documented backup policy.

Test the complete workflow with a synthetic account:

1. Create a synthetic user, account, and Visit.
2. Record a replay containing recognizable but non-sensitive canary values.
3. Confirm that the replay is discoverable through each intended lookup key.
4. Execute the deletion or anonymization workflow.
5. Verify the recording no longer appears in the application, API, search index, export path, or clip store.
6. Confirm how the backup policy applies.
7. Record the result and any known limitation.

Whether a particular request legally requires deletion, restriction, access, or anonymization depends on the applicable law, roles, exemptions, and context. The technical workflow should make the relevant action possible; qualified privacy or legal counsel should determine how a specific request must be handled where necessary.

Treat consent, notice, and lawful basis as legal-review questions

There is no universal “session replay GDPR compliant” switch. Legal requirements can depend on:

• the countries and people involved;
• whether the product stores information on or accesses information from a user’s device;
• the specific replay technology;
• the purposes of collection and later use;
• whether the data identifies or can be linked to a person;
• whether sensitive or special-category data is involved;
• whether the user is a customer employee, the organization’s own worker, a contractor, or another person;
• controller, processor, and subprocessor roles; and
• contracts, sector rules, and communications laws.

An authenticated B2B product is not automatically outside privacy or communications law. A contract with the customer company does not necessarily answer the rights and expectations of each user. A privacy notice does not itself create a lawful basis, and contractual notice alone may not satisfy every consent or transparency requirement.

In some jurisdictions, rules governing storage or access on a device are a separate question from the legal basis for processing the resulting personal data. Consent requirements and exceptions vary. Do not state that consent is always required or that authenticated-product replay is always exempt.

For example, the UK Information Commissioner’s Office finalized its Guidance on the use of storage and access technologies on April 29, 2026. The guidance says prior consent is required when no purpose-specific exception applies. Its statistical-purpose exception is narrow: it does not cover logs or recordings of individual visitors and their actions outside the guidance’s security caveat, and qualifying statistical use must produce aggregate, non-identifying results and meet information and objection conditions. This is UK-specific regulator guidance, not a universal rule.

Organizations should consider:

• a clear and specific purpose;
• an appropriate legal basis where applicable;
• transparent privacy and tracking notices;
• an accurate description of the replay data and purposes;
• consent collection and recording where required;
• an equally usable refusal or withdrawal path where required;
• configuration that matches the stated purpose;
• whether a privacy or data-protection impact assessment is required or prudent;
• additional restrictions for sensitive data;
• different rules and expectations for employee monitoring;
• processor agreements, subprocessors, transfers, and support access;
• a workflow for individual rights; and
• periodic legal review.

Avoid dark patterns. Do not describe replay as essential to a service merely to discourage refusal unless that conclusion is accurate and legally supported.

On February 25, 2026, the French CNIL opened a public consultation on a draft recommendation for session replay tools. The consultation closed on April 22, 2026. As of August 4, 2026, CNIL’s official material remains labeled as a draft; the draft says it is non-exhaustive and is not binding or regulatory. It addresses purpose definition before deployment, minimization, masking, identifier controls, configurable retention, deletion, access control, and security. Treat it as jurisdiction-specific draft regulator guidance, not binding legislation or universal law.

Review managed vendors and self-hosted infrastructure

A managed replay vendor and a self-hosted deployment create different responsibilities. Neither model removes the need for privacy engineering, security, governance, and legal review.

Managed-vendor review

Verify:

• data-processing terms and the parties’ roles;
• the subprocessor list and change process;
• data locations and transfer arrangements;
• client-side, ingestion-time, storage-time, and viewer-time masking behavior;
• default capture settings;
• route, selector, field, attribute, event-property, URL, console, and network controls;
• encryption statements and their exact scope;
• authentication, authorization, audit, SSO, and multifactor options;
• vendor employee and support access;
• retention configuration;
• deletion behavior for primary storage, indexes, clips, exports, and backups;
• breach-notification terms;
• export and migration capability;
• behavior at contract termination;
• SDK and dependency update process; and
• documented technical limitations.

A vendor’s statement that sensitive inputs are masked does not answer whether URLs, rendered text, console output, or network bodies are retained. Review each channel separately.

Self-hosted review

Verify:

• ingestion authentication and transport security;
• network exposure;
• object-storage permissions;
• database and cache permissions;
• encryption appropriate to the risk and architecture;
• secret management;
• production and non-production separation;
• role-based access and auditability;
• backup design and restoration testing;
• dependency and SDK updates;
• patching responsibility;
• monitoring and alerting;
• incident-response ownership;
• data-location and residency decisions;
• retention jobs;
• deletion completeness;
• capacity controls and failure behavior; and
• contract and rights workflows for any downstream providers.

Self-hosting gives the organization control over deployment, storage, retention, and operations. It also makes the organization responsible for configuring and operating those controls. Data custody is an architectural choice, not a privacy, security, or compliance outcome by itself.

Test the stored replay before rollout

A masking configuration is not validated until the team has inspected what the system actually retained.

1. Build production-like test pages using synthetic sensitive values only.
2. Test every input type, including custom components and contenteditable.
3. Test static text and dynamically rendered content.
4. Test tables, modals, menus, tooltips, toasts, and errors.
5. Test query parameters, fragments, redirects, page titles, and referrers.
6. Test uploaded filenames and attachment previews.
7. Test shadow DOM components, iframes, canvas, media, and rich-text editors.
8. Test console and network-capture settings separately.
9. Inspect the stored replay and its raw metadata rather than only the live page.
10. Test multiple supported browsers and viewport sizes.
11. Test account switching, impersonation, permission changes, and logout.
12. Test replay authorization and access logs with several employee roles.
13. Test account, user, Visit, and project deletion.
14. Document every known limitation and its compensating control.
15. Block the release if a synthetic secret or protected value remains visible or retrievable.

Use recognizable canary values such as:

[email protected]
RESET_TOKEN_DO_NOT_CAPTURE
API_KEY_PRIVACY_CANARY
CONFIDENTIAL_REPORT_TITLE_TEST

Never test with production credentials or real personal data.

A useful release artifact is a privacy test matrix containing the component or route, expected control, synthetic value, browser, stored result, pass or fail, evidence link, owner, date, and replay SDK version.

Monitor for privacy regressions

A replay configuration that worked last quarter can fail after an ordinary product change. Reassess controls after interface redesigns, component-library changes, route and URL changes, new form fields or table columns, new error states, third-party widget additions, replay SDK upgrades, new plugins or product areas, account-switching changes, console or network options, masking-rule edits, and retention or storage changes.

Maintain automated fixtures containing synthetic canary values for common sensitive categories. Where the replay platform permits it, run those fixtures in a controlled environment and inspect the stored output. Automated checks should complement, not replace, periodic manual review by authorized people.

Track at least:

• date of the last privacy test;
• SDK and configuration version;
• routes covered and excluded;
• unresolved limitations;
• deletion-test result;
• access-review result; and
• owner and next review date.

Treat masking rules as maintained production code. Review them with the same discipline as authorization logic, data schemas, and API contracts.

Prepare for accidental capture

If replay captures data that should not have been collected:

1. Disable or narrow the affected capture immediately.
2. Restrict access to the affected project and recordings.
3. Identify the relevant projects, sessions, users, accounts, routes, and date range.
4. Delete or quarantine affected data from each applicable storage and index layer.
5. Preserve only the security evidence necessary to investigate the incident.
6. Assess legal and contractual obligations with the responsible privacy, security, and legal teams.
7. Notify relevant internal owners and the vendor when appropriate.
8. Fix the collection, masking, route, or telemetry rule.
9. Retest the stored result before re-enabling capture.
10. Document the incident, decision, root cause, and preventive changes.

Do not assume that every accidental capture is legally reportable, or that none is. Notification duties and deadlines depend on the jurisdiction and facts. Obtain qualified advice rather than relying on a generic article.

Worked B2B example: narrowing replay to a reporting investigation

The situation

AtlasDesk is a fictional B2B operations platform with five product areas: Reporting, User Management, Billing, API Keys, and Support Messages.

The product team sees a measured decline in completion of a new Reporting setup workflow. Aggregate analytics identify the affected step and account segment, but they do not explain the visible interface state. The team proposes session replay to compare successful and unsuccessful Visits.

Its purpose is not “understand all customer behavior.” It is:

The purpose record

Illustration only

Control decision by product area

Global rules:

• /accounts/acme-corp/reports/8392?customer=confidential-name becomes a safe route template such as /accounts/:account_id/reports/:report_id.
• Query parameters and fragments are dropped unless explicitly allowlisted.
• Account and user names are not attached to the replay.
• Email addresses are not used as replay identifiers.
• Console capture is disabled.
• Network bodies and headers are disabled.
• Replay links require server-side authorization.
• Access to an identified Visit is logged.
• Deletion is tested against the replay store, metadata index, generated clips, and exports.
• Backup handling follows the documented backup policy.

Before and after

Why masking every text node was not enough

A global text mask would hide much of the visible interface, but it would not necessarily protect the customer name in a URL, an email address attached as session metadata, a report identifier in a DOM attribute, a support message in a network response, a user object printed to the console, a document preview rendered to canvas, an uploaded filename in a toast, or an API key displayed in a temporary state. It would not limit broad internal access, set retention, or complete deletion from indexes and exports.

The team therefore treats masking as one layer. Scope, exclusion, metadata, identity, access, retention, deletion, and production testing provide the rest of the control system.

Production session replay privacy checklist

Use this session replay privacy checklist as an implementation review. A checked box should be backed by configuration, test evidence, or an approved policy—not an assumption.

Common session replay privacy mistakes

How Hymetry approaches privacy controls for Visits

Hymetry is account-centric product intelligence for B2B SaaS. It connects behavior across Pages, Companies, Users, and Visits so teams can move from an aggregate signal to selected session evidence instead of browsing recordings without a question. This investigation pattern supports product teams and UX researchers that need account, user, page, and Visit context together.

Current Hymetry documentation describes hosted Privacy Controls for common-pattern filtering, configured content controls, and capture scope. The free Open Source edition is self-managed and has a different control surface: its current implementation provides rrweb markup-based blocking, ignoring, and masking; server-side pattern filtering of selected replay fields before persistent storage; URL query-and-fragment cleanup before storage; and a project-level choice between analytics-only and analytics with recording.

These boundaries matter. Server-side filtering occurs after transmission, unmatched content may remain unchanged, and the generic filter does not cover every rendered-text or metadata channel. The live hosted client’s treatment of URL parameters before storage is not publicly verifiable, so URL normalization remains a team requirement rather than a Hymetry guarantee. Teams should verify the edition they deploy and inspect the stored result.

Hymetry’s technical controls should be paired with a documented purpose, minimum necessary identity, access restrictions, deliberate retention, deletion testing, and recurring production review. Masking depends on configuration and does not guarantee total redaction or legal compliance.

Hymetry offers hosted plans and a free Open Source version that teams run on infrastructure they control. Self-management changes data custody and operational responsibility; operators remain responsible for configuration, security, updates, backups, retention, deletion, monitoring, incident response, and legal review.

Frequently asked questions

Is session replay GDPR compliant?

No replay product or configuration is universally “GDPR compliant.” Where the GDPR applies, the organization must evaluate matters such as purpose, necessity, data minimization, legal basis, transparency, processor relationships, security, retention, and individual rights. The answer depends on the implementation and context. Obtain qualified privacy or legal advice where necessary.

Does session replay always require consent?

There is no universal answer. Consent or another requirement may depend on the jurisdiction, whether the technology stores information on or accesses information from a device, available exemptions, the purpose, and the later processing of personal data. An authenticated B2B product is not automatically exempt, and a customer contract does not resolve every user-level question.

Is masking every input enough?

No. Sensitive data can appear in rendered text, URLs, query strings, fragments, page titles, DOM attributes, console output, network bodies, filenames, canvas content, errors, and identity metadata. Input masking is one layer of a broader control system.

Should a B2B SaaS company identify users in replay?

Only when identity is necessary for the documented purpose. Prefer stable internal IDs, minimize direct identifiers, do not use email as the primary identifier, separate account analytics from identified-replay access, audit access, and support deletion or pseudonymization.

How long should session replay be retained?

There is no universal number. Choose the shortest period that supports the documented purpose and review workflow, enable automatic expiry, define any exception, map every copy, and test deletion. Replay retention can reasonably differ from lower-context structured analytics retention.

Is self-hosted session replay more private?

Self-hosting can give a team greater control over deployment, storage, retention, and data custody. It does not by itself make the implementation private, secure, or compliant. The operator becomes responsible for access controls, patching, backups, monitoring, deletion, and incident response.

How should masking be tested?

Use production-like pages containing synthetic canary values. Test static and dynamic states, every input type, URLs, metadata, console and network settings, special browser surfaces, multiple browsers, account switching, employee permissions, and deletion. Inspect the stored replay and raw metadata rather than trusting the live UI.

What should never be recorded?

As a conservative default, exclude passwords, authentication codes, session tokens, API keys, payment-card data, bank details, health information, government identifiers, confidential communications, private documents, customer secrets, employee records, and administrator impersonation workflows. The final scope must reflect the product and applicable obligations.

Sources

Source status was reviewed on August 4, 2026. The list distinguishes binding legislation, regulator guidance, draft regulator guidance, voluntary frameworks, security recommendations, technical documentation, vendor-specific implementation examples, and Hymetry product references. Vendor documentation demonstrates concrete implementation patterns; its inclusion is not an endorsement or proof that the same behavior applies to other products.

1. European Union, Regulation (EU) 2016/679 — General Data Protection Regulation.
   https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
2. European Data Protection Board, Guidelines 4/2019 on Article 25, Data Protection by Design and by Default.
   https://www.edpb.europa.eu/documents/guideline/guidelines-42019-on-article-25-data-protection-by-design-and-by-default_en
3. European Data Protection Board, Guidelines 4/2019, Version 2.0 PDF.
   https://www.edpb.europa.eu/system/files/documents/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf
4. European Data Protection Board, Guidelines 05/2020 on Consent under Regulation 2016/679.
   https://www.edpb.europa.eu/documents/guideline/guidelines-052020-on-consent-under-regulation-2016679_en
5. Information Commissioner’s Office, Data Protection by Design and by Default.
   https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-by-design-and-by-default/
6. Information Commissioner’s Office, Principle (c): Data Minimisation.
   https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/
7. Information Commissioner’s Office, Principle (e): Storage Limitation.
   https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/
8. Information Commissioner’s Office, Pseudonymisation.
   https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/
9. Information Commissioner’s Office, The Right to Be Informed.
   https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/
10. Information Commissioner’s Office, What are the exceptions? — Guidance on the use of storage and access technologies (guidance finalized April 29, 2026).
    https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/
11. Information Commissioner’s Office, About the Guidance on the use of storage and access technologies.
    https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/about-this-guidance/
12. Information Commissioner’s Office, Monitoring Workers.
    https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/
13. Information Commissioner’s Office, Data Protection and Monitoring Workers.
    https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment/monitoring-workers/data-protection-and-monitoring-workers/
14. Information Commissioner’s Office, What Needs to Be Included in a Controller–Processor Contract?
    https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/what-needs-to-be-included-in-the-contract/
15. Information Commissioner’s Office, A Guide to Data Security.
    https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/
16. Commission nationale de l’informatique et des libertés, [Closed] Session Replay: The CNIL Launches a Public Consultation on Its Draft Recommendation (February 25, 2026; consultation closed April 22, 2026).
    https://www.cnil.fr/en/session-replay-cnil-launches-public-consultation-its-draft-recommendation
17. Commission nationale de l’informatique et des libertés, Draft Recommendation Concerning Session Replay Tools (nonbinding consultation draft; English courtesy translation).
    https://www.cnil.fr/sites/default/files/2026-02/recommendation_draft_session_replay.pdf
18. National Institute of Standards and Technology, Privacy Framework portal.
    https://www.nist.gov/privacy-framework
19. National Institute of Standards and Technology, The NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0 (current final version as of August 4, 2026).
    https://doi.org/10.6028/NIST.CSWP.01162020
20. National Institute of Standards and Technology, SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations.
    https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
21. National Institute of Standards and Technology, SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
    https://csrc.nist.gov/pubs/sp/800/61/r3/final
22. National Institute of Standards and Technology, SP 800-88 Rev. 2 — Guidelines for Media Sanitization.
    https://csrc.nist.gov/pubs/sp/800/88/r2/final
23. National Institute of Standards and Technology, SP 800-63-4 — Digital Identity Guidelines.
    https://pages.nist.gov/800-63-4/
24. OWASP Cheat Sheet Series, Logging Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
25. OWASP Cheat Sheet Series, Logging Vocabulary Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html
26. OWASP Cheat Sheet Series, REST Security Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
27. OWASP Cheat Sheet Series, Authorization Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
28. OWASP Cheat Sheet Series, Session Management Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
29. OWASP Cheat Sheet Series, Multifactor Authentication Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
30. OWASP Cheat Sheet Series, Secrets Management Cheat Sheet.
    https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
31. rrweb, Official Repository.
    https://github.com/rrweb-io/rrweb
32. rrweb, Guide and Recording Options.
    https://github.com/rrweb-io/rrweb/blob/main/guide.md
33. rrweb, Console Recording Recipe.
    https://github.com/rrweb-io/rrweb/blob/main/docs/recipes/console.md
34. rrweb, Plugin API Recipe.
    https://github.com/rrweb-io/rrweb/blob/main/docs/recipes/plugin-api.md
35. MDN Web Docs, URL API.
    https://developer.mozilla.org/en-US/docs/Web/API/URL
36. MDN Web Docs, Location API.
    https://developer.mozilla.org/en-US/docs/Web/API/Location
37. MDN Web Docs, HTML data-* Global Attributes.
    https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/data-%2A
38. MDN Web Docs, Using Shadow DOM.
    https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
39. MDN Web Docs, The iframe Element.
    https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe
40. MDN Web Docs, Same-Origin Policy.
    https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy
41. MDN Web Docs, HTMLCanvasElement.toDataURL().
    https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL
42. MDN Web Docs, Clipboard API.
    https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API
43. MDN Web Docs, paste Event.
    https://developer.mozilla.org/en-US/docs/Web/API/Element/paste_event
44. Sentry Documentation, Session Replay Privacy.
    https://docs.sentry.io/platforms/javascript/session-replay/privacy/
45. Sentry Documentation, Session Replay Configuration.
    https://docs.sentry.io/platforms/javascript/session-replay/configuration/
46. Datadog Documentation, Session Replay Privacy Options.
    https://docs.datadoghq.com/session_replay/privacy_options/
47. Datadog Documentation, Real User Monitoring Data Security.
    https://docs.datadoghq.com/data_security/real_user_monitoring/
48. Federal Trade Commission, Protecting Personal Information: A Guide for Business.
    https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business
49. Hymetry, Privacy Controls.
    https://www.hymetry.com/product/privacy-controls/
50. Hymetry, Visits.
    https://www.hymetry.com/product/visits/
51. Hymetry, Open-Source Repository.
    https://github.com/Hymetry/Hymetry