---
title: Data Access Control
description: Define a Restricted Dataset for access control
breadcrumbs: Docs > Account Management > Access Control > Data Access Control
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Data Access Control

## Overview{% #overview %}

Your data in Datadog may contain sensitive data, and should be handled carefully. If you are ingesting sensitive data into Datadog, Data Access Control enables administrators and access managers within a Datadog organization to regulate access to this data. Use Data Access Control to identify sensitive data with a query and restrict access to only specific [Teams](https://docs.datadoghq.com/account_management/teams.md) or [Roles](https://docs.datadoghq.com/account_management/rbac.md?tab=datadogapplication#role-based-access-control).

When you define a *Restricted Dataset*, any data within the boundary of that dataset is restricted. Data outside of any Restricted Dataset remains unrestricted and accessible to users with appropriate permissions. Data Access Control provides an intuitive interface that allows access managers to grant only permitted users access to sensitive data enclosed within the datasets.

## Prerequisites{% #prerequisites %}

### Configure access controls{% #configure-access-controls %}

Data Access Control builds on your organization's existing Datadog access control configuration. Set up [Access Controls](https://docs.datadoghq.com/account_management/rbac.md) first before configuring Data Access Control.

### Tag incoming data{% #tag-incoming-data %}

Data Access Control relies on tags and attributes in your data that can be used to define an access boundary. If you do not have tags defined, consider [Getting Started with Tags](https://docs.datadoghq.com/getting_started/tagging.md) before configuring Data Access Control.

## Configure data access{% #configure-data-access %}

Data Access Control allows you to create a Restricted Dataset, specifying data that only users in designated teams or roles can access.

To view all of your Restricted Datasets, navigate to [Organization Settings](https://app.datadoghq.com/organization-settings/), and select [Data Access Control](https://app.datadoghq.com/organization-settings/data-access-controls/) on the left, under the Access heading.

### Datadog site{% #datadog-site %}

Log in as a user assigned the Datadog Admin role, or any user with a role in your organization with the [`user_access_manage` permission](https://docs.datadoghq.com/account_management/rbac/permissions.md#access-management).

1. Navigate to [Organization Settings](https://app.datadoghq.com/organization-settings/).
1. On the left side of the page, select [Data Access Control](https://app.datadoghq.com/organization-settings/data-access-controls/).
1. Click New Restricted Dataset.

In order to create a Restricted Dataset, identify the data to be restricted with a query.

{% image
   source="https://docs.dd-static.net/images/account_management/rbac/restricted_dataset-3.e7ea8f7b5d0ac2cc5b2bd998c014719d.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/account_management/rbac/restricted_dataset-3.e7ea8f7b5d0ac2cc5b2bd998c014719d.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Create a Restricted Dataset dialog. Selects data in RUM, APM, Logs, and Metrics matching the tag service:hr. Grants access to a Privileged access team." /%}

{% dl %}

{% dt %}
Name Dataset
{% /dt %}

{% dd %}
A descriptive name to help users understand what data is contained in the dataset.
{% /dd %}

{% dt %}
Select data to be included in this Dataset
{% /dt %}

{% dd %}
The boundary definition that describes which data to restrict to a specific set of users. Boundaries are query statements with limitations that allow an access manager to define the scope of sensitive data to be protected. The [supported telemetry types](https://docs.datadoghq.com/account_management/rbac/data_access.md#supported-telemetry) are custom metrics, RUM sessions, APM traces, logs, cloud costs, error tracking issues, Software Delivery repository info (CI Visibility pipelines), Workload Protection Agent Events, and security signals (Cloud SIEM signals only).
{% /dd %}

{% dt %}
Grant access
{% /dt %}

{% dd %}
Select one or more teams or roles that may access the content bound in the Restricted Dataset. Any users who are not members of these groups are blocked from accessing this data.
{% /dd %}

{% /dl %}

**Note:** A maximum of 50 principals (roles or teams) can be tied to a given Restricted Dataset.

You may create a maximum of 10 key:value pairs per Restricted Dataset. Consider defining an additional Restricted Dataset if you need additional pairs.

After completing all the fields to define the dataset, click Create Restricted Dataset to apply it to your organization.

You can create up to 100 Restricted Datasets on the Enterprise plan and up to 10 on other plans. Enterprise customers that set a telemetry type to Restricted can create up to 1,000 Restricted Datasets.

### Supported telemetry types{% #supported-telemetry %}

- Agent Observability traces, Experiments, Datasets, and Annotation Queues
- APM traces
- Cloud costs
- Custom metrics
  - **Note:** Standard metrics are not supported
- Error Tracking issues
- Logs
- RUM sessions
- Security signals (Cloud SIEM and Workload Protection signals )
- Software Delivery repository info (in CI Visibility pipelines)
- Workload Protection Agent Events

The following are available as a Preview upon request:

- Database Monitoring
- Hosts
- Processes
- Containers
- Security findings (Cloud Security, Code Security, Workload Protection, and App and API Protection findings)
- Serverless

## Advanced configuration{% #advanced-configuration %}

### Data not in a Restricted Dataset{% #strict-mode %}

Each telemetry type has a setting that controls who can view data outside a Restricted Dataset. This setting appears in the Data not in dataset column of the Data Restrictions table.

{% dl %}

{% dt %}
Unrestricted (default)
{% /dt %}

{% dd %}
Data that is not in a Restricted Dataset, and untagged data, are visible to all users with appropriate permissions.
{% /dd %}

{% dt %}
Restricted
{% /dt %}

{% dd %}
Data outside a Restricted Dataset is visible only to users with explicit access. Users can view data for that telemetry type only if they have access to a Restricted Dataset or have unrestricted access.
{% /dd %}

{% /dl %}

The Restricted setting helps protect sensitive data when:

- Inconsistent telemetry tagging could leave sensitive records visible under the Unrestricted setting.
- New tag values are added frequently, and you cannot guarantee that an existing Restricted Dataset matches every new value.
- Compliance posture requires a default-deny stance for a telemetry type.

A telemetry type must have at least one Restricted Dataset before you can set it to Restricted. This prevents unintentional loss of access. If you delete all Restricted Datasets for a telemetry type set to Restricted, only teams and roles with unrestricted access retain access. To restore access for other users, grant them access through a new Restricted Dataset or set the telemetry type back to Unrestricted.

Restricted Datasets cannot be shared between the Unrestricted and Restricted settings. Each dataset belongs to one setting.

**Before you set a telemetry type to Restricted**, identify any data for that telemetry type that is *not* in a Restricted Dataset. After you save the change, that data is hidden from users without unrestricted access. Review the Restricted Datasets table on the [Data Access Control](https://app.datadoghq.com/organization-settings/data-access-controls/) page to confirm coverage.

To change the setting for a telemetry type, you must have the [`user_access_manage` permission](https://docs.datadoghq.com/account_management/rbac/permissions.md#access-management).

1. Navigate to [Data Access Control](https://app.datadoghq.com/organization-settings/data-access-controls/).
1. In the Data Restrictions table, hover over the row for the telemetry type, and click the edit (pencil) icon.
1. Under the heading for data not in Restricted Datasets (for example, Logs data not in Restricted Datasets), select Unrestricted or Restricted.
1. Click Save.

### Unrestricted access{% #unrestricted-user-groups %}

Some users, such as high-privilege admins or central observability teams with access to data across the entire organization, need full visibility into a telemetry type regardless of any Restricted Datasets. Rather than adding these users to every Restricted Dataset individually, you can grant their team or role *unrestricted access* for a specific telemetry type.

A team or role with unrestricted access for a telemetry type sees all data for that telemetry type, regardless of Restricted Dataset boundaries or the setting for data not in a Restricted Dataset. Unrestricted access is granted to teams or roles (not individual users) and is configured per telemetry type. For example, a role can have unrestricted access to Logs without affecting access to RUM.

To grant unrestricted access, open the edit dialog for the telemetry type as described in Data not in a Restricted Dataset. Add the teams or roles to the unrestricted access field (for example, Roles and Teams with unrestricted access to all Logs data), and click Save. The Unrestricted Access column of the Data Restrictions table lists these teams and roles.

Unrestricted access pairs especially well with the Restricted setting because it lets designated admins keep working without being added to every dataset.

**Note:** Other access control methods (such as [Logs Restriction Queries](https://docs.datadoghq.com/logs/guide/logs-rbac.md?tab=ui#restrict-access-to-logs) and [Permissions](https://docs.datadoghq.com/account_management/rbac.md)) still apply to teams and roles with unrestricted access.

## Usage constraints{% #usage-constraints %}

After you turn on Data Access Control, Datadog disables or limits other features to control access to sensitive data. See the list of affected features below to see how they are restricted.

### Real User Monitoring (RUM){% #real-user-monitoring-rum %}

#### Session Replay: Extended Retention{% #session-replay-extended-retention %}

By default, Session Replay data is retained for 30 days. To extend retention to 15 months, you can enable Extended Retention on individual session replays. When you create a restricted dataset for RUM, Datadog disables the option for Extended Retention.

#### Session Replay: Playlists{% #session-replay-playlists %}

Playlists are collections of Session Replays you can aggregate in a folder-like structure. When you create a restricted dataset for RUM, Datadog disables Session Replay Playlists.

### Logs{% #logs %}

Data Access Control is separate from the existing [Logs RBAC permissions](https://docs.datadoghq.com/logs/guide/logs-rbac.md?tab=ui#restrict-access-to-logs) feature, also known as log restriction queries. Datadog recommends using a single solution to restrict logs data. If you limit user access using both Data Access Control and log restriction queries, both sets of restrictions apply.

### Monitors{% #monitors %}

Users can create monitors that query and alert on active telemetry. While the user can only directly query data they're allowed to access, the monitor operates as a system user with full access to data.

If you are concerned about unauthorized data access through monitors, Datadog recommends that you track the monitors your users create. Then, restrict access to the creation of monitors that read sensitive data.

### Software Delivery repository info (CI Visibility pipelines){% #software-delivery-repository-info-ci-visibility-pipelines %}

- **Supported telemetry**: Only CI Visibility pipelines are supported. Test Optimizations tests are not supported.
- **CI Logs**: CI Logs are stored in the Log Management product. To restrict access to CI Logs, create a Logs dataset.
- **Supported dataset tags**: Only the following tags are supported:
  - `@git.repository_url`
  - `@git.repository.id`
  - `@git.repository.id_v2`
  - `@gitlab.groups`

### Agent Observability{% #agent-observability %}

- **Supported telemetry**:
  - Traces, using any tag.
  - Experiments, Datasets, and Annotation Queues, restricted by project. An `ml_app` filter set to a project ID hides that project and its experiments, datasets, dataset records, spans, evaluation metrics, and annotation queues from list views, search, and direct links. An annotation queue that does not belong to a project cannot be restricted. See [Data Access Control in Agent Observability](https://docs.datadoghq.com/llm_observability/improve/access_control.md).
- **Not supported**: Managed prompts.
- **OpenTelemetry**: When using [OpenTelemetry instrumentation](https://docs.datadoghq.com/llm_observability/instrument/otel_instrumentation.md), some data sent to Agent Observability may also be written to APM traces, as well as metrics and monitors. If you are protecting sensitive data with a Restricted Dataset on Agent Observability, consider also configuring Restricted Datasets on APM, metrics, or monitors with matching data boundaries.

## Select tags for access{% #select-tags-for-access %}

Each Restricted Dataset can control access to multiple types of data, such as metrics. You are free to use the same or different tags across multiple types of telemetry. Within each telemetry type, you must use a *single* tag or attribute to define your access strategy.

If you have too many combinations of tags or attributes to fit within these constraints, consider [revisiting your tagging](https://docs.datadoghq.com/getting_started/tagging.md) to define a new tag that better reflects your access strategy.

### Supported example{% #supported-example %}

#### Restricted Dataset 1{% #restricted-dataset-1 %}

- Telemetry Type: RUM
  - Filters: `@application.id:ABCD`

#### Restricted Dataset 2{% #restricted-dataset-2 %}

- Telemetry type: RUM
  - Filters: `@application.id:EFGH`
- Telemetry type: Custom Metrics
  - Filters: `env:prod`

### Not supported example{% #not-supported-example %}

#### Restricted Dataset 1:{% #restricted-dataset-1-1 %}

- Telemetry type: RUM
  - Filters: `@application.id:ABCD`

#### Restricted Dataset 2:{% #restricted-dataset-2-1 %}

- Telemetry type: RUM
  - Filters: `env:prod`

Restricted Dataset 1 uses `@application.id` as the tag for RUM data, so a new Restricted Dataset can't change to a different tag. Instead, consider reconfiguring Restricted Dataset 2 to use `@application.id`, or changing all of your Restricted Datasets with RUM data to use another tag.

### Not supported example{% #not-supported-example-1 %}

#### Restricted Dataset 1:{% #restricted-dataset-1-2 %}

- Telemetry type: RUM
  - Filters: `@application.id:ABCD`

#### Restricted Dataset 2:{% #restricted-dataset-2-2 %}

- Telemetry type: RUM
  - Filters: `@application.id:IJKL` `env:prod`

This example correctly uses the `@application.id` tag for RUM, as was done for Restricted Dataset 1. However, the limit is one tag per telemetry type. Instead, consider creating a Restricted Dataset with *either* `application.id` or `env`, or identify a different tag that better combines these attributes.

## Best practices{% #best-practices %}

### Access strategy{% #access-strategy %}

Before configuring Data Access Control, it's important to evaluate your access strategy. Consider reviewing [Reducing Data Related Risks](https://docs.datadoghq.com/data_security.md) as you consider your access strategy. Removing or reducing unnecessary or sensitive data before it reaches Datadog reduces the need for additional access setup.

#### Protecting known sensitive data{% #protecting-known-sensitive-data %}

If you have already identified which data needs to be protected, you can build your Data Access Control configuration around only this specific data. This ensures that non-sensitive data is generally available to your users, allowing them to collaborate and understand ongoing issues or incidents.

For example, if you have a single application that is instrumented with Real User Monitoring (RUM) and captures sensitive inputs from users, consider creating a Restricted Dataset only for that application:

- Name dataset: Restricted RUM data
- Select data to be included in this Dataset:
  - Telemetry type: RUM
    - Filters: `@application.id:<rum-app-id>`
- Grant access:
  - Teams or roles of users who can see this RUM data

This configuration example would protect the RUM data from this application, and keep other data from this application available to existing users in your organization.

#### Protecting all data from a service{% #protecting-all-data-from-a-service %}

If you are instead looking to protect data from a specific service, you can build your Data Access Control configuration around the `service:` tag.

For example, if you have a service `NewService` that is instrumented with Real User Monitoring (RUM) and capturing sensitive inputs from users, consider creating a Restricted Dataset only for that application:

- Name Dataset: Restricted NewService data
- Select data to be included in this Dataset:
  - Telemetry type: RUM
    - Filters: `@service:NewService`
  - Telemetry type: Custom Metrics
    - Filters: `@service:NewService`
  - Telemetry type: APM
    - Filters: `@service:NewService`
  - Telemetry type: Logs
    - Filters: `@service:NewService`
- Grant access:
  - Team who owns the service

This configuration example protects all supported data from `NewService`.

### Teams and roles{% #teams-and-roles %}

Data Access Control supports granting access to users through Datadog roles or teams. When granting access, consider your existing access control configuration and access strategy. If you are pursuing a service-based approach and are already [customizing the Catalog](https://docs.datadoghq.com/internal_developer_portal/catalog/set_up.md), take advantage of the service ownership model by using Teams as part of your Data Access Control configuration.

**Note:** Teams used for Data Access Control must be configured such that adding or removing users can only be done by team members or an administrator, not `Anyone in the organization`.

## Access enforcement{% #access-enforcement %}

Users in a Datadog organization with Data Access Control enabled can only see query results for data to which they have access, such as in a Dashboard, in an Explorer, or through the API. A Restricted Dataset removes access to the data defined in the Restricted Dataset for users who are not permitted, across all Datadog experiences and entry points.

### Data explorers{% #data-explorers %}

When exploring Datadog with restrictions enabled, users without permissions can still browse the list of asset names (applications or metrics), but they cannot see query results, top tags, or facet details restricted by datasets. For instance, querying a metric with restricted data returns a blank graph, making it appear as if the query does not match any data.

### Dashboards and Notebooks{% #dashboards-and-notebooks %}

Similar to exploring data in a data explorer like the RUM Explorer or Metrics Explorer, viewing data in dashboards in an organization that has Restricted Datasets enabled only shows the data the user can access. Since dashboards are shared objects that can be accessed by others, it is possible for two users who have different access to view the same dashboard or notebook at the same time and see different data.

**Note**: Viewers of [Shared Dashboards](https://docs.datadoghq.com/dashboards/sharing/shared_dashboards.md) see all telemetry data displayed in the Dashboard in accordance to the creator's permissions. Review your dashboard content before sharing to ensure no sensitive or confidential data is exposed.

### APIs{% #apis %}

When querying data through Datadog APIs with restrictions enabled, users without permissions do **not** see query results that have been restricted by Restricted Datasets.

## Further reading{% #further-reading %}

Additional helpful documentation, links, and articles:

- [Reducing Data Related Risks](https://docs.datadoghq.com/data_security.md)