Test Your DLP. Prove It Actually Blocks.

Use synthetic test data that matches the same structural rules as real sensitive data. Most DLP products validate detection with format checks (Luhn for credit cards, area number rules for SSNs, BIN ranges for cards), so randomly generated strings won't always trigger. The sample data on this site at /sample-data/ is generated to pass those validators while not corresponding 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
• Custom organization-specific data (sample customer records, sample source code) for EDM or IDM policies

Avoid using real production data for testing, even in non-production environments. The risk of accidentally leaking real data during a DLP test is higher than people expect, and the data protection obligations attached to real PII don't pause for a test.

If you need fresh test data on demand, use the data generator at /generate/ to produce custom samples.

Detection accuracy is usually expressed as a combination of two numbers: how often the DLP catches what it should (recall), and how often it fires correctly when it does fire (precision).

A simple measurement loop:

1. Build a labeled test corpus: known-positive samples that should trigger the policy, and known-negative samples that should not. Use /sample-data/ for the positive set and a representative sample of clean business data for the negative set.
2. Run the corpus through the channel you're testing (web upload, email, USB, etc.) with the policy active in monitor mode.
3. Count true positives (correctly fired), 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 policies to improve precision without sacrificing too much recall, or vice versa, depending on whether the policy is in monitor or block mode.

Healthy mature deployments typically run with policy-level false positive rates below 10 percent and recall above 80 percent for high-value policies. Targets vary by policy type; EDM and IDM policies should be near-zero false positive, while regex-based policies usually accept a higher false positive rate in exchange for broader coverage.

Track these metrics over time. A policy with declining recall is being worked around. A policy with rising false positives needs tuning before users start ignoring its alerts.

Both, in that order.

Monitor mode (sometimes called observe, alert-only, or detect) generates incidents without taking any user-facing action. Always start here. Monitor mode lets you tune policies against real or synthetic traffic without disrupting users or generating help desk tickets. Stay in monitor mode for at least two weeks of representative use before changing the policy action.

User-prompt mode (sometimes called justify or warn) shows the user a dialog asking them to justify or cancel the action. Useful as a middle step between monitor and block, especially for policies where the legitimate-use rate is unclear.

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

• Alert volume is stable and predictable
• False positive rate is below your threshold (typically under 10 percent)
• The user-facing message clearly explains why the action was blocked and how to request an exception
• There is a documented exception workflow for legitimate business needs

Move policies from monitor to block one at a time, not all at once. Start with high-confidence, low-impact policies (for example, blocking uploads of clearly tagged confidential files to personal cloud storage) and expand from there. Some policies should stay in monitor mode permanently because the goal is visibility rather than prevention.

Re-test on a regular cadence and after any change that could affect detection. A reasonable baseline:

• Monthly: quick smoke test of the most critical policies on the most critical channels. A short script that submits sample data via /http-post/ and uploads to ftp://ftp.dlptest.com/24_Hour/ covers most of this in minutes.
• Quarterly: full regression test of all production policies across all channels in scope. Confirm that previously fixed false positives haven't returned 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 silently start failing after an upgrade.
• After every policy change: any time someone tunes a regex, adds a dictionary, or modifies an EDM index, re-run that policy's tests before pushing 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 most-used channels.

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

Windows does not support passive FTP natively (and recent Windows versions have removed the bundled ftp client entirely), so use a third-party client like FileZilla. We provide a ready-to-import profile at /DLP_Test_FTP_FileZilla.xml. On macOS or Linux:

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

Validate that the proxy sends all PUT/POST traffic through the DLP server via ICAP, then ensure the test workstation's browser routes through that proxy. Enable a test SSN and CCN policy, copy sample data from /sample-data/, and submit it via /http-post/ or curl to /api/http-post/ (see that page for examples). Run first in monitor mode, then again in blocking mode.

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

Most modern web DLP is delivered as part of a Secure Service Edge (SSE) or SASE platform rather than 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 is routed through the SSE tenant (via 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 via /http-post/ or curl to /api/http-post/.
4. Verify the incident appears in the SSE console. Run first in monitor mode, then in blocking mode.

Because SSE inspects TLS-decrypted traffic in the cloud, the test workstation does not need to be on the corporate network. Off-network testing is a useful additional validation step.

Once Email DLP is in production, the test is the same regardless of platform: enable a test SSN and CCN policy, then send a few test emails to an external address with sample data in both the body and as an attachment. Validate that incidents fire and that the action (alert, quarantine, block, encrypt) matches what the policy was set to do.

Initial bring-up 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-native). Allowlist the gateway IPs in EOP, and use a test domain or transport rule to scope the bring-up.
• Google Workspace. Configure a content compliance rule or outbound gateway route to your Email DLP product. Test against a non-production sending user to avoid disrupting real mail flow.
• 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 via 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 validate in a non-production routing path first so a misconfigured policy doesn't block real outbound mail.

Confirm the Network Monitor is observing both HTTP and FTP traffic by checking its traffic stats. Enable a test SSN and CCN policy, then submit sample data to /http-post/ and upload a document to ftp://ftp.dlptest.com/24_Hour/. Network Monitor is monitor-only, so you can't test block actions, only detection. If incidents don't appear, run Wireshark on the monitor to confirm the right traffic is being seen.

Note: passive Network Monitors see less and less traffic as more activity moves to TLS-encrypted protocols and off-network endpoints. Most organizations now get equivalent coverage from an SSE / SASE deployment that inspects decrypted traffic in the cloud.

Modern endpoint DLP agents cover many 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 such as ChatGPT and Copilot. Test each channel that's in scope for your policy.

A simple bring-up 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 validate, for example:
   • Web browser: submit via /http-post/ or curl to /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. Verify the agent generates the expected incident for each channel.
5. Run first in monitor mode, then switch the policy to blocking mode and re-test.

For broader deployment guidance, see the Endpoint DLP deployment guide.

Data-at-Rest (DAR) scanning means searching file shares, databases, cloud storage, and endpoints for sensitive data already at rest, regardless of how it got there. This is the third of the classic three DLP categories (alongside Data-in-Use and Data-in-Motion).

Modern DAR is often delivered as part of a Data Security Posture Management (DSPM) product (Cyberhaven, Varonis, BigID, Cyera, Wiz, Microsoft Purview, etc.) rather than a standalone DLP scanner, but the testing approach is the same.

To test:

1. Place a set of 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 trigger a manual scan if the product supports it.
3. Verify the scanner identifies each test file and tags it with the correct classification.
4. Confirm the resulting incident or policy action matches expectation (alert, quarantine, encrypt, restrict access, etc.).

Common gotchas:

• Scan coverage often excludes default directories (Recycle Bin, System Volume Information, OS update caches). Test files placed in those locations may not be detected, by design.
• Many DAR scanners index incrementally. Newly placed files may not appear in results until the next scan window.
• Cloud DAR products may rely on tenant-level API permissions that don't extend to all sub-locations (private channels in Teams, personal OneDrive, etc.).

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

• 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.

To test, identify which architecture is in scope and exercise 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: place 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 verify the agent generates an incident.

Important: sanctioned SaaS apps (corporate tenants) and unsanctioned SaaS apps (personal accounts of the same app, or third-party apps the user found themselves) are often handled by different policies. Test both if both are in scope.

AI tools have become one of the highest-volume data egress channels in most organizations. Users paste sensitive data into ChatGPT, Claude, Gemini, Microsoft Copilot, GitHub Copilot, and dozens of other tools dozens of times a day. DLP coverage for AI tools is a feature in almost every modern endpoint and SSE product, and it usually works in one of three ways:

• Browser extension or endpoint agent that detects paste, type, or upload events on AI tool URLs.
• SSE inline inspection of traffic to known AI service endpoints.
• Network-level URL category blocking that prevents access entirely (the bluntest option).

To test detection:

1. Identify 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 fuller list.
2. Enable an AI-channel DLP policy or repurpose an existing PII or source-code policy to cover AI URLs.
3. From a test endpoint, paste sample data from /sample-data/ into the AI tool's input box. Also try uploading a sample-data file if the tool supports file upload.
4. Verify the agent or SSE detects the paste and generates the expected incident.
5. Test both monitor mode and blocking mode. AI-channel blocks should have a clear user message explaining the policy.

Additional considerations:

• AI tools change rapidly. New endpoints, new file upload methods, and new browser extensions appear constantly. Re-test quarterly at minimum.
• Some products differentiate between consumer AI tools (chat.openai.com) and enterprise-licensed versions (chatgpt.com/enterprise) and apply different policies. Test the boundary explicitly.
• Detection-only ("DLP-aware coaching") is increasingly common: the tool detects sensitive content, redacts it, and lets the user proceed with the redacted prompt. Test that the redaction is doing what you think it is.

Exact data matching (EDM) and indexed document matching (IDM) are advanced policy types most DLP products support. They reduce false positives dramatically by matching against specific known data rather than generic patterns.

• Exact Data Matching (EDM) indexes a structured source (a customer database, an employee roster, a list of patient MRNs) and detects exact field-level 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 detects partial or full 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 the test data has to be related to the indexed source. Synthetic data won't match.

To test EDM:

1. Build the EDM index from a small, controlled test source (not your production customer list). Use sample data from /sample-data/ or generate a test source at /generate/.
2. Construct test content that contains rows from the indexed source: full rows, partial rows, rows with substitutions (slightly altered names, dates of birth).
3. Submit the content through the channel under test.
4. Verify the policy fires only when the configured match threshold is met (typically a minimum number of matching rows and matching columns).
5. Also test near-misses: content that has some matching fields but should not fire.

To test IDM:

1. Fingerprint a controlled set of test documents.
2. Generate test files that include full copies, partial copies (paragraphs only), and modified copies (formatting changes, paraphrased sections) of the fingerprinted documents.
3. Submit each through the channel under test.
4. Verify 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 process at least once before relying on these policies in production.

macOS DLP coverage is genuinely uneven across products. Apple's endpoint security framework gives vendors a supported way to monitor file activity, network connections, and clipboard, but the channel coverage is usually a subset of what the same vendor offers on Windows. Test what's actually supported, not what the marketing page implies.

Things to verify specifically on macOS before relying on DLP enforcement:

• Full Disk Access and Endpoint Security permissions. The agent needs these granted (via MDM profile, ideally) before it can monitor most channels. Verify 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-native channels. These are common data exfiltration paths on macOS and are not always covered. Test or document the gap.
• iCloud sync. A Mac user with iCloud Drive enabled is syncing local files to a personal Apple account. Test whether the agent catches this and what action it takes.
• Time Machine and external drives. Backups to external drives can include sensitive data. Confirm policy behavior.

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

Document any channel that's not supported. macOS users in your population should not be assumed to have the same coverage as Windows users.

The teams that succeed treat Endpoint DLP as a multi-phase program, not a software install. The short version:

1. Plan before you deploy. Build an endpoint inventory, define data scope, write success criteria, and align stakeholders before any agent is 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 telemetry before expanding.
3. Roll out in rings with exit criteria. Move from pilot to IT to broader internal to full deployment in waves, with explicit go/no-go criteria between rings.
4. Move from monitor to enforce one policy at a time. Start with high-confidence, low-impact policies. Avoid the temptation to flip everything to block at once.
5. Invest in steady-state operations from day one. Agent health monitoring, alert triage, exception workflow, and quarterly policy review aren't optional.

For the full playbook with 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 effective. 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 specific 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 are firing 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 exactly 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: demonstrate appropriate technical measures (Article 32). DLP evidence for cross-border data transfers is particularly valuable.
• 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 in a controlled location (a GRC tool, a SharePoint site with restricted access, or a similar repository). Six months of trending data is the most compelling artifact you can offer.