Netskope Global Technical Success (GTS)
Netskope DLP – Building Effective DLP Rules in Netskope
Netskope Cloud Version - 127
Introduction
This article explains how to create and configure DLP Rules in Netskope.provides
DLP Rules define how sensitive data is detected based on previously created Entities, and control the conditions, logic, and severity under which detections are triggered.
Rules form the heart of Netskope DLP — without them, Entities alone cannot inspect or enforce anything.
This document breaks down each part of a DLP Rule, with configuration guidance, use cases, and practical examples.
What is a DLP Rule?
A DLP Rule connects one or more Entities to a specific set of detection behaviors. It defines how data is matched, where it is inspected (content vs metadata), how many matches are required to trigger detection, and what severity should be assigned.
Rules are then added into DLP Profiles, which are later applied to traffic via DLP Policies.
Core Components of a DLP Rule
1. Entity Selection
| What It Is | Why It Matters | Examples / Best Practices |
| Defines which data types the rule should inspect for. You can choose: - Predefined Data Identifiers - Custom or Predefined Dictionaries - Both (multiple entities in one rule) | Entities determine what kind of sensitive content Netskope should detect. | Example: Detect both SSNs and internal keywords like "Project Orion". Best Practice: Group related entities (e.g., all financial identifiers) to keep rules organized. |
2. Exact Match (Fingerprinting)
| What It Is | Why It Matters | Examples / Best Practices |
| This feature allows detection of exact values from structured datasets or sensitive documents you’ve previously fingerprinted, like employee IDs or customer lists. | It provides highly accurate detection with minimal false positives. Only the data you've explicitly uploaded for fingerprinting will trigger alerts, which makes it ideal for confidential or regulated datasets. | Example: Upload a list of customer account numbers; rule triggers only if one of those exact numbers is found. Important: The dataset must be uploaded and configured beforehand under Policies > DLP > Exact Match. Best Practice: Use for sensitive structured data like payroll files, CRM exports, or PII dumps. |
3. Advanced Options
| What It Is | Why It Matters | Examples / Best Practices |
| Lets you define how entities should appear in content to trigger a match. Includes Boolean logic (AND/OR), proximity (words must appear close together), and match count thresholds. | These refinements help you reduce false positives and tune rules for realistic business scenarios. By using these options, your rules can better mimic how sensitive data is actually used or leaked. | Examples: - Match if both "confidential" AND "proposal" are present - Trigger only if 5 or more sensitive keywords are found - Detect "bank" within 15 words of "account number" Best Practice: Use logical conditions for more precise detection, especially in rules using broad or custom dictionaries. |
4. Content Inspection
| What It Is | Why It Matters | Examples / Best Practices |
| Controls whether Netskope scans the actual content (like body text), metadata (like filenames or authors), or both. You can select one depending on your inspection goal. | Targeting the appropriate part of the data object helps reduce unnecessary scanning and improves efficiency. It also ensures relevant data is inspected, depending on where sensitive terms are likely to be found. | Use Cases: - Metadata Only: Detect filenames like “payroll_q1.pdf” - Content Only: Scan contents of emails or files - Content and Metadata: For full-scope inspection Best Practice: Match scanning mode to the data type — for example, use metadata scanning for files where content isn’t relevant but filenames are. |
5. Severity and Match Threshold
| What It Is | Why It Matters | Examples / Best Practices |
| Severity classifies how critical the rule is (Low, Medium, High), while the Match Threshold sets the number of matches needed to trigger the rule. These settings control alert sensitivity. | Proper use of severity helps with triaging alerts and managing incident response, while match thresholds prevent minor or partial matches from triggering alerts unnecessarily. | Examples: - High Severity: Trigger on 10+ credit card numbers - Low Severity: Trigger on 1–2 internal terms in chat Best Practice: Use High severity for regulated data (like PCI or HIPAA), and increase match thresholds for keyword-heavy rules to reduce noise. |
Best Practices for DLP Rules
- Avoid overloading a single rule with unrelated Entities
- Use multiple focused rules rather than one broad one for better tuning and analytics
- Regularly review rules to reflect changes in business processes, regulations, or terminology
- Document what each rule is intended to catch, for long-term maintainability
What’s Next?
Once DLP Rules are created, they must be added to a DLP Profile, which groups them and defines additional filtering options like file types and sizes.
Terms and Conditions
- All documented information undergoes testing and verification to ensure accuracy.
- In the future, it is possible that the application's functionality may be altered by the vendor. If any such changes are brought to our attention, we will promptly update the documentation to reflect them.
Notes
- This article is authored by Netskope Global Technical Success (GTS).
- For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.
