Session Replay Privacy Checklist for B2B SaaS

Document purpose and minimize scope

Begin with the decision replay should support. “Understand all customer behavior” is not a useful purpose. A bounded purpose names the question, affected workflow, eligible population, comparison, intended reviewers, retention, outputs, owner, and stop condition.

Sampling reduces total volume, but it does not make an individual recording safe. A sampled replay can still contain a password, support message, billing data, token, customer name, or private document. Apply the same per-record controls.

Prefer structured analytics when the question only needs counts, sequence events, completion, or error categories. Use replay when visible interface evidence is necessary and proportional to the purpose.

Inventory data and choose the right control

Inspect the recorder's emitted payload, ingestion transformations, stored chunks, metadata database, search index, player, exports, clips, logs, caches, analytics integrations, and backups. List direct and indirect identifiers, visible content, attributes, URLs, input changes, files, canvas/media, console/network fields, errors, performance data, and custom plugins.

Start conservatively. Exclude passwords, tokens, API keys, payment data, authentication, impersonation, support messages, private documents, health/financial data, and other high-risk content unless a reviewed necessity and stronger control exists. Password-field defaults are not enough; ordinary text inputs, search, filenames, validation errors, copied content, and temporary reveal states can carry secrets.

Protect URLs, identity, and diagnostic layers separately

URLs can expose tenant names, email addresses, search terms, report IDs, tokens, filenames, and query parameters even when the page body is masked. Normalize dynamic paths and drop query strings/fragments by default. Allowlist only parameters required for the investigation.

Unsafe:
/accounts/acme-corp/reports/8392?customer=confidential-name

Safer stored route:
/accounts/:account_id/reports/:report_id

Attach the minimum identity needed. Stable pseudonymous internal IDs can connect a Visit to a Company and User without storing names or emails in the replay. They are pseudonyms, not anonymity, when lookup is possible. Protect the lookup service and audit identified access.

Treat each diagnostic layer as a separate opt-in system:

• Console: objects, tokens, customer records, and developer-only text can leak through logs.
• Network: URLs, headers, bodies, GraphQL variables/results, and responses can contain extensive sensitive data.
• Errors: messages and stack traces can include values, file paths, or tenant context.
• Performance: resources and spans can expose endpoints and identifiers.
• Canvas/media/plugins: visual or custom data may bypass ordinary DOM masking.

Keep these disabled unless the purpose requires them and field-level allowlisting/filtering has been tested. A safe structured error category often supplies enough evidence without raw payloads.

Apply least privilege, short retention, and complete deletion

Authorize every replay search and view server-side by project and role. Use named groups, SSO/MFA where appropriate, time-limited elevated access, audit logs, periodic reviews, and separation between product research, engineering, support, and administration. Direct object-storage URLs must not bypass application authorization.

Set retention from the purpose, not a universal default. Detailed replay usually warrants shorter retention than lower-context structured aggregates. Automate expiry, monitor retention drift, and document archives, replicas, versions, exports, and backups.

Build deletion before launch

Build deletion before launch. Support lookup by User, Company, Visit, project, and time range as needed. Delete or make inaccessible:

• recording chunks and manifests;
• metadata and search-index rows;
• caches, generated clips, downloads, and exports;
• derived artifacts that can reconstruct the Visit;
• replicas and object versions;
• backup data under a documented expiry/restore-suppression process.

Test that a deleted recording cannot be found through any supported lookup, direct object reference, restored index, or backup restoration. Document legal/security hold behavior separately.

Treat legal and vendor review as implementation work

This guide is technical and organizational guidance, not legal advice. Qualified counsel should assess lawful basis, consent and storage/access rules, transparency, employee monitoring, data-subject rights, processor/controller roles, transfers, contracts, and sector requirements for the actual jurisdictions and deployment.

Do not assume “B2B” removes individual privacy obligations. Replays concern people using the product, including customer employees and administrators. Notice should describe actual collection and purposes in understandable language.

Review the operating model

For a managed vendor, verify recorder behavior, masking defaults, regional data flow, subprocessors, encryption, access, SSO/MFA, audit logs, retention, deletion, backups, exports, incident terms, support access, and contractual controls. Test claims against your configuration.

For self-hosting, verify collection credentials, private storage, tenant isolation, dependencies, vulnerabilities, secrets, backups, restoration, monitoring, administrator access, incident response, and deletion. Self-hosting changes who owns the risk; it does not remove it.

Test stored replay and prepare for incidents

Test realistic production-like pages and state transitions, including dynamically rendered text, validation errors, tables, modals, portals, shadow DOM, same/cross-origin iframes, canvas, rich editors, uploaded filenames, route changes, SPA account switching, mobile layouts, localization, and temporary reveal states.

1. Capture a test Visit with seeded sensitive canaries.
2. Inspect the network payload leaving the browser.
3. Inspect ingestion logs and transformations.
4. Inspect stored chunks, metadata, index, and exports.
5. Play the replay and search by every identifier.
6. Verify blocked/excluded routes during SPA navigation.
7. Run deletion and restore tests.
8. Repeat after SDK, selector, route, component, or plugin changes.

Monitor capture volume, newly observed routes, masking/blocking failures, unsafe URL patterns, console/network enablement, new attributes, access anomalies, retention drift, deletion backlog, export creation, and SDK/config versions. Treat privacy rules as production code with owners, tests, review, and rollback.

Prepare an accidental-capture playbook: stop or narrow collection, preserve only necessary incident evidence, block access, identify affected projects/Visits/fields, delete or quarantine data, assess notifications with legal/security owners, fix and validate controls, document the incident, and monitor recurrence.

Worked B2B example and production checklist

Fictional illustration: AtlasDesk sees a measured decline in Reporting setup completion for newly invited account administrators. Its purpose is to compare successful and unsuccessful Reporting setup Visits for visible interface states—not to record all customer behavior.

AtlasDesk uses pseudonymous User and Company IDs, disables console and network bodies, restricts access to assigned researchers/engineers, applies an illustrative 30-day investigation retention, and tests deletion across storage, indexes, clips, exports, and backups. The 30 days is not a universal recommendation.

How Hymetry approaches replay privacy

Hymetry connects Visits with Pages, Companies, and Users while providing privacy-control context for replay. Teams should still configure route scope, text/input handling, identity, retention, access, and deletion for their deployment and verify the emitted and stored data.

The open-source repository makes current tracker and filtering behavior inspectable. Inspect the exact version deployed; repository availability is not proof that a configuration meets a legal or organizational requirement.

Sources

Source status reviewed August 4, 2026. Sources include binding legislation, regulator guidance, a nonbinding draft, voluntary frameworks, security recommendations, technical documentation, vendor examples, and Hymetry references. Vendor examples are not endorsements or proof of equivalent behavior elsewhere.