Before Your List Goes to a Data Vendor: DPA and Retention Questions for Your Agency

On 6 November 2026 we read the data processing agreement (DPA), plan and retention pages of six data vendors: BlitzAPI, Clay, MoltSets, Firecrawl, FullEnrich and Apollo. We did not open the linked sub-processor lists. At BlitzAPI and Firecrawl, the form of DPA you get depends on the plan. Firecrawl's pricing page lists one as "Not available" on two of its six plan columns. And MoltSets titles its addendum "Controller-to-Controller" and acts as a processor only for the data you submit.

A DPA that a vendor's terms pull in by reference is a real contract term, though not one signed with your company. But retention matters more, because it decides what happens to your list once the job ends. The pages state it three ways: default storage (FullEnrich, 3 months), a delete-or-return window after termination (Apollo, 90 days) and an export window (Clay, 30 days). BlitzAPI and MoltSets give no number for data you send.

One case changes this. If your agency uploads nothing and only searches a vendor's own database, the terms for what you send matter less and the terms for what comes back matter more. Thirteen questions at the end put the same checks to any agency.

What a data processing agreement is, and what "by reference" means

A data processing agreement is the contract between you and a vendor that handles personal data for you. Under the GDPR, the controller is the party that decides why and how personal data is used. A processor handles it on the controller's behalf. And a named person's work email is information relating to an identifiable person, which Article 4(1) defines as personal data.

Article 28(3) says processing by a processor "shall be governed by a contract or other legal act" that sets out the subject-matter and duration of the processing and the type of personal data. The contract must also stipulate that the processor acts "only on documented instructions from the controller" and will "allow for and contribute to audits". At the controller's choice, the processor "deletes or returns all the personal data" when the services end. Article 28(9) is shorter. The contract "shall be in writing, including in electronic form."

Article 28 asks for a written contract with set content, and electronic form counts. But the text we read says nothing that makes a contract incorporated by reference invalid. "By reference" opens questions instead: what the link points to, whether you can read it before you buy, which plan it covers, and whether the vendor is your processor for your list or acting for itself.

DPA by plan

Across the six vendors a DPA comes in three forms: signed with you, countersigned on a paid plan, or published by the vendor and accepted online or tied to its terms. But on two vendors, BlitzAPI and Firecrawl, the form changes with the plan.

Firecrawl's row matters most. Its sentence promises a countersigned DPA on a paid plan, but its grid says "Not available" under Free and Hobby. An agency scraping on the Hobby plan would have no DPA to point you to. That's two of six plan columns. Ask which plan your agency is on today.

BlitzAPI's Terms describe the DPA as "published on our website". We could not find it from BlitzAPI's site on 6 November 2026. The home page's legal links lead to the privacy policy and the terms, and the five addresses we tried returned a 404. But a page we couldn't find doesn't prove there isn't one.

BlitzAPI's Start and Scale plans also carry a monthly record cap, which BlitzAPI's new plans, measured covers.

Processor or controller, depending on the data

The same vendor can work for you on one flow and for itself on another.

MoltSets titles its addendum "Controller-to-Controller Data Protection Addendum". Then, "Solely with respect to Submitted Data", it makes you the controller and MoltSets a processor. And when the services end it returns or deletes Submitted Data at your choice. For the data it sends back, the addendum says that except for Submitted Data neither party acts as a processor for the other. But the Terms put the duty to delete data received from MoltSets on you.

BlitzAPI's Terms 13.2 say it processes "only the Client's account and billing information" and doesn't use client-provided data "to enrich its own database". Terms 13.3 add that unless the DPA says otherwise, each party "acts as an independent controller for its own purposes". The client is "solely responsible for its downstream use of the Data". On its search database, FullEnrich says "the data comes from data providers and is processed by FullEnrich for its own commercial purposes."

Two clauses speak to agencies. Where MoltSets' customer acts as an Agency, the addendum says that customer will "act on behalf of the Controller". BlitzAPI's Terms 5.3 let agencies use its Data for their own clients "only under the Agency's own subscription" and only for those clients' internal B2B purposes. Under that clause the agency's subscription, not yours, is the contract behind the data it pulls for you.

Take two jobs. An agency submits your customer list to MoltSets, and for Submitted Data MoltSets is a processor. Or the agency searches BlitzAPI's database for new names. BlitzAPI is supplying its own data, and under Terms 13.3 whoever holds the subscription answers for its downstream use.

What happens to your list after the job

The pages state retention three ways (default storage, a deadline after termination, an export window), and some state none.

Clay's 30 days is a window to export. After it, Clay "may delete" the data. The page sets no date.

Read the MoltSets and BlitzAPI rows together. MoltSets puts the deletion duty on you, with a carve-out for products already delivered. BlitzAPI lets you keep what you pulled, for internal use only, and bars resale. But neither page says whether the copy that landed in your CRM counts. Ask your agency.

Apollo's DPA does name CRM copies, though for removal requests, not for the end of a subscription. Customers must review Apollo's removal requests list at least once every 30 days. Within 30 days of Apollo posting a request, they must either "permanently delete the affected individual's data from all systems within Customer's control, including CRM systems" or document a separate legal basis for keeping it. Apollo adds that suppression or cessation of active use does not satisfy the deletion obligation.

Zero data retention is a plan feature too. Firecrawl lists it on Enterprise only ("We keep no scraped content after the request, on approved use cases"), and BlitzAPI lists it among the terms set on a call for Build Your Infra. But Article 28(3)(g), quoted above, gives you the choice between deletion and return and no number of days.

Sub-processors, data origin and transfers

FullEnrich's DPA promises at least eight days' notice of a change to its sub-processors. Apollo promises 30 days before it adds one and MoltSets 30 days before it replaces one. And Clay says it will notify before an intended change. Its DPA (7.3) gives the customer 30 days to object in writing.

BlitzAPI's privacy policy says it compiles its data "from publicly available and third-party professional sources", and its Terms (3.3) make the client "solely responsible for its use of the Data in compliance with applicable laws and source-platform terms". Clay's Terms put compliance for any marketplace data you import on the customer. FullEnrich says its search data comes from data providers and names none. The wider stack is in our cold outbound data stack guide.

Clay's DPA concludes three modules of the EU standard contractual clauses (1, 2 and 4) and refers to a UK addendum. FullEnrich and Apollo name the clauses too. But MoltSets' privacy policy covers transfers to the US with the sentence "you consent to that transfer", and its addendum names no clause module.

The checklist to run on any agency

Put these to the agency in writing, vendor by vendor, and keep the answers next to each data processing agreement.

Question 13 comes from Apollo's clause: a vendor's terms can put the deletion on the customer. The vendor side looks different. BlitzAPI's privacy policy says that on a valid request it adds the person to "a suppression list so that it is not returned again through the Services". That protects against the vendor returning the same name. It says nothing about the copies in your sending tool and your CRM, so ask the agency to show how a removal request reaches both. A suppression list is the record of who must not be contacted again. Our questions before hiring a GTM engineering agency covers the rest of the interview. A later piece covers what Firecrawl cost in our own test.