Why session replay needs a consent gate under GDPR
Session replay and identified product analytics are processing of personal data under the GDPR, so they need a lawful basis and a working consent gate before any SDK fires. A recording captures what a visitor typed, clicked and scrolled, and an identified event ties that behavior to a person. For a product team lead in an EU-facing organization, the practical answer is that the replay SDK, the analytics SDK and any third-party tag must stay silent until the gate records a valid choice, and that the gate itself must be tested and documented. Regulation (EU) 2016/679 is binding in all EU Member States and applies in Iceland, Liechtenstein and Norway, so the obligation follows the audience, not just the company's address.
The GDPR requires no audit report, attestation or certificate, so there is no single document that proves compliance on request. Instead, the controller must be able to show its decisions and controls. Article 32 requires security of processing that fits the risk, which for recordings of logged-in users usually means masking at capture, role-based access to replays and a tested retention limit. Articles 33 and 34 set breach notification duties to supervisory authorities and, where risk is high, to the affected people, so the team should know which system holds recordings and who can export them before an incident. Article 83 sets fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for breaches of the principles, lawful basis and data subject rights, which is where an SDK that fires before consent falls.
DeployOpen plans and implements the self-hosted analytics stack, builds the gate integration, and prepares the controls and evidence a data protection review will ask for. It does not issue audit reports or certifications, and independent auditors and supervisory authorities make those judgments. Before scoping work, confirm with your data protection officer or counsel which lawful basis applies to each event type, whether any Article 42 certification scheme is relevant to your sector, and whether pending changes to the GDPR affect your plans. Ask a partner to show how the gate is tested, how consent withdrawal stops collection, and which records of processing will be produced at go-live.
Which GDPR obligations shape the replay setup
This table maps the GDPR obligations that affect session replay and identified analytics to what the function must do and how to configure it in OpenReplay or PostHog. Read each row as a question to answer before go-live, and treat the configuration column as the starting point for your own legal and technical review.
| Obligation | What the function must do | How to configure it in OpenReplay or PostHog |
|---|---|---|
| Article 6 lawful basis and consent | Establish a lawful basis for each recording or identified event, and obtain consent where it is the basis, such as for non-essential tracking | Load the replay and analytics SDKs only after the consent tool reports opt-in for the relevant category; confirm with counsel whether consent or another basis applies |
| Article 5 principles | Collect only what the stated purpose needs, keep it accurate, and limit storage to what is necessary | Define an event tracking plan, avoid free-text fields in event properties, and document the purpose of each replay and event type |
| Articles 12 to 14 transparency | Tell users clearly what is recorded, why, for how long and who receives it | Describe session replay in the privacy notice and cookie notice; align the disclosed retention period with the configured value |
| Articles 15 and 16 access and rectification | Locate a user's recordings and events on request and provide them, correcting data where needed | Keep a stable user identifier that support staff can search; test the export path with a sample identity before go-live |
| Article 17 erasure | Delete a user's recordings and identified events when erasure applies, and confirm deletion | Confirm the platform's deletion API or admin process for persons and recordings; PostHog states it cannot selectively delete imported event data, so plan for this before migrating history |
| Article 18 and 21 restriction and objection | Stop processing for users who object or whose processing is restricted | Map objection to SDK gating and opt-out flags so recording stops for that user across devices |
| Article 25 data protection by design | Build privacy into defaults, minimizing capture before data reaches storage | Enable capture-time masking by CSS selector and input redaction; OpenReplay describes a private mode that masks all text and inputs by default; test masking after each front-end release |
| Article 30 records of processing | Keep a record of processing activities covering purposes, categories, recipients, retention and transfers | Record the replay tool, hosting location, event categories, masking rules, retention setting and sub-processors; keep the record under version control with the configuration |
| Article 32 security of processing | Protect recordings with access controls, encryption, logging and backups proportionate to the risk | Restrict viewer roles, enable audit logging where the edition supports it, and confirm encryption at rest and in transit with the vendor or your own hosting team |
| Articles 33 and 34 breach notification | Detect a breach in the analytics stack and notify the supervisory authority and affected users within the required windows where risk applies | Include the replay database and admin consoles in your incident runbook; define who assesses captured data after a suspected exposure |
| Chapter V transfers | Assess where recordings are stored and whether any SDK, CDN or support access moves data outside the EEA | Self-host in EU infrastructure where the design requires it; PostHog offers an EU (Frankfurt) cloud region, and self-hosting keeps data in the operator's infrastructure; list every third-party script that loads on the page |
Which self-hosted platform fits the consent model
OpenReplay combines session replay, DevTools data, product analytics and cobrowsing in one product. For consent purposes, its most relevant features are the capture-time controls. According to its README, the SDK masks or skips data before it reaches the server, masks elements by CSS selector, redacts inputs and offers a private mode that masks all text and inputs by default. Self-hosting keeps session data in your own infrastructure, and the README notes that first-party tracking from your own domain is not blocked by ad blockers. Retention is self-managed in the open-source edition.
- Capture-time masking: Selector-based masking and input redaction apply before data leaves the browser, which narrows what your recordings can contain.
- Private mode: The default-masked setting suits flows where you want to start from zero visible content and unmask deliberately.
- Licensing: Most of the monorepo is AGPLv3, some directories are MIT, and the ee/ directory is under a separate commercial license defined in ee/LICENSE.
- Enterprise features: SSO and SAML, SCIM, roles, audit trail and a custom SLA are listed on the Enterprise edition, not in the open-source edition.
- Retention: The open-source edition relies on self-managed retention, so the retention period is set by your team and must match the period in your records of processing.
Confirm with the vendor and in a test environment that masking holds after front-end releases, and that your consent tool can block the SDK before any capture begins.
PostHog covers product analytics, session replay, feature flags, surveys and data pipelines in one repository. Its self-host documentation offers a free Docker Compose hobby deployment under the MIT license, but PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for product, infrastructure or other questions on self-hosted instances. Its README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that. Consent gating needs to be designed with that support boundary in mind.
- Licensing: The repository is MIT except the ee/ directory, which is covered by a separate license. Premium features from ee/ on a self-hosted instance require a PostHog license.
- Fully free option: The README points teams that need fully free software to posthog-foss, a repository purged of proprietary code and features.
- Support boundary: Self-hosted instances carry no vendor support, so the operating team owns patching, incident response and the consent configuration.
- Scale guidance: The README's roughly 100k events per month figure is a planning threshold, and PostHog's self-host docs note that new Kubernetes deployments of its paid self-hosted product are no longer supported.
- Sanitization: Confirm which masking options apply to session replay in your version, and test them against forms and pages that carry personal data.
Before you choose PostHog, confirm which features your consent design needs are in the MIT core and which sit in ee/, and whether an in-house team can own support.
The two platforms use different licensing models, and both affect what you can deploy and what you must pay for. OpenReplay uses AGPLv3 for most of its code, which carries source-availability obligations if you modify and offer the software over a network. PostHog's core is MIT, but its enterprise features sit under a separate license. In both cases, the features you need for consent (masking, access controls, retention, SSO) may sit in the commercial layer, so the licensing review should start from the feature list, not the headline license.
- Copyleft obligations: AGPLv3 applies to modifications you make and distribute or make available to users over a network, so confirm the effect on any custom SDK changes.
- Permissive core: MIT allows broad internal use, but the ee/ directory is governed separately in PostHog's repository.
- Commercial features: Access controls, audit trails and SSO are the features most often in the commercial layer, and they matter for who can view recordings.
- Documented ownership: Record which license governs each component in your software bill of materials and your records of processing.
- Counsel review: Ask your legal team to confirm the obligations for your use before you deploy.
Check the LICENSE and ee/LICENSE files in each repository at the version you plan to deploy, and ask the vendor for a written statement of which features are commercial.
Platforms that fit a consent-gated EU deployment
Each option below can hold session replays and identified analytics, but they differ in where the data sits, who operates the software and what the license allows. The cards show the decisions that follow from those differences, so you can match a platform to your consent model and hosting constraints before you run a pilot.
OpenReplay open-source edition
The open-source edition is free to self-host, with community support and self-managed retention, so your team sets how long recordings live. It runs on a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage to start, per the project README. Because recordings stay on your infrastructure, you control the processor relationship and erasure workflow directly. Confirm the AGPLv3 obligations with counsel before you modify the code and offer it to users.
OpenReplay Enterprise edition
The self-hosted Enterprise edition adds SSO and SAML, SCIM provisioning, roles and permissions, and an audit trail, which matter when you must show who opened a recording and when. It sits under a separate commercial license in the ee/ directory. Pricing is custom on multi-year contracts, so ask the vendor to confirm which access and audit features are in the agreed scope and what support terms apply.
PostHog hobby Docker Compose deployment
PostHog offers a free Docker Compose deployment under the MIT license, installed with a deploy-hobby script. PostHog recommends a server equivalent to 4 vCPUs, 16 GB of RAM and more than 30 GB of storage, and suggests open-source deployments suit about 100k events per month. Self-hosted instances are officially unsupported, so your team carries patching, backups and retention settings. Plan for that operating load before you rely on it for consent-gated data.
PostHog foss repository
The posthog-foss repository is purged of proprietary code and features, which suits teams that must avoid any license covering premium functions. PostHog's README points teams that need fully free software to this repository. The trade-off is a narrower feature set than the main repository, so confirm that session replay, consent-aware SDK behavior and the retention controls you need are present before you choose it.
PostHog Cloud EU (Frankfurt)
As a comparison point, PostHog Cloud offers an EU (Frankfurt) hosting region, so data stays in the EU without you operating the servers. You still need a processor agreement, a transfer assessment for any sub-processors, and a clear view of which SDK calls reach third-party endpoints. SSO, audit logs and custom roles are sold as platform packages. Ask the vendor to confirm the current region, sub-processor list and retention terms in writing.
How to gate SDKs behind a consent tool, step by step
This sequence makes sure no session replay or identified analytics data leaves the browser until the visitor has made a valid choice, and that each choice is provable later. It produces a documented, tested configuration that a data protection reviewer can follow from purpose to request.
Classify data and purposes
The privacy or product owner lists every event, property, recording and identifier the site or app would collect, and names the purpose of each one, such as aggregate usage counts, funnels, error diagnosis or identified user profiles. Engineering marks which fields can contain personal data, including form inputs, URLs with query strings, account IDs and free text. The output is a data inventory that maps each field to one purpose, and no SDK is configured until that inventory is signed off.
Choose the lawful basis per purpose
With legal counsel, the controller decides which purposes can rely on another lawful basis and which require consent. Session replay and identified product analytics generally need consent under the ePrivacy rules for storing or reading information on the device, and the GDPR sets the standard for what valid consent means. Record the decision and the reasoning for each purpose. The output is a register entry per purpose that the consent configuration can reference, and counsel should confirm the position for each jurisdiction served.
Load the consent banner before SDK initialization
The consent tool loads first in the page load sequence, and the analytics and replay SDK snippets are kept out of the initial HTML so they cannot run by default. Front-end engineers confirm the load order in the tag manager or build pipeline, including single-page app route changes. The check is that a clean browser session shows the banner before any analytics script is requested. Confirm the exact integration method with the consent tool vendor's documentation.
Block capture until opt-in
The SDK is initialized only after the consent tool reports an affirmative choice for the relevant category, and it stays disabled when the visitor declines or makes no choice. Where the SDK offers an opt-out or opt-in mode, the team sets the default to not capturing and tests the switch both ways. The output is a single gate in code that every analytics and replay call passes through, so no page component can start capture independently. Confirm the SDK's opt-in API in the vendor documentation for the version in use.
Configure masking by selector and input redaction
Before data reaches the server, the team configures capture-time masking for elements that contain personal or financial content, by CSS selector, and redacts all form inputs that are not needed for analysis. Network payloads and request URLs that carry identifiers are filtered at capture where the tool supports it. The output is a written masking map that lists each selector and its reason, reviewed by the privacy owner. OpenReplay documents capture-time masking and input redaction, and teams should confirm the equivalent controls in their chosen platform.
Apply private mode to sensitive pages
Pages that handle authentication, payments, health information, legal forms or support messages run in the most restrictive mode, either with recording disabled entirely or with the platform's private mode that masks all text and inputs by default. Routing rules define these pages by path, and the rules are reviewed whenever a new sensitive page is added. The output is a list of excluded or private routes that is checked against the site map at each release.
Record consent state with each event
The consent decision, its version, its timestamp and the category choices are stored in a consent log and, where the analytics tool supports it, attached as a property to the events and recordings captured under that choice. This lets the team show which consent state applied to a given session during an audit or a data subject request. The output is a consent record format and a retention rule for those records, agreed with the privacy owner.
Test that no request fires before consent
QA runs automated and manual tests in a fresh browser profile, first with no choice made, then with refusal, then with acceptance, and records every outbound request to analytics, replay and third-party endpoints. Each test case is repeated after front-end releases, because masking selectors and load order often break quietly. The output is a signed test report that shows zero capture requests before consent and expected requests after it. Teams should repeat the tests whenever the consent tool or the SDK version changes.
Handling access and erasure requests for recordings
A data subject request for a recording only works if you can find the recording, so the first control is the identifier you store at consent time. Map each consented visitor to a stable user ID where they are logged in, and record the session ID and, where you use it, a device identifier against that user ID when consent is captured. Without that mapping, an access or erasure request arrives with an email address and nothing in your analytics store can be matched to it. Confirm with your platform which identifiers it indexes for search, whether replay can be filtered by user ID after the fact, and whether a request can be answered from the platform's interface or needs a query run by your engineers. Document the procedure as a runbook with a named owner, the roles allowed to export a recording, and the log of who viewed it.
Deletion is where the platform choice matters most. Test whether your chosen platform can delete a single session or the events for one user without a full purge of the project, and do this on a staging instance before go-live rather than during the first live request. PostHog's managed migration documentation states that once historical events are imported there is no way to selectively delete event data, so any migration from another analytics tool carries that limit into your deletion process. Before you commit, ask the vendor or your implementation partner to show the exact steps, the time to propagate deletion to backups and replicas, and what remains in logs or exports. Write down the result as evidence that the process has been tested.
Retention should be a written policy per purpose, not a platform default. Set one period for replays used in debugging, another for aggregated product analytics, and state who approves exceptions. The platforms differ in who sets the clock: OpenReplay's open-source edition uses self-managed retention, so your operations team owns the purge job, while PostHog's Free plan on its cloud product includes 1-year data retention. Neither default is a policy. Confirm the response period you must meet for access and erasure requests against Article 12 of the GDPR with your counsel, because that period is not stated in the facts this page relies on. Keep the outcome of each request, including refusals and the reasons, as part of your records of processing.
Evidence auditors and supervisors ask for
This table lists the records a supervisory authority or auditor will expect to see for session replay and identified analytics, and the component that produces each one. Read it as a checklist for your own accountability file, where the controller shows how consent, masking, retention and erasure work in practice. The main takeaway is that most of this evidence is generated by your own tools and pipelines, so it has to be configured and retained from day one.
| Evidence item | What it shows | Produced by |
|---|---|---|
| Records of processing (Article 30) | Purposes, categories of data, recipients, transfers and retention for each recording or analytics flow | Controller's records register, maintained with the DPO or privacy lead |
| Consent logs with timestamps and versions | That each visitor's choice was recorded, when, and against which banner and policy text version | Consent tool audit log |
| Consent banner configuration export | The categories, default states, wording and script-to-category mapping in force on a given date | Consent tool configuration export, stored under change control |
| SDK loading tests before and after consent | Evidence that replay and analytics scripts do not load or send data before the relevant choice is given | CI test suite or scripted browser checks, with saved results |
| Masking test results after front-end releases | That selectors, input redaction and private-mode settings still hide sensitive fields after each release | CI masking tests and sampled replay review records |
| Retention configuration | The retention period set per project or data class and the date each setting took effect | Platform admin settings export and change history |
| Erasure and access request logs | Dates received, identity checks, search scope across recordings and events, actions taken and responses sent | Ticketing system, linked to platform deletion records |
| Access control and admin audit logs | Who can view replays, who holds admin rights, and when roles or permissions changed | Platform admin audit trail and identity provider logs |
| Data protection impact assessment (where required) | Risk analysis, necessity and proportionality, and mitigations for large-scale or sensitive monitoring | Privacy lead with security and product owners |
| Transfer assessment for third-party SDKs | Which CDNs, SDKs or hosts receive data, where they are located, and the safeguards relied on | Privacy lead, using vendor documentation and network tests |
| Breach runbook (Articles 33 and 34) | Steps to assess, document and notify a personal data breach to the supervisory authority and affected people | Incident response team, tested through exercises with dated records |
What tooling alone does not satisfy
A session replay or identified analytics tool can capture data, mask fields and store recordings, but it cannot decide whether processing is lawful or prove that consent was given. The cards below cover the gaps that remain after the software is installed, and each one needs an owner, a written decision and a check.
No tool supplies a lawful basis
Choosing a lawful basis under Article 6 is a controller decision, and for session replay it is usually consent. No SDK or consent banner can make that decision for you, and a banner that is shown but not recorded does not give you evidence. Document the basis for each product analytics purpose, including whether identified events fall under consent or a separate justification, and keep that record with the processing activity entry. Confirm the position with your data protection officer or counsel before enabling recording.
Consent tools miss first-party scripts
A consent management platform can block tags it knows about, but a self-hosted replay script served from your own domain often loads before or outside that gate. Map every script, pixel and SDK that runs on consent-sensitive pages, including ones added by tag managers, and confirm that the replay SDK initializes only after an affirmative choice. Test with consent refused and check the network trace, not only the banner.
Masking drifts after front-end releases
Capture-time masking by CSS selector works only while the selectors match the current page. A redesigned checkout, a new form field or a renamed class can expose card numbers, health details or account data in recordings without any alert. Treat masking rules as code: review them in each front-end release, add automated checks that fail when a sensitive field is unmasked in a test session, and sample live recordings on a schedule.
Self-hosting does not remove controller duties
Keeping recordings in your own infrastructure reduces third-party transfers, but you remain the controller for everything stored there. You still answer access and erasure requests, set retention, apply security of processing under Article 32 and handle breach notification under Articles 33 and 34. Assign named owners for each duty and write them into your records of processing, because the hosting model does not transfer them to the tool.
Self-managed PostHog has no vendor support
PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product or infrastructure questions on self-hosted instances. For a regulated team, that means patch management, incident response, backups and upgrades must be owned by your staff or a contracted partner under written scope. Ask who fixes a masking defect or a broken deletion job before go-live.
Enterprise controls sit on custom terms
OpenReplay's pricing page lists SSO and SAML, SCIM provisioning, roles and permissions, and audit trail as features of the self-hosted Enterprise edition, sold at custom pricing on multi-year contracts. Access control over who can view recordings is central to avoiding a data leak, so confirm early whether the open-source edition meets your access and logging requirements or whether the Enterprise terms are needed. Read the ee/ license terms before you rely on any of those features.
Questions teams ask before hiring outside help
What drives the cost of consent gating and masking for session replay?
The cost depends on how many pages and SDK integrations need gating, how many forms and sensitive fields must be masked, and how many front-end releases must be retested. Most of the spend is labor: someone maps every page and event, wires the consent tool to the SDK so nothing loads before a choice is recorded, configures masking by CSS selector and input redaction, and verifies the result in a test environment. Some costs are one-time (the initial mapping and configuration), while others recur whenever the front end changes and masking must be checked again. Ask any quote to itemize discovery, consent integration, masking rules, testing across browsers and devices, documentation for your records of processing, and post-go-live support as separate lines.
Can one internal engineer set up consent and masking alone?
A single engineer can often handle a small site with a few pages and no sensitive forms, but the work usually touches more than code. The engineer must understand which events are personal data, how the consent tool blocks scripts, where recordings are stored, and how masking holds after each release. Teams with a single engineer should plan for legal review, a second person to test flows, and time for ongoing checks after each deployment. OpenReplay's README describes capture-time masking by CSS selector, input redaction and a private mode that masks all text and inputs by default, so the configuration is achievable in-house, but the verification and documentation are where capacity usually runs short. Confirm the internal skills and hours you can commit before deciding.
How long does consent gating and replay setup take?
The timeline is set by the number of pages, the number of tracking tags, the state of your existing consent banner, and how quickly legal and product can agree on what to mask. Discovery and the written scope come first, followed by configuration, test cases for each consent state, and a sign-off round. No fixed duration applies to every site, so ask a prospective partner for a phased plan with dates tied to named deliverables, and confirm what counts as done in the signed scope. Fixed-scope engagements, which DeployOpen typically uses, let you compare timelines against an agreed list of pages and events.
What does the work need from legal and product teams?
Legal must confirm the lawful basis for each analytics purpose, decide whether replay and identified analytics need opt-in consent, and approve retention periods and the wording of notices. Product owners must list the flows that handle personal data, such as sign-up, payment, account settings and support forms, and agree which fields are excluded from recording. Both teams should review the records of processing, since the GDPR's Article 30 duties cover the processing activities an organization carries out. Ask the implementation partner to specify these inputs in the written scope so that legal and product sign-offs are scheduled as milestones instead of surfacing late in the project.
Does the GDPR require a certificate for session replay?
No. The GDPR requires no audit, attestation or certificate for session replay or any other processing. Certification under Article 42 is voluntary, is issued for at most three years by accredited bodies or supervisory authorities, and does not reduce the controller's responsibility for compliance. What the regulation expects is evidence that you chose a lawful basis, obtained consent where needed, limited data collection, secured the stored recordings and honored data subject requests. DeployOpen prepares systems, controls and evidence for these reviews but does not issue certificates or audit reports. Your independent auditor or supervisory authority will assess whether the evidence is adequate.
Does self-hosting remove the consent requirement?
No. Self-hosting changes where recordings are stored, but it does not change whether the GDPR applies to the data subject's behavior. Session replay and identified product analytics still need a lawful basis, and in many cases consent before the SDK runs. Keeping data in your own infrastructure helps with transfer rules and vendor risk, and OpenReplay's README notes that self-hosting keeps session data in the operator's own infrastructure. That benefit sits alongside your duties as controller, including transparency, minimization, retention limits, security of processing under Article 32 and the ability to answer access and erasure requests. Self-hosting is a design choice that supports compliance, not a substitute for it.
What happens to replays captured before consent was in place?
Recordings captured without a valid lawful basis or consent should be treated as a compliance issue to resolve with legal before anything else is done. Typical steps include stopping collection for affected users, identifying which recordings were captured and from which pages, deciding with legal whether they must be deleted or can be retained, and documenting the decision. Be aware that some platforms do not allow selective deletion of individual event data once it is imported, as PostHog's migration documentation notes for imported events. Ask a partner to define how existing data is identified, quarantined and erased, and what evidence of that process will be kept, within the written scope.
Which parts of consent and replay setup should a partner handle?
A partner is most useful for the parts that need repeatable engineering and evidence: consent gating for each SDK, masking rules tested against real flows, access and erasure procedures for recordings, retention configuration, and the documentation your compliance team needs. Legal decisions, such as the lawful basis and final notice wording, stay with your organization. Ask for a written list of deliverables that separates configuration, testing, documentation and ongoing support, and confirm which items are one-time and which are retained as a service. DeployOpen plans, implements and documents self-hosted platforms in the client's own infrastructure and offers ongoing support as a retainer.
When cross-border transfers and third-party SDKs change the design
Self-hosting in EU infrastructure keeps the primary replay and event store in the EU, but it does not by itself make the whole setup free of transfers. Commission Implementing Decision (EU) 2023/1795 on the EU-US Data Privacy Framework matters when personal data goes from the EEA to a US recipient that is certified under that framework. If your PostHog or OpenReplay instance runs in your own EU cloud account and no vendor in the US receives its data, that decision is usually not the controlling question for the recordings themselves. The question shifts to everything the browser or app touches on the way to that store. Confirm with your counsel which transfers, if any, remain once the storage design is settled.
The components most often missed are the ones that sit outside your application code. Content delivery networks, DNS resolvers, error trackers, tag managers and the consent management platform itself can each receive IP addresses, device identifiers or page URLs from the visitor's browser before any consent decision is applied. Inventory each script and request the page loads, record the provider, the processing location and the contract basis, and check whether the consent tool loads before or after the replay SDK. A consent platform hosted in the US that receives the visitor's choice is a transfer decision in its own right, and it belongs in your records of processing.
For the design, decide early which third-party requests are blocked until consent, which are first-party and served from your own domain, and which must stay out of the page entirely. Use the sibling topic on EU data sovereignty for the detail on EU cloud regions, CDN choices and data protection review documentation, so this section does not repeat it. Ask your implementation partner to produce a request-level map from a clean browser session with consent refused, and retest it after each front-end release, because a new tag added by a marketing team can reintroduce a transfer that the original design ruled out.
What a fixed-scope consent implementation covers
The sequence turns a session replay and product analytics setup into a self-hosted stack where consent gates every SDK, masking is tested before recordings are kept, and the retention, erasure and records of processing evidence is handed over in writing. Scope, deliverables and timelines are agreed in writing before work starts.
Scope the data inventory and lawful basis
DeployOpen works with your privacy, legal and product owners to list every event, property, recording and third-party script the site or app sends, and which of them identify a person. The output is a signed data inventory with a proposed lawful basis and consent category for each tracking purpose, plus the list of systems in scope. Nothing is deployed until this inventory is agreed in writing as part of the fixed scope.
Deploy the self-hosted analytics platform
Engineers install the chosen platform, such as PostHog or OpenReplay, inside your own cloud account, data center or private network, with storage, backups and access paths that match the inventory. They confirm which edition and license terms apply, including any features that sit under a separate commercial license. The check that closes this step is a working instance in a non-production environment with data residency documented.
Integrate the consent tool and gate SDKs
Your consent management platform is connected so that analytics and replay SDKs load only after the relevant consent category is granted, and are withdrawn when consent is revoked. DeployOpen tests the blocking behavior in each browser and tag path, including tags loaded by other scripts. The closing check is a test log showing that no tracking request fires before consent and that revocation stops new collection.
Configure masking and verify it holds
Capture-time masking is set for inputs, sensitive selectors, network payloads and any private-by-default mode the platform offers, so personal data is removed before it reaches the server. Test cases cover forms, account and payment screens, and common front-end release changes. The output is a masking test report with pass or fail results per page, and a regression check that runs after each release.
Build retention and erasure runbooks
Retention periods from the inventory are configured in the platform, and runbooks are written for handling access requests and erasure requests that touch recordings, events and person profiles. Where a platform cannot delete selected event data after import, the runbook states that limit and the agreed alternative. The output is tested runbooks, with a dry run showing a sample request traced from intake to confirmed deletion.
Assemble records of processing and evidence
DeployOpen drafts the records of processing activity entries for the tracking purposes, lists the processors and transfer mechanisms for any vendor component, and collects configuration exports, consent logs, masking reports and runbook tests into an evidence pack. The pack supports your own compliance review; it is not an audit report or certification. The check is a review meeting where your data protection lead confirms each entry matches the live configuration.
Hand over and document operations
Administrators receive architecture notes, configuration as code where applicable, access and role documentation, and the operating procedures for retention reviews and release testing. Knowledge transfer sessions cover how to rerun masking tests and how to respond to a request. The handover is complete when your team signs the acceptance checklist, and any ongoing support or upgrades are covered by a separate retainer agreed in writing.
How DeployOpen works on this
DeployOpen plans, implements, hardens and documents self-hosted session replay and product analytics inside your own cloud accounts, data centers or air-gapped networks. For consent-gated replay, the work covers which SDKs load before and after consent, how masking and retention are configured, and the evidence your data protection team needs.
How we scope
- Written scope lists each site, app and SDK that will load the replay or analytics tag, and the consent states each one must respect.
- Scope defines which pages and flows are excluded from recording, such as payment, login and health or account pages, before any build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.
How we build
- We gate the replay and identified analytics SDKs behind your consent management tool so nothing initializes before an opt-in is recorded.
- We configure capture-time masking by CSS selector, input redaction and private-by-default mode, then test masking after each front-end release.
- We set retention periods per data category and configure access roles so recordings are viewable only by the people who need them.
How we hand over
- You receive configuration documentation covering consent wiring, masking rules, retention settings and the access model in writing.
- We prepare a records of processing entry draft and a data flow description for your data protection officer to review and adopt.
- We document the runbook for access requests, erasure requests for recordings and retention deletion, so your team can operate it without us.
How we support
- Support after go-live is available as a retainer covering upgrades, configuration changes and re-testing of masking after releases.
- Continuous security testing of the replay deployment and the instrumented pages can be added to the retainer if your scope requires it.
- Our work prepares systems, controls and evidence for your assessments. Independent auditors and certification bodies issue any audit report or certificate.
