Lusha Email Data: The Legal Basis It Rests On, and What It Leaves to You

A prospect replies to a campaign asking one question: where did you get my email address. Most senders have no answer beyond the name of the tool, and the tool's marketing pages are written for buyers rather than for that moment. Lusha is one of the few contact-data vendors that publishes a direct answer, and it sits in the documentation rather than on the product pages.

Lusha's own support documentation tells customers what to say. Its privacy and compliance section states that if someone you have contacted asks where you got their information, you can tell them it came from Lusha, described on that page as a B2B data provider that "aggregates professional contact information from public sources". The same page points the contact at Lusha's data page, its GDPR page and its trust centre, and notes that a person who wants their details removed can submit a request through Lusha's removal form, where "Removal is free and processed automatically".

That is a usable answer, and it is worth knowing before you need it. What matters more for anyone about to send at volume is the sentence that sits one page over, because it defines the legal position you are actually operating from.

The legal basis, stated plainly by the vendor

Lusha's compliance guidance for B2B outreach is unusually direct about where the responsibility sits. The page states that Lusha's data practices are aligned with major privacy laws including GDPR and CCPA, and that the company "relies on legitimate interest as the legal basis" for processing and providing business contact information.

Then it adds the sentence that changes how you should plan a campaign: Lusha "does not collect active opt-in consent from individuals specifically for third-party outreach".

Read those two together and the arrangement is clear. Legitimate interest is a lawful basis under GDPR, and it is the basis most B2B data vendors operate on. It is also a basis that has to be assessed against the specific processing being done, by the party doing it. Buying a record from a vendor that relies on legitimate interest does not transfer a completed assessment to you. It gives you data whose supplier believes its own collection is lawful, and leaves the question of whether your outreach is lawful exactly where it started.

Lusha says so itself. Under customer responsibilities the page assigns two things to the buyer: ensuring you have a valid legal basis for using the data in your outreach, and managing opt-out requests so that people who opt out are not contacted again. The page closes by noting that Lusha provides tools and data but "does not offer legal advice".

What the vendor doesPer Lusha's privacy and compliance docs

• Aggregates business contact information from public sources
• Relies on legitimate interest as its legal basis for processing
• Operates a free removal form, processed automatically
• Maintains Do Not Call tables and opt-out contact handling in-product

What the customer ownsNamed explicitly on the same page

• Establishing a valid legal basis for your own outreach
• Managing opt-out requests so opted-out people are not contacted again
• Knowing the data protection and marketing law in your region
• Including a clear and accessible opt-out in every message

The regional carve-out worth reading twice

Most vendor compliance pages generalise. Lusha's names specific jurisdictions, and one of the entries is a refusal rather than a reassurance.

On Spain, the guidance is ordinary: comply with GDPR principles, use the data for legitimate purposes, communicate professionally, provide opt-out options. On Switzerland, the page states that "Lusha does not confirm that unsolicited B2B email outreach in Switzerland is automatically compliant", and tells customers to evaluate local legal requirements themselves.

A vendor declining to make a compliance claim about a specific country is more informative than a vendor making one. It tells you which markets carry enough legal ambiguity that the supplier will not stand behind them, and it tells you where your own legal review needs to be real rather than a formality. If your target list crosses into Switzerland, that sentence is the one to hand to whoever signs off on the campaign.

The practical consequence for list building is that jurisdiction becomes a segmentation axis rather than an afterthought. A list assembled by role and company size, with no geographic gate, inherits whatever legal exposure its most restrictive country carries. Splitting by market before send costs one filter and makes the exposure visible.

Where the email addresses come from, and what that predicts

Lusha's description of its sourcing as aggregation from public sources is the vendor's own characterisation, and it is the right level of specificity to quote. It is also enough to predict how the data will behave on your list.

Aggregated public-source data has a characteristic shape. Coverage is strongest where people publish themselves, which means senior and outward-facing roles at companies with a web presence. It thins out in the places outbound teams often care about most: operational roles that never appear on a website, businesses in sectors with low digital footprint, and any company whose staff are deliberately not discoverable. Freshness follows the same pattern, because a record only updates when something public changes.

None of that is a criticism of the vendor. It is the structural property of the sourcing method, and it is why the useful evaluation question is never the published coverage figure. The question is coverage on your segments, measured on your own sample. The method for running that test is the same one that applies to every provider in the category, and it is set out in our guide to waterfall enrichment: draw a sample from your real targets, record how many returned any address and how many returned one on the company domain, and verify with something other than the tool being tested.

1. Step 1Segment by jurisdiction

   Split the list by market before enrichment, so the most restrictive country does not set the risk profile for the whole campaign.

2. Step 2Record the source per contact

   Keep the provider name against every address. A reply asking where you got the data is answerable in seconds or not at all.

3. Step 3Suppress before send

   Load opt-outs, prior unsubscribes and any do-not-contact list as suppression, not as a review step.

4. Step 4Verify separately

   Run addresses through a verifier that is not the finder that supplied them, so you are measuring accuracy rather than the provider's confidence.

5. Step 5Send one message

   Our documented practice is one message per campaign with a clear opt-out, and a new campaign on a new angle rather than a reminder on the old one.

Opt-out management is an architecture decision

Lusha assigns opt-out management to the customer, and the product carries surfaces for it: the documentation index lists Do Not Call tables and opt-out contacts as their own sections, alongside guidance on why contacts are excluded from a bulk reveal.

The trap is treating suppression as something that happens inside one tool. Opt-outs arrive in several places at once. Someone clicks unsubscribe in an email. Someone replies asking to be removed. Someone submits a removal request to the data vendor directly, which takes them out of future pulls but does nothing about the copy of their record already sitting in your sending platform. Those three routes produce three different states, and only the first is usually automated end to end.

The version that survives an audit keeps one suppression list that every campaign reads from, fed by all three routes, held outside whichever data vendor is current. That way changing enrichment provider does not reset your opt-out history, which is the failure mode that turns a tidy compliance story into an awkward one. Our own stack keeps suppression at the sending layer for exactly this reason, so a vendor swap cannot silently reintroduce a contact who asked to be left alone.

The same logic applies to the opt-out in the message itself. Lusha's guidance names a clear and accessible opt-out mechanism as a general guideline for B2B outreach using its data. That is a copy decision as much as a legal one, and it belongs in the template rather than in a signature nobody reads. What the legal picture looks like across regimes is covered in more depth in our writing on GDPR compliance and on whether cold email is legal, and the Canadian regime, which is stricter than most, has its own treatment in CASL compliance for cold email.

What this means when you are choosing between providers

Compliance posture is rarely the axis people compare data vendors on. Coverage and price dominate, and both are easier to put in a spreadsheet.

It deserves a column anyway, for a reason that shows up months after purchase. The cost of a weak position here is not a fine in the ordinary case. It is that a reply you cannot answer, or a removal request you cannot honour across systems, forces an operational change under time pressure. Deciding in advance which jurisdictions you will send into, and holding suppression somewhere durable, costs almost nothing at setup and is expensive to retrofit.

Three questions separate providers usefully, and all three are answerable from public documentation rather than from a sales call. What legal basis does the vendor claim, and does it say so in writing. Does the vendor make jurisdiction-specific claims, and does it decline to make any. What does the vendor explicitly assign to the customer. Lusha answers all three on its documentation host, which is more than several of its competitors do, and the answers are what this article has quoted rather than characterised.

For the coverage and price half of the comparison, our roundup of alternatives to Lusha covers where each provider tends to be strong, and the mechanics of testing any of them on your own segments are in email verification tools.

Before the first send on vendor-sourced data

• ✓Yes: The list is segmented by jurisdiction and you know which markets are in scope
• ✓Yes: Provider name is stored against every contact record
• ✓Yes: One suppression list, held outside the data vendor, feeds every campaign
• ✓Yes: Every message carries a plain opt-out in the body
• ✓Yes: Someone has read the vendor's own compliance page rather than its marketing page
• ✕No: Relying on the vendor's legal basis as though it covers your sending
• ✕No: Treating a removal request to the vendor as removal from your own database

The short version

Lusha publishes more about its legal position than most contact-data vendors, and what it publishes is a division of labour rather than a guarantee. The vendor claims legitimate interest for its own processing, states plainly that it holds no opt-in consent for your outreach, declines to vouch for unsolicited B2B email in at least one named country, and hands you the legal basis and the opt-out handling.

That is a workable arrangement for a B2B sender who plans for it. It is a poor one for a sender who assumed the purchase came with cover. The difference between the two is a jurisdiction filter, a durable suppression list, and having read the compliance page before the campaign rather than after the reply.

If you want the list, the copy and the sending infrastructure assembled with those decisions already made, see what a first campaign looks like.

Vendor documentation quoted here was verified against raw page bytes from docs.lusha.com in August 2026. Verify current terms with the vendor before relying on them, and treat legal questions as legal questions.