A data loss prevention (DLP) policy states which data is protected, where it may and may not go, what happens when a rule is broken, and who owns exceptions and reviews. Write it before you configure any tool, and run new rules in monitor mode before you block anything.
What is DLP?
A common definition, from the Committee on National Security Systems glossary as published by NIST, describes a system's ability to identify, monitor and protect data in use (for example endpoint actions), in motion (network actions) and at rest (storage), using deep content inspection and contextual analysis of a transaction, within a centralized management framework. The attributes it lists for context include the originator, the data object, the medium, the timing and the recipient or destination.
That framing gives you a structure for the policy. Three states of data, content plus context, and central management.
What goes in the policy?
Scope: which systems, users and data types the policy covers. Start with the data whose loss would hurt most.
Classification: the labels you use, such as public, internal, confidential and restricted, and what each means in practice. A policy without agreed labels cannot be enforced consistently.
Rules: for each class, which channels are allowed. Email to external addresses, cloud storage, removable media, printing, messaging apps, uploads to web services, copy to personal devices.
Actions: monitor, warn the user, require a justification, block, or quarantine. Different actions for different risks.
Detection methods: patterns such as card or national ID numbers, exact data matching against a known list, labels, file fingerprints and context like destination.
Exceptions: who may approve them, for how long, and how they are recorded.
Roles: policy owner, data owners, incident handlers, and the people who review alerts.
Privacy and legal: what you monitor, how you tell staff, and what local law permits. Monitoring employee communications is regulated in many places, so involve legal counsel and HR.
Review: how often rules are tuned and how effectiveness is measured.
A constructed example
An HR team keeps a spreadsheet of salary data. The policy classifies it as restricted. Rules: it may be stored only in the HR shared drive, may be emailed only to named HR addresses, may not be uploaded to personal cloud storage, and may not be copied to removable media.
In month one every rule runs in monitor mode. The team finds two things: a payroll vendor legitimately receives a weekly export, and a manager forwards a copy to a private mailbox to work from home. The vendor gets an approved exception tied to a fixed address. The private forwarding gets a warning message with a link to the approved remote access method.
Blocking on day one would have stopped payroll and angered the vendor. Monitoring first showed which flows were real.
How to check or apply this
- Pick the three data types you most need to protect and write the policy for those only.
- Map where each travels today. Interview owners and check logs, not just diagrams.
- Define labels and who assigns them. Prefer automatic labeling where accurate, with user override and logging.
- Write channel rules and actions for each label.
- Turn rules on in monitor mode for several weeks and read the results.
- Tune rules to cut false positives, then move the clearest ones to warn and block.
- Train staff briefly on what the labels mean and why warnings appear.
- Review exceptions monthly, and the whole policy at least yearly.
- Measure true positives found, false positive rate and time to resolve alerts.
What goes wrong?
Too many rules at once produce alert floods that nobody reads. Pattern-only detection flags test data and invoices. Encrypted traffic and personal devices can hide movement from network controls. And DLP does not stop a determined insider who photographs a screen, so combine it with access limits and training.
DLP is one control among several. Least privilege, logging and clear ownership of data do much of the work upstream.
Quick check
Should DLP block from the first day?
Usually not. Monitor first to learn real data flows, then move accurate rules to warn and block so you do not disrupt legitimate work.
Does a DLP policy cover data in the cloud?
It can, if the policy names cloud services as channels and your tooling can see them. Check which services and upload paths your tools actually cover.
Sources
Last reviewed: 18 October 2026.
