The essentials in 30 seconds
- Testing your DLP means triggering synthetic data exits, channel by channel, and recording the result: blocked; detected, not blocked; or not detected.
- A “green” console says nothing about what gets through: a DLP that misses warns nobody.
- The plan comes down to 3 decisions, scope, scenarios, cadence, and is replayed every quarter as well as after a migration.
“Our DLP has been running for 2 years. What exactly has it blocked?” We often hear this question from the CISOs we meet, and the console cannot answer it. To find out, you have to test your DLP. Here is the checklist your team can start with on Monday morning, along with a test plan that fits on one page.
Testing your DLP means deliberately triggering synthetic data exits, channel by channel, then checking for each one whether it was blocked, only logged or ignored. Your DLP can have all its rules active and still leak. For the broader framework, see our page on data exfiltration testing.
Why a “green” DLP console proves nothing
The console shows you active policies, published rules, deployed agents. It never shows what did not trigger an alert. A DLP that misses warns nobody. The screen stays green. Yet the attacker has time: a median dwell time of 14 days according to Mandiant’s M-Trends 2026.
The causes are well known, and often mundane. An endpoint agent disabled on part of the estate. A rule left in audit mode since the pilot phase. An exception added for an urgent project and never removed. A new SaaS service that nobody added to the scope. A password-protected archive that the analysis engine cannot open. Or a threshold: an EDR that lets files go out to Google Drive up to a certain volume, then cuts them off, which a split upload gets around. None of these produces a visible error. Nothing is reported. We cover them in detail in the article on DLP false negatives.
Three possible results for each test
Before launching anything, agree on a common reading grid with your SOC. Each replayed scenario ends in one of these 3 states:
| Result | What it means | Expected action |
|---|---|---|
| Blocked | The data did not leave and the event is logged | Check that the alert reaches your SOC with the right context |
| Detected, not blocked | The data left, but an alert exists | Decide whether this channel justifies switching to blocking |
| Not detected | The data left without any trace | Fix as a priority, according to the channel’s sensitivity |
Testing your DLP: the channel-by-channel checklist
Here is what your team should check, at a minimum, on each major egress channel. Keep it simple. Ordinary user actions are enough: if a USB stick gets through, there is no need to bring out attacker techniques to settle the question.
Workstation (endpoint)
- Copy a sensitive synthetic file to a USB stick, then to an encrypted external drive (T1052 in MITRE ATT&CK).
- Print a document marked “Confidential”.
- Copy and paste a sensitive extract into an unauthorised application, Notion for example.
- Run the same test on a laptop outside the corporate network, working remotely without a VPN.
- Check the agent on 20 randomly chosen machines: is it present, up to date and under the right policy?
- Send to a personal Gmail or Outlook.com address, in the message body and then as an attachment.
- Attach a file compressed as a ZIP, then as a password-protected ZIP.
- Send to an external recipient in blind copy (Bcc).
- Place sensitive data in an image or a scanned PDF.
Web and network
- Upload a synthetic file to WeTransfer or Smash, from Chrome or Edge.
- Paste sensitive content into a web form, Copilot or Gemini.
- Transfer to a destination that your proxy has not categorised.
- Check TLS inspection coverage on outbound HTTPS flows.
Cloud and SaaS applications
- Share a document via a public link from Microsoft 365 or Google Workspace.
- Sync to a personal Dropbox or OneDrive account.
- Post a file in a Teams or Slack channel open to external guests.
- Bulk download from a business application, Salesforce for example.
The day-to-day use of collaboration tools deserves a review of its own.
A mini test plan in three decisions
Diagram · the test plan in three decisions
1. Scope
Do not start with everything. Choose 2 or 3 categories of data that would cost you dearly if they leaked (customer files, payroll, blueprints or source code) and the people who have access to them. Include at least one mobile user and one privileged account. I would rather see a few scenarios run this week than a complete inventory planned for next quarter.
2. Scenarios
For each category, cross your data with the channels in the checklist. Build realistic decoys: close enough to the real data to trigger your rules (number formats, keywords, classification labels), without ever being real. That is what lets you test in production without using any real business data, as explained in the article on synthetic data in production.
A well-written scenario looks like this: “A remote salesperson sends a fake 500-row Excel customer export to their personal mailbox as a compressed attachment. Expected result: blocked, with a SOC alert within 15 minutes.” Writing the expected result in advance avoids arguments afterwards.
3. Cadence
- Baseline: a full run at least every 3 months.
- Events: a targeted replay after a migration, a new SaaS tool, a major agent update or a policy change.
- Critical channels: an automated check, every 12 hours or daily, on the 2 or 3 most exposed channels.
Why insist so much? Because a rule that blocked in January may see nothing in April without anyone having touched it directly. A one-off test tells you where you stood on that day. Replaying it every month shows you whether things are improving.
Next step
What does your DLP let through, channel by channel?
A 30-minute demo: a full campaign across the 8 channels we test, on our demo environment. The POC shows, on site, how the solution behaves in your environment, on one simple scenario in a synthetic environment. What actually leaves through your channels is what the pilot shows you.
Reading the results and deciding
A test that produces 50 findings with no order of treatment is useless. Rank each failure on two axes: the sensitivity of the data and how easy the action that got it out was. A customer export that leaves through a simple drag and drop in a browser comes before a theoretical leak that requires administrator rights.
Finally, keep a history. Record the rate of blocked scenarios per channel, how it changes from one run to the next, and the time to fix. In front of an ISO 27001 auditor or your management, this says far more than a console screenshot. On the Enforcis side, upcoming versions will bring multi-level reporting (leadership, CISO, operations), with MITRE ATT&CK mappings and, where the correspondence is established, MITRE D3FEND, as well as SIEM integrations.
Frequently asked questions
Should you warn the SOC before testing?
For a first run, yes, and your support team too: otherwise your decoys will trigger a real incident response. Once the rules have stabilised, a discreet run also measures what the SOC sees without being warned.
How do you write a DLP test scenario?
One sentence is enough, as long as it includes a profile, a piece of data, a channel and the expected result. Example: a remote salesperson sends a fake 500-row Excel customer export to their personal Gmail, as a ZIP; expected, blocked with a SOC alert within 15 minutes. Written in advance, this result avoids arguments afterwards. To replay these scenarios over time, see continuous validation, pentest or red team.
Should remote workstations be tested separately?
Yes. A laptop off the network, without a VPN, often no longer goes through your proxy: the endpoint DLP then carries almost all of the control. On that mobile machine, replay the copy to a USB stick (T1052) and the upload to a personal Dropbox or OneDrive. Include a privileged account in the scope too. And check on 20 randomly chosen machines that the agent is present, up to date and under the right policy.
How many scenarios should you start with?
Around fifteen well-chosen ones already take you a long way: 3 data categories crossed with 5 channels. We prefer 15 scenarios replayed every month to 100 written once.