What B2B Teams Get Wrong About Data Privacy When Enriching Company Records

Every B2B team that’s looking to enrich company records eventually asks the same question: is this data safe to use?

Unfortunately, most answer this question with an assumption instead of checking the regulations.

Several of those assumptions are myths, some of which are completely wrong and others only partly true.

This article examines five of the most common myths about enriching company data, and what the regulations require instead.

Myth #1: "If Data Is Publicly Available, I Can Use It However I Want"

You’ve likely been told that if information comes from a public database, all privacy rules don’t apply.

In other words, you can freely use this type of data for things like sales outreach, lead lists, and cold prospecting.

However, that is not the case, as Philippe Dufresne, Privacy Commissioner of Canada, explained in a 2024 announcement.

His point is that the legal status of information does not change because it is easy to reach.

For example, consider a recent decision against a data broker.

The Italian data protection authority fined Lusha Systems, a B2B data company, €2 million in July 2026 and banned it from processing Italian residents' data.

Part of what Lusha sold had been scraped from public social networks, which the regulator did not accept as a reason to skip a valid legal basis.

Under the General Data Protection Regulation (GDPR), you need a lawful basis to collect personal data, regardless of the source.

Because these decisions affect buyers as well as data vendors, B2B teams need to ask some key questions before using a data enrichment service:

• Which sources does the data come from?
• When was it collected, and when was it last checked?
• What legal basis does the vendor rely on?
• Where is the data hosted, and which sub-processors access it?

Take our data-as-a-service solution Veridion, for instance.

Our company enrichment service reads the entire unstructured web and returns structured profiles for every active company in the world.

As a result, Veridion returns detailed company profiles at whatever volume you send, with a count of what matched and what did not.

Still, there are certain principles followed in the data collection methodology that keep the process lawful.

For instance, personal data is never collected from any source, including contact information, biometric data, and facial imagery.

Plus, Veridion's privacy policy is a good example of what to look for in a data vendor.

It details data collection and hosting practices, along with the legal bases for processing shown in the image below.

Documentation at that level tells you what a vendor does in practice, which is the only dependable way to judge whether public sourcing was lawful.

Myth #2: "Company Data Is Never Considered Personal Data"

Many scenarios exist where a record starts as company information and ends as something else.

A supplier profile, a prospect list, and a vendor master record all begin with attributes that describe an organization rather than a person.

As such, there is often confusion when data enrichment adds new fields to those records.

Teams believe that as long as the data is related to a company, it is safe to collect and use without a privacy review.

However, if we look at the image below, we can see how enriching a simple company-level record can quickly reveal personal data.

As an example, if a data provider does not have measures in place, enriching a company website attribute can end up scraping all data present on the website.

That may include employee profiles, author pages, and team introductions, which name individuals and often list their direct contact details.

From that point, the record describes people, and every GDPR obligation applies to it.

Without following a strict collection policy, a vendor can expose its clients to fines, as shown in the case below.

Uncontrolled data collection of that kind usually means the legal basis for the activity was never considered, which is serious because there is no way to correct it after the fact.

Not to mention the obligation under Article 14 of the GDPR, which requires that individuals are informed when their data is obtained from a third party.

The issue is relevant even for one-person businesses like sole traders, freelancers, and unregistered micro-companies.

While some overlap may exist between the person and the business, things like an email address or a direct phone number are still personal data.

The UK's Information Commissioner's Office (ICO) states this plainly in its direct marketing guidance.

The ICO adds that an email address on its own will not tell you whether it belongs to a sole trader or to a limited company, which makes address-level filtering unreliable as a control.

Pure company-level attributes about these businesses are not covered by the GDPR, including turnover, sector, and years in operation.

But the named individual that enrichment attaches to those attributes is covered, and that changes the obligations for the whole record.

Myth #3: "Data Enrichment Doesn't Require a Data Processing Agreement"

The third myth concerns how much scrutiny an enrichment arrangement needs.

Many teams treat a data vendor as an ordinary supplier, and assume a standard commercial contract covers everything.

When we consider a data enrichment vendor, though, it can play two different roles, outlined below.

As an independent controller, which is the role a vendor takes when selling ready-made datasets, the requirements are generally lighter on the contract side.

No processing agreement is needed, but Article 14 requires you to inform the individuals in that dataset that you hold their data, and to tell them where it came from.

But the most common case when it comes to enrichment is the vendor acting as a data processor, where you send your own records for matching and the vendor works only to your instructions.

In these cases, a data processing agreement (DPA) is mandatory before any personal data is transferred.

These agreements are required under Article 28 of the GDPR, and the absence of one is an infringement in itself.

As to what they need to encompass, the GDPR website provides a useful template.

In general, an agreement records what is being processed and for how long, the purpose, the types of data and people involved, and the responsibilities of each side.

These requirements do not mean that you can use boilerplate agreements, however.

As written in the guidelines of the European Data Protection Board (EDPB), which coordinates the national regulators, a DPA should not just list out and restate the GDPR provisions.

Instead, the EDPB recommends drafting terms that are specific to your own situation.

That means naming the datasets you transfer, stating what the vendor may and may not do with them, and recording how instructions are issued.

Myth #4: "Removing the Name Makes the Data Anonymous"

Some B2B teams believe that if personal data is stripped out of a record, by deleting the name column or replacing it with an internal ID, whatever remains is anonymous and safe to use.

After all, if nobody can read a name in the file, no individual is identifiable and the GDPR no longer applies.

But, as shown in the ruling from the Court of Justice of the European Union (CJEU) below, the reality depends on what exists alongside the file.

If we look at the court ruling, it clearly states that replacing names with code keys is just pseudonymization.

Meaning the identifying details have been separated from the record and stored somewhere else, rather than destroyed.

In other words, since the Single Resolution Board (SRB) kept the linkage table that connects each code to its author, it was still possible for the names to be revealed at a later point.

Compare that to truly anonymized data, which has three key characteristics.

The main one relevant here is that the process is irreversible, meaning neither you nor anyone else with access to extra information can restore the link to a person.

And no identifiers remain in the record.

An identifier is any detail that points to one specific person, which covers much more than names and email addresses.

Job titles, locations, and dates are identifiers when the combination narrows a record to one individual.

The second point is important, since certain identifying details can be used to retroactively work out who a record describes.

Consider the simplified example shown below.

Identifiers like a job title, combined with a company's location and name, can be used to reach a single person, especially once that combination is checked against a public professional profile.

Despite the identification being indirect, the record is still personal data, because the GDPR covers indirect identification explicitly and applies every obligation accordingly.

The only way to be completely safe is to avoid enriching company profiles with personal data in the first place, or to ensure that whatever remains is fully anonymized.

Myth #5: "B2B Data Is Exempt From Privacy Regulation"

Finally, many teams have the misconception that since B2B data concerns people at work rather than private consumers, it is not regulated by privacy law.

One possible origin for this misconception is California, which did once treat business contact data as an exception, with the following timeline:

• 2018: the California Consumer Privacy Act (CCPA) is passed.
• 2019: an amendment adds a temporary B2B exemption to the statute.
• 2020: Proposition 24 extends that exemption to 1 January 2023.
• 2022: a further extension is introduced in the legislature but never passed.

However, on 1 January 2023, that exception ended.

Today, California has stronger requirements in place, and B2B data brokers must register with the state annually and comply with things like centralized deletion mechanisms.

Since August 2026, data brokers have to check the state platform every 45 days and act on the requests they find there.

As part of their consumer privacy rights, people can also request access, correction, and deletion of their data, whether it was collected at work or at home.

As far as other states are concerned, most have now passed comprehensive privacy laws of their own.

That being said, some states' privacy laws exclude individuals acting in a commercial context.

In simple terms, a procurement manager who gives a work email at a trade show is acting for an employer, so the record created from that exchange is not covered.

But regulations like the CAN-SPAM Act still apply, since the federal rules for commercial email make no exception for messages sent between businesses.

Depending on where you operate and where your records come from, different frameworks apply, summarized below.

So, if the person is not in the US, the GDPR has no B2B exemption at all, and the same is true of the UK version.

For teams buying enriched data across borders, the practical consequence is that a single dataset can be covered by several regulations at once.

Rather than checking each record against each law, the workable approach is to apply the strictest applicable framework to the whole file.

Conclusion

That covers the five myths that most often lead B2B teams into trouble with enriched company records. 

The pattern behind all of them is the same, which is that a label on a dataset says nothing about what the law sees inside it. 

So, question your vendors on key compliance issues early on, and data enrichment will remain a business advantage rather than a legal liability.