Most privacy software regret comes from the same few mistakes: buying a suite for a problem that a spreadsheet and a ticket queue could handle, judging connectors by a logo wall, and signing without an exit plan. Here's how to avoid them.
This piece covers the decisions around the purchase. The line-by-line vendor questions are in the interactive privacy software buyer's checklist, which scores each vendor by section and lists the must-haves still unconfirmed. Use the two together. Read this before you take any demos, then use the checklist during them.
Start with the problem, not the category
Privacy tooling is sold in categories: data discovery, DSR automation, consent management, vendor risk, assessments, and suites that combine them. (For how these fit together, see The privacy tech stack, layer by layer.) Categories are how vendors organize their marketing. Your problem looks more like one of these:
- "We can't answer requests on time." That's a workflow and system-coverage problem. How many requests do you get, how many systems does each one touch, and which step takes longest?
- "We don't know where personal data is." That's a discovery problem. Is the data mostly in a few structured stores, or spread across SaaS apps, file shares and tickets?
- "Our cookie banner probably isn't compliant." That's a consent and tag-governance problem, and often partly a marketing-ops problem.
- "An auditor or a customer asked for our ROPA." That's a documentation problem, and sometimes a one-off.
Write the problem down in a sentence with a number in it: "We get about 40 requests a month, each touches nine systems, and we missed the deadline on six last quarter." That sentence becomes your success criterion, and it stops the evaluation from drifting toward whichever vendor has the nicest dashboard.
Build vs. buy
Building is more realistic than vendors suggest for some problems, and much less realistic for others.
| Problem | Building is reasonable when… | Buying makes more sense when… |
|---|---|---|
| DSR intake and tracking | Volume is low, you already run a ticketing system, and a form plus a workflow with deadline fields covers it. | Volume is high or spiky (agent services can send hundreds at once), or you need identity verification and secure delivery built in. |
| DSR fulfillment (find and delete) | Your data lives in a few systems you control, and engineers can write and maintain deletion jobs. | Requests touch many SaaS tools, each with its own API, and nobody owns maintaining those integrations. |
| Data inventory / ROPA | You have tens of systems, not hundreds, and the main job is interviewing system owners. A structured spreadsheet or wiki works. | Systems change faster than people can update a document, or you need classification of what's actually inside the data. |
| Data discovery and classification | Rarely. Writing good classifiers for names, IDs, health data and free text is a product in itself. | Almost always, if you need it at all. |
| Consent / cookie management | Rarely. Region-specific rules, tag blocking and opt-out signals change too often. | Almost always for consumer-facing sites with marketing tags. |
The honest version of build vs. buy includes upkeep. A homegrown deletion script that covers eight systems today needs someone to update it when the ninth arrives. If no team will own that, the in-house build is the risky option. If you're still working out how much a manual approach costs, the data map cost calculator and What a manual data map really costs give you a baseline to compare quotes against.
How to run the evaluation
- Name an owner and a small panel. One person owns the decision. The panel should include whoever will use the tool day to day (often privacy ops), an engineer who'll integrate it, and security. Procurement and legal join for the contract stage.
- Write requirements as tests. "Supports deletion in Salesforce" is a claim. "Deletes a test contact and its related activity records in our Salesforce sandbox, and logs it" is a test. Mark the handful that are must-haves.
- Shortlist on paper. Use the security and contract basics (assurance reports, hosting regions, the DPA and sub-processor list) to cut the list before anyone spends time on demos. A vendor that can't answer where your data is processed doesn't need a demo.
- Run scripted demos. Send the same scenarios to every vendor in advance and ask them to show those, not their standard tour. Score each with the checklist straight after the call, while it's fresh.
- Do a proof of concept with your systems. Two finalists at most. Connect them to sandboxes or realistic test data and run your must-have tests. Two to four weeks is typical. Set the length in advance so the trial doesn't drift.
- Check references that look like you. Ask for a customer of similar size, using the same core systems. Ask what implementation actually took and what they'd do differently.
- Negotiate with the gaps in hand. Every unticked item on the checklist is either a contract term, an implementation commitment or a known gap you've accepted.
Red flags
None of these rules a vendor out on its own, but each one is worth a direct follow-up question.
In the demo
- The demo only runs on their sample data. If they won't connect to a sandbox during evaluation, you're buying the integration on trust.
- "Automated" means it opens a ticket. Many DSR products automate intake and routing, then hand deletion to a person in each system. That can be fine, but price it as a workflow tool.
- Connector counts with no detail. Ask what each connector can do. Read-only metadata access and full delete capability are very different things.
- The AI classifies everything perfectly. Real data produces false positives and misses. A vendor that can't show you how to correct a misclassification hasn't run on messy data.
- Roadmap answers to must-have questions. "It's coming in Q2" belongs in the contract with a date and a remedy, or it doesn't count.
In security review and the contract
- A trust-page badge instead of a report. Ask for the full SOC 2 Type II report or the ISO/IEC 27001 certificate and its statement of applicability, and read the scope. A report that covers only part of the company or product won't tell you much about the part you're buying.
- Vague hosting answers. "We use AWS" doesn't tell you which region, or where support staff access it from.
- No public sub-processor list, or no change notice. Under GDPR you need to be told about changes and be able to object (see Sub-processor lists).
- Uncapped renewals and auto-renewal with a long notice window. Combined with high switching costs, these are how year-three prices double.
- Export "on request". If only the vendor can produce your export, you don't really have one.
Total cost of ownership
The license is usually the smallest part of what you'll misjudge. A realistic multi-year cost includes:
| Cost line | What to pin down |
|---|---|
| Subscription | The pricing unit (data sources, records, employees, domains, requests, modules), your count today and in three years, and overage terms. |
| Implementation | Vendor fees or partner fees, and whether "implementation" includes building connectors or only configuring them. |
| Internal engineering | Hours to provision credentials, build custom integrations, fix broken connectors and handle upgrades. Get your own engineers' estimate. |
| Operating staff | Who reviews classifications, works the DSR queue, updates the ROPA and answers alerts. Tools reduce this work but don't remove it. |
| Infrastructure | Compute for scanners you host yourself, plus egress and API costs in source systems. |
| Renewal uplift | The cap in the contract, or the risk if there isn't one. |
| Exit | Time to export, migrate and remove agents. You'll pay it eventually, either at the end of this contract or a later one. |
Model each finalist over the same period (three years is common) at your current size and at your growth case. Vendors that price on different units can swap places as you grow.
Before you sign
Go through the contract with the checklist results next to it. At minimum, confirm:
- A DPA that meets GDPR Article 28 and, if you're covered by the CCPA, the service provider terms (see Data processing agreements).
- Data residency or processing-location commitments that match what you were told.
- Breach notification with a stated timeframe.
- A renewal cap and a reasonable non-renewal notice period.
- Export in open formats, a retrieval window after termination, and deletion with confirmation.
- Any must-have the vendor promised but hasn't built yet, written in with a date and a remedy.
None of this is legal advice. Have counsel review the DPA and limitation-of-liability terms, which are where privacy-tool contracts most often differ from a standard SaaS deal.
After the purchase
Plan a 90-day check against the problem sentence you wrote at the start. Are requests closing on time? Does the inventory cover the systems you said it would? If not, raise it while you still have leverage, before the first renewal conversation. For the program around the tool, see Planning a privacy program: the first 90 days. For a working approach to the DSR queue itself, see Handling data subject requests.