Many industries and geographies have strict privacy requirements. In most cases, these requirements don't prevent the usage of Session Replay. The right configuration and processes can help you to reach compliance.
This guide describes the privacy-by-default approach to data privacy compliance with Session Replay:
Most businesses today need to comply with multiple laws and regulations with privacy implications. Some are based on geography, others on the industry that a company operates in. A thoughtful strategy and using Dynatrace’s robust privacy tools can enable you to comply with these complex rules.
Session Replay configuration is one element of your overall privacy setup. Our approach to privacy is much broader than Session Replay. Our documentation explains the breadth of configuration options available to you to avoid collection of personal data. Given the close relationship between Real User Monitoring (RUM) and Session Replay, we recommend that you also consult the privacy capabilities for RUM described in our documentation.
Session Replay offers four masking approaches, including the Mask all and Allow list masking modes.
The Mask all masking mode offers the highest level of privacy, where all texts, user input, attribute values, and images are masked out of the box. However, given the breadth of this mode, it can limit the replay experience because it masks content that doesn't contain personal or sensitive data.
The Allow list masking mode offers a good alternative if you prefer a narrower approach: all page content is masked unless you selectively and explicitly unmask it. If necessary, this can be combined with the opt-in mode. As the unmasking is applied on-ingest, any changes only apply to future sessions and cannot be applied retroactively.
Following the privacy-by-default approach, as a first step, establish guidelines to categorize content into allowed content and protected content to help guide configuration of privacy features of the Dynatrace platform.
Allowed content
Content that can be captured is referred to here as allowed content.
This could include:
Protected content
Content that should not be captured is referred to here as protected content.
To decentralize unmasking, add a single entry to the Session Replay recording allow list.
[data-dtrum-allow]
This delegates all unmasking decisions from the central allow list to the page contents. Each HTML element that contains only allowed content can be marked with the attribute data-dtrum-allow
. Its content will then be unmasked and included in Session Replay.
Because these unmasking decisions will be decentralized, they will also be implemented asynchronously. This does not, however, impede the implementation of this approach, as the Allow list masking mode can be implemented before applications have implemented their unmasking decisions.
During the interval after Allow list masking mode is implemented but before applications have implemented their unmasking decisions, Session Replay will provide reduced insight for applications without any elements unmasking. As the unmasking process is completed, however, visibility into the sessions is restored.
Organizations that use a custom component library can simplify the unmasking process by implementing and exposing corresponding unmasking flags and setting meaningful defaults. This reduces effort on the side of the application teams and increases maintainability.
As applications evolve, there is the risk that page content and previously implemented unmasking rules diverge.
If a previously unmasked section of a page is changed to include protected content that now needs to be masked, unmasking needs to be updated accordingly. If it is not updated, this introduces the risk of capturing protected content.
To avoid such cases, implement corresponding quality gates in the release process. These can be implemented by capturing sessions of a new application version in the source stage, and using Session Replay to verify that no protected content is available in the replays.
A new application version should then only be allowed to be promoted to the target stage if no protected content can be located.
The privacy-by-default approach distributes the unmasking process to the application teams.
With no un-masking, all content is masked. This broad masking of session replays can limit the use of those session replays, because no content is visible. If you want to enable viewing some of the content then the application teams need to implement unmasking.
The approach described on this page allows organizations to roll out and configure Session Replay in an environment with strict privacy requirements. Based on Dynatrace's flexible configuration, it uses a privacy-by-default approach that distributes unmasking decisions to teams with the right domain knowledge.