Compliance Requirements

Due to wiretapping & privacy laws in certain jurisdictions, it is essential to ensure that our session recording practices comply with local regulations. Below are the key compliance requirements we need to adhere to when using LogRocket for recording user sessions and activities,

Overview

LogRocket captures two categories of data:

Session Recordings (DOM capture): Visual replay of user interactions, mouse movements, clicks, and page changes
Technical Data: Network requests, console logs, JavaScript errors, performance metrics, and custom events

Key Requirements

Application Types

LogRocket session recording requirements differ based on the application type:

Aspect	Borrower-Facing (e.g., ECC)	Non-Borrower-Facing (e.g., EncompassWeb, TPO)
OneTrust Banner	For obtaining user consent	For transparency/disclosure only
Consent Required	Yes - C0002 (init), C0003 (recording)	No - shown for informational purposes
Session Recording	Enabled only with C0003 consent	Always enabled by default
User Opt-Out	✅ Can opt-out via OneTrust	❌ Cannot opt-out
Target Users	Consumers/borrowers	Professional/business users

Rationale for non-borrower-facing: Professional applications require continuous session recording for technical troubleshooting, security monitoring, user experience optimization, and compliance requirements.

Feature	With C0002 Only	With C0002 + C0003	Without C0002
LogRocket Init	✅ Initialized	✅ Initialized	❌ Not Initialized
Session Recording (DOM)	❌ Disabled	✅ Enabled	❌ Not Available
Visual Replay	❌ Not Available	✅ Available	❌ Not Available
Mouse Movements	❌ Not Captured	✅ Captured	❌ Not Captured
Clicks & Interactions	❌ Not Captured	✅ Captured	❌ Not Captured
Page Changes	❌ Not Captured	✅ Captured	❌ Not Captured
Network Requests	✅ Captured	✅ Captured	❌ Not Captured
Console Logs	✅ Captured	✅ Captured	❌ Not Captured
JavaScript Errors	✅ Captured	✅ Captured	❌ Not Captured
Performance Metrics	✅ Captured	✅ Captured	❌ Not Captured
Custom Events	✅ Captured	✅ Captured	❌ Not Captured

Data Minimization: Only log data that is necessary for the intended purpose.
Anonymization: Implement multiple anonymization strategies:
- Input sanitization using 'lipsum' method to replace user input with placeholder text
- Text sanitization enabled by default to protect sensitive text content
- Hidden ARIA attributes (aria-label, aria-labelledby, aria-describedby, etc.) to protect accessibility-related PII
- Request and response body sanitization to remove sensitive data
- Custom sanitizers for URLs, network requests, and responses
- Support for masking specific elements and attributes

Implementation

Both application types display the OneTrust cookie banner with different purposes:

Borrower-facing (ECC): Banner obtains user consent before enabling LogRocket
Non-borrower-facing (EncompassWeb, TPO): Banner informs users about session recording (transparency only)

Sample OneTrust based cookie banner

Sample Cookie Choices

Priority Order:

Manual override (dangerouslyOverrideSessionRecordingConsent === true) — force ON only. Setting the override to false does not force-disable; it falls through to the normal sources below.
OneTrust consent groups (C0003)
Current window URL parameter (analyticsConsent)
Iframe src URL parameter (analyticsConsent) - Legacy support for AngularJS microapps
Default (no consent) - Lowest priority

OneTrust Integration Details

Integration Setup (Shell Microapp Only)

OneTrust SDK must be integrated using Google Tag Manager as a custom HTML tag:

Set window.hasOneTrust flag: The application's shell microapp must set window.hasOneTrust = true before loading Google Tag Manager
```
// In shell microapp - set before GTM loads
window.hasOneTrust = true;
```
Set appEnv Data Layer variable: Push the application environment to the Data Layer before GTM loads
```
// In shell microapp - set before GTM loads
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  appEnv: 'production', // or 'development', 'staging', 'qa', etc.
});
```
This variable is used in GTM to load envvironment specific OneTrust SDK.

Note: React boilerplate based shell microapp to set the window.gtmDataLayer variable in global.js file.
Configure OneTrust in Google Tag Manager: Add OneTrust SDK as a custom HTML tag in GTM with the following steps:

a. Setup Variables
1. Create a JavaScript Variable for OneTrust flag:
- Go to your GTM workspace
- Click "Variables" → "User-Defined Variables" → "New"
- Name it "js-hasOneTrust"
- Variable Type: Select "JavaScript Variable"
- Global Variable Name: hasOneTrust
- Format Value: Check "Convert undefined to false"
- Click "Save"
1. Create a Data Layer Variable for application environment:
- Go to your GTM workspace
- Click "Variables" → "User-Defined Variables" → "New"
- Name it "dlv-appEnv"
- Variable Type: Select "Data Layer Variable"
- Data Layer Variable Name: appEnv
- Data Layer Version: Select "Version 2"
- Default Value: localhost
- Click "Save"
1. Create a Data Layer Variable for OneTrust consent groups:
- Go to your GTM workspace
- Click "Variables" → "User-Defined Variables" → "New"
- Name it "dlv-OnetrustActiveGroups"
- Variable Type: Select "Data Layer Variable"
- Data Layer Variable Name: OnetrustActiveGroups
- Data Layer Version: Select "Version 2"
- Click "Save"
b. Set up triggers:
1. Custom-EnableOneTrust-d1 trigger:
  - Click "Triggers" → "New"
  - Name it "Custom-EnableOneTrust-d1"
  - Trigger Type: Select "Initialization"
  - This trigger fires on: "Some Initialization Events"
  - Fire this trigger when: js-hasOneTrust equals true and dlv-appEnv matches RegEx ^(d1|localhost)$
  - Click "Save"
2. Custom-EnableOneTrust-q1 trigger:
  - Click "Triggers" → "New"
  - Name it "Custom-EnableOneTrust-q1"
  - Trigger Type: Select "Initialization"
  - This trigger fires on: "Some Initialization Events"
  - Fire this trigger when: js-hasOneTrust equals true and dlv-appEnv equals q1
  - Click "Save" Note: Similary create triggers for other environments like i1,pl1,s1,uat1 & pr etc.
3. Custom-EnableGA trigger:
  - Click "Triggers" → "New"
  - Name it "Custom-EnableGA"
  - Trigger Type: Select "Initialization"
  - This trigger fires on: "Some Initialization Events"
  - Fire this trigger when: js-hasOneTrust equals false
  - Click "Save"
4. (C0002) Activate Performance trigger:
  - Click "Triggers" → "New"
  - Name it "(C0002) Activate Performance"
  - Trigger Type: Select "Custom Event"
  - Event name: OneTrustGroupsUpdated
  - Use regex matching: Check this option
  - This trigger fires on: "Some Custom Events"
  - Fire this trigger when: dlv-OnetrustActiveGroups matches RegEx ,C0002,
  - Click "Save"
c. Create tags:
1. OneTrust-Load-d1 tag:
  - Go to your GTM workspace
  - Click "Tags" → "New"
  - Name it "OneTrust-Load-d1"
  - Tag Type: Select "Custom HTML"
  - Borrower-facing applications (e.g., ECC): Paste the OneTrust SDK script with consent control enabled (see docs/onetrust-borrower-facing.html for reference template)
  - Non-borrower-facing applications (e.g., EncompassWeb, TPO): Paste the OneTrust SDK script with transparency-only mode (see docs/onetrust-non-borrower-facing.html for reference template)
  - Advanced Settings → Enable "Support document.write"
  - Firing Triggers: Select "Custom-EnableOneTrust-d1"
2. OneTrust-Load-q1 tag:
  - Go to your GTM workspace
  - Click "Tags" → "New"
  - Name it "OneTrust-Load-q1"
  - Tag Type: Select "Custom HTML"
  - Borrower-facing applications (e.g., ECC): Paste the OneTrust SDK script with consent control enabled (see docs/onetrust-borrower-facing.html for reference template)
  - Non-borrower-facing applications (e.g., EncompassWeb, TPO): Paste the OneTrust SDK script with transparency-only mode (see docs/onetrust-non-borrower-facing.html for reference template)
  - Advanced Settings → Enable "Support document.write"
  - Firing Triggers: Select "Custom-EnableOneTrust-q1"
3. GA4-Config-Load tag:
  - if this tag exists, edit it to change the trigger to (C0002) Activate Performance & Custom-EnableGA triggers created above.
  - save the tag.
d. Test the integration:
- Check whether OneTrust banner appears as expected
- Verify that LogRocket initializes and session recording starts only after user consents
g. Publish the changes:
- Submit the workspace
- Add version name/description
- Publish to select environments
Important: The OneTrust script must be added via GTM, not directly in the HTML, to ensure proper consent management and integration with other GTM tags.

Data Sanitization in Session Recordings

To protect user privacy during session recording, the following sanitization measures are enforced:

Input Sanitization

All form inputs are sanitized using the 'lipsum' method, which replaces actual user input with placeholder text. This prevents:

Password fields from being recorded
Credit card numbers from appearing in recordings
Personal information entered in forms from being captured

Text Content Sanitization

Text sanitization is enabled by default (textSanitizer: true) to protect sensitive information displayed on the page. This automatically sanitizes:

Text content in HTML elements
Dynamically generated text that may contain PII
Text nodes that could reveal sensitive user data

Hidden Attributes

The following ARIA attributes are hidden from session recordings to prevent accessibility-related PII exposure:

aria-label
aria-labelledby
aria-describedby
aria-details
aria-errormessage
aria-valuetext
aria-placeholder

URL Sanitization

Sensitive URL parameters are automatically redacted:

Authorization codes: The standalone code query parameter is redacted to code=REDACTED (does not affect parameters like zipcode or promo_code)
All occurrences of the code parameter in the URL are redacted
Custom patterns can be added via the browser.urlSanitizer configuration

Network Sanitization

Network requests and responses are sanitized to prevent sensitive data leakage:

Request headers: Authorization headers are replaced with **redacted** (case-insensitive matching)
Request bodies: All request bodies are set to null by default
Response bodies: All response bodies are removed by default
Custom headers: Headers like x-secret trigger complete response removal

Testing and Development

For development testing only, session recording consent can be force-enabled using window.emui.dangerouslyOverrideSessionRecordingConsent

window.emui = window.emui || {};
window.emui.dangerouslyOverrideSessionRecordingConsent = true;

Critical Warnings:

⚠️ This variable is for development testing ONLY
⚠️ NEVER use in production - this bypasses user consent
⚠️ A warning will be logged when this override is active
⚠️ Only === true overrides consent. Setting it to false (or leaving it unset) is not a force-disable — the library falls through to OneTrust / analyticsConsent URL parameter / iframe src parameter, which can still grant consent on their own.

Use cases: Testing session recording behavior without configuring OneTrust, or forcing recording on/off during local development.

Localhost Development

For local development on localhost, LogRocket is disabled by default. You can enable it using either:

Environment Variable: Set LOGROCKET_ENABLE_ON_LOCALHOST=true in your .env file
Configuration Flag: Set window.emui.logRocketConfig.localhostEnable = true before calling initLogRocket

LogRocket will be enabled on localhost if either the environment variable or the configuration flag is set to true.

Compliance Checklist

Common Requirements (All Applications)

Input sanitization verified (all forms use 'lipsum' method)
Text sanitization enabled (textSanitizer: true is set)
URL sanitization tested for sensitive parameters
Network request/response sanitization confirmed
ARIA attribute hiding validated
Cross-domain session tracking tested for multi-microapp scenarios (if applicable)

Borrower-Facing Specific (e.g., ECC)

Confirmed application is borrower-facing (consumer-facing)
OneTrust integration configured with C0002 and C0003 for consent control
Verified OneTrust banner obtains user consent
Verified C0002 required for LogRocket initialization
Verified C0003 required for session recording (DOM capture)
Verified users can opt-out via OneTrust cookie preferences
User consent flows tested (accept, decline, change preferences)
Verified LogRocket does NOT initialize without C0002
Verified LogRocket initializes with C0002 but disables DOM without C0003

Non-Borrower-Facing Specific (e.g., EncompassWeb, TPO)

Confirmed application is non-borrower-facing (professional/business user tool)
OneTrust banner configured for transparency/disclosure only
Verified OneTrust banner does NOT control LogRocket behavior
Verified session recording always enabled (dom.isEnabled: true)
Confirmed LogRocket initializes regardless of consent state
Verified users CANNOT opt-out of session recording
Users informed about continuous session recording in terms of service

Overview​

Key Requirements​

Application Types​

Consent Matrix (Borrower-Facing Applications)​

Implementation​

Cookie Banner with OneTrust​

User Journey: First Visit (No Prior Consent)​

User Journey: Returning Visit (Consent Previously Given)​

Consent Check Hierarchy​

OneTrust Integration Details​

Integration Setup (Shell Microapp Only)​

Data Sanitization in Session Recordings​

Input Sanitization​

Text Content Sanitization​

Hidden Attributes​

URL Sanitization​

Network Sanitization​

Testing and Development​

Localhost Development​

Compliance Checklist​

Common Requirements (All Applications)​

Borrower-Facing Specific (e.g., ECC)​

Non-Borrower-Facing Specific (e.g., EncompassWeb, TPO)​