Notifications
Clear all
Topic starter
10/07/2026 9:23 pm
TL;DR: California’s evolving privacy framework is expanding who can qualify as a data broker, shifting the burden from business model labels to how personal data is collected, shared, and operationally handled across systems, according to OneTrust. The practical risk is not classification alone but whether teams can execute recurring rights requests, downstream deletion, and audit-ready proof at scale.
NHIMG editorial — based on content published by OneTrust: Why More Organizations Now Qualify As Data Brokers
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should privacy teams handle data broker obligations across indirect data flows?
A: Treat indirect collection as a lifecycle governance problem, not a classification exercise.
Q: Why do third-party data flows create so much compliance risk?
A: Because rights obligations travel with the data.
Q: What do organisations get wrong about DSAR automation?
A: They often automate intake before they automate traceability.
Practitioner guidance
- Map indirect data exposure paths Inventory where personal data enters the organisation without a direct consumer relationship, including analytics, enrichment, activation, and partner feeds.
- Operationalise recurring request workflows Replace inbox-driven handling with repeatable workflows for intake, identity matching, deletion, status tracking, and evidence retention.
- Extend governance to third parties Require processors and downstream partners to support deletion, access, and status reporting in a way your organisation can verify.
What's in the full article
OneTrust's full article covers the operational detail this post intentionally leaves for the source:
- How DROP changes request cadence, reporting, and fulfilment expectations for in-scope organisations
- Examples of the data sharing patterns that can pull analytics and marketing ecosystems into broker scope
- The operational steps for tracing deletion obligations across partners, derived data, and inferred records
- How OneTrust frames DSR automation for ongoing privacy workflows and audit evidence
👉 Read OneTrust's analysis of California's expanding data broker scope and DROP →
Data broker scope is widening in California. Are privacy teams ready?
Explore further
10/07/2026 9:46 pm
The core shift is from data broker classification to data governance execution. California’s expanding definition matters because it breaks the old assumption that only companies selling data are in scope. The operational test now hinges on whether an organisation can locate, match, and act on data that moved through indirect and downstream channels. For privacy, IAM, and data governance teams, scope is becoming a workflow discipline rather than a legal label.
A question worth separating out:
Q: Who is accountable when consumer rights requests fail in downstream systems?
A: Accountability should sit with the organisation that determines how the data is collected, shared, and operationalised, even when external partners process it. In practice, privacy, data, and security owners need a shared control model so that fulfilment, reporting, and proof do not stop at the first system boundary.
👉 Read our full editorial: California's expanding data broker scope raises privacy operations risk
