DLP (Data Loss Prevention) is a set of tools and rules that watch an organization's sensitive data while it is being used, sent, or stored, and then warn, block, or log when the data is about to leave the organization without permission. Examples are attaching a file to an email to an outsider, copying it to a USB drive, or uploading it to an outside website. A channel that has grown recently is pasting data into AI chatbots, which is part of Shadow AI (employees using AI tools the organization has not approved). This article is a pair with Data Classification: A Practical How-to Guide, because DLP works best when the organization already knows which data matters.

DLP watches data in three states

The NIST glossary defines DLP, citing CNSSI 4009-2022 (a US glossary for national security systems), as the ability to identify, monitor, and protect data in three states:

  • Data in use: actions on the user's own device, such as copying, printing, or saving to USB
  • Data in motion: actions on the network, such as email and web uploads
  • Data at rest: data in storage, such as file servers and cloud storage
INFOGRAPHIC
DLP watches data in three states
Sensitive data
protect all three states
In use
copy, print, save to USB
In motion
email, web uploads
At rest
file servers, cloud storage

The same definition says DLP works through deep inspection of the content of data together with analysis of the context of each transaction: the originator, the data object, the medium, the timing, and the recipient, managed from one central point. The key point is that DLP decides on both content and context, not just on what kind of file it is. The same file sent to a colleague may pass, while sending it to an unauthorized outside destination may be blocked. Note that the NIST definition above was written to protect national security system information, so commercial products may differ in the details.

INFOGRAPHIC
How DLP decides on each transaction
01
User acts
email, upload, copy
02
Inspect content
is sensitive data present
03
Check context
sender, medium, recipient, time
04
Apply the policy
log, warn, or block

How DLP recognizes sensitive data

Common ways of inspecting content are listed below, summarized from the NIST IR 8496 draft on data classification and from the documentation of one DLP vendor:

  • Keywords: search for words or phrases such as "confidential" or a project code. Simple to understand, but cannot tell how the word is being used
  • Patterns (regular expressions): a way to search text by pattern, such as card numbers, phone numbers, and email addresses
  • Checking the value and the nearby text: one vendor's documentation says it applies validation functions and also looks at text close to the match, to cut wrong matches
  • Machine learning: computers learn from examples that are already classified. It needs enough examples for every class and is complex to set up and manage
  • Classification labels: if the data already carries a label, DLP can use the label as a condition without guessing from the content

The NIST draft also warns that analyzing the content of unstructured data, such as documents and emails, makes its significance hard to interpret. That is why Data Classification: A Practical How-to Guide should be done first or alongside, so DLP has reliable labels to use instead of guessing.

What DLP does on a match, and how strict to start

One vendor's documentation (Microsoft Purview) shows responses that are common in DLP systems, ordered from light to heavy. Other products may use different names and capabilities:

  • Log only: does not interrupt work, but records who did what with which kind of data
  • Warn the user: shows a message that the user may be about to share something they should not
  • Block, but let the user override with a justification: the user can proceed but must state a reason, which is recorded
  • Block outright: no override, for cases that are clearly prohibited
INFOGRAPHIC
Raise strictness one step at a time
1
Log only
see what really happens
2
Warn the user
show a message before sending
3
Block with override
reason required, recorded
4
Block outright
only clearly prohibited cases

That vendor's guide recommends starting in simulation mode (a mode where the policy inspects and reports but does not yet act), reviewing the results, and tuning the conditions until normal work is disturbed as little as possible before full enforcement. It also says business process owners should help decide which behaviors to allow, and that users should be trained alongside. Starting too strict on day one risks blocking normal work and generating more false positives (wrong alerts) than the team can follow.

DLP and NIST SP 800-53 controls

In the NIST SP 800-53 Rev. 5 control catalog (Release 5.2.0), no control is titled DLP, but DLP helps make several controls real. The discussion of control SC-7(10) lists using data loss and data leakage prevention tools among the techniques for preventing exfiltration (unauthorized removal of information from the system). Related controls include:

  • AC-4 Information Flow Enforcement: controls where information may travel, within a system and between systems, as distinct from who may access it
  • SC-7(10) Prevent Exfiltration: prevent information from leaving the system, whether intentional or unintentional, and test for it periodically
  • SI-4(18) Analyze Traffic and Covert Exfiltration: analyze outbound traffic to detect covert exfiltration
  • MP-7 Media Use: restrict or prohibit portable media such as flash drives, and prohibit portable storage devices with no identifiable owner
  • AU-13 Monitoring for Information Disclosure: watch for evidence of unauthorized disclosure of organizational information, for example on public websites or code-sharing platforms
  • PM-12 Insider Threat Program: run an insider threat program with a cross-discipline incident handling team

DLP and Shadow AI

The risks, the policy, and how to offer approved AI tools are covered in What Is Shadow AI? Risks Organizations Can't See and How to Respond, so this article covers only the role of DLP. OWASP (a software-security community that publishes risk lists for AI applications) warns under LLM02:2025 that users may unintentionally provide sensitive data, that the data could later appear in the model's output, and it advises educating users not to enter sensitive information into these tools.

DLP can help in part, in three ways:

  • See data sent to AI websites: if traffic passes an inspection point, such as a web gateway (an intermediary that inspects web access, see SASE and SSE Explained: When Each One Fits) or an organization-controlled browser, DLP can inspect the text and files users send. One vendor's documentation says it has policies covering several consumer AI web apps
  • Warn before sending: a warning at the moment a user is about to paste confidential data teaches at the moment it matters
  • Use classification labels as conditions: for example, do not allow "confidential" data to go to unapproved tools

But DLP has weaknesses worth knowing, or you may wrongly assume you are safe. They are:

  • It cannot inspect what it cannot see: SP 800-53 (SI-4(10)) says organizations balance encrypting traffic for confidentiality against keeping visibility into that traffic for monitoring
  • Off-network and personal devices: using AI from a personal phone or account outside the corporate network may never pass an inspection point
  • Unstructured data is hard to interpret: the NIST draft says unstructured content is hard to interpret, so keyword and number-pattern matching may miss reworded text (the second half is our inference)
  • Lists of AI sites need constant upkeep: if a policy relies on a list of known sites, a new tool that is not on the list can slip through
INFOGRAPHIC
DLP and AI use: what it covers and where the gaps are

Gaps DLP may not see

  • Encrypted traffic it cannot inspect
  • Personal devices and accounts off-network
  • Reworded text or brand-new tools

What DLP covers well

  • AI sites passing the organization's inspection point
  • Data that carries a classification label
  • Clear patterns such as card numbers

So use DLP alongside approved AI tools and staff training, as described in What Is Shadow AI? Risks Organizations Can't See and How to Respond, rather than relying on DLP alone or on bans alone.

Common mistakes

  • Switching on blocking from day one: normal work gets stuck and false alerts flood the team
  • Not knowing where the important data is or how important it is: without classification, DLP must guess from content alone
  • Believing DLP covers every channel: channels that never pass an inspection point, such as personal devices off the network, are not watched
  • No owner for the alerts: alerts arrive but nobody investigates them or tunes the policy
  • Not telling users and not offering a proper way to keep working: users do not understand why they were blocked and may look for ways around it
  • Using DLP instead of access control and encryption: DLP is one more layer of defense, not a substitute for controlling who may access data

Start today

  • Pick the first 3 types of data: for example customer data, source code, and employee data, then name an owner and a level for each
  • Pick 2 starting channels: for example email to outside recipients and uploads to AI websites
  • Start with a logging or simulation policy: give it a period such as 30 days to see what really happens before warning or blocking (30 days is our suggestion, not a standard value)
  • Name who owns the alerts: who investigates, who decides exceptions, and who tunes the policy
  • Tell staff in advance: explain what will be inspected and give a way to request approved AI tools

To see where your organization stands on preventing data leaks, try the self-assessment.

Scope and accuracy

The definition from the NIST glossary was written for national security systems. The SP 800-53 content was read from the OSCAL catalog (a machine-readable data file, the format NIST uses to publish its controls) release 5.2.0. The DLP response methods are summarized from a single vendor's documentation, and other products may differ. This article cites no DLP effectiveness figures because none were verified from a primary source. All information was checked against sources opened on 22 October 2026.

Leaked personal data is also a PDPA matter, covering both protective measures and the 72-hour breach report; see PDPA Security Measures: A Guide for Security Teams.

References and further reading