Data Loss Prevention (DLP) Guide

Data loss prevention fails far more often through noise and blind spots than through missing technology: policies that alert on every 16-digit number get ignored, and the channels people actually use to move data are never covered. DLP inspects data in motion, at rest and in use, decides whether it is sensitive, and applies an action such as a warning, a block or encryption. Today that has to cover endpoints, web traffic, email, sanctioned and unsanctioned SaaS, and the prompts staff paste into AI assistants. This guide covers detection methods (including exact data match and document fingerprinting), classification and labelling, policy design, rollout in audit mode, tuning false positives and measurement. It is for security engineers, data protection teams and architects deploying or rescuing a DLP programme. Product features are named as worked examples only.

Key takeaways

• Know your data before you write rules. A classification scheme, a data inventory and labels on the most sensitive content make every later DLP rule more precise.
• Exact matching beats patterns for high-value data. Exact data match (EDM) and document fingerprinting detect your actual customer records and templates, with far fewer false positives than regular expressions.
• Cover the channels data really leaves by. Endpoint, web, email, SaaS sharing and AI prompts each need a control point; one strong channel just moves the leak to a weaker one.
• Deploy in audit mode, coach, then block. Run every new policy in simulation, move to policy tips with override and justification, and block only patterns you have tuned.
• Do not forget non-human paths. API tokens, service accounts and OAuth integrations can pull data in bulk without touching a monitored endpoint.

How DLP detects sensitive data

Every DLP engine combines content inspection (what the data is) with context (who, where, how much, to where). Detection methods differ sharply in precision.

Exact data match and fingerprinting in practice

• EDM: in Microsoft Purview, you upload a sensitive information source table (rows of records, columns of fields), hashed with a salt so that "only the hashed values are uploaded". A primary element (for example an account number) must be detectable by an existing pattern; supporting elements such as surname or date of birth found within a defined proximity raise confidence. The table can hold up to 100 million rows and be refreshed daily. This is the main tool for banks and insurers wanting to detect real customer data, not anything that looks like an account number.
• Fingerprinting: Purview's document fingerprinting converts a standard form into a hash of its word pattern; the original is not stored. Partial matching can be set between 30% and 90% of the text, or to Exact. It does not detect password-protected files, image-only files, or files larger than 4 MB, and a tenant can hold roughly 100 fingerprints. Other products call the wider capability indexed document matching (IDM), which fingerprints whole document sets rather than templates.
• Cloud data stores: Google Cloud Sensitive Data Protection (formerly Cloud DLP) separates a discovery service that builds data profiles across an organisation, folder or project from an inspection service for deep scans of one resource, and offers transformations such as masking, redaction, bucketing, date shifting and tokenisation for de-identification. See the Privacy-Enhancing Technologies Guide.

Classification and labelling first

CIS Controls v8.1 puts data inventory (3.2) and a data classification scheme (3.7) well before deploying a DLP solution (3.13). Without them, DLP rules guess.

• Keep the scheme short: four levels (for example Public, Internal, Confidential, Highly Confidential) are easier to apply consistently than eight. Map each level to handling rules and DLP actions.
• Label priority: in Purview, label order sets priority, with the most restrictive label at the bottom of the list, and only one sensitivity label can be applied to an item.
• Defaults and mandatory labelling: a default label raises coverage, but Microsoft advises that "It's usually not a good idea to select a label that applies encryption as a default label to documents", and that mandatory labelling without a default label "can frustrate your users with the frequent prompts".
• Auto-labelling: apply or recommend labels automatically using the same detection methods as DLP, so that labels and DLP rules reinforce each other.
• Persistence: labels are stored in file and email metadata, so "the label stays with the content", and because the metadata is clear text, third-party services such as a CASB can read it and act on it.
• Visible markings: labels can add headers, footers and document watermarks, which tell recipients how to handle content and deter casual forwarding.

Data discovery and the record of where personal data lives come from the same effort. See the Data Mapping and ROPA Guide.

DLP channels: endpoint, network, email, cloud and AI

Endpoint DLP

Microsoft Purview Endpoint DLP is a representative feature set: it can audit or restrict upload to restricted cloud service domains, access from unallowed browsers (uploads are redirected to a supported browser), paste to supported browsers, copy to clipboard, copy to USB removable devices, copy to network shares, print, copy over unallowed Bluetooth apps and copy over RDP. Most activities support audit, warn and block. Device control (blocking or read-only mounting of removable media by device class or serial number) usually sits alongside it in the endpoint platform. See the Endpoint Security Guide.

Screen capture and screen watermarking

Screen capture and photographs of screens are the hardest channel to control. Some endpoint agents, enterprise browsers and virtual desktop platforms can block screenshot tools for labelled content or overlay a user-specific visible watermark (user name, time) on the screen. A watermark does not stop capture, but it deters it and makes a leaked image attributable. Use it for high-risk workspaces such as deal rooms and customer data consoles. See the Enterprise Browser and Browser Security Guide.

Email DLP

Email DLP rules work best on attachments with labels or EDM matches sent to external domains. Pair them with detection of mailbox forwarding rules to external addresses (ATT&CK T1114.003 Email Forwarding Rule), a common quiet exfiltration path. See the Email Security Guide.

Cloud, SaaS and AI

API-mode CASB scanning finds sensitive files already shared publicly or with external users; inline mode stops uploads as they happen. Purview, for example, lists locations for Exchange, SharePoint, OneDrive, Teams, devices, on-premises repositories, Power BI, connected non-Microsoft apps such as Box, Dropbox, Google Workspace and Salesforce, Microsoft 365 Copilot, and inline web traffic to services including ChatGPT, Gemini and DeepSeek. OWASP's LLM02:2025 Sensitive Information Disclosure tells organisations to "Provide guidance on avoiding the input of sensitive information" into models. The Samsung ChatGPT source code leak began with staff pasting code into a public AI tool. See the Shadow AI Discovery Guide and the Enterprise AI Copilot Security Guide.

Designing DLP policies

Microsoft's guidance is to write a policy intent statement first: you "should be able to summarize, in a single statement, the business intent for every policy". For example: detect documents containing customer records stored in collaboration sites and stop them being shared with external users or uploaded to personal cloud storage. Then map the statement to five choices: what to monitor, scope (users and groups), locations, conditions and actions. Conditions and actions together form a rule.

• Thresholds: set confidence level and instance count (Microsoft calls the count "leakage tolerance"). One card number in an email signature is not ten thousand in a spreadsheet; use separate rules for low and high volumes.
• Graduated actions: audit only, then a policy tip that warns the user, then block with override and a recorded business justification, then block. Reserve hard blocks for high-confidence, high-volume or highest-label matches.
• Destination context: distinguish internal, partner domains and personal destinations. Allow sanctioned tenants of cloud storage and block personal ones of the same service.
• Exceptions as logic, not loopholes: Purview's rule builder supports AND, OR, NOT and nested groups. Express exceptions (for example HR sending payroll files to the payroll provider) as narrow NOT conditions with an owner and review date.
• Risk-adaptive rules: some platforms let DLP strictness follow user risk. Purview Adaptive Protection passes insider risk levels (Elevated, Moderate, Minor) into DLP conditions for Exchange, devices and Teams, so a user in a risky state gets stricter enforcement. Agree the governance for this with HR and privacy first. See the Insider Threat and Identity Guide.

The thresholds in this table are illustrative starting points to tune, not recommendations.

Rolling out DLP without breaking the business

1. Agree ownership: data owners decide what is sensitive and who handles alerts for their data; security runs the platform; privacy and HR agree how user-level alerts are used.
2. Discover and label: scan repositories, build EDM tables and fingerprints for the crown jewels, and roll out labelling with defaults.
3. Run in simulation: deploy every new policy in audit or simulation mode. In Purview, "Actions defined in a policy aren't applied while the policy is in simulation mode." Run for at least two business cycles (for example month-end) so legitimate flows appear.
4. Review and tune: sample matches, measure the false positive rate per rule, and adjust thresholds, exceptions and detection methods.
5. Coach in pilot rings: switch on policy tips for a pilot group (IT and security first, then one business unit). Microsoft suggests using policy tips "to raise awareness with your users before changing the policy status from simulation mode to more restrictive modes".
6. Enforce gradually: move tuned rules to block with override, then block, ring by ring. Announce changes before they happen.
7. Keep a rollback path: version every policy, record who changed what, and be able to return a rule to simulation the same day when it disrupts a business process. Allow for propagation delay: Purview, for example, says policies take effect about an hour after being turned on.

Choosing an approach

• Small organisations: start with the DLP built into the productivity suite and email service, plus device control on endpoints. Labels on a handful of document types and two or three policies give most of the value.
• Large or regulated organisations: add EDM for customer data, SSE or CASB for unsanctioned SaaS and AI, network DLP for egress points, and a case management workflow integrated with the SIEM.
• Suite-native versus standalone: suite-native DLP reads labels and covers its own services well; standalone or SSE platforms cover more third-party channels. Many organisations run both, and must then avoid duplicate alerts and conflicting actions.
• API versus inline CASB: API mode is easier to deploy and covers data at rest; inline mode can block in real time but needs traffic steering and TLS inspection.

Tuning false positives

• Replace patterns with exact data: move the noisiest pattern rules to EDM or fingerprints for the data you actually hold.
• Require corroboration: combine a pattern with keywords or supporting fields within proximity, and raise the confidence level required for blocking.
• Raise instance counts for blocking: keep low counts for audit only.
• Exclude known-good flows narrowly: test data sets, payroll provider domains, sanctioned tenants. Review exceptions quarterly.
• Use override justifications as feedback: recurring legitimate justifications show a rule that needs changing; recurring vague ones show a user who needs a conversation.
• Tune fingerprint thresholds: higher partial-match percentages reduce false positives but, as Microsoft notes, "might result in more false negatives".

Where identity fits

DLP is built around a human at a device. Bulk data theft increasingly uses identities that never touch a monitored endpoint.

• API tokens and service accounts: a stolen API key or service account credential can export a CRM or data warehouse directly (ATT&CK T1213.004 Customer Relationship Management Software, T1530 Data from Cloud Storage). Monitor per-identity data volume in SaaS audit logs and alert on export spikes. See the API Key Management Guide.
• OAuth integrations: in the Salesloft Drift breach, OAuth tokens held by a chatbot integration were stolen and used to access Salesforce data across hundreds of customer organisations. See the SaaS and OAuth App Governance Guide.
• Sharing links and storage tokens: the Microsoft SAS token exposure showed how one over-permissive storage link can expose 38TB of internal data. API-mode scanning for anonymous links belongs in the DLP scope.

Detection, response and measurement

Send DLP events to the SIEM alongside identity and endpoint telemetry so analysts can see who moved what, from where, and what else they did. Purview, for example, records DLP-monitored activity to the audit log and Activity explorer. See the SIEM Guide.

• Triage routing: low-severity matches go to the user as coaching, medium to the data owner, high to the SOC. Repeated high-severity events from one user, especially a leaver, go to the insider risk process.
• Data spillage: when sensitive data lands somewhere it should not (a public channel, the wrong tenant, an AI tool), treat it as an incident: contain, remove copies, assess notification duties, and record the root cause. See the Incident Response Guide.

Metrics that show DLP is working:

• Coverage: percentage of crown-jewel data sets covered by EDM, fingerprints or labels, and percentage of managed endpoints with a healthy DLP agent.
• Precision: false positive rate per rule from sampled reviews; target the top ten noisiest rules each quarter.
• Enforcement maturity: share of policies in block or block-with-override versus audit.
• User behaviour: override rate and repeat-incident rate after a policy tip.
• Response time: median time from high-severity DLP alert to triage decision.
• Exposure at rest: number of sensitive files shared publicly or with personal accounts, trending down.

Framework and ATT&CK mapping

Beyond NIST, DLP maps to NIST CSF 2.0 PR.DS-01, PR.DS-02 and PR.DS-10 (data at rest, in transit and in use), ISO/IEC 27001:2022 Annex A 5.12 (classification), 5.13 (labelling) and 8.12 (data leakage prevention), and CIS Controls v8.1 safeguards 3.7, 3.13 and 3.14 (log sensitive data access).

Common failure patterns

• Blocking on day one: untested block rules stop payroll or a customer process, and the whole programme is switched off by executive request.
• Pattern-only detection: regex rules for numbers without checksums or corroboration bury analysts in false positives until nobody reads alerts.
• No alert owner: incidents go to a shared mailbox, nobody triages, and real exfiltration is found months later.
• Leaving the obvious channels open: email is covered but personal webmail, code-sharing sites and AI chat are not. The Twitter source code leak saw proprietary code sit on GitHub for months.
• Ignoring machine paths: DLP watches people while integrations and service accounts export data unseen.
• Monitoring without legal groundwork: user-level DLP data is personal data about employees; deploying without notices and a DPIA where required invites challenge. See the DPIA Guide: Running a Data Protection Impact Assessment.

Practitioner checklist

• Publish a four-level classification scheme and map each level to DLP actions.
• Build EDM tables or fingerprints for the most sensitive structured data and templates.
• Write a one-sentence intent statement for every policy and document its configuration.
• Cover endpoint, web, email, SaaS sharing and AI prompt channels, and record known gaps.
• Deploy every new policy in simulation or audit mode for at least two business cycles.
• Move to policy tips with override and justification before any hard block, in pilot rings.
• Assign an alert owner and triage target for each severity.
• Monitor data volume per API token, service account and OAuth app in SaaS audit logs.
• Review the noisiest rules and all exceptions quarterly.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: SP 1800-28, Data Confidentiality: Identifying and Protecting Assets Against Data Breaches
• OWASP: LLM02:2025 Sensitive Information Disclosure
• MITRE ATT&CK: T1567 Exfiltration Over Web Service
• Microsoft Learn: Learn about data loss prevention
• Microsoft Learn: Learn about exact data match based sensitive information types
• Microsoft Learn: Learn about Endpoint data loss prevention
• Google Cloud: Sensitive Data Protection overview

Related NHI Mgmt Group resources: Shadow AI Discovery Guide · Email Security Guide · Data Mapping and ROPA Guide · Insider Threat and Identity Guide · SIEM Guide