Session Replay Privacy Governance Under GDPR and ISO 27701

The demo that turned product insight into privacy evidence

The demo screen looked like a breakthrough. Sarah, the CISO of a fast-growing SaaS company, watched the product team replay a real onboarding session from their new analytics platform. The cursor moved across the interface, a user hesitated at step three, clicked back twice, opened a help tooltip, then abandoned the flow.

The product manager was excited. Session replay would show exactly where customers struggled. Heatmaps would reveal which fields caused friction. Crash diagnostics would tell engineering which browsers failed. Mobile telemetry would help prioritize fixes by device version. It looked like a goldmine for user experience.

Then Sarah saw what the tool had actually captured.

One user typed a password into the username field by mistake. Another pasted a national ID number into a free-text box. A support agent opened a customer account during a troubleshooting session, exposing financial data on screen. Crash logs contained email addresses, IP addresses, route names, authentication state, device identifiers and feature flags that revealed the customer’s internal workflow.

The analytics vendor called itself a processor. The customer contract said production PII could not be used for analytics without approval. The privacy notice said only that the company used analytics to improve the service. It did not mention session replay, behavioral monitoring, device identifiers, masking, retention, recipients or international transfers.

The product team saw harmless operational data. Sarah saw unstructured, unmasked and ungoverned personally identifiable information, PII, inside a cloud platform with broad internal access and unclear legal basis.

That is the real problem with product telemetry and session replay privacy governance. The risk is not that telemetry exists. The risk is that it is treated as low-risk technical exhaust instead of a governed processing activity touching lawful basis, privacy notice, DPIA screening, supplier contracts, masking, access control, retention, incident response and audit evidence.

Under ISO/IEC 27701:2025, organizations need a Privacy Information Management System, PIMS, that treats privacy as an operating model. Under GDPR, controllers must demonstrate compliance with principles such as lawfulness, fairness, transparency, purpose limitation, data minimization, storage limitation, integrity, confidentiality and accountability. Session replay and product telemetry sit directly in that accountability zone because they often monitor how identifiable people behave inside a digital service.

Clarysec’s approach is to pull telemetry out of the shadows and place it into a traceable governance chain: inventory, role classification, lawful basis, DPIA screening, privacy notice, supplier assessment, masking, retention, access control, evidence and continuous review. That chain is supported by the Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec’s PIMS policies, and Zenith Controls: The Cross-Compliance Guide Zenith Controls.

Why product telemetry is not just analytics under GDPR

GDPR defines personal data broadly, including online identifiers and information relating to an identified or identifiable natural person. It also defines processing broadly, covering collection, storage, use, disclosure, erasure and destruction. Product telemetry can therefore become personal data processing when it includes, links to, or can reasonably be associated with users, tenants, administrators, employees or customer end users.

Common telemetry data points include:

• User IDs, email addresses, tenant IDs and account IDs
• IP addresses, device identifiers, browser fingerprints and mobile advertising IDs
• Feature usage, click paths, scroll depth, form interaction and error behavior
• Crash dumps, route names, API payload fragments and diagnostic logs
• Session replay recordings, DOM snapshots, keystroke events and heatmaps
• Support metadata, screenshots, screen recordings and user feedback
• Performance events linked to account, role, geography or customer segment

The privacy issue deepens when telemetry reveals behavior. GDPR Article 3 can apply even to non-EU SaaS providers where they offer goods or services to individuals in the Union or monitor their behavior within the Union. Session replay, heatmaps and product analytics are often behavioral monitoring in ordinary language, even when the business purpose is product improvement rather than advertising.

GDPR Article 6 requires a lawful basis for each processing purpose. Consent may be appropriate where tracking is optional, intrusive or governed by local ePrivacy rules. Legitimate interests may be possible for limited telemetry, but only after assessing necessity, proportionality and the rights and freedoms of individuals. Contract may support telemetry that is strictly necessary to provide the service, but not every product optimization or replay use case fits comfortably under contract.

Special-category risk also matters. GDPR Article 9 restricts processing of data revealing health, biometric, political, religious or other sensitive categories. Many SaaS vendors assume they do not collect this data, then discover that customers paste it into support forms, workflow fields, notes, HR records, legal matter descriptions, medical claims or screenshots captured by replay tools.

Clarysec’s Enterprise Data Protection and Privacy Policy Data Protection and Privacy Policy makes lawful basis and minimization explicit:

All processing shall be based on a valid legal ground (e.g., consent, contract, legal obligation).

From section ‘Policy Implementation Requirements’, policy clause 6.1.1.

Only data necessary for a specific, legitimate business purpose may be collected and processed.

From section ‘Policy Implementation Requirements’, policy clause 6.2.1.

For smaller teams, the Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME requires inventory discipline:

The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods

From section ‘Governance Requirements’, policy clause 5.2.1.

It also gives product and engineering teams a clear privacy-by-design baseline:

Privacy by design and by default must be enforced in all new systems and services.

From section ‘Governance Requirements’, policy clause 5.3.1.

The governance correction is simple: do not ask whether telemetry is “analytics.” Ask whether it is a processing activity involving PII, behavioral monitoring, profiling, supplier access, retention and security controls.

Start with role clarity under ISO 27701:2025

ISO/IEC 27701:2025 privacy governance works best when organizations first define their role. Are you acting as a PII controller, deciding why session replay is used and what data is captured? Are you a processor, capturing telemetry on behalf of a customer under documented instructions? Are you both, depending on the feature and customer configuration?

Clarysec’s PIMS policy set uses role tags to make this operational. “Both” applies regardless of whether the organization acts as controller or processor. “Controller” applies where the organization determines purposes and means. “Processor” applies where processing is performed on documented instructions.

A SaaS provider may be a controller for telemetry used to improve its own product, detect UX friction or prioritize roadmap decisions. The same provider may be a processor for telemetry captured within a customer-controlled workspace where the customer determines the purpose. In rare cases, joint controllership may arise where both parties jointly determine purposes and means. In other chains, the provider may be a subprocessor handling telemetry for another processor.

The Enterprise PII Processing Inventory and Lawful Basis Policy PII Processing Inventory and Lawful Basis Policy makes the first gate concrete:

[Both] The Process Owner / Business Owner MUST create a REG02 processing inventory record before any new PII processing activity begins.

From section ‘Processing inventory baseline’, policy clause 4.1.1.

For product telemetry, REG02 should not contain a vague “analytics” row. It should separate purposes and data flows.

ISO/IEC 27001:2022 supports this PIMS work by giving the organization structure for context, interested-party requirements, scope, leadership, roles, risk assessment, treatment planning, operational control and externally provided services. The ISMS asks what the assets, risks, owners, controls and evidence are. The PIMS asks what PII is processed, why, under which role, with what rights, safeguards and notices.

Together, they prevent the classic privacy gap where product teams enable tracking faster than governance can classify it.

DPIA triggers: when product insight becomes high-risk processing

Not every telemetry event requires a full DPIA. But session replay and behavioral analytics often require DPIA screening because they can involve systematic monitoring, profiling, large-scale processing, sensitive content, vulnerable users, innovative technology or materially changed processing.

The Privacy Risk Assessment and DPIA Policy Privacy Risk Assessment and DPIA Policy is explicit for controllers:

[Controller] The Process Owner / Business Owner MUST refer processing involving large scale, systematic monitoring, profiling, automated decisions, special category PII, criminal conviction or offence data, vulnerable PII principals, innovative technology, or materially changed processing to the Privacy Lead / PIMS Manager in REG04 before processing begins.

From section ‘DPIA triggers and requirement determination’, policy clause 4.2.2.

A session replay DPIA screening should ask practical questions:

• Does replay capture form input, page content, chat text, uploaded documents or error payloads?
• Does masking happen before data leaves the browser, or only after ingestion?
• Can the tool capture passwords, tokens, secrets, one-time codes or payment fields?
• Are sessions linked to named users, accounts, IP addresses or device identifiers?
• Can employees search replays by user, customer, segment, error, URL or behavior?
• Does the vendor use the data for analytics, AI training, benchmarking or product improvement?
• Are international transfers involved?
• What retention period is configured, and can deletion be enforced by tenant or user?
• Can customers disable replay, configure masking or request deletion?
• Are employees, administrators and customer end users covered by notices?
• Is there a risk of capturing children’s data, health data, financial data or HR data?

The Enterprise Data Protection and Privacy Policy reinforces the high-risk threshold:

Threat modeling and Data Protection Impact Assessments (DPIAs) are mandatory for high-risk processing systems.

From section ‘Policy Implementation Requirements’, policy clause 6.3.4.

An important Clarysec lesson from audits is that session replay risk is not only a privacy issue. It is also a security architecture issue. If DOM snapshots capture bearer tokens, internal IDs, hidden fields or sensitive customer workflows, the organization has created a new high-value data store outside its normal logging, DLP and access review perimeter.

Turn the replay tool into an auditable asset

The fastest way to reduce telemetry risk is to stop treating tools as invisible product plumbing. In the Zenith Blueprint, Risk Management phase, Step 9, “Identifying Assets, Threats, and Vulnerabilities,” Clarysec instructs organizations to inventory assets and record owner, location and classification. It specifically notes that personal data assets should be flagged for GDPR relevance and critical service assets should be noted for potential NIS2 applicability.

The Blueprint frames an information asset as anything of value that could be harmed by a security incident, including information, software, cloud services, services/processes and third-party services. For telemetry governance, each analytics platform, replay vendor, SDK, event pipeline, data lake, dashboard, export and support recording repository becomes an auditable asset.

This connects privacy governance to ISMS evidence. Product, privacy, engineering and audit teams can point to the same record instead of maintaining separate narratives.

Use Zenith Controls as the cross-compliance spine

Clarysec uses Zenith Controls as a cross-compliance guide, not as a replacement for official frameworks. For telemetry and session replay, the central ISO/IEC 27002:2022 themes are privacy and protection of PII, cloud service governance, supplier relationships, data masking, asset inventory, classification, access control and change management.

In Zenith Controls, ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, is the anchor. Its practical foundation is data awareness:

The foundation of this control is data awareness. The organization must know what PII it collects, where it resides, why it is being processed, and who can access it.

From Zenith Blueprint, Controls in Action phase, Step 23, Control 5.34, Privacy and Protection of Personally Identifiable Information.

Zenith Controls maps 5.34 to supporting ISO/IEC 27002:2022 controls such as 5.9 inventory of information and other associated assets, 8.11 data masking, 5.23 information security for use of cloud services, 5.12 classification of information, 5.14 information transfer, 5.15 access control, 5.16 identity management, 5.19 information security in supplier relationships, 5.8 information security in project management and 8.32 change management.

For data masking, Zenith Controls identifies ISO/IEC 27002:2022 control 8.11 as preventive and focused on confidentiality. It also connects masking to 8.3 information access restriction, 8.10 information deletion, 8.12 data leakage prevention, 8.24 use of cryptography and 8.33 test information. This matters because session replay masking cannot be cosmetic. It must be designed, tested and evidenced.

The Data Masking and Pseudonymization Policy-sme Data Masking and Pseudonymization Policy - SME gives a simple rule that also applies to product analytics:

Must not use live personal data in testing, external tools, or analytics unless formally authorized.

From section ‘Roles and Responsibilities’, policy clause 4.4.1.

A practical Clarysec workflow for approving session replay

Imagine the product team wants to enable replay for all failed checkout sessions in a fintech app. The business case is real: abandoned checkout affects revenue and customer satisfaction. The governance question is whether that insight can be collected lawfully, proportionately and securely.

Step 1: Create REG02 before the SDK goes live

Use REG02 under the PII Processing Inventory and Lawful Basis Policy. Record the purpose, data categories, user categories, source, recipients, retention, transfers, system owner, lawful basis and role.

Do not write “analytics.” Write “session replay for failed checkout troubleshooting and conversion improvement.” List specific fields, including user ID, tenant ID, IP address, device ID, click events, page routes, DOM snapshots, masked form fields, error codes and payment flow status.

Step 2: Determine lawful basis

For basic crash diagnostics and aggregated performance metrics, legitimate interests may be defensible if the organization documents necessity, proportionality, safeguards and user expectations. For full session replay, especially on authenticated screens, consent may be clearer where local rules or intrusiveness require it.

A hybrid approach is often more practical: use legitimate interests for limited, non-intrusive, masked telemetry, and require explicit opt-in or tenant-level enablement for session replay. Whatever the answer, it must be documented and reflected in notices, contracts and configuration.

Step 3: Screen for DPIA triggers in REG04

Failed checkout replay may involve financial behavior, authentication, payment screens and systematic monitoring. The Process Owner refers the activity to the Privacy Lead. The screening evaluates necessity, proportionality, individual expectations, masking, access controls, vendor use, retention and alternatives such as aggregated funnel metrics.

The Privacy by Design and Default Policy Privacy by Design and Default Policy requires a specific minimization analysis:

[Both] The Process Owner / Business Owner MUST document de-identification, pseudonymization, aggregation or non-identifiable processing feasibility in REG04 before approving identifiable PII for testing, analytics, reporting or secondary operational use.

From section ‘Data minimization and privacy-default design’, policy clause 4.2.5.

Step 4: Configure privacy defaults before production capture

Engineering should configure the SDK to:

• Disable keystroke capture by default
• Mask all input fields unless expressly approved
• Block replay capture on payment, password, MFA, health, HR or sensitive free-text pages
• Strip tokens, authorization headers and hidden fields
• Replace user ID with a pseudonymous analytics ID where feasible
• Truncate IP addresses or store them separately with restricted access
• Apply short raw replay retention
• Enable tenant-level opt-out where contractually required
• Route access through SSO, MFA and role-based approval
• Enable audit logs for replay viewing, export and deletion

Step 5: Update privacy notice and customer documentation

The Privacy Notice and Transparency Policy Privacy Notice and Transparency Policy requires notice content to be drawn from REG02:

[Controller] The Process Owner / Business Owner MUST include PII categories, PII principal categories, source category where indirect, recipient categories, retention reference, and transfer reference from REG02 in REG07 before submitting a privacy notice for approval.

From section ‘Notice content and transparency information’, policy clause 4.2.3.

The notice should explain product analytics and replay in plain language: what is captured, why it is captured, whether it is optional, who receives it, how long it is retained, where it is transferred and how users can exercise rights.

Step 6: Assess the vendor and contract flow-down

Before procurement, onboarding, renewal or a material feature change, use REG08 under the Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy:

[All] The Process Owner / Business Owner MUST identify each proposed third-party relationship that will process, access, receive, store, transmit, support, or otherwise affect PII in REG08 before procurement, onboarding, renewal, or material third-party privacy change.

From section ‘Relationship identification and classification’, policy clause 4.1.2.

Vendor review should cover data location, subprocessors, encryption, access controls, breach notification, deletion, audit rights, customer data use, AI training exclusions, support access, retention, export controls and incident cooperation.

The Enterprise Data Protection and Privacy Policy also reminds teams:

Contracts with processors shall include:

From section ‘Enforcement and Compliance’, policy clause 8.5.1.

The SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME reinforces that:

Contracts must include mandatory clauses covering:

From section ‘Governance Requirements’, policy clause 5.3.

The audit question is straightforward: can you prove the replay vendor is bound to your privacy, security, retention, deletion, assistance and incident obligations?

Step 7: Evidence the technical controls

In the Zenith Blueprint, Controls in Action phase, Step 19, “Technological Controls I,” Clarysec instructs teams to verify automated deletion and retention, review masking and pseudonymization in testing and analytics, and assess DLP controls.

For replay, retain evidence such as:

• SDK configuration screenshots
• Masking rule definitions
• Test captures showing sensitive fields blocked
• Retention configuration
• Deletion logs
• Access review records
• Vendor DPA and subprocessors list
• Replay viewing audit logs
• DPIA approval or documented screening outcome
• Privacy notice approval

This is what turns privacy by design from a slogan into audit-ready evidence.

Cross-compliance mapping for telemetry governance

Telemetry governance often begins as a GDPR issue, but it rarely stays there.

GDPR Article 5 requires lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, security and accountability. Article 6 requires lawful basis. Article 4 clarifies controller, processor and breach roles. Article 9 raises the bar where special-category data appears in captured content. For session replay, these principles translate into clear notices, minimized capture, masked fields, limited retention, access controls, supplier contracts and DPIA evidence.

NIS2 can become relevant for SaaS, cloud, digital infrastructure, MSP, MSSP and certain digital providers depending on size, sector and service criticality. Article 20 makes cybersecurity governance a management body responsibility. Article 21 requires risk management measures including policies, incident handling, continuity, supply-chain security, secure development, control effectiveness, cyber hygiene, cryptography, HR security, access control and asset management.

DORA applies to many financial entities and creates a sector-specific digital operational resilience regime from 17 January 2025. Its ICT risk management expectations cover governance, asset and dependency mapping, protection, detection, continuity, recovery, training and third-party oversight. For fintech telemetry, DORA-style thinking asks whether replay tools support or affect critical or important functions, whether the vendor is an ICT third-party provider, and whether contracts include audit and incident assistance.

NIST CSF 2.0 adds a practical integration layer. Its GOVERN function requires understanding stakeholders, dependencies, legal, regulatory, contractual and privacy obligations. IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER outcomes map naturally to telemetry assets, data flows, access control, logging, incident triage, containment and recovery.

COBIT 19 auditors, or ISACA-trained assessors using governance principles, will usually ask whether telemetry supports enterprise objectives, whether risk ownership is clear, whether benefits are balanced with risk, whether policies are enforced and whether monitoring demonstrates control performance.

How auditors test the same replay workflow

A privacy auditor starts with REG02, REG04 and REG07. They select a replay activity and ask for the purpose, lawful basis, categories of PII, PII principal categories, recipients, retention, transfers, DPIA screening, notice text and processor agreements. They test whether the actual SDK configuration matches the approved processing record. If the record says input fields are masked, they ask for evidence.

An ISO/IEC 27001:2022 auditor starts with scope, risk assessment, Statement of Applicability, supplier controls and operational evidence. They may connect telemetry to asset inventory, access control, cloud services, supplier relationship management, secure development and incident readiness. If replay was introduced through a product change, they ask whether risk assessment was updated and whether externally provided services were controlled.

A DORA auditor in a fintech context asks whether the telemetry vendor is listed in the ICT third-party register, whether the service supports a critical or important function, whether contracts include locations, data processing regions, incident assistance, audit rights, termination rights, business contingency requirements and transition support.

A NIST CSF assessor starts with the current profile. Is session replay documented as a technology dependency and data processing activity? Is there a target state? Are gaps tracked in a risk register or plan of action? Are supplier requirements expressed in contracts? Are detection and response roles defined if replay data is exposed?

A COBIT 19 or ISACA-style auditor asks whether governance is effective. Did the management system define ownership? Were stakeholders consulted? Is risk accepted at the right level? Are control metrics reviewed? Are exceptions visible to management? Is the product insight worth the privacy and supplier risk?

The value of Zenith Controls is that one replay workflow can be mapped across privacy and security controls without creating disconnected evidence packs. The same masking evidence supports PII protection, data leakage prevention, access restriction and privacy by design. The same supplier review supports cloud governance, processor management, NIS2 supply-chain security and DORA ICT third-party risk. The same inventory supports GDPR accountability, ISO 27701:2025 PIMS records, ISO/IEC 27001:2022 asset management and NIST CSF asset outcomes.

Common findings in telemetry reviews

Telemetry audits usually reveal repeat patterns.

First, the processing inventory says “analytics” but does not distinguish crash reporting, heatmaps, replay, support recordings and AI-based product insights. That makes lawful basis, notice and retention impossible to validate.

Second, masking exists but is not tested. Teams assume the vendor masks passwords, but free-text fields, hidden fields, autocomplete, custom components or mobile screens bypass the rules.

Third, replay access is too broad. Product, engineering, support and customer success all have dashboard access, but there is no business justification, periodic review or audit log review.

Fourth, retention defaults are excessive. Raw session recordings are kept for months because the vendor default was never changed, even though troubleshooting value decays quickly.

Fifth, supplier contracts lag behind usage. The vendor was onboarded as a product analytics tool, but later enabled replay, AI summaries, support integrations or data exports without updated privacy review.

Sixth, privacy notices are generic. They mention analytics but not behavioral replay, device identifiers, recipients, retention or user choices.

Seventh, product changes bypass DPIA screening. New SDK features are enabled through configuration toggles, not procurement, so privacy and security teams never see the change.

The Clarysec fix is not to ban telemetry. It is to build a lightweight but mandatory control gate for telemetry changes.

Practical telemetry governance checklist

Use this checklist before enabling, expanding or renewing product telemetry, mobile analytics, crash reporting, heatmaps or session replay.

Tie the checklist to the Zenith Blueprint steps: Step 9 for asset identification, Step 19 for deletion, masking and DLP evidence, and Step 23 for PII protection in action. Then use Zenith Controls to map ISO/IEC 27002:2022 controls 5.34, 5.23, 5.19, 8.11, 5.15, 5.16, 5.8 and 8.32 so the same evidence supports GDPR, ISO 27701:2025 PIMS, ISO/IEC 27001:2022 ISMS, NIST CSF, NIS2 and DORA conversations.

The board-level message: telemetry is a trust control

Product telemetry gives organizations real value. It helps teams fix broken workflows, improve accessibility, reduce support burden, detect crashes, prioritize engineering work and understand customer outcomes. But session replay can also become a surveillance layer if it is invisible, excessive or poorly secured.

For CISOs and compliance leaders, the message to the board is simple: telemetry is not only a product optimization capability. It is a trust control. If governed well, it improves service quality while respecting privacy. If governed badly, it creates undocumented monitoring, uncontrolled supplier risk and avoidable breach exposure.

NIS2 reinforces management accountability for cybersecurity risk management. DORA makes ICT third-party and resilience governance central for financial entities. GDPR places accountability on the controller. ISO 27701:2025 helps operationalize privacy roles, records, notices, DPIAs and processor governance. ISO/IEC 27001:2022 provides the ISMS engine for risk, ownership, controls and evidence.

Clarysec brings these together through policies, registers, the Zenith Blueprint, and Zenith Controls.

Make your telemetry audit-ready before the next release

If your organization uses product analytics, session replay, crash reporting, heatmaps, mobile telemetry or support screen recordings, start with one question: can you prove what is captured, why, under which lawful basis, for how long, by whom, through which supplier, and with what masking?

Use the Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to inventory telemetry assets, review masking and deletion controls, and assess supplier governance. Use Zenith Controls: The Cross-Compliance Guide Zenith Controls to map privacy, cloud, masking, access and supplier controls across frameworks. Use Clarysec’s PIMS policies, including the PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Privacy by Design and Default Policy, Privacy Notice and Transparency Policy, and Processor, Subprocessor and Third-Party Privacy Management Policy, to make every telemetry workflow traceable.

Before the next SDK toggle goes live, run a telemetry privacy governance review. Your product team will still get insight, but your auditors, customers and users will get something more valuable: evidence of trust.