How to Write a DLP Policy That Actually Blocks Something

Quick answer. Most DLP policies are lists of patterns, which makes them detection policies rather than enforcement policies. A DLP policy only becomes enforceable when it names three things: the data, the destination it must not reach, and the point in the path where the block happens. dope.security puts that third element on the device, so a rule about an upload or an AI prompt is enforced before the data leaves the laptop.

The three parts of a DLP policy, and the one everybody skips

Open almost any data-loss prevention policy document and you will find an excellent inventory of data types. Social security numbers, card numbers, patient identifiers, source code, a client list, a board deck. You will usually find severity levels and an incident workflow too. What you will rarely find is a sentence that says where the data must not go, and almost never a sentence that says which control stops it going there.

That is not a documentation nitpick. It is the reason so many programs run for years in monitor mode. A rule that says "detect credit card numbers" is satisfied by an alert. A rule that says "a card number must not reach a personal cloud drive or a consumer AI assistant, enforced on the endpoint before upload" can be tested, can fail, and can be fixed. If you need the category groundwork first, the complete guide to data loss prevention covers what DLP is before we get into how to write the rule.

So the structure we recommend is boring and effective. Every policy line has a data clause, a destination clause, and an enforcement clause. If any of the three is missing, it is not a policy line yet.

Why the destination clause matters more than the pattern

Classification gets almost all the attention and most of the budget. It is the interesting engineering problem, so vendors compete on detector counts, dictionaries, exact data match and confidence tuning. But two events with the same pattern can carry wildly different risk, and only the destination tells you which is which.

A card number moving into your own payment system is business as usual. The same card number pasted into a consumer chatbot is a reportable event. Same detector, same confidence score, opposite outcome. If your policy stops at the pattern, your analysts are the ones supplying the destination logic by hand, one alert at a time, which is how alert fatigue is manufactured.

Destination is also where the interesting failure mode lives in 2026. It is no longer another company's server. It is the same hostname on a different account, which is the point we make in CASB versus DLP: a CASB answers which app, DLP answers which data, and the question that actually decides risk is which tenant of that app. Write the destination clause in tenant terms and it becomes enforceable. Write it in domain terms and you have a policy that blocks a company's marketing site.

The enforcement clause: naming where the block happens

This is the clause that separates a document from a control. There are only a few honest answers, and each has a different failure profile.

• At rest in a SaaS tenant: an API scan finds a shared file after it has been shared, which is good hygiene and inevitably retrospective. CASB Neural does this for OneDrive and Google Drive with one-click remediation, and it is the right tool for exposure that already exists.
• In the network path: a cloud proxy can inspect an upload, but only after steering traffic to a point of presence and back, and in most stacks only with a data-protection add-on licensed on top. Zscaler's prompt DLP requires its Data Protection add-on, with AI Guard and AI Scanning licensed separately; Netskope's full inline DLP with threat and AI controls sits in a higher tier, with CASB-API sold as its own SKU.
• Inside one vendor's applications: a suite-native control such as Microsoft Purview enforces well inside its own estate and stops at the edge of it, which is why teams looking at coverage beyond Microsoft end up comparing options in the Microsoft Purview DLP alternatives.
• On the device, at egress: Dopamine DLP intercepts the file upload or the AI prompt on the endpoint, classifies it through zero-retention APIs (US Patent 12,464,023) and applies Block, Monitor or Off. The data has not left yet, which is the only version of this where "prevention" is the accurate word.

Most mature programs use more than one. The point of writing the clause down is that you stop assuming coverage you do not have. A policy that says "block" with no enforcement clause usually means "alert," and everyone finds that out during an incident.

Write rules about actions, not about documents

A common failure is writing policy about objects. "Confidential documents must be labeled and protected." Fine, except the leak is almost never a document. It is a copied paragraph, a screenshot, a pasted table, a chunk of a customer list typed into a prompt box. None of those are objects in a repository, so none of them are reachable by a policy written about repositories. That is the structural limit we described in sensitive data discovery, and it applies to policy language just as much as to tooling.

Write about actions instead. Upload. Paste. Prompt submission. Attachment. Sign-in to a non-corporate tenant. Each one is an event a control can intercept, and each one can carry a destination. "A prompt containing customer records must not be submitted to a non-corporate AI tenant, blocked on the endpoint" is a rule you can run a test against this afternoon. The mechanics of enforcing at that layer are in endpoint DLP and data in motion.

Then decide your posture per action, not per data type. Block is right for a small number of high-confidence, high-consequence combinations. Monitor is right for most things, for a while, because it gives you the evidence to justify the block later. Off is a legitimate choice when the noise is not buying you anything, and saying so in the document is more honest than leaving a rule enabled that everyone ignores.

A DLP policy that only detects versus one that enforces

Same intent, two outcomes. Each line pairs the detection-only version with the enforceable version.

• Data clause: a detection policy lists regular expressions and dictionaries; an enforceable policy also states the confidence threshold and what happens at each level, so a partial match does not silently become a block.
• Destination clause: a detection policy names a category such as "cloud storage"; an enforceable policy names the tenant, which is what lets you allow the corporate Google Workspace account and block the personal one on the same domain.
• Enforcement clause: a detection policy says "the DLP tool will flag"; an enforceable policy says which control acts, and where in the path, so it can be tested by trying to do the thing.
• Coverage clause: a detection policy assumes traffic passes through a corporate network; an enforceable policy states what happens on a laptop at an airport, which for dope.security is the same policy, because the dope.endpoint agent carries it.
• Evidence clause: a detection policy produces an alert count; an enforceable policy produces a record of what was blocked and why, with a human-readable Dopamine Summary explaining the detection rather than a rule ID.
• Review clause: a detection policy is reviewed annually; an enforceable policy is reviewed whenever a new destination appears, which in the AI era is roughly monthly.

Read either column on its own and it still makes sense. That is the test for whether your policy document can survive being read by someone who was not in the room.

The AI clause you probably need to add this quarter

Most DLP policies written before 2024 have no destination clause for AI, because there was no AI destination. Adding one is not a matter of appending "and AI tools" to the cloud storage line, because AI usage breaks three assumptions at once. The data leaves as free text rather than a file. The same hostname serves corporate and personal accounts. And a growing share of it does not happen in a browser at all, but in a desktop client, an IDE or a Model Context Protocol connection.

So the AI clause needs to name tenants, cover thick clients as well as browsers, and treat a prompt as an egress event. In practice that means three layers working together: Shadow IT discovery to find which AI tools are in use, SWG policy to allow, warn or block, and Cloud Application Control to restrict access to approved tenants, with Dopamine DLP inspecting prompt content across ChatGPT, Claude, Perplexity, Abacus and Copilot. The reasoning behind that structure is in how AI DLP prevents sensitive data leakage, and the enforcement surface is on the Fly Direct Secure Web Gateway page.

One caution on tone. A policy that reads as a blanket AI ban will be routed around within a week, usually onto a personal device you cannot see. Allow the sanctioned tenant, block the personal one, and inspect the prompt. That is a policy people can comply with while still doing their jobs.

Rolling it out without breaking the company

Sequence matters more than completeness. Start in Monitor for everything, for two to four weeks, and read what actually happens rather than what you assumed. Pick the two or three combinations that are both high-consequence and high-confidence and move only those to Block. Publish the block list internally before it turns on, with a stated route for exceptions, because an unexplained block becomes a ticket and a workaround.

Then measure the thing that matters, which is not alert volume. It is whether the events you care about stopped happening, and whether your help desk load went up. When Outreach Health moved off its legacy gateway, web access tickets dropped 70 percent in 90 days and policy changes went from days to minutes, which is the operational half of this that never appears in a policy template. The write-up is in the healthcare displacement case study.

Review on a destination trigger, not a calendar. A new AI assistant, a new SaaS tool, a new acquisition: each one is a new destination clause, and each one is a five-minute edit if your policy is structured the way we described and a rewrite if it is not.

Frequently Asked Questions

What should a DLP policy actually contain?

At minimum, three clauses per rule: the data it covers, the destinations it must not reach, and the control and location that enforce it. Add a posture (Block, Monitor or Off), a confidence threshold, an exception route and an owner. If a rule cannot be tested by attempting the action it forbids, it is documentation rather than policy.

Should we start in block mode or monitor mode?

Monitor first, for two to four weeks, then promote a small number of high-confidence, high-consequence rules to block. Starting in block mode across the board generates exception traffic faster than your team can process it, and the workarounds people invent are worse than the original risk. dope.security supports Block, Monitor and Off per policy so you can promote rules individually.

How does a DLP policy handle employees working off the corporate network?

That depends entirely on the enforcement clause. Network-path enforcement only applies while traffic is being steered through the network, so a laptop on home wifi is covered only if it is tunneled back. With dope.security the enforcement point is the device, so the same policy applies on any network, including mainland China, with no regional uplift and no backhaul.

Does a DLP policy help with PCI DSS, HIPAA or GDPR audits?

It helps considerably, but only if it produces evidence rather than intent. Auditors respond to a rule that names a data type, a prohibited destination and an enforcement point, plus records of enforcement. It is also worth noting where inspection happens: on-device inspection means user traffic is not decrypted in a third party's data center, and Dopamine DLP classifies through zero-retention APIs with no training on customer data, which simplifies data residency conversations. The specific control mapping is always a discussion with your auditor.

How is a DLP policy different from an acceptable use policy?

An acceptable use policy tells people what they are permitted to do and is enforced socially, through HR process. A DLP policy tells a control what to prevent and is enforced technically. You want both, and they should agree, because a technical control that contradicts the written rules generates escalations instead of compliance.

A policy is a testable claim

Restating the thesis in different words: a document that only describes sensitive data has described the problem, not the control. The sentence that makes a DLP policy real is the one nobody writes, the one that says where the block happens, and until it is written the program is an alert pipeline with a governance document attached to it. Add the destination and the enforcement point and every line becomes a claim you can go and try to break.

dope.security makes that enforcement point the device, so a prompt or an upload is inspected before it leaves, tenant-level rules separate corporate from personal accounts on the same domain, and SWG, CASB Neural, Dopamine DLP and Cloud Application Control run from one console. Bring your current policy document and book a 20-minute demo, and we will find the lines that are missing an enforcement clause.