Why More Organizations Now Qualify as Data Brokers

The Data Broker Definition Is Expanding Beyond Traditional Models

For years, “data broker” referred to a narrow category of companies that collect and sell personal data without a direct relationship with consumers. But that definition is expanding and creating new operational risks that many companies did not anticipate.

Under California’s evolving privacy framework, following the entrance into force of the Delete Act, the definition is moving away from a business model and toward a “data relationship model”. The focus is now on how personal data is collected, shared, and used when the consumer does not intentionally engage with the organization.

States outside California, including Oregon and Hawaii, are considering introducing legislation with similarly expensive definitions of data brokers as part of their own data broker framework.

An organization may fall into data broker territory when it:

• Collects or receives personal data indirectly
• Shares or discloses personal data beyond first-party use
• Supports downstream data processing, enrichment, or activation without direct consumer interaction

For example, a mar tech platform ingesting third-party audience data for campaign activation, or an analytics provider enriching datasets without direct user interaction, may now need to assess whether they meet the threshold.

The question shifts from “Do we sell data?” to “Do we operate on data without a direct relationship to the consumer?”

From Definition to Enforcement Expectations

The expansive definition on its own is only part of the shift. The impact comes from how it connects to enforcement and operational expectations.

Regulators are actively evaluating whether organizations can operationalize consumer rights, not just document them, making enforcement decisions where data brokers fail to operationalize the requirements under the Delete Act. This shows up in two consistent areas:

• Whether consumer rights requests are honored fully and consistently
• Whether systems are capable of handling those requests at scale

Data broker obligations come into focus at this point. Organizations without a direct consumer relationship cannot rely on traditional request channels or contextual signals. They must locate, match, and act on consumer data across systems with limited context and often at higher volumes.

This raises the bar from policy alignment to operational readiness, where systems, workflows, and ownership models are expected to hold up under regulatory scrutiny.

For data brokers operating without a direct consumer relationship, a unified consent and preference management (UCPM) layer can support consistent handling of privacy preferences even when requests arrive with limited context through mechanisms like the DROP platform.

DROP Turns Definitions into Operational Reality

As outlined in our previous coverage of California’s Delete Request and Opt-Out Platform (DROP), the platform centralizes deletion requests across all registered data brokers, allowing consumers to submit a single request that reaches every organization in scope.

Deletion rights now operate at scale, with organizations receiving bulk requests, limited identifying context, and recurring obligations tied to fixed processing cycles.

Starting August 1, 2026, data brokers must access DROP at least once every 45 days, retrieve requests, delete all associated data including inferences, and report status.

This transforms compliance from a reactive process into a recurring operational workflow. A process that was once occasional and reactive becomes structured, repeatable, and time-bound.

A company that previously handled a small number of DSARs through email or ticketing systems now faces periodic batches of requests requiring:

• Identity matching across fragmented datasets
• Deletion across internal systems and third-party environments
• Proof of completion tied back to the platform

The issue is not whether the organization qualifies as a data broker, but whether it can actually meet the obligations that come with it.

OneTrust’s Data Subject Request (DSR) Automation helps organizations operationalize deletion obligations by centralizing request intake, workflow management, and fulfillment tracking across complex data environments.

The Hidden Scope: Data Sharing Creates Exposure

A common assumption is that data broker obligations apply only to organizations that sell data. In practice, sharing personal data outside of a direct consumer relationship can introduce similar exposure, particularly when data is reused, enriched, or activated across multiple parties.

This includes scenarios such as:

• Sharing data with third-party analytics providers
• Activating audiences across advertising ecosystems
• Enriching datasets through external partners
• Aggregating data from multiple sources for downstream use

Consider a retail organization that shares pseudonymized customer data with an external partner for audience modeling. If that partner operates without a direct relationship to the consumer and further processes or shares that data, the downstream entity may fall within data broker scope.

This introduces a second layer of complexity when a deletion request is received; the obligation may extend beyond internal systems into downstream data flows. Organizations need to understand not only where data lives internally, but where it travels and who is responsible for acting on it.

DSARs Become the Breaking Point for Many Programs

For data brokers, DSARs introduce a different level of complexity compared to first-party scenarios.

Requests often arrive without context, require matching across multiple identifiers, and must be fulfilled across systems that were not originally designed to operate together.

Now layer in DROP: requests arrive in structured batches, must be processed on a defined cadence, and require reporting back through the platform. Deletion must include not only raw data but also derived data and inferences.

A privacy team managing requests through spreadsheets and inboxes quickly encounters limits. A marketing operations team relying on multiple activation platforms may not have a clear path to ensure that deletion propagates across all environments. An organization with multiple third-party relationships may not have visibility into whether downstream partners have fulfilled the request.

Regulatory expectations now depend on whether systems can support these workflows end-to-end. It is no longer enough to respond to requests. Organizations must show that responses are complete, consistent, and repeatable across every system where data exists.

Rather than reacting to each request individually, OneTrust's Data Subject Request (DSR) Automation supports repeatable, auditable workflows aligned to the ongoing obligations introduced by California’s data broker framework.

Three Questions Every Organization Should Be Asking

To understand your exposure under the updated California framework, start here:

1. Could we be considered a data broker under California’s updated definition?
If your organization processes or shares personal data without a direct consumer relationship, the answer may be yes.

2. Can we operationalize the core requirements at scale?
Registration, disclosures, and DSAR fulfillment require consistent, repeatable processes. Spreadsheets and inboxes do not scale.

3. Do our third-party relationships create downstream obligations?
If personal data flows beyond your systems, deletion and access rights may need to follow it.

These questions help shift the conversation from classification to execution, where most compliance gaps emerge.

From Definition to Program Design

Understanding whether your organization qualifies as a data broker is only the starting point. The more important question is whether the organization can operationalize the requirements that follow. This requires clarity across three areas:

• Data visibility: Organizations need to understand where personal data exists across systems, including derived data and inferences.
• Data flow mapping: It must be clear how data moves between systems and third parties, and where obligations extend beyond the organization.
• Execution ownership: Responsibilities for fulfilling requests must be defined across teams, systems, and partners.

Without this foundation, compliance efforts remain reactive. Requests are handled individually, decisions are recreated each time, and consistency becomes difficult to maintain. With it, organizations can move toward workflows that support recurring, high-volume obligations like those introduced by DROP.

Privacy Programs Moving Forward

The expansion of the data broker definition is bringing more organizations into scope, particularly those operating across complex data ecosystems without direct consumer relationships.

At the same time, mechanisms like DROP are standardizing how consumer rights are exercised, introducing recurring workflows that test how data is managed across its lifecycle.

Organizations that rely on indirect data collection, third-party sharing, or downstream activation should reassess how their privacy programs operate in practice, not just how they are defined on paper.

For deeper analysis of developments related to data brokers and global regulatory trends, explore OneTrust DataGuidance.

You can also join our upcoming webinar, California DROP Explained: What the New State-Run Request Platform Means for Businesses, where DataGuidance contributors break down how DROP works in practice and what organizations should be doing now to prepare.

Key Questions on Data Brokers and DROP