Privacy Rights

Latest Dynatrace

Privacy Rights empowers you to address and manage customer requests related to their data subject rights under applicable data protection laws (for example, GDPR and CCPA/CPRA).

The built-in workflows provide a straightforward method to search for data associated with end users. You can then review the retrieved personal data and make informed decisions about exporting it. The system also allows you to track and follow up on these requests through the request dashboard. Each step is documented with an audit trail to ensure compliance with your obligations. Privacy Rights only supports the export of logs. With deleteion/cleanup workflows you can make informed decisions about deletion or export.

Privacy Rights only supports export, deletion, and cleanup of logs from Grail.

To install Privacy Rights, find Privacy Rights in Dynatrace Hub Hub and select Install.

Export requests

To obtain a personal data export, you need to fill in a request export form.

In the request, specify:

User details such as user type. This can be an end user (your customer) or an employee.
A user identifier such as an email address, IP address, or a custom user ID.
The Grail search scope (timeframe and log buckets).

Best practices

To limit the scope of requests:

Use the shortest possible timeframe and select relevant buckets only.
Make sure you aren't exporting personal data of other individuals or confidential data.
Use policies to help ensure that your organization’s policies regarding personal data exports are followed.

Policies map policy requirements to DQL that can be applied to refine the export query. For example, if you have a financial_logs bucket and your organizational policy is that this should never be included in personal data exports, you can create an export policy | filter dt.system.bucket != “financial_logs” and apply this to all export requests by default. Policies map policy requirements to DQL that can be applied to refine the export query. For example, if you have a financial_logs bucket and your organizational policy is that this should never be included in personal data exports, you can create an export policy | filter dt.system.bucket != “financial_logs” and apply this to all export requests by default.
Consider the number of logs you export/delete. The higher the number, the more difficult it is to review the data.

Audit log

Privacy Rights ingests log entries as audit logs. This allows you to audit and download historical actions, such as request creation, request approval, and policy creation.

By default, audit logs go to the default_logs bucket. To change this, you can assign your logs to a privacy_audit bucket. This is a custom bucket that needs to be created manually, and the name is not configurable. You can customize the retention period to suit your needs and restrict access to the bucket using IAM policies.

You also need to manually set up a bucket assignment rule. To do this, go to Settings > Log Monitoring > Bucket assignment. Ensure that the rule has higher priority than any other rules that might assign the app’s logs to a different bucket, such as Audit logs.

If no audit logs are visible and the privacy_audit bucket does not exist, there may be a bucket assignment rule that assigns the app’s audit logs to a different bucket than default_logs. In such cases, add an assignment rule that assigns the audit logs to default_logs and sets its priority higher than other rules.

Policies

With Privacy Rights, you can also create and manage request policies to enrich or filter request results, for example, to prevent the deletion of audit logs and compliance records.

When creating a policy, you can define its conditions using DQL. We suggest the following:

Use the parse command to extract personal data fields from your logs, such as a profile ID or IP address
Use the filter command to exclude data that should not be deleted, such as audit logs or compliance records.

Create a service user

Privacy Rights uses a service user to process approved deletion and cleanup requests in the background when the app is not being used. Before you create a service user, you need to create a policy that will be assigned to the service user.

To create a policy to assign to the service user

In Dynatrace, go to Account Management.
Select Identity & access management > Policy Management.
Select Policy.
Provide a policy name in the Policy name field.
optional In Policy description, provide a description to help other users understand how this policy is used.

In Policy statement, provide the following policy statement:

ALLOW app-engine:apps:run WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW storage:records:delete;
ALLOW storage:fieldsets:read;
ALLOW storage:system:read;
ALLOW storage:logs:read;
ALLOW storage:buckets:read;
ALLOW state:app-states:read;
ALLOW state:app-states:write;
ALLOW email:emails:send;
ALLOW storage:logs:write;

Select Save.

You then need to create the service user.

In Dynatrace, go to Account Management.
Select Identity & access management > Service users.
Select Add service user.
In Name, name the user privacy-rights. The name must match exactly.
optional In Description, explain how the service user is used.
Select Save.

You will see an overview table with all your service users.
In the Actions column, select the > View Service User.
Select Permission.
In the Permission name list, select the policy you created for the service user. If you have multiple environments and only use Privacy Rights in a single environment, restrict the service user to this environment by selecting it in the Scope section.

Grant access with IAM permissions

To use Privacy Rights, you need certain IAM permissions to make sure it functions correctly. You can grant these permissions by assigning them to a group with the following IAM policy: To use Privacy Rights, you need certain IAM permissions to make sure it functions correctly. We recommend you create a Privacy Rights request assignees group to assign all Privacy Rights users to, and a Privacy Rights request reviewers group with additional permissions for reviewers.

You can grant these permissions by assigning them to a group with the following IAM policy:

Privacy rights request assignees

ALLOW app-engine:apps:run WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW state:app-states:read, state:app-states:write, state:app-states:delete WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW email:emails:send;
ALLOW storage:buckets:read;
ALLOW storage:logs:read;
ALLOW storage:fieldsets:read;
ALLOW state:user-app-states:read, state:user-app-states:write, state:user-app-states:delete WHERE shared:app-id = 'dynatrace.privacy.rights';
ALLOW app-engine:functions:run;
ALLOW storage:logs:write;

This policy should be bound to the group as an environment policy. The group should also include the view logs permission for the environment. We recommend restricting app engine and app state permissions to the app ID, unless the user also needs access to other apps. Privacy Rights request reviewers

ALLOW storage:records:delete;
ALLOW iam:service-users:use WHERE iam:service-user-email = "YOUR-SERVICE-USER-EMAIL-HERE";
ALLOW automation:workflows:read;
ALLOW automation:workflows:write;

Each policy should be bound to its group as an environment policy. Replace the placeholder value for iam:service-user-email with the email of your privacy-rights service user.

To find the email of your service user

In Dynatrace, go to Account Management.
Select Identity & access management > Service users.

You will see an overview table with all of your service users.
In the Actions column, select > View Service User.
The email is listed as Service user email in the Details section.

We recommend that you restrict access to the app, app state, and service user to a small group of trusted users. The service user has extensive permissions and could be mistakenly or deliberately abused, for example, to delete a large volume of data. Users with access to the app state may be able to modify requests even if they don't have access to the app UI.

To prevent users from accessing Privacy Rights, you can create a group with the following policy and add all users who shouldn't be able to export, delete, or access the sensitive data in the app to the group.

ALLOW app-engine:apps:run WHERE shared:app-id != 'dynatrace.privacy.rights';
ALLOW state:app-states:read, state:app-states:write, state:app-states:delete WHERE shared:app-id != 'dynatrace.privacy.rights';
DENY app-engine:apps:run WHERE shared:app-id = 'dynatrace.privacy.rights';
DENY state:app-states:read, state:app-states:write, state:app-states:delete WHERE shared:app-id = 'dynatrace.privacy.rights';
DENY iam:service-users:use WHERE iam:service-user-email = "YOUR-SERVICE-USER-EMAIL-HERE";

IAM policies are additive, so make sure that no other policies including the ALLOW app-engine:apps:run or ALLOW state:app-states:{read, write, delete} permissions (such as the default AppEngine - User policy) are active for these users. They should also not be granted state-management:app-states:delete, which would allow them to delete requests or have read access to audit logs in the default_logs or privacy_audit buckets (depending on your chosen audit logging configuration).

Frequently asked questions

If you see a banner informing you that permissions are misconfigured, confirm that:

Permissions are configured correctly for the service user, to learn more see Privacy Rights.
The simple workflow used by the app has not been mistakenly deleted or switched off. Users with the automation:workflows:admin permission can view and edit the workflow in Workflows after enabling admin mode. The workflow should be enabled on a schedule and include the app’s Process deletion requests workflow action.

If you noticed that deletion and cleanup requests in the Approved state don't transition into the Processing state, confirm that:

Permissions are configured correctly for the service user, to learn more see Privacy Rights.
The simple workflow used by the app has not been mistakenly deleted or switched off. Users with the automation:workflows:admin permission can view and edit the workflow in Workflows after enabling admin mode. The workflow should be enabled on a schedule and include the app’s Process deletion requests workflow action.

If any deletion error occurs, then your request transitions into the Failed state. In the request details, further information will be provided for each failed task. Deletion and cleanup requests are processed in one or more tasks that cover specific timeframes. You can assume that deletion has succeeded for any timeframe not listed in the failed tasks. There are four reasons why a deletion task may fail:

Invalid request: the request was not accepted because either it uses DQL that is unsupported for deletion or it matches too many records. No data has been deleted. You can resolve this by creating a new request with a modified query and attempting deletion again for the failed timeframe(s).
Trigger timeout: due to a temporary outage, it was not possible to start deletion and the task timed out. No data has been deleted. We recommend you wait 12 hours or longer, then create a new request for the failed timeframe(s) to attempt deletion again.
Processing timeout: due to a temporary outage during deletion, the task has timed out. Data may have been partially deleted. We recommend you wait 12 hours or longer, then create a new request for the failed timeframe(s) to attempt deletion again.
Internal error: an internal error occurred during deletion. In this unlikely case, data may have been partially deleted for the timeframe. Please contact Support so we can support you in resolving the issue.