Product guide

DLP Policies

Build DLP policies from matching rules, channels, target scope, exceptions, and an enforcement action.

What a Policy Is#

A DLP policy is the unit of enforcement. It says what to look for, where to look, who it applies to, and what happens on a match. Everything else in the DLP module - incidents, exceptions, reporting - is a consequence of policies.

Keep policies narrow and single-purpose. One policy that protects customer records on USB is easier to tune, review, and explain than one policy that tries to cover every channel and every data type.

Moftgate DLP policies screen — DLP policies, protected channels, and rule distribution view.

Creating a Policy#

1
Start in audit mode
Create the policy with the action set to audit. This records matches without stopping the user, which is what you need to measure false positives.
2
Attach matching rules
Select the classifications and patterns that describe the content you are protecting. Reuse existing rules instead of writing new ones where possible.
3
Enable only the needed channels
Each channel adds inspection work on the endpoint. Enable the channels the policy actually requires.
4
Set a narrow target scope
Apply the policy to a small pilot group first. Expand the scope only after the incident list looks accurate.
5
Review, then enforce
Read the incidents produced by the pilot, add exceptions where needed, and only then change the action to block.

Matching Rules#

A policy is made of seven parts. Each one can be changed without rebuilding the others:

Part	What it does
Name and description	How the policy appears in the list and in every incident it produces.
Matching rules	The classification and pattern rules that decide whether content is sensitive.
Channels	Which of the protected channels this policy inspects: USB, web, email, clipboard, screenshot, printing.
Target scope	Groups, profiles, tags, or individual endpoints the policy applies to.
Exceptions	Users, groups, or processes that are excluded so a legitimate workflow is not blocked.
Action	Audit or block, plus the message shown to the user when a match occurs.
State	Enabled or disabled. A disabled policy keeps its configuration but inspects nothing.

Reuse classification rules

Share matching rules between policies so that a change to a classification is reflected everywhere it is used.

Target Scope and Exceptions#

Target scope is expressed as groups, profiles, tags, or individual endpoints - never as a free-text device name.
Exceptions are more precise than scope changes. Add an exception for the workflow that needs it instead of removing endpoints from the policy.
Review exceptions periodically. An exception added for a project tends to outlive the project.
When a policy produces repeated false positives on one team, the rule is usually wrong, not the team.

Frequently Asked Questions#

Should I block immediately?

No. Start in audit mode. Blocking a policy that has not been reviewed produces false positives that users cannot work around and that erode trust in the platform.

Can two policies match the same content?

Yes, and both incidents are recorded. Overlapping policies are useful during a migration, but they should be consolidated once the target scope is stable.

How do I handle a legitimate exception?

Add an exception for the specific user, group, or process rather than disabling the policy or widening the scope. Exceptions are visible and can be reviewed later.

What does the user see?

In audit mode, nothing. In block mode, the user sees the message you configured for the policy, so write it as an instruction rather than as an error.