Vendor Security Reviews for Signup Enrichment: What to Actually Ask

The review that shows up after growth already picked a vendor

The usual order of events: a growth manager finds an enrichment tool, runs a trial, likes the ICP scores it produces, and loops in security to get a contract signed. Security's first question is almost never about accuracy. It's "what happens to our signup data once it leaves our database?"

That question is reasonable, and it's also where most enrichment rollouts stall for weeks, because nobody on the growth side came prepared with an answer. Not because the vendor is doing anything wrong (most aren't), but because "we send emails to a third-party API and get job titles back" is not an answer a security team can sign off on.

This post is the list growth managers should work through before that call, not during it. None of it requires a security background. It requires knowing what to ask and recognizing a dodge when you hear one.

What SOC 2 actually tells you

A SOC 2 report gets treated as a pass/fail stamp. It isn't one. It's an audit of specific controls against criteria the vendor chose, covering a specific period, performed by a specific firm. All three of those details change what the report means for you.

Type I vs Type II. A Type I report says the vendor's controls were designed correctly on one date. A Type II report says those controls actually operated correctly over a window of time, usually six to twelve months. Type I is a starting point. For a vendor handling your users' professional data on an ongoing basis, you want Type II. You also want to know how many they've issued; a vendor on their first Type II report has a shorter track record than one three reports in.

Trust service criteria. SOC 2 reports are scoped to one or more of five criteria: security, availability, processing integrity, confidentiality, and privacy. "We have a SOC 2 report" doesn't tell you which of these it covers. A report scoped to security and availability says nothing about how the vendor handles data deletion requests. Ask which criteria are in scope before you ask to see the report.

The exceptions section. Skip straight to it. Every real SOC 2 report has some noted exceptions — a control that didn't operate as designed for part of the period. A report with zero exceptions after a long observation window is a mild red flag by itself; it can mean the scope was drawn narrowly enough to avoid finding anything. What matters is whether the vendor explains the exception and what they changed afterward.

Sub-processors: enrichment vendors chain other vendors

Signup enrichment is rarely one company doing everything in-house. A typical pipeline touches a data provider for firmographic lookups, a separate provider for LinkedIn-adjacent profile data, cloud infrastructure for storage and compute, and sometimes a third service for email verification. Each of those is a sub-processor, and each one that touches personal data extends your compliance exposure, not just the vendor's.

Ask for the current sub-processor list and how you're notified when it changes. A vendor that can rattle off their sub-processors by name, with what each one does, has actually mapped their own data flow. A vendor who says "we use industry-standard providers" without naming them either hasn't mapped it or doesn't want to.

This connects directly to the data processing obligations your own company carries under GDPR and similar laws: you're the controller, the enrichment vendor is your processor, and their sub-processors are processors once removed. If one of them has a breach, it's your users' data in the headline, not just the sub-processor's name.

Where the lookups actually happen

Data residency gets treated as a checkbox — "do you store data in the EU, yes or no" — but the real question is narrower: where does each type of data live, and for how long, at each stage of the pipeline.

A signup enrichment flow usually has three stages worth asking about separately:

1. In-flight lookup. The vendor queries one or more data sources to resolve an email or domain to a company and profile. Where does this request originate, and does it pass through infrastructure in a region your contract doesn't cover?
2. Result storage. Once resolved, the enriched record (name, title, company, LinkedIn URL, confidence score) lands in a database. This is usually the long-lived copy and the one that matters most for residency commitments.
3. Logs and caches. Request logs, API response caches, and retry queues often hold a shadow copy of the same data with a separate (and frequently longer) retention period that nobody thinks to ask about.

If your contract says EU data stays in the EU, confirm that applies to all three stages, not just the primary database. Log retention is where this quietly breaks.

The data processing agreement: five clauses that matter

Most DPAs are templates, and most of the template is boilerplate neither side reads closely. Five sections are worth actually reading line by line:

• Processing purpose and scope. Does it name the specific use (signup enrichment, ICP scoring, teammate discovery) or is it generic enough to cover anything the vendor decides to do later?
• Sub-processor flow-down. Does the vendor commit to imposing the same data protection terms on their own sub-processors, or just on themselves?
• Breach notification window. 72 hours is the common standard tied to GDPR's own notification clock to regulators. A DPA that's silent on timing, or vague ("promptly"), pushes the risk back onto you.
• Deletion mechanics. Can they delete a single individual's record on request, within a stated timeframe, and confirm it in writing? Or does deletion only happen at contract termination for the whole dataset?
• Audit rights. Can you request evidence of their security controls (the SOC 2 report, a penetration test summary) during the contract term, not just at signing?

If a vendor's legal team pushes back hard on any of these five, that's useful information before you've paid them, not after.

The questions worth asking on the actual call

A short list that tends to surface real answers instead of marketing language:

• "Walk me through what happens to one signup's email address from the moment it hits your API to the moment the enriched record is stored." A vendor who can answer this in under two minutes, specifically, has actually thought about their own pipeline.
• "If I ask you to delete one person's data today, what's the process and how long does it take?" Listen for whether the answer names a system, not just a policy.
• "What's your most recent SOC 2 exception, and what did you change afterward?" This is a trust question more than a compliance one — a vendor who answers directly instead of deflecting is usually the safer bet regardless of what the report says.
• "Do you keep raw source data (scraped pages, API responses) after resolving the enrichment, and for how long?" This is where confidence and provenance tracking either exists or doesn't — vendors that store source attribution tend to also have a cleaner answer on retention, because they built the data model to support both.

Red flags that should stall a deal, not just slow it down

• No SOC 2 report of any type, and no alternative framework (ISO 27001, a recent third-party pentest) offered in its place.
• A sub-processor list the vendor won't share without a signed NDA before you've even seen pricing.
• "We don't really do deletion requests, it's a shared database" as an answer to the deletion question.
• A DPA that references data protection terms "available on request" instead of attaching them.
• Reluctance to say which cloud provider and region host the primary database.

None of these mean the vendor is acting in bad faith. Plenty of smaller enrichment providers haven't built this muscle yet because nobody asked. But that's exactly the gap you're trying to find before signing, not after your users' data is already in their system.

A rollout checklist before enrichment goes live

• SOC 2 Type II report received and the in-scope trust criteria confirmed.
• Sub-processor list reviewed, including what each one does with your data.
• Data residency confirmed for storage, logs, and caches — not just the primary database.
• DPA reviewed line by line on purpose, sub-processor flow-down, breach notice window, deletion, and audit rights.
• Deletion process tested with one real request before go-live, not assumed to work.
• Named point of contact on both sides for security incidents and data requests.

Where this fits with the rest of the enrichment stack

A security review is not a separate project from signup enrichment. It's the part of the rollout that decides whether the ICP scoring and routing work you're excited about actually ships on schedule. Teams that treat it as paperwork to get through tend to hit the same questions again at renewal, usually from a different security reviewer who wants the answers documented this time. Teams that build the checklist into vendor selection the first time mostly don't revisit it.

Groful tracks source and confidence on every enriched field and documents sub-processors and deletion mechanics as part of standard onboarding, which covers most of this list before the question gets asked. If you're running your own vendor review right now, the pricing page has the plan-level specifics, or reach out directly with your specific residency or audit requirements and we'll answer them in writing before you sign anything.