California's CPRA (Proposition 24) went beyond CCPA's transparency-first model and added something more demanding: an affirmative data minimization requirement. Businesses can no longer collect personal information speculatively. The law now requires that collection, use, retention, and sharing of PI be "reasonably necessary and proportionate" to the purposes you disclosed at collection.
This page covers what that means in practice — what triggers it, what you have to do, and how Strac automates the operational side across your SaaS and cloud stack.
California Civil Code § 1798.100(a)(3) states:
"A business' 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."
This applies to all personal information under CPRA — not just sensitive PI. The standard is proportionality: does the scope of data you collect match the business purpose you've disclosed?
Three things are required:
The California Privacy Protection Agency (CPPA) enforces these requirements. Fines run $2,500 per unintentional violation and $7,500 per intentional violation — and regulators can treat each affected record as a separate violation.
CCPA gave consumers the right to know what was collected and to opt out of sale. CPRA added a structural change: the obligation sits on the business, not on consumer action.
The practical difference: under CCPA you could collect broadly and justify it post-hoc. Under CPRA, your data collection has to be scoped at the point of collection.
Data minimization and data retention are connected in CPRA. Section 1798.100(a)(3) covers retention directly: once the purpose for which PI was collected is fulfilled, you are required to delete it.
What that means operationally:
The practical question is: which data types are most likely to create minimization exposure? Here is a breakdown by category and where they typically accumulate:
Strac discovers all of these data types across Zendesk, Salesforce, Slack, S3, Google Drive, and 50+ other integrations — then redacts or deletes them automatically based on your retention policies.
Meeting CPRA data minimization requirements at scale means finding PI where it lives and enforcing rules on it automatically — not running manual audits every quarter.
Strac does this in three ways:
1. Discovery across your SaaS and cloud stack
Strac's DSPM (Data Security Posture Management) scans Salesforce, Zendesk, Google Drive, S3, Slack, GitHub, and 50+ other integrations to find where PI is actually stored. Most companies don't know they have SSNs in year-old support tickets or driver's license images in a shared Google Drive folder. Strac surfaces them by data type, location, and quantity.
2. Redaction without disruption
Once PI is located, Strac redacts it inline — replacing sensitive values with tokens like [SSN REDACTED] without deleting the surrounding record. This preserves business context (the ticket, the order record, the Slack message) while removing the PI that triggered the minimization requirement. Strac is the only DLP that also redacts inside images and scanned documents using OCR — so a driver's license photo attached to a Zendesk ticket doesn't escape detection.
3. Deletion on retention schedule
For data past its retention period, Strac triggers deletion workflows — removing records from connected systems when the retention clock runs out. Enforcement, not just policy.
See Strac DSPM | Zendesk DLP | Salesforce DLP | S3 DLP
Under CPRA, retaining a customer's driver's license or SSN in a Zendesk ticket months after the support issue was resolved is not "reasonably necessary and proportionate." Strac scans Zendesk, Intercom, and Salesforce records — including image attachments — using ML and OCR to detect identity documents, SSNs, and credit card numbers. Once the ticket's purpose is fulfilled, Strac redacts the sensitive values inline or deletes the attachment entirely.
When employees paste customer SSNs or share ID document screenshots in Slack during escalations, that data is retained in Slack's message history indefinitely — well beyond any proportionate business purpose. Strac monitors Slack in real time, detecting and redacting identity numbers and document images in any channel or DM before they spread. Historical messages are also scanned retroactively.
Onboarding emails, KYC submissions, and verification threads in Gmail and Outlook accumulate passport scans and license images with no retention schedule. CPRA requires disclosed retention periods that are actually enforced. Strac integrates with Office 365 and Gmail to scan both new and historical email — including attachments — and automatically redacts or deletes identity documents and regulated PI based on your configured retention policies.
Gmail DLP → | Slack DLP → | Office 365 DLP →
Yes, with a limited carve-out. CPRA exempts PI collected in a "business context" — meaning PI of individuals acting in their capacity as employees or representatives of another business — from many consumer-facing rights. But the minimization language in § 1798.100(a)(3) applies broadly. Most legal counsel advise treating B2B contacts with the same data discipline as B2C consumers, given the carve-out's narrow scope.
The CPPA has not issued a bright-line definition, but the standard looks at whether the data collected is (a) actually needed to fulfill the stated purpose and (b) proportionate in scope to that purpose. Collecting SSNs for a newsletter signup is not proportionate. Retaining SSNs in a support ticket two years after the ticket closes is not reasonably necessary.
They are connected but separate. Data minimization is an affirmative obligation on the business — you must limit collection and delete on schedule regardless of whether a consumer requests it. The right to delete is consumer-triggered. Both require deletion infrastructure; minimization also requires scoping collection at the outset.
The CPPA can impose $2,500 per unintentional violation and $7,500 per intentional violation. Because each affected record can be treated as a separate violation, a database with 50,000 records containing unnecessary PI creates significant exposure. The CPPA also has authority to require corrective action plans.
Yes. The CPRA employee exemption is narrower than CCPA's and continues to evolve through California legislation. HR data is particularly high-risk given the volume of sensitive PI involved — payroll files, benefit enrollment records, background check results. Businesses should apply the same proportionality standard to employee PI as to consumer PI.
Yes. Under CPRA's contract requirements, your service providers and contractors must have obligations limiting their use of PI to the specified purpose and requiring deletion or return of PI when the contract ends. This flows the minimization obligation downstream to every SaaS vendor that processes your PI.
.avif){kind=icon}
.gif)
.webp)
.png)
