Does your DLP actually work?

Use fake data that follows the same rules as real sensitive data. Most DLP products check the format (Luhn for credit cards, area number rules for SSNs, BIN ranges for cards), so random strings won't always trigger. The sample data at /sample-data/ is built to pass those checks and doesn't belong to any real person or account.

A good test set includes:

• SSNs with valid area-group-serial combinations
• Credit card numbers that pass the Luhn algorithm, for each major brand
• Bank account and routing numbers in valid formats
• PHI samples (MRN, NDC, ICD codes) if you're testing HIPAA policies
• Data specific to your organization (sample customer records, sample source code) for EDM or IDM policies

Don't use real production data for testing, even in non-production environments. The risk of leaking real data during a DLP test is higher than people expect, and your obligations around real PII don't pause for a test.

If you need new test data, use the data generator at /generate/ to build it.

It usually comes down to two numbers: how often DLP catches what it should (recall), and how often it's right when it fires (precision).

Here's a simple way to measure it:

1. Build a labeled set of test data: samples that should trigger the policy, and samples that shouldn't. Use /sample-data/ for the first group and a representative sample of clean business data for the second.
2. Run it through the channel you're testing (web upload, email, USB, etc.) with the policy in monitor mode.
3. Count true positives (fired correctly), false positives (fired on clean data), false negatives (missed real samples), and true negatives (correctly didn't fire).
4. Calculate precision = TP / (TP + FP) and recall = TP / (TP + FN).
5. Tune the policy to improve precision without losing too much recall, or the other way around, depending on whether the policy is in monitor or block mode.

Healthy, mature deployments typically run below 10 percent false positives per policy and above 80 percent recall on high-value policies. Targets vary by policy type. EDM and IDM policies should be near zero false positives, and regex policies usually accept more false positives in exchange for broader coverage.

Track these numbers over time. If recall is dropping, people are working around the policy. If false positives are rising, tune it before users start ignoring its alerts.

Both, in that order.

Monitor mode (sometimes called observe, alert-only, or detect) creates incidents without doing anything to the user. Always start here. You can tune policies against real or fake traffic without disrupting users or creating help desk tickets. Stay in monitor mode for at least two weeks of normal use before you change the policy action.

User-prompt mode (sometimes called justify or warn) asks the user to justify or cancel the action. It's a useful middle step, especially when you don't know how much of the activity is legitimate. It's also your chance to tell someone what they did and what to do instead.

Blocking mode stops the action and notifies the user. Only move a policy to block mode when:

• Alert volume is stable and predictable
• The false positive rate is below your threshold (typically under 10 percent)
• The message the user sees explains why the action was blocked and how to request an exception
• There's a documented exception process for legitimate business needs

Move policies from monitor to block one at a time. Start with high-confidence, low-impact policies, like blocking uploads of clearly tagged confidential files to personal cloud storage, and go from there. Some policies should stay in monitor mode permanently because all you want from them is visibility.

Re-test on a regular schedule and after any change that could affect detection. Here's a reasonable baseline:

• Monthly: a quick smoke test of your most critical policies on your most critical channels. A short script that submits sample data to /http-post/ and uploads to ftp://ftp.dlptest.com/24_Hour/ covers most of this in minutes.
• Quarterly: a full regression test of all production policies across all channels in scope. Make sure the false positives you already fixed haven't come back and that detection rates are stable.
• After every DLP product update: policy engines and detection logic change between releases. A test that passed last quarter can start failing after an upgrade without any warning.
• After every policy change: any time someone tunes a regex, adds a dictionary, or changes an EDM index, re-run that policy's tests before pushing it to production.
• After every major endpoint change: OS upgrades, browser updates, and new EDR or antivirus deployments can interact with the DLP agent. Smoke test the channels people use most.

Keep the test results. A six-month trend of detection rates per policy is the most useful thing you can show an auditor or a security committee.

Windows doesn't support passive FTP natively, and recent versions have removed the bundled ftp client entirely, so use a third-party client like FileZilla. Here's a profile you can import: DLP_Test_FTP_FileZilla.xml. On macOS or Linux:

1. Open a terminal.
2. cd into the folder with your test files.
3. Run ftp ftp.dlptest.com -p.
4. Log in as dlpuser. The current password is at /ftp-test/.
5. Run put testdoc.docx to upload.

Check that the proxy sends all PUT/POST traffic through the DLP server using ICAP, then make sure the test workstation's browser goes through that proxy. Enable a test SSN and CCN policy, copy sample data from /sample-data/, and submit it to /https-post/ if the proxy does SSL inspection, or /http-post/ for plain HTTP traffic it doesn't need to decrypt. Both pages have curl examples against /api/http-post/. Run it first in monitor mode, then again in blocking mode.

This works for any ICAP-based DLP integration, including Symantec/Broadcom Web Prevent, Forcepoint, Trellix, and similar on-premises deployments. For cloud-delivered web DLP through SSE or SASE, see the next FAQ.

Most web DLP today is part of a Secure Service Edge (SSE) or SASE platform, not an on-premises proxy. Common examples include Netskope, Zscaler, Microsoft Purview / Defender for Cloud Apps, Palo Alto Prisma Access, Cisco Umbrella, Forcepoint ONE, and Cyberhaven.

To test:

1. Confirm the test endpoint's traffic goes through the SSE tenant (using a PAC file, agent, or device tunnel).
2. Enable a test SSN and CCN policy in the SSE console.
3. Copy sample data from /sample-data/ and submit it to /http-post/ or use curl against /api/http-post/.
4. Check that the incident shows up in the SSE console. Run it first in monitor mode, then in blocking mode.

SSE inspects TLS-decrypted traffic in the cloud, so the test workstation doesn't need to be on the corporate network. Test it off-network too.

Once Email DLP is in production, the test is the same on any platform. Enable a test SSN and CCN policy, then send a few test emails to an external address with sample data in the body and as an attachment. Check that incidents fire and that the action (alert, quarantine, block, encrypt) matches the policy.

The initial setup depends on your email platform:

• Microsoft 365 / Exchange Online. Use a connector to route outbound mail through your Email DLP gateway, or use Microsoft Purview DLP and Exchange Online mail flow rules if your DLP is Microsoft. Allowlist the gateway IPs in EOP, and use a test domain or transport rule to limit the scope during setup.
• Google Workspace. Configure a content compliance rule or outbound gateway route to your Email DLP product. Test with a non-production sending user so you don't disrupt real mail.
• On-premises Exchange or other SMTP gateways. Allowlist the Email DLP IPs in your edge MTA, configure the forward address to your MTA, and add a send connector on Exchange pointing to a test domain.
• Cloud email security / ICES (Abnormal, Avanan, Mimecast, Proofpoint, Material, etc.). These usually integrate through journaling, API, or inline relay. Follow the vendor's integration guide for outbound DLP, then run the same test described above.

Whichever platform you're on, always test in a non-production routing path first so a misconfigured policy doesn't block real outbound mail.

Check the Network Monitor's traffic stats to confirm it's seeing both HTTP and FTP traffic. Enable a test SSN and CCN policy, then submit sample data to /http-post/ (plain HTTP, since most passive Network Monitors can't decrypt TLS) and upload a document to ftp://ftp.dlptest.com/24_Hour/. Network Monitor is monitor-only, so you can only test detection, not blocking. If incidents don't show up, run Wireshark on the monitor to confirm it's seeing the right traffic.

Network monitors have faded out as more traffic moves to TLS and off the corporate network. Most organizations now get the same coverage from an SSE or SASE that inspects decrypted traffic in the cloud.

Endpoint DLP agents cover a lot of channels: web browsers, FTP clients, cloud sync clients (OneDrive, Google Drive, Dropbox, Box), USB and removable media, printing, clipboard, screenshots, AirDrop and Bluetooth, virtual desktop sessions, and AI tools like ChatGPT and Copilot. Test each channel that's in scope for your policy.

Here's a simple first test:

1. Enable a test SSN and CCN policy on the endpoint agent.
2. Copy sample data from /sample-data/.
3. Trigger each channel you want to test, for example:
   • Web browser: submit to /http-post/ or use curl against /api/http-post/.
   • FTP: upload a sample data file to ftp://ftp.dlptest.com/24_Hour/.
   • USB: copy a sample data file to a USB drive.
   • Cloud sync: save a sample data file into a OneDrive, Google Drive, or Dropbox folder.
   • Clipboard / AI: paste sample data into a browser-based AI chat that your policy is meant to cover.
4. Check that the agent creates the incident you expected for each channel.
5. Run it in monitor mode first, then switch the policy to blocking mode and test again.

For more on rolling it out, see the Endpoint DLP deployment guide.

Data-at-Rest (DAR) scanning means searching file shares, databases, cloud storage, and endpoints for sensitive data that's already sitting there, no matter how it got there. It's the third of the classic DLP categories, along with Data-in-Use and Data-in-Motion.

A lot of DAR today comes as part of a Data Security Posture Management (DSPM) product (Cyberhaven, Varonis, BigID, Cyera, Wiz, Microsoft Purview, etc.) and not a standalone DLP scanner, but you test it the same way.

To test:

1. Put sample data files in each target location: an SMB share, a SharePoint or OneDrive folder, an S3 bucket, a Google Drive shared folder, and a local endpoint folder. Download files from /sample-data/ or use the generator at /generate/.
2. Wait for the scanner's normal indexing or scan cycle, or start a manual scan if the product supports it.
3. Check that the scanner finds each test file and tags it with the correct classification.
4. Confirm the incident or policy action is what you expected (alert, quarantine, encrypt, restrict access, etc.).

Common gotchas:

• Scans often skip default directories (Recycle Bin, System Volume Information, OS update caches). Test files in those locations may not be detected, by design.
• Many DAR scanners index incrementally. New files may not show up until the next scan window.
• Cloud DAR products may rely on tenant-level API permissions that don't reach every location (private channels in Teams, personal OneDrive, etc.).

Cloud and SaaS DLP covers content stored in or moving through cloud services like Microsoft 365, Google Workspace, Salesforce, Box, Slack, Jira, Workday, and hundreds of others. Most DLP coverage for these apps comes from one of three approaches:

• CASB or SSE inline (Netskope, Zscaler, Palo Alto Prisma Access, Cisco Umbrella, Microsoft Defender for Cloud Apps, Forcepoint ONE) inspects traffic between the user and the SaaS app.
• API-based scanning (Microsoft Purview, Google Workspace DLP, vendor-native scanners) reads content directly out of the SaaS tenant.
• Browser isolation or browser extension DLP (Cyberhaven, Talon, Island) sits in the browser and inspects content as it's typed, pasted, or uploaded.

Figure out which approach you have, then test it directly:

• Inline (CASB / SSE): route the test endpoint through the SSE tenant, then upload sample data from /sample-data/ into the SaaS app's upload interface (a Salesforce attachment, a Box upload, a Slack message with a file).
• API-based: put sample data inside the SaaS app (a SharePoint file, a Google Doc, a Salesforce record) and wait for the scanner's indexing cycle.
• Browser-based: paste sample data into a SaaS app's web form on a managed endpoint and check that the agent creates an incident.

Sanctioned SaaS apps (corporate tenants) and unsanctioned ones (personal accounts on the same app, or apps people found themselves) often get different policies. Test both if both are in scope.

A lot of people aren't uploading full files into AI tools anymore. They paste a snippet of code, a paragraph out of a document, or some numbers from a financial report. So test copy and paste, not just file uploads.

DLP usually sees AI traffic in one of three ways:

• Browser extension or endpoint agent that sees the paste, typing, or upload on the AI tool's site.
• SSE inline inspection of traffic going to known AI services.
• URL filtering that blocks the whole site. This is the hammer approach. In my opinion it's whack-a-mole, because people will keep going until they find a tool you haven't blocked.

To test detection:

1. Pick the AI tools in scope. At minimum, include chat.openai.com, claude.ai, gemini.google.com, copilot.microsoft.com, and github.com/copilot. Your security team will have a longer list.
2. Enable an AI policy, or point an existing PII or source code policy at the AI URLs.
3. From a test endpoint, paste sample data from /sample-data/ into the AI tool's input box. If the tool takes file uploads, upload a sample file too.
4. Check that the agent or SSE caught the paste and created the incident you expected.
5. Test in monitor mode, then blocking mode. When you block, the user should see a message that says why and points them to the tool they should use instead.

A few more things to check:

• These tools change fast. New sites, upload methods, and browser extensions show up all the time, so re-test at least quarterly.
• A personal account and a corporate account on the same AI tool can get different policies, like chat.openai.com and chatgpt.com/enterprise. Test both.
• Some tools redact the sensitive data and let the user continue with the redacted prompt. Test that the redaction does what you think it does.

Exact data matching (EDM) and indexed document matching (IDM) are advanced policy types that most DLP products support. They cut false positives a lot because they match against specific known data, not generic patterns.

• Exact Data Matching (EDM) indexes a structured source (a customer database, an employee roster, a list of patient MRNs) and looks for exact field matches in content. A policy might say "block if at least three rows from the customer table appear together in a single document."
• Indexed Document Matching (IDM) fingerprints whole documents and looks for full or partial copies of them. A policy might say "block if more than 30 percent of a fingerprinted contract appears in an outbound email."

Both are tricky to test because your test data has to come from the indexed source. Generic fake data won't match.

To test EDM:

1. Build the EDM index from a small test source you control, not your production customer list. Use sample data from /sample-data/ or generate a source at /generate/.
2. Build test content with rows from the indexed source: full rows, partial rows, and rows with small changes (slightly altered names, dates of birth).
3. Submit the content through the channel you're testing.
4. Check that the policy fires only when the match threshold is met (typically a minimum number of matching rows and columns).
5. Also test near misses: content with some matching fields that shouldn't fire.

To test IDM:

1. Fingerprint a set of test documents you control.
2. Create test files with full copies, partial copies (paragraphs only), and modified copies (formatting changes, paraphrased sections) of those documents.
3. Submit each one through the channel you're testing.
4. Check that the policy fires above the match percentage threshold and stays quiet below it.

Both EDM and IDM indexes need to be refreshed on a schedule. Test the refresh at least once before you rely on these policies in production.

macOS coverage varies a lot by product. Apple's endpoint security framework gives vendors a supported way to monitor file activity, network connections, and clipboard, but the coverage is usually a subset of what the same vendor offers on Windows. Test what's actually supported, not what the marketing page says.

Things to check on macOS before you rely on DLP enforcement:

• Full Disk Access and Endpoint Security permissions. The agent needs these granted, ideally with an MDM profile, before it can monitor most channels. Check that the agent reports as fully authorized.
• System Extension authorization. macOS requires explicit approval for kernel and system extensions. Confirm the agent's extension is loaded and authorized.
• Browser coverage. Safari, Chrome, Firefox, Arc, and Edge all behave differently. Test each browser your users actually use.
• AirDrop, iMessage, and other Apple channels. These are common ways for data to leave on macOS and aren't always covered. Test them or document the gap.
• iCloud sync. A Mac user with iCloud Drive turned on is syncing local files to a personal Apple account. Test whether the agent catches this and what it does.
• Time Machine and external drives. Backups to external drives can include sensitive data. Check how the policy behaves.

Use sample data from /sample-data/ and run the same channel tests from "How to test Data-in-Use (Endpoint DLP)" above. Run them on multiple macOS versions. The two most recent are usually enough, but include any older versions still in scope.

Document any channel that isn't supported. Don't assume your macOS users have the same coverage as your Windows users.

Endpoint DLP is a multi-phase project, not a software install. The short version:

1. Plan before you deploy. Build an endpoint inventory, define which data is in scope, write success criteria, and get stakeholders aligned before any agent gets installed.
2. Pilot in monitor mode. Deploy to 1 to 5 percent of the fleet, run policies in observe mode for at least two weeks, and tune against real data before you expand.
3. Roll out in rings with exit criteria. Go from pilot to IT to broader internal to full deployment in waves, with go/no-go criteria between each ring.
4. Move from monitor to enforce one policy at a time. Start with high-confidence, low-impact policies. Don't flip everything to block at once.
5. Plan for day-to-day operations from day one. Agent health monitoring, alert triage, exceptions, and quarterly policy reviews aren't optional.

For phase-by-phase detail, sample success metrics, common pitfalls, and vendor-specific considerations, see the Endpoint DLP deployment guide.

Auditors want evidence that the control is in place, configured correctly, and working. For DLP, that means three things:

• Coverage evidence. A report showing the percentage of in-scope endpoints, servers, and SaaS tenants that are protected. Auditors will ask how you defined "in-scope" and how you handle gaps.
• Policy mapping. A document mapping each regulatory requirement to the DLP policy that addresses it. PCI DSS Requirement 3.4 → policy "PCI block on outbound web." HIPAA 164.312(e)(1) → policy "PHI alert on outbound email." GDPR Article 32 → policy "EU PII block to non-EU destinations." Most products can export this as a report.
• Test evidence. A log of regular DLP tests showing the policies fire on the expected sample data. Quarterly tests against /sample-data/ and ftp://ftp.dlptest.com/24_Hour/, plus screenshots or exported incident reports, give an auditor what they're looking for.

Common frameworks and the DLP evidence they typically expect:

• PCI DSS: controls around cardholder data discovery, transmission, and storage. Auditors want evidence that PAN is detected and blocked on egress channels.
• HIPAA: technical safeguards including transmission security. Auditors want evidence that PHI is detected on outbound email and web.
• GDPR / UK GDPR: show appropriate technical measures (Article 32). DLP evidence for cross-border data transfers is especially useful.
• SOC 2: Common Criteria around logical access and confidentiality. DLP evidence supports CC6 and CC9.
• ISO 27001 / 27002: Annex A controls A.5.10, A.8.12, and A.13.2 all benefit from DLP evidence.

Keep the evidence somewhere controlled, like a GRC tool or a SharePoint site with restricted access. Six months of trend data is the best thing you can show them.