Buying DLP: What to Ask Vendors
- kind
- Checklist
- domain
- Procurement
- stage
- Context
- read
- 3 min
- assumes
- No prior programme in place
Twelve questions that separate a product that fits your problem from one that demonstrates well.
Every product in this category demos impressively, because the demo uses prepared data on a clean environment. These questions surface what happens afterwards.
About detection
1. Show me this running on our data, not your demo tenant. A proof of concept in your environment, on your files. Vendors who decline are telling you something. Two weeks is enough.
2. What is the false positive rate on our data in monitor mode? Not a general claim — the actual volume during the trial, and how much tuning it took to get there.
3. How does it detect our unstructured intellectual property? Pattern matching handles identifiers. Ask specifically how it would recognise a proprietary design document, and expect the honest answer to involve fingerprinting or location-based rules rather than content classification.
4. What does it not see? A vendor with a clear answer is one worth working with. Every product in this category has substantial blind spots and the ones who name them are easier to plan around.
About operations
5. How long from purchase to a tuned, reviewable alert volume? Ask for a reference customer of similar size and ask them the same question. The answer is usually two to three times the vendor estimate.
6. Who operates this day to day, and how many hours? Detection engineering, tuning, alert review, exception management. Products differ enormously here and the operating cost usually exceeds the licence over three years.
7. How are exceptions managed? Every organisation needs dozens of exclusions for legitimate workflows. Ask to see how they are created, documented, reviewed and expired. Products that make this hard accumulate permanent undocumented holes.
8. What happens when the agent fails? On an older machine, with a full disk, during an upgrade. Ask about performance impact and get a number.
About the awkward parts
9. What personal data does the product collect, and where is it processed? You will need this for your impact assessment. If they cannot answer precisely, that is a problem for your legal team.
10. Can we restrict what our own analysts can see? Metadata review without content access, logged content access as a separate permission, audit of who looked at what. Governance depends on this and not every product supports it.
11. What can we not turn off? Some products bundle screen capture or keystroke logging with functions you do want. If it cannot be disabled, that is a compliance issue in several jurisdictions.
12. How do we get our data out and what happens at the end of the contract? Ask before signing.
What to weight lightly
Machine learning claims without an explanation of inputs and outputs. Ask what it does when a person changes role, and what the baseline period is.
Threat detection percentages. Measured against what, on whose data.
Analyst recognition as a primary criterion. It reflects market presence more than fit for your problem.
Feature count. The products with the longest lists are frequently the hardest to operate, and an unused feature is a cost.
Before the process starts
Write down the three data categories you are protecting and the channels you need covered. Then evaluate against that document, not against a feature matrix.
Vendors will expand your requirements during the process — it is their job — and a written scope from before the first demo is what keeps the evaluation honest.
The comparison nobody runs
Against doing something simpler.
Cloud audit log review, access reduction, and a departing-employee process cost a fraction of a DLP deployment and address a substantial share of real incidents. For some organisations that is the right answer, and it is worth costing before committing to a platform and its operating burden.