What is the CCPA data minimization requirement?

Most of the CCPA is written as a set of consumer rights. Someone asks, and the business has to answer within a deadline. Data minimization is not built that way, and that is why it is the provision most often absent from a compliance program that otherwise looks complete.

Section 1798.100(c) does not wait for anyone. It is a continuous limit on what a business may collect, use, keep, and share, and it is enforceable on its own terms.

The exact text of the CCPA minimization rule

Subdivision (c) of Civil Code section 1798.100 reads in full:

A business's collection, use, retention, and sharing of a consumer's personal information shall be reasonably necessary and proportionate to achieve the purposes for which the personal information was collected or processed, or for another disclosed purpose that is compatible with the context in which the personal information was collected, and not further processed in a manner that is incompatible with those purposes.

The provision was added by Proposition 24 and, per the section's own credit line, is operative from 1 January 2023.

Reading the four verbs and the two tests

Four activities are covered: collection, use, retention, and sharing. Each is separately subject to the standard. A business can pass on collection and fail on retention, which is the most common shape of the problem.

Two tests apply to each.

Reasonably necessary asks whether the activity actually serves the stated purpose. A field nobody reads fails here.

Proportionate asks about scale relative to that purpose. This is the harder test and the one that is usually skipped. Collecting a full date of birth to confirm that a user is over eighteen is arguably necessary to the age question and clearly not proportionate to it, because a yes-or-no age check answers the purpose and a full date of birth supplies a permanent identifier as a side effect. Collecting precise geolocation continuously to support a feature that needs a city name is the same failure at a larger scale.

The two tests are joined by "and," so passing one does not carry the other.

Purposes, compatible purposes, and the context limit

The rule anchors to the purposes for which the information was collected or processed. It then permits another disclosed purpose, but only one that is compatible with the context in which the information was collected.

Both qualifiers matter. Disclosure alone is not enough; the new purpose must also be compatible with the original context. And the subdivision closes with an independent prohibition: the information may not be further processed in a manner that is incompatible with those purposes.

In practice this is the provision that governs the reuse of an existing dataset for something new. Support tickets collected to resolve customer issues, then fed into a model, then used to build a marketing segment, travel a long way from the context in which the consumer handed them over. Adding a line to the privacy policy does not close that gap, because the test is compatibility with context, not notice.

The retention ceiling in 1798.100(a)(3)

Minimization has a second limb in the same section, and it is stated as a disclosure duty with an obligation hidden in its tail.

Section 1798.100(a)(3) requires a business that controls the collection of personal information to inform consumers, at or before the point of collection, of the length of time it intends to retain each category of personal information, including sensitive personal information, or if that is not possible, the criteria used to determine that period. The subdivision then adds the operative words: provided that a business shall not retain a consumer's personal information or sensitive personal information for each disclosed purpose for which the personal information was collected for longer than is reasonably necessary for that disclosed purpose.

So the statute requires a stated period and separately forbids exceeding what is reasonably necessary for the purpose. A business that publishes a retention schedule and does not run it has disclosed the standard it is failing.

This sits directly alongside the retention disclosure duty in the notice at collection, and the two are best built as one piece of work.

Why minimization changes the shape of a deletion request

A business that has genuinely minimized has less to find when a deletion request arrives, fewer systems to notify, and a shorter list of service providers and third parties to pass the request along to under section 1798.105(c)(1).

The reverse is also true, and it is the practical reason minimization deserves priority over the request workflows it supports. Every field kept past its purpose is a field that has to be located, justified against one of the eight exceptions in section 1798.105(d), and deleted under a 45-day clock. Data you never collected costs nothing to delete.

Where to start

Start with the inventory rather than the policy. Section 1798.100(c) is measured against purposes, so the first artifact is a list of what you collect and why, category by category.

Fields with no owner and no purpose are the easy deletions. Fields whose purpose has quietly ended, such as onboarding data from accounts closed years ago, are the next. What remains is the set worth arguing about on proportionality, and that argument is much shorter once the first two passes are done.