Right to Opt Out of Sale and Sharing of Personal Information

To meet the Right to Opt Out of Sale and Sharing of Personal Information, you must give consumers a clear, persistent way to opt out of “sale” and “sharing,” then technically enforce that choice across your website, apps, and third-party data flows. Operationally, that means: publish a “Do Not Sell or Share My Personal Information” mechanism, recognize opt-out signals, stop disclosing covered data for those users, and retain proof you did it. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Key takeaways:

• You need both a consumer-facing opt-out path and back-end enforcement across tags, pixels, and third-party sharing. (Cal. Civ. Code §§ 1798.100-1798.199.100)
• “Sharing” can include cross-context behavioral advertising; treat adtech and measurement integrations as in-scope until you have a documented determination. (Cal. Civ. Code §§ 1798.100-1798.199.100)
• Audits focus on execution evidence: link placement, signal recognition, suppression rules, contracts, and change control. (Cal. Civ. Code §§ 1798.100-1798.199.100)

This requirement trips up mature privacy programs because it is less about publishing a privacy notice and more about controlling real data movement. If your website or app sends identifiers to ad networks, analytics providers, data brokers, or marketing partners, you need a reliable way for a consumer to say “stop selling or sharing my personal information,” and you need systems that actually stop the flow after the opt-out. (Cal. Civ. Code §§ 1798.100-1798.199.100)

For a Compliance Officer, CCO, or GRC lead, the operational challenge is coordination: legal must define what counts as “sale” and “sharing” for your business model; marketing and product must adjust tracking and targeting; security and engineering must implement preference signals across devices and properties; procurement must ensure third-party terms align with your opt-out obligations. (Cal. Civ. Code §§ 1798.100-1798.199.100)

This page translates the right into a requirement you can execute: who must comply, how to decide if you “sell or share,” the exact steps to implement the opt-out, what evidence to keep for exams, and where teams commonly fail (cookie banners that don’t control tags, opt-out stored but not enforced, and incomplete third-party inventories). (Cal. Civ. Code §§ 1798.100-1798.199.100)

Regulatory text

Statutory requirement (excerpt): “A consumer shall have the right, at any time, to direct a business that sells or shares the consumer's personal information to third parties not to sell or share the consumer's personal information.” (Cal. Civ. Code §§ 1798.100-1798.199.100)

Operator interpretation: If your organization “sells” or “shares” personal information, you must (1) provide a consumer-facing opt-out mechanism and (2) honor the opt-out by stopping the relevant disclosures to third parties. Treat “sell” and “share” as operational categories tied to specific data flows (pixels, SDKs, server-side events, list transfers, audience matching), not as abstract legal labels. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Plain-English meaning for implementers

• Consumers can tell you: “Do not sell or share my personal information.”
• Your systems must respect that choice across your web properties and apps, including third-party tracking and ad targeting contexts.
• You must not penalize the consumer for opting out (for example, by degrading service in a way that crosses into discrimination concerns referenced in the statutory scheme). (Cal. Civ. Code §§ 1798.100-1798.199.100)

Who it applies to

Entity scope (who)

This requirement is relevant to businesses subject to the California Consumer Privacy Act / CPRA framework that sell or share personal information, including financial institutions and state-registered advisers operating consumer-facing digital properties or marketing programs. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Operational scope (where it shows up)

You should treat the requirement as triggered when any of the following are true in your environment:

• Your website/app uses third-party cookies, pixels, SDKs, or tag managers that transmit identifiers to third parties for advertising or measurement.
• You send hashed identifiers, emails, device IDs, or customer lists to third parties for audience creation, enrichment, or targeting.
• You permit third parties to collect personal information from your digital properties for their own purposes beyond providing services to you. (Cal. Civ. Code §§ 1798.100-1798.199.100)

What you actually need to do (step-by-step)

Step 1: Decide whether you “sell” or “share,” by mapping real data flows

Build a data-flow view focused on outbound disclosure events:

1. Inventory third parties present on your sites/apps (tag manager exports, SDK lists, network logs).
2. Classify each disclosure: what personal information is sent, when, and for what purpose.
3. Document your determination of whether each flow is a “sale,” “sharing,” or neither, based on your counsel’s interpretation and the CCPA/CPRA definitions you follow internally. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Practical tip: treat cross-context behavioral advertising-related flows as “sharing” by default until you can justify a different conclusion with written analysis and contracts. This avoids the common failure mode where marketing labels a tracker as “analytics,” but it still supports ad targeting. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Step 2: Implement the consumer-facing opt-out mechanism

You need a clear and conspicuous pathway for consumers to submit the opt-out, commonly implemented as:

• A “Do Not Sell or Share My Personal Information” link on the website, plus an equivalent in-app path where relevant. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Execution details that auditors test:

• The link is reachable from the homepage and persists across key pages.
• The opt-out experience works for unauthenticated users.
• The opt-out does not require unnecessary information (collect the minimum needed to honor it). (Cal. Civ. Code §§ 1798.100-1798.199.100)

Step 3: Recognize opt-out preference signals and route them into enforcement

The requirement is operationally meaningless unless your systems can ingest opt-out signals and convert them into suppression actions:

• Web signal handling: detect opt-out preferences from supported browser/OS signals (your engineering team needs a clear requirement statement; your legal team should confirm the standard(s) you will treat as valid).
• Preference store: write the opt-out state to a system that downstream systems can read (consent platform, customer profile, or a dedicated preference service).
• Propagation: distribute the opt-out to tag management rules, ad/analytics configurations, and server-side event forwarding. (Cal. Civ. Code §§ 1798.100-1798.199.100)

If you need a structured way to manage third-party enforcement and evidence, Daydream can help by tying each third party to its data uses, contract posture, and required technical controls, then tracking remediation to closure.

Step 4: Enforce the opt-out technically (stop the “sale/sharing” flows)

Translate the opt-out into concrete blocks:

• Tag/pixel suppression: prevent firing of advertising and cross-site tracking tags for opted-out users.
• SDK configuration: disable ad tracking / data sharing toggles for opted-out users in mobile.
• Server-side routing controls: stop forwarding opted-out events to ad platforms and other third parties receiving data for covered purposes.
• Audience/list hygiene: exclude opted-out consumers from outbound customer lists and matched audiences; prevent re-upload. (Cal. Civ. Code §§ 1798.100-1798.199.100)

A useful control statement: “If a consumer has an opt-out flag, the system must not transmit identifiers or event data to third parties classified as ‘sale/sharing recipients,’ and must not include the consumer in outbound audience files.”

Step 5: Align third-party contracts and instructions to your enforcement model

Your opt-out program will break if third parties can continue using data you already sent:

• Confirm contract terms and platform settings support your instructions to stop “sale/sharing” processing for opted-out consumers.
• Maintain a list of third parties that receive data for advertising/targeting or other “sharing” purposes and confirm your ability to suppress data at collection time, not only after transfer. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Step 6: Build monitoring, QA, and change control

Most failures happen after a website redesign or marketing campaign adds new tags.

• Pre-release checks: require a privacy review for new tags/SDKs and changes to event schemas.
• Automated scanning: regularly scan sites for new third-party calls and compare against your approved inventory.
• Regression testing: test opted-out vs. not opted-out sessions and confirm network calls stop for in-scope endpoints. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Required evidence and artifacts to retain

Keep evidence that demonstrates both the consumer right and operational enforcement:

• Opt-out mechanism screenshots (web and app), with date-stamped captures. (Cal. Civ. Code §§ 1798.100-1798.199.100)
• Data-flow inventory of third parties receiving personal information, with your “sale/sharing” classification and rationale. (Cal. Civ. Code §§ 1798.100-1798.199.100)
• Technical design docs showing how the opt-out signal is captured, stored, and propagated.
• Tag manager rules / configuration exports showing suppression logic for opted-out users.
• Test results (network logs or QA scripts) demonstrating that opted-out sessions do not transmit data to “sale/sharing” third parties.
• Third-party contracts / DPAs and platform settings evidence relevant to restricting downstream use.
• Change tickets for implementation and subsequent tag additions, showing approvals and testing. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Common exam/audit questions and hangups

Expect reviewers to ask:

• “Show me where a consumer can opt out, and prove it works.” (Cal. Civ. Code §§ 1798.100-1798.199.100)
• “Which third parties receive personal information from your digital properties, and which are ‘sale’ vs. ‘sharing’?” (Cal. Civ. Code §§ 1798.100-1798.199.100)
• “How do you detect and honor opt-out preference signals in practice?” (Cal. Civ. Code §§ 1798.100-1798.199.100)
• “Demonstrate that opted-out consumers are excluded from ad targeting and audience uploads.” (Cal. Civ. Code §§ 1798.100-1798.199.100)
• “How do you prevent reintroducing trackers during marketing releases?” (Cal. Civ. Code §§ 1798.100-1798.199.100)

Hangups that slow audits:

• No single owner across Marketing/Engineering/Privacy for tag governance.
• “We use a CMP” without evidence that the CMP controls third-party calls.
• Inability to explain affiliate sharing and adtech sharing in consistent terms. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Frequent implementation mistakes (and how to avoid them)

1. Publishing the link but not enforcing suppression. Fix: require a technical test script that proves network calls stop for opted-out users. (Cal. Civ. Code §§ 1798.100-1798.199.100)
2. Relying on cookie deletion as “opt-out.” Fix: store a durable preference signal (account-level where possible, plus browser-level where not). (Cal. Civ. Code §§ 1798.100-1798.199.100)
3. Incomplete third-party inventory. Fix: scan production traffic and tag containers; procurement lists are never complete for marketing tech. (Cal. Civ. Code §§ 1798.100-1798.199.100)
4. Misclassifying “analytics” tools that also support ad targeting. Fix: review actual endpoints and feature toggles; document your classification rationale. (Cal. Civ. Code §§ 1798.100-1798.199.100)
5. Opt-out honored on web but not mobile (or vice versa). Fix: define a single preference model and require parity acceptance criteria for every channel. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources, so this page does not list specific cases. Your risk posture should still assume that regulators and plaintiffs will test the gap between what your link promises and what your telemetry shows. The highest practical risk comes from adtech-style data sharing that continues after opt-out because tags fire before preferences load, server-side forwarding ignores preferences, or marketing adds new partners outside governance. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Practical 30/60/90-day execution plan

Use phases rather than calendar promises; teams vary based on tag sprawl, app complexity, and third-party volume.

First 30 days (Immediate stabilization)

• Assign an accountable owner and define decision rights across Privacy, Marketing, Engineering, and Procurement.
• Produce a “sale/sharing” data-flow map for all digital properties and list transfers.
• Publish or validate the “Do Not Sell or Share My Personal Information” mechanism and confirm it is reachable and functional. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Next 60 days (Technical enforcement)

• Implement opt-out signal capture and a durable preference store.
• Suppress in-scope tags/SDKs and server-side forwarding for opted-out users.
• Establish audience/list suppression so opted-out consumers are not uploaded to targeting platforms. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Next 90 days (Governance and audit-readiness)

• Add monitoring for new third-party calls and require privacy review in the release process.
• Finalize your evidence pack: screenshots, configs, tests, and contract posture.
• Operationalize periodic reassessment of third parties and tag changes; Daydream can centralize third-party records, determinations, and remediation evidence so audits do not turn into screenshot hunts. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Frequently Asked Questions

Do we need a “Do Not Sell or Share My Personal Information” link if we believe we don’t sell data?

If you do not sell or share personal information, you may decide the link is not required, but you need a documented, data-flow-based determination to support that position. Many teams discover “sharing” through adtech integrations even when they do not “sell” in the ordinary sense. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Does “sharing” include cross-context behavioral advertising?

Your operating assumption should be yes for typical ad targeting and similar adtech use cases, consistent with the CPRA concept referenced in common compliance summaries. Treat pixels/SDKs that support targeted ads as in-scope until you document a reasoned exception. (Cal. Civ. Code §§ 1798.100-1798.199.100)

What’s the difference between an opt-out link and a cookie banner?

A banner can collect preferences, but the requirement is about stopping “sale/sharing,” not just displaying notices. If your banner does not technically prevent disclosure to third parties after opt-out, it will not satisfy the operational intent of the right. (Cal. Civ. Code §§ 1798.100-1798.199.100)

How do we prove we honored opt-outs during an audit?

Keep dated UI captures, tag/SDK configuration exports, and test logs showing opted-out sessions do not send data to “sale/sharing” recipients. Also retain change tickets showing approvals and regression testing after site changes. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Do opt-outs need to be honored for logged-out visitors?

The right applies to consumers generally, so you need a method that works without account authentication, typically via browser-level preference signals and a stored opt-out preference tied to the device or browser. Document any limitations and how you mitigate them. (Cal. Civ. Code §§ 1798.100-1798.199.100)

Our marketing team says we can keep analytics running after opt-out. Is that allowed?

It depends on whether the analytics flow is classified as “sale/sharing” in your data-flow analysis and on the tool’s actual behavior and settings. Treat “analytics” labels as non-authoritative; validate what data is sent to which third party endpoints and for what purposes. (Cal. Civ. Code §§ 1798.100-1798.199.100)