GDPR Lawful Basis for B2B Website Visitor Identification

B2B teams want to know who is looking at their website, and the law is specific about how far that "who" is allowed to go. GDPR compliance for visitor identification comes down to one dividing line: does the tool identify a company, or does it identify a person. Everything else in this piece, from legitimate interest to AI agent traffic to CRM integrations, builds on that single distinction.

The company-level / person-level split as the foundational legal question for B2B visitor identification

GDPR protects personal data, and a company is not a person. That sentence sounds simple, but it carries the entire weight of how a B2B visitor identification program gets built, defended, and audited. A name, a work email, a LinkedIn profile, a job title attached to a visiting company record, each of these becomes personal data the moment it can be linked to one identifiable person, regardless of whether the context is professional or personal.

The distinction is not just academic. But the line is not as clean as "company data is always safe." Even a tool that only ever outputs a company name is still processing something that, under the right conditions, courts have treated as personal data. That means company-level tools remain subject to GDPR. They just operate under a far more forgiving basis than anything touching an individual's identity, which is the subject of the next section.

For EU visitors specifically, person-level identification in practice requires opt-in consent, and almost nobody grants it when asked directly. The split isn't a legal technicality teams can route around with clever wording. It shapes what a product can legally offer, region by region.

Legitimate interest under Article 6(1)(f) as the lawful basis for company-level identification

Legitimate interest under Article 6(1)(f) is the lawful basis that makes company-level identification workable, but it is not a basis a company gets to claim just by asserting it. It has to pass a documented three-part test covering purpose, necessity, and balancing, and a controller who skips the documentation has nothing to show a regulator who asks.

The purpose test is the easiest of the three to satisfy here. Recital 47 of GDPR names direct marketing directly as a potential legitimate interest, and identifying which businesses are visiting a business website fits squarely inside that frame. The necessity test asks something harder: can the same goal be reached with less data. The balancing test is where judgment actually comes into play. The data revealed, company name, sector, size, is already public business information. That balance tends to tip in the controller's favor.

None of this is worth anything without a document. A legitimate interest assessment, or LIA, states the purpose, demonstrates why the processing is necessary, and records the balancing reasoning in writing. A company that has done the thinking but never wrote it down has nothing to show a regulator, and an unwritten justification is functionally the same as no justification. Tooling should also respect browser-level signals like Global Privacy Control, so the opt-out works even when the visitor never reads the policy. That opt-out requirement is also where GDPR's lawful basis analysis runs into a second, separate law: ePrivacy.

The ePrivacy layer that legitimate interest alone cannot satisfy

A solid legitimate interest assessment under GDPR does not clear a tool's use of cookies. If a visitor identification tool sets a cookie or reads a device identifier to recognize someone returning to a site, that act of reading or writing to the device triggers a separate consent requirement under the ePrivacy Directive, and it applies no matter how strong the GDPR basis is underneath it.

The mechanism sits in Article 5(3) of the ePrivacy Directive, which governs access to anything stored on a visitor's device, cookies, device fingerprints, browser-stored identifiers. Consent is the default requirement for any non-essential access of that kind. This has a direct operational consequence: a visitor identification tool that depends on cookies carries a structurally higher compliance risk than one that doesn't, because once a real consent banner goes up, a large share of EU visitors will decline, and the tool loses visibility into exactly that traffic.

A way around this trigger involves not touching the device. Some company-level identification tools compare the visitor's IP address against a database of registered business networks, so nothing gets written to or read from the visitor's browser. Because nothing is ever stored on the visitor's device, ePrivacy's consent trigger simply never fires. "Cookieless by design" is the difference between a tool that needs a banner and one that doesn't.

Enriching a company record with person-level contact details

The moment a workflow appends a name, a title, a work email, or a LinkedIn profile to a company record that was previously anonymous, GDPR's personal data rules apply in full. The business context doesn't soften the classification. A work email that contains someone's name, a job title tied to an identifiable individual, a LinkedIn profile URL: each of these is personal data the instant it's attached to a person.

Enrichment from public sources, a LinkedIn profile, a company's own website, a Chamber of Commerce registry, is permissible under a legitimate interest framework, because the individual made that information publicly available for a legitimate business purpose. What isn't permissible is buying personal data from a broker with no transparency about where it came from, or processing private information that was never made available for business contact to begin with.

This is where Article 14 comes in, and it is the step teams miss most often. When personal data is collected from a source other than the individual themselves, GDPR requires telling that person where their data came from. Skipping this step is not a theoretical risk sitting in a legal memo somewhere. The outreach that follows also has to earn its place: a relevant message to a decision-maker at a company that has shown genuine interest, sent with a clear sender identity, a working opt-out, and contact details sourced from public channels, is a different thing from bulk, undifferentiated outreach, and only the former holds up under this framework.

The US regulatory picture when EU GDPR does not apply

GDPR reaches further than US teams often assume. The regulation applies to any US company whose website monitors the behavior of people located in the EU, and the scope is set by where the visitor is standing. A US-based SaaS company with no overseas office and no foreign entity can still be fully inside GDPR's reach the moment visitors from that region land on its site.

For teams whose traffic is mostly domestic, the California Consumer Privacy Act adds a parallel layer that works on its own logic. The CCPA also requires a notice at collection, spelling out what categories of personal information are gathered and why, and in practice that means the privacy policy has to name the visitor identification tool directly.

State law doesn't move in lockstep, either. And the same structural threshold that governs GDPR risk governs CCPA risk too: most of the CCPA obligations concentrate at the exact point where identification moves from company-level to person-level. Geography changes which statute is doing the work, not whether this framework applies.

AI agents visiting a site as a separate and largely undocumented GDPR exposure

Everything above assumes a human being is doing the visiting. Increasingly, that assumption doesn't hold. AI agents that autonomously browse websites, query databases, and act on what they find are performing processing under Article 4(2) GDPR at every step that touches personal data, and most B2B teams have no documented lawful basis for that specific processing, even where a broader basis already covers the underlying data.

Regulators are starting to catch up to this gap. The guidelines establish that automated crawling for identity data sits within GDPR's scope. One clarification from the EDPB closes a loophole some teams assumed existed: the absence of a robots.txt restriction on a website does not amount to valid GDPR consent. Whether a crawler is technically permitted to access a page is a separate question from whether processing the personal data found there is lawful.

There's an added wrinkle when an agent doesn't just collect data but acts on it without a human in the loop, routing a visitor into a sales sequence, or excluding an account from a campaign. What is already clear is the prerequisite: a team cannot document a lawful basis for processing it hasn't detected. Knowing which AI agents, ChatGPT, Claude, and other autonomous crawlers among them, are visiting a site has become a compliance requirement sitting alongside its obvious value as sales intelligence. Platforms that detect this kind of traffic, including Maverick Intelligence's identification tools, give teams the visibility needed to even begin that documentation. Detection is the starting point, not the finish line.

CRM and ad-platform integrations breaking the compliance chain the front-end established

A clean, well-documented identification setup on the front end can still fall apart downstream. The most common structural failure across B2B go-to-market stacks is what might be called the consent-sync gap: a visitor declines tracking through a cookie banner, but because that banner was never integrated with the CRM, enriched data about that same visitor keeps driving automated sales sequences and ad retargeting as though nothing happened.

A consent management platform can stop a script from firing on the page. Consent and subscription status need to live in one authoritative place and stay synchronized everywhere else, because a contact who opts out in one platform but not another can silently reappear through the next sync, undoing the opt-out without anyone noticing.

International transfer rules add another layer of risk to this same stack. HubSpot's EU data hosting handles the geographic half of GDPR's Chapter V transfer obligations, but it doesn't resolve the underlying issue: HubSpot, Inc. is a US entity, and US law enforcement can seek to compel it to produce EU customer data through a CLOUD Act order no matter where that data physically sits, subject to a probable-cause warrant and the provider's right to challenge it, a scenario that can conflict with GDPR Article 48. Each hop in that chain needs its own data processing agreement and its own transfer mechanism review.

There's a measurement cost sitting on top of the legal one. Attribution systems that have to retroactively delete customer data under a GDPR request can end up invalidating their own historical attribution in the process, so non-compliance doesn't just create legal exposure, it quietly degrades the data a team uses to justify its own ad spend. The ground under cookie-based attribution has also shifted: on October 17, 2025, Google announced it was retiring the Attribution Reporting API along with nine other Privacy Sandbox technologies across Chrome and Android, adding more structural pressure on cookie-dependent measurement for EU traffic specifically. For teams running integrations like Maverick's connections into HubSpot, Salesforce, Slack, and major ad platforms, this is a concrete review to run, system by system, before any automated workflow goes live.

Building and documenting a defensible practice: the operational steps that turn legal theory into a reviewable record

Everything in the sections above points toward one practical conclusion: a defensible B2B visitor identification practice isn't a setting a team configures once and forgets. A regulator evaluates the record, documented and reviewable, of decisions made along the way.

The work starts before any tool gets switched on, with a written Legitimate Interest Assessment that states the specific business purpose, such as identifying in-market companies for sales prioritization, demonstrates why the processing is necessary and can't reasonably be done with less data, and records the balancing reasoning weighing the visitor's privacy impact against the commercial interest at stake. A vendor that can't produce a DPA on request should be disqualified outright, regardless of whatever claims sit on its homepage.

The privacy policy needs updating to match, disclosing that identification is happening, naming the lawful basis relied on, and offering an opt-out that actually works. Data minimization has to become an operational habit rather than a line in a policy document: filtering out ISP and junk traffic instead of retaining it, keeping raw IP data only as long as identification requires, and setting retention windows by data type, up to three years for nominative personal data where there's been no further interaction. Article 14 gets satisfied at the point of first enrichment contact, by naming the data source directly in the first outreach message so the recipient knows where their details came from and how to exercise their rights.

The downstream chain needs its own audit: mapping every system that receives visitor data, confirming that an opt-out actually propagates across all of them in real time, and reviewing the transfer mechanism on any integration where either party is a US entity. Platforms like Maverick Intelligence, which enrich visits with company, name, title, LinkedIn, and email details for identified buyers while also detecting AI agents and crawlers, span several of these steps at once, identification, enrichment, and the downstream workflows that follow. That range is why the documentation framework has to be applied to each capability layer on its own terms, since identification, enrichment, and automated processing each sit at a different point on the lawful basis spectrum, and treating them as one undifferentiated decision is how gaps open up in the record a regulator will eventually ask to see.