Personal data captured by Dynatrace
- Latest Dynatrace
- 12-min read
From monitored environments, Dynatrace may capture end-user data, potentially including personal and confidential information about your end users.
This page identifies where personal data may be captured and how you can limit the capture, storage, and display thereof to help you comply with privacy-related legal requirements, including the California Consumer Privacy Act (CCPA; California, United States), General Data Protection Regulation (GDPR; European Union), or Lei Geral de Proteção de Dados (LGPD; Brazil).
Dynatrace masks data according to our three levels of data protection: at capture, at storage, and at display. In the following sections, icons indicate the level of masking applied to each data type that Dynatrace captures.
| Captured by default |
| Not captured by default |
| Masked |
| Not masked |
| Masking preferences can be configured; masked by default |
| Masking preferences can be configured; not masked by default |
| Masking is dependent on the configuration set during capture and storage |
| Masking preferences are set according to end-user permission |
Service request monitoring
Dynatrace captures the most important data points of incoming requests as well as the web requests of end-users of your application (that is, service requests). URLs, client IPs, and certain HTTP header fields are captured automatically.
You can configure global privacy settings to mask client IP addresses, URIs, and HTTP post parameters.
Configure masking via the Mask end-user IP addresses and GPS coordinates option in the data privacy settings.
Configure masking at capture via the OneAgent-side masking option and masking at storage via the Mask personal data in URIs option in the data privacy settings.
Only certain headers are captured automatically. You can capture other headers via request attributes.
Query parameters are always masked on display and can also be masked upon storage. To capture parameters explicitly, configure request attributes.
To avoid capturing certain exceptions, go to 
Settings > Collect and capture > Distributed tracing > Deep monitoring, expand the Exclude noisy and unnecessary exceptions section, and add the required exclusion rules.
Literals that are part of the WHERE clause of an SQL statement are replaced with *****, for example, WHERE userId = '*********'.
Bind variables support is available for database monitoring. To learn how to start capturing SQL bind values, see Data collected with Dynatrace database monitoring. SQL bind values are replaced with *****. Only users who have permission to view a specific entity or management zone can view unmasked bind values within that entity or zone.
Configure via request attributes.
OpenTelemetry attributes for distributed tracing
Dynatrace automatically captures all OpenTracing and OpenTelemetry attributes, but it only stores attributes that are not blocked. See Enable the OpenTelemetry Span Sensor for OneAgent.
| Data type | Default | Masking at capture | Masking at storage | Masking at display |
|---|---|---|---|---|
Non-blocked attributes |
|
|
|
|
Real User Monitoring (RUM) and Session Replay
For the personal data that RUM and Session Replay capture, and how to mask it, see RUM data privacy and compliance.
Log Monitoring
Log Monitoring is an optional feature that is enabled by default. You can use it to directly access the log content of all your system's mission-critical processes, search for specific log messages, and store all logs centrally.
Log files can include user names, email addresses, URL parameters, and other information that you might not want to disclose. By default, nothing is masked, but Log Monitoring offers the ability to mask sensitive information in the logs. You define the masking rules, so any data can be replaced with an SHA-1 hash or a fixed phrase, for example, *****, #######, MASKED, or Last name.
| Data type | Masking at Dynatrace log processing | Masking at OneAgent configuration |
|---|---|---|
Log file content |
|
|
OneAgent diagnostics
OneAgent diagnostics is an optional feature that enables you to collect and analyze support archives for anomalies.
Support archives are created by Dynatrace OneAgent and contain OneAgent log and configuration files as well as specific data from monitored hosts and processes, for example, process names and identification numbers. OneAgent log files may contain personal data, for example, as part of a stack trace.
To comply with regional data protection and privacy regulations, Dynatrace does the following:
-
Masks some personal data before storing a support archive in Cassandra and uploading it to an AWS S3 bucket. For example, IBANs and URI credentials are replaced with
<masked>. However, some personal data may not be masked. -
Writes audit log messages when support archives are created, analyzed, accessed, and deleted to ensure transparency in the use of support archives.
-
Provides access to OneAgent support archives only to users that have the View sensitive request data environment permission.
-
Automatically deletes all diagnostic data 30 days after its collection.
This applies to the data in your Dynatrace environment. You can also choose to delete collected diagnostic data earlier.
| Data type | Masking at capture | Masking at storage | Masking at display |
|---|---|---|---|
OneAgent log and config files |
|
|
|
Live Debugger
Live Debugger is an optional feature. To make it available, enable Live Debugger on your OneAgents. You can use Live Debugger to debug your services and applications in any environment in real time without stopping your applications.
Live Debugger collects snapshots that can include variable values that your application processes. You can define masking rules, so any data can be replaced with an SHA-1 hash or a fixed phrase, for example, *****, #######, MASKED, or Last name. Masking is performed by the agent on your server, so sensitive data will not leave your server or network.