> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/data-security-documentation/data-security/dlp-harmonization.md).

# DLP Harmonization

{% hint style="warning" %}
**Beta**

This feature is currently in beta.
{% endhint %}

DLP harmonization is the process by which Cortex connects to your DLP providers, extracts their policy configurations, and restructures the provider-specific data into a single normalized schema. These normalized policies are stored in the Cortex Data Inventory as [assets](/data-security-documentation/inventory-and-monitoring/asset-management.md). Because every provider's fields are mapped to the same schema, you can compare, filter, and sort policies from all of them in one inventory through the [Unified Policies page](#the-unified-policies-page).

Cortex currently ingests and normalizes DLP policies from Cortex Endpoint DLP and [Microsoft Purview](https://www.microsoft.com/en-us/security/business/data-security-governance/microsoft-purview-data-security#tabs-pill-bar-ocb9d4_tab3).

Additional providers are planned for future releases.

### The Unified Policies page

The normalized results are presented on the **Unified Policies** page, at **Modules → Data Security → Data Loss Prevention → Unified Policies**. This page is the single inventory of every DLP policy Cortex has ingested.

Cortex maps all ingested policies into a policy and rule model. In this structure:

* Policies act as the overarching containers that group related data protection guidelines.
* Rules are the specific, actionable conditions nested inside a policy that determine exactly what triggers an alert or response.

A single policy can contain multiple rules, and each rule maintains its own individual settings, priorities, and statuses. For example, you can have a fully active policy that contains a mix of active and inactive rules.

The following image shows the Unified Policies page:

<figure><img src="https://3280164297-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHfNuZNmWlqy9Bl7fETmL%2Fuploads%2FuxCBaqVWXJHwsuC0Wfq6%2Fimage.png?alt=media&amp;token=284b6441-15d4-4ae4-833e-c45698d17d14" alt=""><figcaption></figcaption></figure>

Widgets across the top summarize policy counts by status, connected providers, the most common data profiles, and coverage by channel. Teams can use these to analyze operational states and identify coverage gaps.&#x20;

Below them, a table lists every normalized policy, one row per policy, filterable and exportable on any field. The table displays only a default selection of fields as columns; use **Display** to add or remove them. The fields displayed by default give key details about the policy, outlining what it covers, it's activity mode, who last modified it and when, and when it was created and last scanned.

To drill down further, click any policy to view simplified **Overview** and **Configuration** tabs for immediate clarity on policy intent and rule logic.

The **Overview** tab displays more detailed information about the policy, including a description, its audience and exclusions, and its provider piority.

The **Configuration** tab lists the policy's rules in priority order. Expanding a rule shows its detection conditions, which you can read either as a visual AND/OR/NOT tree or as code.

Only policies from connected providers appear in the inventory, and each provider has its own requirements. See [Connecting your DLP providers](#connecting-your-dlp-providers) for details.

The inventory is read-only. Editing a policy through the Unififed Policies Page is not supported. Cortex re-scans each connected provider every 12 hours, picking up new, updated, and deleted policies without user intervention. A policy deleted upstream disappears from the inventory on the next scan. Each row's **Last scanned** field records the most recent successful pull, so check it before treating a row as authoritative for a recent change.&#x20;

### Connecting your DLP providers

Each provider has its own connection method. If you disable a connector, its policies remain in the inventory for 30 days but are no longer updated.&#x20;

#### Cortex Endpoint DLP

Ingesting Endpoint DLP policies is automatic if you have Endpoint DLP policies configured in Cortex.

#### Microsoft Purview

Onboard Purview through the **Microsoft Security Connector** at **Settings → Data Sources**. The wizard walks you through selecting Purview, enabling the Policies Discovery capability, running a generated script in your Azure environment, and entering the resulting credentials. For the full procedure, see the [Microsoft Security](/data-security-documentation/cortex-data-security-data-sources-and-connectors/vendor-specific-data-sources-and-connectors/microsoft/microsoft-security.md) connector documentation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/data-security-documentation/data-security/dlp-harmonization.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
