> 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/cortex-xsiam/protect-your-endpoints/endpoint-dlp/best-practices.md). # Best Practices The following guidelines are best practices for creating a DLP workflow to optimize DLP design and performance. Whether you are starting or building a new rule, we recommend reviewing these recommendations carefully so your DLP plan has a clear, logical flow and runs correctly and efficiently. When defining a data-in-motion rule, start with a couple of endpoints to verify that the rule you created is working before implementing it for a wider audience.
Use clear rule names and descriptions Describe rules clearly. Rules should be clear to someone not familiar with the DLP workflow. This applies to rule names and the rule description. When naming a data-in-motion rule, the guideline should be that users can understand what the rule does by reading the rule name alone, without needing to open the rule to view its details. | Clear | Unclear | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | | Block files classified as PII to Google Drive | Block PII file | |

Note

A good example would be to add the description from the Raised Issue Name of the specific Data-in-Motion rule.

Block uploads to social networks

| Block social network |
Select the appropriate action Choosing to BLOCK a source will prevent it from reaching its destination. Be sure to consider the consequences before you decide to BLOCK or ALLOW. You can always use the REPORT action before to test that the rule is properly configured to identify the correct conditions and data.
Consider the source, destination, and data scope If no source is defined, you must select the data scope. The data scope defines the data profile, which constitutes sensitive data for your organization and applies to both files and tables. The source refers to the data we want to protect. When selecting the source, select the web application from which the file originated. The DLP process inspects data as it's being transmitted and takes action based on the policy. | Endpoint type | Setting | Example | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Source | Custom web application group |

Add a custom web application (should be configured before creating the rule) called Sensitive sources , which contains the following URLs:

Note

When adding a source, it becomes a mandatory requirement that must be met for the rule to trigger. You should only apply this setting if you want the rule to take action exclusively when files originate from those specific locations.

| | Destination | | | | Data scope | Data profiles | Financial | Example 143. Process example: Block files originating from the internal company portal (source) that are moving to the web application WhatsApp web (destination).
Refer to HITS in the data-in-motion table to understand the impact of the rules **HITS** show the number of raised issues. This only appears when the BLOCK or REPORT action rules are matched. Refer to **Modules** → **Data Security** → **Data Security Issues** → **Threats**, to view the details of the alert or incident that the DLP system has flagged. The issue is raised when a user action or system event matches the conditions of the data-in-motion rule. ![HITS\_DLP\_screen.png](/files/jNGNDmiVsQOocnwbk3lM) A raised issue from DLP is an alert triggered by a DLP system. This alert indicates that someone has performed an action that violates a policy designed to protect sensitive data. The DLP system automatically detects a policy violation, such as a user trying to download a document containing credit card information from Google Drive. This raises an issue. The issue includes details about the user, the type of data involved, and the action that was attempted. Depending on the policy, the system might block the action, prompt the user with details on why it was blocked, and allow them to override the action or to add justification, or simply log and send the event to the XDR DLP console. Security teams then investigate these issues to determine if the activity was malicious, accidental, or a legitimate business need.
Verify Endpoint DLP settings Go to **Modules** → **Data Security** → **Endpoint Data-in-Motion Rules** → **Endpoint DLP Settings** to configure the tenant settings for DLP. DLP rule/s can override the **End User Dialog** settings with more specific definitions and texts.
--- # 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://cortex-docs.paloaltonetworks.com/cortex-xsiam/protect-your-endpoints/endpoint-dlp/best-practices.md?ask=&goal= ``` `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.