If you're running a data vendor operation and weighing a shift toward brokerage, or evaluating whether to work with a broker, the compliance picture deserves more attention than most overviews give it. Operating as a full data broker is not a matter of scale; it puts you under a different regulatory posture entirely.
When "data vendor" becomes "data broker"
The legal definitions matter here, and they're narrower than you might expect. In California, a "data broker" is specifically a business that knowingly collects and sells to third parties the personal information of consumers with whom it has no direct relationship.
That last clause is key: if you're enriching data for companies that already have a relationship with the people in their CRM, you may not trigger broker status. If you're licensing datasets about individuals who've never heard of you, you probably do. Broker status also turns on whether you sell that personal information to third parties, and on statutory carve-outs such as data already covered by the FCRA, GLBA, or HIPAA.
California's data broker registration law requires annual registration with the California Privacy Protection Agency, which maintains a public registry of data brokers, plus registration disclosures and a fee. The state's Delete Act requires registered brokers to participate in DROP, the state's centralized deletion mechanism, with brokers beginning to process consumer deletion lists on August 1, 2026, on an at-least-every-45-days cadence. Other states are following with their own frameworks, and the definitions aren't uniform; what qualifies as "selling" data, what counts as "personal information," and what exemptions apply all vary by jurisdiction.
Before you assume you're exempt, map your actual data flows. Where does the information originate? Who are you licensing it to? What are they doing with it? The answers determine which rules apply.
The privacy framework patchwork
Operating across jurisdictions means operating under multiple overlapping regimes. The two you'll encounter most often are GDPR in Europe and CCPA/CPRA in California, but they work differently.
GDPR requires a lawful basis for processing personal data, often legitimate interest for B2B use cases, but only after a documented necessity and balancing assessment. You need to document your reasoning, provide clear privacy notices, and implement mechanisms for access requests, objections, and erasure. The regulation assumes individuals have rights over their data regardless of whether they gave it to you directly.
CCPA/CPRA operates more transactionally. You must disclose what you collect and how you use it, honor opt-out requests for sale or sharing, and respond to data subject requests within specified timeframes. California requires businesses that sell or share personal information, including brokers when applicable, to treat compliant opt-out preference signals (such as Global Privacy Control) as valid opt-out requests.
Maintaining compliance across both frameworks simultaneously is where the real complexity lives, especially when your data covers individuals in multiple jurisdictions. You'll need processes that can handle deletion requests arriving from California while respecting GDPR's different timelines and verification requirements. You'll need privacy notices that satisfy disclosure obligations in multiple regimes without becoming incomprehensible.
Ethical sourcing as a risk and clarity stance
For B2B-focused data operations, the cleanest compliance posture involves drawing deliberate boundaries around what you collect and how. Public-web sourcing from business-related sources (like company websites, job postings, and professional profiles on public platforms) presents a different risk profile than extracting data from behind authentication walls or aggregating consumer behavioral data.
This is a defensibility decision as much as an ethical one. When your customers face questions from their own legal and procurement teams about where their enrichment data comes from, they need clear answers. If your sourcing model involves credentialed access to protected platforms, adversarial data extraction, or personal data collected without any transparency to the individuals involved, those answers get complicated.
Separating your B2B company and professional data lines from any consumer behavioral data you might handle also simplifies compliance. The opt-out flows, retention policies, and subject access processes can differ based on the nature of the data and the legal basis for processing it. Keeping these lines distinct operationally makes it easier to demonstrate compliance when audited.
Security and governance expectations
Brokers centralize data at scale, which makes them targets. Certain security expectations follow:
- encryption in transit and at rest
- access controls tied to business need
- monitoring for unauthorized access
- incident response procedures
- vendor risk management for any third parties touching your data
Governance requirements go on top of security:
- data inventories documenting what you hold and where it came from
- retention policies that you actually enforce
- Data Protection Impact Assessments for high-risk processing activities in GDPR contexts
- internal policies governing acceptable use for both your own operations and customer licensing terms
The licensing terms themselves become a governance mechanism. Responsible brokers restrict sensitive use cases, prohibit re-identification of anonymized data, bar discriminatory applications, and require customers to honor their own downstream obligations to data subjects.
The bottom line for evaluators
Becoming a data broker, or working closely with one, means accepting a compliance overhead that doesn't go away. Registration obligations, privacy framework requirements, subject rights processes, security controls, and governance documentation all require ongoing investment.
It comes down to whether your data model, sourcing practices, and operational maturity can support these obligations. For organizations built around clarity (clear sourcing boundaries, documented schemas, transparent limitations), the compliance posture follows naturally from how the business already operates. For those who've grown without that foundation, the retrofit is harder than building it right the first time.
Enrich Layer is a registered California data broker. This article is informational and not legal advice.
