> For the complete documentation index, see [llms.txt](https://helpdesk.augmentt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://helpdesk.augmentt.com/modules/secure/purview/dlp.md).

# DLP

Data Loss Prevention (DLP) policies detect sensitive information — credit card numbers, health records, national ID numbers, or your own custom patterns — moving through or sitting in a tenant's data, and take action when they find it: block sharing, show the user a policy tip, notify an admin, or just log the match for review.

{% hint style="warning" %}
Purview is a separately licensed add-on, not part of the base Secure module. If a client isn't authorized for it, this tab shows a message directing you to contact **<sales@augmentt.com>** instead of the usual controls.
{% endhint %}

You'll find it at **Secure > Purview > DLP**, split into **Policies** and **Templates**.

## The rule model

A DLP policy is a container: it holds one or more **rules**, and it's the rules — not the policy itself — that carry the actual detection logic. Each rule Microsoft returns (and Augmentt displays) is built from:

* **Conditions** — most commonly `ContentContainsSensitiveInformation`, a set of sensitive-information-type matches (each with its own confidence threshold and minimum instance count), but also things like sender/recipient conditions, content size, or an **advanced rule** (a raw JSON condition tree) for logic the simple builder can't express.
* **Actions** — what happens on a match: block access or block external sharing (`BlockAccess` / `BlockAccessScope`), restrict specific permissions (`RestrictAccess`), require an admin override or business justification, generate an incident report (`IncidentReportContent`) to specified recipients, send a policy tip to the user, or simply log the event for simulation.
* **Notifications** — who gets alerted (`GenerateAlert`, `NotifyEmailCustomText`), whether the notified user sees a policy tip and can override it.

Rules are evaluated in **priority** order at the policy level — Microsoft evaluates DLP rules in a strict, tenant-wide priority sequence, and Augmentt's **Policies** list shows and lets you edit that priority directly (move up/down, or to top/bottom).

{% hint style="info" %}
Augmentt does not offer a rule-condition-and-action *builder* — you don't compose a rule from scratch by picking conditions and actions in the UI. Instead, rules travel with the **template**: you either build a template from an existing live policy on a tenant (capturing its rules as-is) or import one, then deploy that template — rules included — to a tenant. Once deployed, selecting a policy in Augmentt opens a detail view showing its full rule set exactly as Microsoft returns it (a read-only JSON view per rule), matching what you'd see in the Purview portal. This mirrors how Retention and Sensitivity Labels work too: Augmentt manages *policies*, not a from-scratch rule/condition editor.
{% endhint %}

## Locations (scope)

At deploy time, a DLP policy is scoped to one or more **workloads**, each with its own inclusion/exclusion model:

| Workload                                                      | Scope shape                                                                                |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Exchange**                                                  | All groups, or specific users/groups (senders and their group membership), with exclusions |
| **SharePoint**                                                | All sites, or specific sites, with exclusions                                              |
| **OneDrive for Business**                                     | All users/groups, or specific users/groups (by who shared), with exclusions                |
| **Teams** (chat and channel messages)                         | All users/groups, or specific users/groups, with exclusions                                |
| **Endpoint devices**                                          | All devices, with exclusions                                                               |
| **Third-party apps** (Defender for Cloud Apps connected apps) | All instances, or specific instances, with exclusions                                      |
| **On-premises repositories** (via scanner)                    | All repositories, or specific repositories, with exclusions                                |
| **Power BI**                                                  | All workspaces, with exclusions                                                            |
| **Managed cloud apps / Applications**                         | Specific Entra-registered apps, all accounts or specific accounts per app, with exclusions |
| **Inline web traffic** (via Edge for Business / SaaS)         | All users/groups, with exclusions                                                          |
| **Microsoft 365 Copilot experiences**                         | All users/groups, with exclusions                                                          |
| **Microsoft 365 Foundry / Application enforcement plane**     | All users/groups, with exclusions                                                          |

A single policy can span multiple workloads at once (e.g., Exchange + SharePoint + OneDrive together), and each workload's inclusion/exclusion sets are independent.

## Creating and deploying a DLP policy

1. From **Templates**, either convert an existing live policy on a tenant into a reusable template, or import one you already have. There's no rule-builder path to a brand-new template — the rule logic always originates from a real Microsoft policy.
2. From **Policies**, deploy a template to the selected tenant, or use the **baseline** deploy option to push it to a group of tenants at once.
3. At deploy time you choose:
   * The **mode** to start in — run it in simulation (with or without user notifications, and optionally auto-turn-on after 15 days if untouched), turn it on immediately, or leave it off.
   * **Locations** — which of the workloads above are in scope, and per-location inclusions/exclusions. Templates lock in *which* workloads were used, but tenant-specific identities (specific users, sites, or app instances) are re-selected fresh per deployment, since a rule about "these three sites" on the source tenant is meaningless on a different tenant.
4. Augmentt validates policy and rule names against what already exists on the target tenant before deploying, since Microsoft requires DLP rule names to be unique across **all** policies in a tenant and will reject a deployment that collides.

**Mode** reflects Microsoft's DLP lifecycle:

* **On** — the policy is enforcing its actions.
* **In simulation (with or without notifications)** — Microsoft evaluates matches without taking action, so you can see what the policy *would* have caught before turning it on. Augmentt shows simulation status (completed, in progress, expired, not completed) and a matched-vs-total item count.
* **Off** — the policy exists but isn't evaluated.

Deployed policies and their rules can be edited and deleted from Augmentt afterward; deleting a policy queues the corresponding removal in Microsoft Purview. The list also shows each policy's sync status with Microsoft (completed / in progress) and last-changed timestamp.

## Default templates

Purview ships with **no built-in DLP policy templates** in Augmentt. Every template comes from either converting a real, already-deployed policy on a connected tenant into a template, or an explicit import — there is no seeded starter library (no "US financial data," "UK PII," etc. templates pre-populated for you to deploy on day one). This matches how Retention and Sensitivity Label templates work.

{% hint style="info" %}
Separately, Augmentt's **Aware alerting** does ship a set of default alert types keyed to Microsoft's own out-of-the-box DLP alert policies from the Security & Compliance center — for example alerts for US financial data, US and UK PII, and ID-number matches. These are alert *definitions* Augmentt can notify on when Microsoft's built-in DLP alert policies fire; they are not Augmentt-managed DLP policy templates and don't appear under Purview > DLP > Templates.
{% endhint %}

## Fleet view

Switching to **All Companies** on the DLP tab shows every connected tenant with a simple status per tenant — loading, a policy count, empty, or an integration error — so you can scan for DLP coverage gaps across your whole client base before drilling into any one tenant. Because Microsoft has no single cross-tenant Purview API, this is one request per connected tenant rather than a combined call, so a slow or failing tenant never blocks the others from loading.

## How deployment actually works

Everything you create or change here is applied to the customer's tenant through Microsoft's **Security & Compliance PowerShell** cmdlets (the same plane behind the Purview compliance portal), not the Microsoft Graph API. Augmentt queues the change as a background task against the tenant and polls it to completion — the same task-based pattern used elsewhere in Secure.

## Posture-check resolution

There is **no dedicated DLP entry in Compliance Audit today**. Checking the platform's posture-check registry (`SECURE_CHECK_TYPES` and its numeric mapping) confirms this directly: the only DLP-adjacent entry is a *deprecated, commented-out* `DATA_LOSS_PREVENTION` check that Microsoft/CSP no longer supports — it isn't scored. Nothing else references DLP, and there's no compliance-audit item that reads "DLP policy configured" or similar. If a client isn't authorized for Purview, or hasn't deployed any DLP policy, Compliance Audit won't flag it either way.

Put plainly: DLP posture in a tenant is not currently reflected in the client's compliance score. It's worth knowing what a well-configured DLP policy is protecting against anyway, since you may be asked to justify deploying one even though it won't move a score:

* **Unintentional data exfiltration** — an employee emailing a spreadsheet full of credit card numbers to a personal address, or dragging a folder of client SSNs into a public SharePoint link, without any malicious intent. A DLP rule with a block or policy-tip action catches this at the moment of the mistake.
* **Regulatory exposure** — PCI-DSS, HIPAA, and similar regimes expect an organization to demonstrate active controls over where regulated data (cardholder data, PHI) can flow. A DLP policy tuned to the relevant sensitive-information types is often the concrete evidence an auditor wants to see.
* **Silent, ongoing leakage** — without DLP, sensitive data moving through email, Teams, or endpoint devices generates no signal at all. Even a simulation-mode policy (no blocking, just logging) turns that blind spot into visibility, which is often the first useful step for an MSP assessing a new client.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://helpdesk.augmentt.com/modules/secure/purview/dlp.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.