
Tools and providers
Part of How to vet the tools behind lead generation networks
Lead generation networks vendor due diligence checklist
Lead generation networks vendor due diligence: check UK GDPR, PECR, assurance reports, lead provenance, suppression and exit evidence before approval.
This checklist helps a UK buyer inspect a lead generation network before approving it. Seven working terms come first, then the review steps, and the ten consolidated checks sit at the end.
Evidence boundary: The contracting entity, product, edition, subcontractors and contract set covered by the review.
Tenant scope: The configured service and systems included in an assurance claim, rather than the supplier as a whole.
Source record: A lead's origin, collection wording, timestamp and intended recipients.
Processing role: The decisions each party makes about purposes, recipients and data operations.
Suppression state: The continuing application of objections and exclusions across routing, export and later use.
Synthetic fixture: A non-live case for testing routing, access, suppression, incident evidence or export.
Exit proof: Evidence that records can be recovered, suppression retained and deletion completed along agreed paths.
Start with scope, then gather evidence
Fix the review boundary before evaluating a supplier: name the contracting entity, product and edition, subcontractors, and contract set. Then map the configured journey from collection to storage, routing, export, suppression and deletion. This defines which product configuration each request and answer must actually address.
Use the records request as an index, then check that each item applies to the product and configuration being assessed. Give privacy, security, service, accessibility and commercial review to named owners, with a way to verify each response. An answer without an owner remains unresolved.
Scope and ownership assignments
- Procurementlegal entity, product, subcontractors, contract set
- Service ownercollection, storage, routing, export, suppression, deletion
- Privacy counselroles, purposes, recipients, transfers
- Securitysystems, access paths, logs, recovery, incident contact
- Accessibilitybuyer journeys and assistive-technology tests
Judge assurance by tenant scope
Tenant scope shows whether an assurance claim relates to the service being considered. A certificate, summary or supplier-wide report is not enough unless it covers the relevant product, configured tenant, review period and exclusions. Record any exceptions and remediation status, and seek evidence that can be inspected.
Possible independent evidence includes an ISO 27001 certificate, SOC 2 Type II report, Cyber Essentials Plus certification, or an equivalent assessment. Check product coverage, test period, exclusions and remediation status. A summary alone cannot establish whether the purchased configuration was within scope or whether its security controls were assessed.
For security review, compare claimed controls with the CAF principles and guidance, and record which evidence applies to this tenant. Match the request to service criticality and access. The supplier tool review can help frame questions about the products and systems behind the service.
Follow the source record through each role
Keep each source record connected to the lead as it moves through collection and onward use. Preserve its origin, collection wording, timestamp and intended recipients, then identify who decides matching, enrichment, contact and reuse. Role labels alone do not establish responsibility; compare them with the operations the configured service performs.
Use the data route to compare stated roles with actual data handling, and compare the service description with the contract records. Contract wording cannot turn an independent controller into a processor. The controller and processor guidance can inform review of the roles and instructions described for the service.
The UK GDPR principles and Data Protection Act 2018 provide the baseline. The Data (Use and Access) Act 2025 also makes it necessary to check which provisions are in force for the processing or marketing activity. Use the UK rules in England to check the purposes, recipients and transfers in scope.
Carry permission into the suppression state
Check whether the permission claimed for a source supports the buyer, intended recipient and proposed contact channel.
A supplier warranty does not show that people were told about the buyer or that the planned contact is permitted. Exclusions and objections need to remain effective throughout the route, not just at collection.
For electronic mail, check the relevant ICO guidance and PECR rules for unsolicited direct marketing. Record the lawful basis claimed, consent evidence or a valid soft opt-in where applicable, the subscriber type and channel rules. For live calls, check screening against TPS or CTPS. Test the permission statement against the actual buyer and intended use.
Test objection propagation without contacting real people. Set retention by purpose and check deletion from live data, exports and agreed backup paths. Connect each processor instruction to the system behaviour it should control, then retain evidence that suppression persists after routing. A policy description alone does not demonstrate that the configured route preserves the suppression state.
Check whether each party must pay the data protection fee, noting that exemptions apply, and screen for high-risk processing that may require a DPIA. For restricted international transfers relying on appropriate safeguards, record the transfer mechanism, such as the ICO's International Data Transfer Agreement (IDTA), the UK Addendum to the EU standard contractual clauses or a UK adequacy regulation, and complete the required transfer risk assessment. Resolve these checks against the processing that will actually take place.
Exercise the configured journey with a synthetic fixture
A synthetic fixture lets reviewers test the configured journey without using real people. Use it for routing, suppression, access, incident evidence, accessibility and export, and compare expected results with what the service actually does. Keep the tested configuration identifiable so that a later change does not inherit approval automatically.
Test the implemented form with keyboard navigation, screen magnification and representative screen readers. Check labels, instructions, error identification, focus order, timeout and confirmation in the buyer's embedded experience. Supplier test results cannot establish that the configured page and its wording work as intended for the people using it.
Use WCAG 2.2 as the technical reference, but retain expected and observed results from the actual configuration. Keep accessibility alongside provenance and advertising review using the quality gates. Include buyer-facing wording so unsupported claims cannot pass simply because the form operates correctly.
Compare the public proposition with the contract and system behaviour. Do not imply a verified provider, guaranteed response or outcome without supporting evidence. Keep consumer-facing wording in the review record, and give responsibility for reviewing that wording to someone distinct from the person who tested the technical journey.
Make exit proof a condition of release
Treat exit proof as a release condition, not a later task. Require a sample export and a defined route to recover essential evidence, retain suppression and leave the service without manual reconstruction. If these outcomes cannot be demonstrated, hold the purchase rather than assume exit will work.
The sample export should contain the agreed records, relationships, timestamps, consent or notice evidence, suppression state and audit history. Specify its format, delivery owner, retrieval period, assistance, deletion certificate and unresolved complaint route. Check that the required material can be recovered before production use, rather than accepting a supplier response that only describes the intended process.
Use this synthetic acceptance checklist before approval:
- Test routing, suppression, access, incident evidence, accessibility and export with synthetic cases.
- Keep each expected result beside the observed result.
- Name the rollback owner and record the last verified configuration.
- Require a fresh review after a new source, recipient, integration, subprocessor or product release.
Run the synthetic launch tests without contacting real people. Tie the change record to the configuration tested, so approval for one setup is not treated as approval for a later version with different sources, recipients or integrations.
The consolidated vendor checklist
Use these ten checks as one list before approval. Each maps to a section above.
- Entity and scope.Name the contracting entity, product, edition and subcontractors, and check the company on Companies House.
- Registration.Check the supplier appears on the ICO register of fee payers, and on the Financial Services Register if the leads concern regulated products.
- Assurance.Ask for ISO 27001, SOC 2 Type II or Cyber Essentials Plus evidence that covers your tenant, with period and exclusions.
- Roles.Record who is controller and processor for each purpose, in the data processing terms.
- Source record.Require origin, collection wording, timestamp and intended recipients for every lead.
- Permission and suppression.Check the PECR basis for the channel, TPS or CTPS screening for calls, and test that objections persist.
- Lead quality.Ask how invalid, duplicate and out-of-area leads are detected and removed, and how a bad lead is reported.
- Commercial terms.Settle exclusivity, resale, price per lead, refund or replacement rules, and the time limit for returns.
- Transfers.Record the IDTA, UK Addendum or adequacy route and the transfer risk assessment for any restricted transfer.
- Exit proof.Test a sample export, retained suppression and deletion before release.
Turn the evidence into a release decision
Finish with a due-diligence register that gives every risk a decision, evidence link, reviewer, expiry and stop authority. Mark each item pass, fail or unresolved. A strong result in one area cannot compensate for a critical control that remains unverified, so keep outstanding decisions visible.
Require named privacy, PECR, security, accessibility, consumer, commercial, procurement and technical reviewers to sign the relevant gates before production use. Keep evidence and decisions with their owners, including open issues that prevent approval. A complete record shows what was checked, what remains unresolved and who can stop release.



