Under the CCPA as amended by the CPRA, an analytics team wants to keep raw clickstream forever — what do the data minimisation and retention rules require?

## The rule in the statute The CPRA wrote a **data minimisation and purpose limitation** principle into the CCPA. Civil Code **1798.100(c)** says a business's collection, use, retention and sharing of a consumer's personal information *shall be reasonably necessary and proportionate* to achieve either: - the purposes for which it was collected or processed, or - another **disclosed purpose** that is **compatible with the context** in which it was collected, and it may not be further processed in a way incompatible with those purposes. Retention is tied to the same idea from the notice side: **1798.100(a)(3)** requires the notice at collection to state how long each category will be kept, or the criteria used, and forbids keeping personal information for each disclosed purpose **longer than is reasonably necessary** for that purpose. ## How the regulations make it testable 11 CCR **7002** breaks the statute into three questions. | Question | What decides it | Source | |---|---|---| | Is the purpose legitimate for this data? | the consumer's **reasonable expectations**: the relationship, the type and amount of data, the source and method of collection, how clearly the purpose was disclosed, and how visible any service providers or third parties are | 7002(b) | | Is another purpose compatible? | those expectations at the time of collection, the new purpose (including whether it is a statutory business purpose), and the **strength of the link** between them | 7002(c) | | Is the processing necessary and proportionate? | the **minimum personal information** needed, the **possible negative impacts** on consumers, and **additional safeguards** such as encryption or automatic deletion | 7002(d) | Where a purpose fails 7002(a), the business must obtain **consent** under 11 CCR 7004 before processing for it (7002(e)), and even consented processing must be necessary and proportionate (7002(d)). Collecting new categories, or using data for incompatible purposes, also needs a **new notice at collection** (7002(f)). The regulation's own examples show the shape of the test: using data to **repair errors** that impair the requested service has a strong link to what the consumer expected; using cloud-storage data to research an **unrelated facial recognition** product has a weak one. ## Retention is a disclosed number Because 1798.100(a)(3) requires a period or criteria per category, retention becomes something a business publishes and can be held to. Two consequences: 1. A retention statement has to be **specific per category**: "as long as necessary" with no criteria does not tell the consumer anything. 2. The disclosed period itself must pass the necessity test; disclosing a long period does not make keeping data that long lawful. ## Applying it to "keep raw clickstream forever" Raw clickstream keyed to a device or account identifier is personal information: online identifiers and internet activity are listed categories in Civil Code 1798.140(v)(1)(A) and (F). The team's request fails on three counts: - **No purpose.** "It might be useful" is not a purpose disclosed to the consumer. - **No proportionality.** Most analytic questions need sessions, funnels or aggregates, not every raw event with its identifier, indefinitely. - **No disclosable retention.** "Forever" cannot be stated as a period that is reasonably necessary for any named purpose. A defensible design instead: 1. Name the purposes, for example product analytics, debugging, and security and integrity. 2. Give each a retention: raw events for a short debugging and security window; longer only in aggregated form. 3. Aggregate or **deidentify** past that window, then delete the raw events. 4. Publish the per-category retention in the notice at collection and keep the privacy policy consistent. 5. Treat any new use, such as training a model for an unrelated product, as a new purpose that needs a compatibility analysis and possibly a new notice and consent. ## Deidentified and aggregate data Information that is **deidentified** under Civil Code 1798.140(m) is outside the CCPA's definition of personal information, but only if the business takes reasonable measures against re-association, **publicly commits** not to re-identify, and **contractually binds recipients** to the same. Swapping a device ID for a hashed device ID that still links events to one person does not meet that bar. ## Mistakes interviewers listen for - Treating minimisation as a collection-time rule only, when 1798.100(c) covers use, retention and sharing. - Believing any purpose written into a privacy policy is automatically allowed. - Confusing pseudonymised event data with deidentified data.