DPO Checklist for Sales Tools: What to Verify

Sylvain Charmet · Co-founder, Enrich-CRM

Created September 17, 2026

What Is a DPO Checklist for Sales Tools?

A DPO checklist for sales tools is a fixed set of questions covering data source, server location, retention, legal basis, sub-processors, and contract terms that a data protection officer uses to evaluate any vendor handling personal data before approving a purchase. It exists so compliance review doesn't depend on remembering to ask the right thing on the fly.

The Core DPO Checklist: 8 Questions Before You Buy

These are the questions worth bringing to the vendor call yourself, before your DPO has to ask them for you.

Where is the data collected from, and when? Was this contact's information gathered in advance and stored in a database, or looked up on demand when you queried it? The answer changes who needs a legal basis for what, and when.
Where are the servers, and where is data processed? A vendor processing EU personal data on EU infrastructure sidesteps the cross-border transfer question. A US-based vendor processing the same data needs a valid transfer mechanism (typically Standard Contractual Clauses) and a documented risk assessment.
What's the retention policy? Ask specifically: how long is a record kept after it's returned to you, and is there a deletion path if you ask for one.
Is there a Data Processing Agreement, and can you get it without a sales call? A DPA that requires three emails and a demo booking to produce is itself a data point about how the vendor treats compliance internally.
Are sub-processors documented publicly? Every integration a sales tool connects through — a CRM sync, an enrichment API, an automation platform — is a data flow your DPO needs on record. If the vendor can't produce the list, you can't either.
What's the legal basis for processing, and can the vendor explain it in one sentence? For B2B professional contact data, this is almost always legitimate interest, not consent — but the vendor should be able to say so plainly, not shrug it back to you. Our legal basis for data enrichment guide walks through why.
How does the vendor handle a deletion or access request? GDPR gives individuals the right to ask what's held about them and to have it corrected or removed. A vendor that can't describe this process in under a minute probably hasn't built one.
Is pricing and contract structure transparent? Not a legal question on its own, but a vendor that hides pricing behind "book a demo" tends to be less forthcoming on the other seven questions too — it's a useful proxy signal.

If the tool also surfaces signals — a job change or a buying-intent trigger tied to a named person — apply the same eight questions to that data specifically. Signal data about an individual is still personal data, and it usually comes from a different source than the core contact record, which means it can have a different answer to question one.

Red Flags That Should Stall a Purchase

Some answers are worth pausing the deal over rather than working around:

"We'll send the DPA after the contract is signed." A DPA is a prerequisite to processing, not a follow-up item.
No answer on where servers are located, or an answer that changes between the sales call and the documentation.
"We don't really have a retention policy — we just keep everything." This is a data minimization problem waiting to become an audit finding.
Sub-processor list only available on request, and the request goes unanswered. If a vendor can't tell you who else touches your data, you can't tell your own customers either.
The vendor markets itself as having "millions of pre-verified contacts" with no explanation of how or when that data was collected. That phrasing is usually a sign of a stored-database model built before any customer asked for it — worth a direct question about the original collection basis, per the GDPR compliant prospecting guide.

None of these automatically disqualify a vendor. Plenty of stored-database providers operate lawfully with proper contracts in place. But a vague or delayed answer to any of them is a reason to keep asking, not a reason to sign.

How to Bring Sales and Compliance to the Same Table

The checklist works best when it isn't a gate sales hits after they've already picked a favorite. A few practical habits close that gap:

Loop the DPO in at shortlist stage, not contract stage. Send the eight questions to two or three vendors before a demo is even booked. Vendors that answer quickly and in writing are already telling you something.
Ask for the answers in a document, not a call. A sales rep improvising an answer to "where are your servers" on a live call is a weaker record than a written line in a security page or trust center.
Treat integrations as part of the review, not an afterthought. A real-time enrichment tool that connects to your stack through HubSpot, Clay, Zapier, Make, n8n, a REST API, or a CSV export adds a data flow at each connection point — worth naming explicitly in the checklist rather than assuming it's covered by the main contract.
Re-run the checklist at renewal, not just at purchase. Vendors change infrastructure, get acquired, or add sub-processors. A checklist that was accurate a year ago isn't automatically accurate today.

FAQ

What questions does a DPO ask about a new sales tool?

Primarily: where the data was collected and when, where it's processed and stored, what the retention period is, whether a DPA is available, who the sub-processors are, what legal basis applies, how deletion requests are handled, and whether pricing and contract terms are transparent. The eight questions above cover all of these.

Both, in practice. Sales typically drives the vendor selection and negotiates the deal; the DPO or legal team reviews the data protection terms before signing. The checklist works best as a shared document both sides use from the shortlist stage onward, rather than something legal applies retroactively to a vendor sales has already committed to.

Does a small sales team need a formal DPO checklist?

Not a formal DPO role necessarily, but the same questions apply regardless of company size — GDPR doesn't have a small-business exemption for processing EU personal data. Even a two-person sales team evaluating an enrichment tool should ask about server location, retention, and legal basis before connecting it to a CRM full of contact data.

What's the difference between reviewing a data enrichment tool and a stored contact database?

The core checklist is the same, but question one — where the data was collected and when — carries more weight for a stored database, since the vendor collected and held that data before you ever asked for it. A tool that looks up records on demand, rather than maintaining a standing database, has a shorter answer to most of the retention and collection questions by design.

Should the checklist cover data enrichment vendors differently from cold email tools?

The underlying questions are identical — source, location, retention, legal basis, sub-processors, DPA — but the answers matter more for enrichment vendors specifically, since they're the ones adding or verifying personal data (a phone number, a verified email, a job title) rather than just sending messages to data you already hold.

Want to see how a vendor answers this checklist before you even get on a call? Create a free Enrich-CRM account — 100 credits per month, no credit card required, EU servers in Paris, and paid plans from €29/month.