# The Data Provider Vetting Standard: What a Source Must Prove Before You Buy

*You can grade any prospective data provider pass or fail on sourcing, lawful basis, rights handling, and accuracy, so two reviewers reach the same verdict.*

- Canonical URL: https://www.refolk.ai/guides/data-provider-vetting-standard
- Pillar: Process, data, and compliance
- Format: Standard
- Published: 2026-08-05
- Last reviewed: 2026-08-05
- Reading time: 16 min

## Key takeaways

- Under CCPA regulations Section 7051, a service-provider contract missing any of its nine mandatory terms is not weak paper, it legally reclassifies the transfer as a sale or share and shifts opt-out and notice liability onto the buyer.
- High-quality B2B data providers should deliver 97%+ accuracy with hard bounce below 1%, against an industry average accuracy near 50%, so sample-test the claim rather than accept it.
- GDPR Article 14 forces the buyer to name the source of purchased personal data, so a provider that cannot document source category, collection date, and lawful basis makes the buyer's first-touch notice impossible.
- Regulators grade the supplier's supplier: the ICO faulted Experian's provenance vetting, not its intentions, making documented sourcing an enforcement trigger rather than a nicety.
- In Refolk's index, US professionals listing CCPA as a skill number 440 against 1,219 listing GDPR, so vet US-law coverage specifically instead of treating GDPR fluency as proxy for it.
- A clean sample can hide a dirty database because catch-all addresses pass standard verifiers, so demand catch-all handling detail alongside any headline accuracy figure.

Before you sign with a people or company data provider, someone has to decide the vendor is safe to buy from - not lawful to send once you hold the data, but safe as a source, on the record. This standard is for recruiting operations, revenue operations, and anyone who will have to answer for how the data was gathered. It gives you a single pass/fail rubric and evidence checklist so a vendor is approved or rejected on documented, verifiable criteria, and so two reviewers grading the same vendor reach the same verdict.

Most GDPR outbound material starts after the data is already in your CRM. This one stops at the moment before purchase and grades the provider as a company: what it can prove about where each record came from, what contract it will sign, whether its rights handling actually works, and whether its accuracy claim survives a controlled test.

## What "safe to buy from" means

A provider is safe to buy from when it can document sourcing, name a lawful basis, honor data-subject rights on demand, and pass a controlled accuracy test - all before any data moves. If any one of those fails, the vendor fails, regardless of how polished its trust page looks.

These four are not preferences. They map to obligations that fall on you the moment you receive the data. GDPR Article 14 governs personal data obtained from sources other than the data subject - public records, brokers, third parties, or scraping - and requires you to tell each person the source of their data, whether it came from a publicly accessible source, and the categories of data held. You cannot make that disclosure if the provider cannot document source category, collection date, and lawful basis per field. The provider's transparency is the precondition for your transparency.

The grading dimensions and what each proves:

| Dimension | What a pass proves | What a fail looks like |
|---|---|---|
| Provenance | Every field maps to a named source | "Proprietary aggregation" answers |
| Lawful basis | The vendor can state the basis per source | "GDPR compliant" badge, no explanation |
| Rights handling | Opt-out and erasure tested and holding | Suppression applied to one campaign only |
| Accuracy | 97%+ on a sample, bounce under 1-2% | ~50% market-average accuracy |

> **Rule:** The contract gates the data, not the other way round
>
> Require the DPA and the CCPA Section 7051 terms before any records move. Under GDPR the DPA must be in place before processing begins, and under CCPA a missing mandatory term reclassifies the transfer as a sale.

## Why the contract is the compliance object, not a formality

The written contract is not paperwork that follows a good decision - it is the object regulators grade first, and a gap in it can convert you from a buyer into a seller. Treat the DPA and the CCPA service-provider terms as the gating artifact, in hand before you accept a single record.

On the GDPR side, Article 28(3) requires the DPA to set out the subject-matter and duration of the processing, its nature and purpose, the type of personal data, and the categories of data subjects. It then imposes eight processor obligations: the processor acts only on documented instructions, ensures personnel confidentiality, assists with data-subject rights, deletes or returns data upon termination, and allows for audits, alongside security measures under Article 32 and sub-processor flow-down. An Article 28 breach sits in a fine tier of up to EUR 10 million or 2% of global turnover.

The US side has a sharper edge. Section 7051 of the CCPA regulations lists nine mandatory terms that every contract with a service provider or contractor must contain, in force since March 2023. If the paper is not right, the consequence is structural rather than cosmetic:

**9 - mandatory Section 7051 terms a CCPA service-provider contract must contain**

Miss any one and the transfer legally becomes a "sale or share", cascading into opt-out, notice, and downstream liability.

That is the trap. A paperwork gap does not merely weaken your position - it silently reclassifies the transfer as a sale or share, which cascades into opt-out obligations, notice obligations, and downstream liability. A missing clause converts the buyer into a seller. This is why classification comes first: decide whether the provider is a controller or a processor/service provider, then demand the matching contract before anything else happens.

One more contract failure hides in plain sight: the generic DPA. Boilerplate that does not describe your actual processing does not satisfy the regulation. Each clause must be specific to the concrete processing relationship - the data types, the purposes, the categories of people. A template with the vendor's name dropped in is a fail even when every heading is present.

## How to test provenance so a dodge cannot pass

Provenance is proven one field at a time, by asking where each record came from and requiring a named source in reply. A real answer names sources; a dodge - "proprietary AI aggregation", "proprietary data" - is itself the red flag.

Run the provenance test as a fixed question set, per field or per field category, and record the answers verbatim. For each of contact, contract, and usage data, you want four things: the source category, the collection date, the lawful basis, and any onward-sharing history. German regulator commentary on Article 14 is explicit that the extra content beyond Article 13 is the categories of personal data and the origin of the data - the data source, for example whether it came from publicly accessible sources. If the vendor cannot give you that, you cannot write your notice.

The Experian enforcement action is the reason this matters beyond theory. After a two-year data-broking investigation, the ICO issued an enforcement notice on 27 October 2020 and ordered Experian to stop processing personal data of any individual who had not been sent an Article 14-compliant notice, with over 30 million profiles flagged as available to sell for marketing. What the regulator faulted was the provenance process itself: Experian checked supplier privacy notices every three months, one supplier every six, and the ICO found the sampled notices unsatisfactory. The First-Tier Tribunal largely overturned the notice in 2023 and the ICO said it would appeal, so the law here is not fully settled - but the mechanism is the lesson. Regulators grade the supplier's supplier, and thin provenance vetting is an enforcement trigger, not a hypothetical.

> A vendor that cannot name the source and lawful basis for a record is not offering data, it is offering your liability.

#### The provenance-to-notice chain

1. **Source named** - Vendor states where each field came from
2. **Basis stated** - Vendor names the lawful basis per source category
3. **Metadata handed over** - Buyer receives source category and collection date
4. **Notice drafted** - Buyer writes an Article 14 notice from that metadata

*If any link is missing, the buyer's Article 14 first-touch notice cannot be written.*

Your test for Article 14 supportability is concrete: can you draft a sample first-touch notice from the metadata the provider supplies? The notice must name the source and the categories of data, and it must reach the person within one month of obtaining the data, at first communication, or before first disclosure to another recipient, whichever is soonest. If you cannot draft it from what the vendor gave you, the vendor has failed this criterion.

## The accuracy and freshness benchmarks you can actually test

Accuracy is a claim until you sample-test it, and there are published baselines that make the test objective. High-quality B2B data providers should deliver 97%+ accuracy with email bounce rates below 1%, against an industry average of only 50% accuracy from most providers. Take a representative sample, verify it yourself, and grade against those numbers.

Deliverability thresholds are external and enforceable, which is what makes them useful - they are set by the mailbox providers, not the vendor. Most ESPs begin flagging accounts when hard bounce rates exceed 2% consistently, rates above 5% trigger active account review, and rates above 10% risk immediate suspension. A dirty list is not just wasted spend; it is a direct threat to your sending reputation.

| Metric | Pass | Fail signal |
|---|---|---|
| Hard bounce on sample | below 1-2% | above 5% |
| Provider accuracy | ~97%+ | ~50% (market average) |
| Annual decay | ~22.5% | above 40% |

On freshness, anchor on a sourced baseline. HubSpot's Database Decay Simulation, built on MarketingSherpa research, puts monthly B2B contact decay at 2.1%, compounding to about 22.5% a year. Estimates in the wild range from 22% to over 40%, and a widely repeated "70.3% a year" figure attributed to Gartner does not trace back to any Gartner report. Treat any extreme decay number a vendor cites to sell you "continuous refresh" as a provenance test in itself: ask for the source. If it does not trace, discount it.

> **Watch out:** A clean sample can sit on a dirty database
>
> Catch-all addresses pass standard verifiers as valid but carry material bounce risk, and 23-31% of B2B databases contain them. Lists verified more than six months ago show an average 8-12% increase in invalid addresses. Ask how the vendor handles catch-alls and when the sample was last verified, not just the headline accuracy percentage.

## Grade the vendor's own privacy staffing

A vendor's "privacy team" is a signal you can weigh, but it is not evenly distributed across jurisdictions or across the two regimes you care about. Grade it deliberately, because a team that looks strong on GDPR may be thin exactly where your US exposure sits.

Two patterns from Refolk's index are worth putting in front of a vendor claim. First, dedicated Data Protection Officer staffing tracks the legal mandate for it:

| Country | DPO titleholders | Derived index (US=1.0) |
|---|---|---|
| United States | 78 | 1.00 |
| Germany | 201 | 2.58 (derived) |

Germany, with a mandatory-DPO regime, shows 2.58 times the DPO-titled staffing of the US in Refolk's index. So when a US-based vendor describes an equivalent DPO function, weigh that against the base rate. Its self-described DPO role may be materially lighter than an EU counterpart's, and you should ask what the person actually does day to day.

Second, US-law coverage is thin relative to GDPR coverage, and the sale/share risk lives on the US side.

**440 - US professionals listing CCPA as a skill in Refolk's index**

Against 1,219 listing GDPR - CCPA-skilled talent is roughly one-third the GDPR pool (36%, derived).

That gap matters because a vendor's privacy staffing may be GDPR-weighted while your California exposure - where a missing Section 7051 term reclassifies your transfer as a sale - is under-covered. Vet US-law coverage specifically. Do not accept GDPR fluency as a proxy for CCPA competence.

I ran this search: `Compliance or data governance leaders at US contact-data providers who list CCPA experience` - [see the full result list](https://www.refolk.ai/s/rr2k9aaq2x).

*Returns named people at data providers whose profiles claim CCPA-specific coverage, so you can check whether a vendor's US-law staffing is real before you take its word for it.*

When you need to confirm a vendor's stated privacy function against who actually holds those roles, [Refolk](/) resolves the question in plain English rather than from the vendor's own org chart. Ask for the roles you care about at the kind of company you are buying from, and grade the answer against the vendor's claim.

## The vetting procedure, step by step

Run these seven steps in order. Sources differ on whether the contract or provenance comes first - the vendor guides lead with sourcing transparency, while legal frameworks treat the written contract as the gating artifact. This standard treats the contract as the gate, because a paperwork gap carries the sale/share liability, but interrogate provenance immediately after and stop the process if either fails.

#### Grade a data provider before purchase

1. **Classify the relationship and demand the contract** - Decide controller vs processor/service provider, then require the DPA and CCPA Section 7051 terms up front. Done = a DPA meeting Article 28(3) and a Section 7051 clause set are in hand before any data moves. (Legal/RevOps, 1-2 days.)
2. **Interrogate provenance per field** - Ask per field for source category, collection date, lawful basis, and onward-sharing history. Done = every field maps to a named source; "proprietary aggregation" answers fail. (Data/Compliance, 1-2 days.)
3. **Confirm Article 14 supportability** - Verify the provider gives enough metadata to draft a first-touch notice naming source and data categories. Done = a sample notice can be written from provider-supplied metadata. (Compliance, 1 day.)
4. **Run a controlled sample test** - Take a representative sample, verify emails, and measure hard-bounce and match rates against the accuracy claimed. Done = bounce under ~1-2% and accuracy near 97% on the sample. (Ops, 3-5 days.)
5. **Test suppression and DSAR** - Seed a record, submit an opt-out and an erasure request, and confirm timing and that suppression persists into later files. Done = deletion confirmed within one month, opt-out within 15 business days, seed stays suppressed. (Compliance/Ops, up to 1 month.)
6. **Audit security and sub-processors** - Review transfer method, retention and deletion terms, sub-processor list and flow-down, and transfer mechanism such as SCCs. Done = no shared accounts or unprotected files; a sub-processor notice workflow exists. (Security, 2-4 days.)
7. **Grade pass/fail and record** - Both reviewers score against the rubric independently, and disagreement forces a re-check. Done = a signed verdict on the record. (Two reviewers, 1 day.)

The rights test in step five deserves its own note. The provider must support erasure and objection, and you verify it by testing, not by reading the policy. Seed a record you control, submit a deletion and an opt-out, and confirm the deadlines hold: organizations must respond to a deletion request without undue delay and within one month of receipt, extendable by two months for complex or numerous requests with notice; CCPA requires opt-out action within 15 business days. Then confirm the harder thing: that suppression persists across every future file, not just the campaign where the opt-out was raised. Where resold data has been shared with other controllers, Article 19 obligates the primary organization to inform them of the erasure request unless doing so is impossible or disproportionately difficult.

## How this goes wrong: the failure modes

Most vetting fails not on the obvious rejects but on vendors that pass on paper and fail on substance. Each of these has a false positive that looks like a pass, and a specific check that catches it.

| Failure mode | Looks like | The check |
|---|---|---|
| Compliance by slogan | Polished "GDPR compliant" trust page | Ask for the lawful basis per source category; the vendor cannot explain it |
| Provenance dodge | "Proprietary AI aggregation" reads as sophistication | A real answer names sources; a dodge is the red flag |
| Clean sample, dirty database | Sample verifies fine | 23-31% of B2B databases carry catch-alls verifiers pass as valid |
| Stale "verified" list | A recent verification date | Lists verified 6+ months ago show 8-12% more invalid addresses |
| Opt-out that does not stick | Confirmation email for one campaign | Seed a record and confirm it stays suppressed across later files |
| Generic DPA | All the right headings present | Each clause must describe the concrete processing, not a template |
| Service-provider paper that is really a sale | A signed contract | A missing Section 7051 term silently reclassifies the transfer and shifts liability |

Two of these are worth extra weight. The catch-all problem is the reason a clean sample cannot be the whole accuracy test: HCP lists without catch-all verification produce hard bounce rates 2.4 times higher, so a sample that verifies at 97% can still bounce in production if the database is full of catch-alls the verifier waved through. Demand catch-all handling detail.

And the unsourced decay stat is a tell. A vendor that anchors its pitch on a scary refresh number with no traceable source is failing a provenance test on its own marketing. Anchor your planning on sourced numbers, not the scariest number in a vendor's sales deck. If the vendor cannot source its own claims about the market, question its claims about its data.

> **Tip:** Make the reviewers grade blind of each other
>
> Have both reviewers score against the rubric independently before comparing. Where they disagree, the disputed criterion gets re-checked rather than negotiated. This is what makes two people reach the same verdict on the same vendor.

## The pre-purchase checklist

Before you record a pass, confirm every item below. A single unchecked item is a fail, not a discussion point - that is what keeps two reviewers aligned.

#### Verify before you sign

- [ ] The relationship is classified (controller vs processor/service provider) and documented
- [ ] A DPA meeting Article 28(3) is signed and describes the actual processing, not a template
- [ ] A full CCPA Section 7051 nine-term clause set is present
- [ ] Every field maps to a named source, collection date, and lawful basis
- [ ] A sample Article 14 notice can be drafted from provider-supplied metadata
- [ ] A representative sample tests near 97% accuracy with hard bounce under 1-2%
- [ ] Catch-all handling is documented and the sample's verification date is under 6 months
- [ ] A seeded opt-out was honored within 15 business days
- [ ] A seeded erasure was confirmed within one month and persisted into later files
- [ ] Sub-processor list, flow-down, and transfer mechanism (SCCs) are reviewed
- [ ] Two reviewers graded independently and a signed verdict is on the record

## Keeping the verdict current

A pass is a snapshot, not a permanent status, because the data decays and the vendor's practices change. Re-run the parts that go stale on a schedule you set at signing, and keep the evidence file with the contract so the next reviewer inherits the record rather than starting over.

Three things drift and need a defined re-check. Accuracy and freshness drift with decay: re-sample against the same thresholds at least twice a year, given the 8-12% invalid-address increase on lists older than six months. Rights handling drifts as the vendor changes systems: re-seed an opt-out and an erasure annually and confirm the deadlines still hold. And the legal surface moves: the US state-privacy landscape changes over time, so re-confirm that the vendor's contract still covers the states where you have exposure rather than assuming last year's Section 7051 set is enough. When any re-check fails, the vendor drops back to "under review" until it passes again - the same standard, applied to a vendor you already bought from.

## Frequently asked questions

### How do I vet a data provider before signing?

Grade the provider on four things before purchase: documented provenance per field, a lawful basis you can name, working data-subject rights handling, and accuracy you have sample-tested. Require the contract first, because under GDPR the DPA must be in place before processing begins and under CCPA a missing Section 7051 term reclassifies the transfer as a sale. Run all seven procedure steps, then have two reviewers grade independently and record a signed verdict.

### What clauses must a data processing agreement contain?

GDPR Article 28(3) requires the DPA to state the subject-matter, duration, nature and purpose of processing, the type of personal data, and the categories of data subjects, plus eight processor obligations covering documented instructions, confidentiality, rights assistance, deletion or return, audits, security under Article 32, and sub-processor flow-down. For US coverage, the CCPA regulations Section 7051 list nine mandatory service-provider terms. Each clause must describe the actual processing, not read as a generic template.

### What accuracy and bounce rate should I expect from a good vendor?

High-quality B2B data providers should deliver 97%+ accuracy with hard bounce below 1%, against an industry average near 50% accuracy. Test it on a representative sample rather than accepting the claim. Watch the external deliverability thresholds too: most ESPs begin flagging accounts above 2% hard bounce, review above 5%, and risk suspension above 10%, so a dirty list threatens your sending reputation directly.

### What are the biggest red flags in a data vendor?

The named red flags are unclear sourcing that hides behind phrases like 'proprietary data', compliance by slogan where the vendor claims 'GDPR compliant' but cannot explain the lawful basis, refusal of a controlled sample test, volume without a stated methodology, and no suppression workflow to accept a do-not-contact file. Scraped-and-sold lists are the biggest risk: if a vendor cannot name the source and lawful basis for a record, assume it is non-compliant.

### How do I verify a vendor actually honors opt-outs and deletions?

Test it. Seed a record you control, submit an opt-out and an erasure request, and confirm the timing holds: CCPA requires action within 15 business days and GDPR expects a response within one month, extendable by two months for complex requests. Then confirm the suppression persists into later files, not just the campaign where the opt-out was raised, since one-campaign suppression is a common failure.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/data-provider-vetting-standard*