Most B2B personalization projects hit the same wall in week two. Marketing has the segments and the headline variants ready, then someone from legal asks how the visitor identification part works under GDPR, and nobody has an answer written down. The project waits.
This post is the answer we would want written down. It covers personalization data privacy for B2B websites under the three rule sets that cause most of the questions (GDPR, the EU ePrivacy rules on cookies and device access, and California's CCPA/CPRA), what each one actually requires, and a launch checklist you can hand to your legal team. It is not legal advice. The goal is to get marketing and legal to the same conversation faster, with the primary sources linked so your counsel can check them.
Why B2B personalization has a different privacy profile
Most privacy guidance is written for consumer scenarios: ad tracking across shopping sites, behavioral profiles sold to third parties. B2B website personalization usually looks different:
- The main input is company-level data (industry, size, location, technology used), usually derived from the visitor's IP address.
- The output is mild: a manufacturing visitor sees manufacturing case studies instead of fintech ones.
- Many visitors come from companies you already sell to or target, so there is a plausible business reason to show them relevant content.
None of that makes B2B personalization exempt from privacy law. A person still sits behind every IP address, and the laws protect that person, not the company. What changes is the risk level and which legal basis is realistic. Getting that classification right is most of the work.
GDPR: the IP address question
The first question legal will ask is whether an IP address counts as personal data. The honest answer is "often yes, depending on who holds it." In Breyer (Case C-582/14), the Court of Justice of the EU held that a dynamic IP address is personal data for a website operator if that operator has the legal means to identify the visitor with additional information held by the internet service provider. The case was decided under the old Data Protection Directive, but the GDPR definition of personal data in Article 4(1) explicitly lists "an online identifier" as something that can make a person identifiable, so the same reasoning carries over.
Our view: plan as if every IP address you process is personal data. Arguing otherwise saves you very little and makes your documentation look evasive to a regulator.
Picking a legal basis
Article 6 GDPR lists six legal bases. Two are relevant to website personalization:
| Legal basis | Where it fits | What you owe the visitor |
|---|---|---|
| Legitimate interests, Art. 6(1)(f) | Company-level personalization from an IP lookup, where nothing is stored on the device | A documented balancing test (Legitimate Interest Assessment), a clear privacy notice, and a working way to object under Article 21 |
| Consent, Art. 6(1)(a) | Anything that needs cookies or similar device access, and any profile tied to a named person | Consent that is freely given, specific, informed and unambiguous, and that can be withdrawn as easily as it was given (Article 7(3)) |
Two details matter here. First, the Breyer press release also notes the Court's point that a website operator can have a legitimate interest in processing visitor data, provided it is weighed against the visitor's rights. That is the balancing exercise your LIA has to show. Second, if personalization is part of direct marketing, Article 21(2) and (3) give the visitor an absolute right to object: once they object, you stop. Build the opt-out before launch, not after the first complaint.
What a GDPR mistake can cost
Under Article 83(5), infringements of the processing principles, the legal basis rules in Article 6, consent conditions in Article 7, and data subject rights in Articles 12 to 22 can draw fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher. Those are maximums, not typical fines. The more realistic cost for a mid-market B2B team is a regulator inquiry that forces you to pause personalization while you produce documents you should already have.
ePrivacy: where "cookieless" gets misunderstood
The ePrivacy Directive (2002/58/EC, Article 5(3)) is the rule behind cookie banners. It requires consent before storing information on, or gaining access to information in, a user's device, unless the storage or access is strictly necessary for a service the user asked for. It applies alongside GDPR, and it does not care whether the information is personal data.
In the UK the equivalent rule sits in PECR. The ICO's guidance is clear that consent must be actively and clearly given, and that cookies which are only helpful or convenient still need it. Personalization cookies fall into that group.
Here is the part many vendor blogs skip. A lot of personalization marketing says "server-side, cookieless, so no consent needed." That is too simple. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) (final version October 2024) say that tracking based only on IP addresses can fall under Article 5(3), and that unless you can ensure an IP address does not originate from the user's device, you have to treat it as covered. The same guidelines say Article 5(3) applies when client-side code instructs the browser to send identifiers to you.
What that means in practice:
- A one-off server-side IP lookup used to pick a headline for the current page view is the lowest-risk pattern. Some lawyers will still want it covered by consent or a clear exemption analysis under the EDPB guidelines, so ask yours.
- Using the IP address to follow a visitor across pages or sessions is tracking, and the EDPB view is that it needs the same consent analysis as cookies.
- Any JavaScript snippet that reads or sets identifiers in the browser (cookies, local storage, fingerprinting signals) needs consent before it runs, unless strictly necessary.
One timing note: the planned ePrivacy Regulation that was supposed to replace the Directive is gone. The European Commission announced in its 2025 work programme that it would withdraw the proposal, and the existing Directive plus national implementing laws stay in force. Do not wait for new EU cookie rules before setting up consent properly.
CCPA/CPRA: does it even apply to you?
California's law only applies to for-profit businesses that do business in California and meet at least one threshold. According to the California Privacy Protection Agency, those are:
- Gross annual revenue of $26.625 million or more (the figure as adjusted from January 1, 2025).
- Buying, selling or sharing the personal information of 100,000 or more California residents or households.
- Deriving 50% or more of annual revenue from selling or sharing California residents' personal information.
For B2B teams, the important history is that the temporary exemption for business contact data and employee data expired on January 1, 2023. A buyer browsing your site from a work laptop in California is a consumer under the law.
If you are in scope, the obligations that touch personalization are:
- Disclose in your privacy policy that you collect IP-derived data for personalization and what categories of data you use.
- If enrichment or ad partners receive visitor data in a way that counts as "selling" or "sharing" (sharing covers cross-context behavioral advertising), offer a "Do Not Sell or Share My Personal Information" link and honor opt-outs.
- Answer requests to know, delete or correct within 45 calendar days, extendable by another 45 days if you notify the person, per the CPPA FAQ.
Penalties were raised for inflation on January 1, 2025: administrative fines of up to $2,663 per violation and $7,988 per intentional violation, according to the CPPA announcement. Other US states have their own comprehensive privacy laws with different thresholds, so if you have meaningful traffic from those states, map them separately rather than assuming the California analysis covers you.
A working framework: three data tiers
The easiest way to make this manageable is to classify every input your personalization uses before you build anything.
| Tier | Data | Typical legal position | Launch order |
|---|---|---|---|
| 1. Company-level, per request | Industry, size, location from a server-side IP lookup, nothing stored on the device | GDPR legitimate interests with an LIA; check the ePrivacy angle with counsel | First |
| 2. Behavioral, device-based | Return visits, pages viewed, engagement scores held in cookies or local storage | Consent under ePrivacy before anything is set; legal basis under GDPR | After your consent setup works |
| 3. Individual profile | Named contacts, emails linked to browsing, CRM deal stage, third-party enrichment about the person | Consent or a carefully documented basis, DPAs with every vendor, full data subject rights | Last, and only where it pays off |
Our view: launch with Tier 1. Showing a logistics company your logistics case study does not require knowing anything about the person reading it. Most of the obvious personalization wins (industry headline, relevant proof, company-size pricing emphasis) live in Tier 1. Tiers 2 and 3 add value, but they also add consent dependencies and paperwork, so add them once Tier 1 is measured and stable.
Step by step: launching compliantly
1. Split the experience around consent
The common mistake is to block all personalization until the visitor clicks "Accept." A better design:
- Before consent: only Tier 1 personalization from a server-side lookup, with no identifiers stored on the device. No behavioral history.
- After consent to personalization cookies: start recording return visits and engagement, and use them for Tier 2 rules.
- After a form submission: link the account to CRM data (Tier 3) where your privacy notice and legal basis cover it.
Test it the boring way: open the site in a clean browser profile, decline everything, and check the Application tab in DevTools. No personalization cookie or local storage key should appear. Then accept and check again.
2. Make consent categories match reality
A visitor who accepts "analytics" has not agreed to "personalization." If your consent tool has granular categories, add a personalization category (or put personalization under an existing "functional" or "marketing" category that describes it accurately) and make sure the personalization script listens to that category specifically.
3. Audit every vendor in the data flow
For each vendor that touches visitor data (IP enrichment, analytics, CDP, CRM, consent tool), write down:
- What data they receive from your site and what they send back.
- Where they store and process it, and which transfer mechanism covers any transfer outside the EEA.
- Whether they use your visitor data for their own products. If they do, they may be acting as a controller rather than a processor, which changes your contracts and your privacy notice.
- Whether a Data Processing Agreement is signed and where it is filed.
The contract only covers half of it; the other half is how each vendor actually protects the data. If your team has no in-house security expertise, outside cybersecurity services can review vendors' access controls and storage before you sign.
Example of what this audit tends to catch (illustrative): an analytics tool whose terms allow it to use customer data to build its own audience products. That is not a processor relationship, and you either renegotiate, disclose it properly, or switch to a tool that stays in the processor role, such as a personalization analytics setup that only processes data on your instructions.
4. Write the three documents
- Privacy policy section. What you collect (IP-derived company data, behavioral data with consent), why (to show relevant content), legal basis, retention, vendors, and how to object.
- Legitimate Interest Assessment. Purpose test (showing relevant content to business visitors), necessity test (why company-level data is enough and you do not need more), balancing test (no sensitive data, company-level output, easy objection, short retention).
- Cookie policy. Every cookie or storage key the personalization system sets, its purpose, lifetime, and category.
5. Set retention limits you can enforce
GDPR's storage limitation principle in Article 5(1)(e) means keeping personal data no longer than the purpose needs. The law does not set a number, so pick one and justify it. Example: behavioral data for 90 days, enriched account data for 12 months to cover a typical B2B sales cycle. Whatever you choose, configure it in the tools so deletion happens automatically.
6. Rehearse a data subject request
Under Article 12(3), you have to answer access, deletion and objection requests without undue delay and within one month, extendable by two further months when necessary. California gives 45 days. Run a test request before launch: pick a colleague who has visited the site, and try to find, export and delete everything your stack holds about them. If your visitor identification tool cannot do this per IP address or per contact, you have a problem to solve before going live.
Common compliance mistakes
Calling company data "anonymous"
Identifying a company is not the same as processing anonymous data. The IP address you used for the lookup is personal data in most realistic scenarios. Say so in your documentation, rely on a documented legal basis, and move on.
Assuming "server-side" means "consent-free"
As covered above, the EDPB reads Article 5(3) broadly enough to cover IP-based tracking and client-side identifier collection. Server-side, per-request company lookups are the lowest-risk design, but they are a design choice to discuss with counsel, not an automatic exemption.
No objection path
If your legal basis is legitimate interests, the visitor can object. A link in the privacy policy that leads to an email inbox nobody monitors does not count. Give them a setting that turns personalization off and honor it in the personalization engine.
Feeding in third-party intent data without checking provenance
Third-party intent data is often built from cross-site browsing. If the provider cannot show how consent or another legal basis was obtained for that collection, you inherit that weakness the moment you use it. Ask for their data provenance documentation before signing, and prefer first-party behavioral signals. We cover the trade-offs in more detail in our guide to intent data for B2B website personalization.
Indefinite retention
Personalization tools often keep everything by default. Check the retention setting on every tool in the stack, not just the main personalization platform.
Pre-launch checklist
- Data inventory done, every input classified as Tier 1, 2 or 3.
- Legal basis documented per tier, with an LIA for Tier 1.
- ePrivacy analysis of the IP lookup and any client-side script reviewed by counsel.
- Consent banner has a category that covers personalization, and a clean-browser test confirms nothing is stored before consent.
- DPAs signed with every vendor; storage locations and transfer mechanisms recorded.
- Privacy policy and cookie policy updated.
- Objection and opt-out path works and is respected by the personalization engine.
- Retention limits configured in every tool.
- Test data subject request completed within the GDPR and CCPA deadlines.
- CCPA scope checked against the three thresholds, and other US state laws mapped if you have traffic there.
Why privacy constraints make for better personalization
This is the opinion part, and some teams will disagree with it. Working within privacy rules pushes you toward the personalization that tends to work anyway.
Company-level segments reach every visitor, including the ones who decline cookies, so your first test is not limited to the subset that clicked "Accept." Fewer, broader segments (for example five or six by industry and company size) are easier to write good content for than dozens of micro-segments built from browsing patterns, and each segment gets enough traffic to measure. And when you cannot lean on third-party data, you invest in a first-party data strategy built on how people actually use your own site, which is the data that reflects their interest in you specifically.
If you want a starting point for those segments, our post on firmographic segments that convert walks through how to pick them, and how company-level visitor identification works explains what the IP lookup can and cannot tell you.
Getting started without stalling in legal review
The realistic risk for most B2B teams is not a fine. It is months of back-and-forth because nobody gave legal a concrete design to review. Give them one:
- A one-page data flow diagram showing the IP lookup, what comes back, and what is stored.
- The tier table above, filled in for your stack.
- A draft LIA and privacy policy section.
- The clean-browser consent test results.
Then launch Tier 1 on a few high-traffic pages, measure for 30 days, and add Tier 2 once consent works and the numbers justify it.
Markettailor fits this order of operations: its firmographic segmentation works from company-level data, so you can start with Tier 1 rules while the consent work is being finished. If you want to compare plans before talking to legal, see Markettailor pricing.