California and New York privacy laws and what they change in your dashboard metrics

What to take away

What CCPA and CPRA actually require of a metrics pipeline

California's privacy law is not a reporting rule. It is a data handling rule that happens to break your reporting. Every metric that counts people, households or devices has to survive a deletion or correction request, and most dashboards were never built that way.

The table below is the practical answer. The statutes that force it follow.

The CCPA gives California consumers the right to know what personal information a business collects, to delete it, to opt out of sale or sharing, and to not be discriminated against for exercising those rights.

The California Consumer Privacy Act (CCPA) | State of California - Department of Justice - Office of the Attorney General sets out those obligations in the form the Attorney General enforces.

For an analytics team, the practical consequence is simple. If a user asks you to delete their data, your dashboard cannot keep showing them in a unique-user count. A number that cannot be recomputed after deletion is a number you cannot defend.

The CPRA amended the CCPA and added the right to correct inaccurate personal information, the right to limit use of sensitive personal information, and a retention disclosure duty. That last one is the one that hits dashboards hardest.

The timeline matters. The CCPA took effect on January 1, 2020, and the Attorney General began enforcing it on July 1, 2020.

Voters passed the CPRA as Proposition 24 in November 2020. Most CPRA obligations took effect on January 1, 2023, and the California Privacy Protection Agency began enforcing the CPRA regulations on July 1, 2023.

Retention disclosure means you must state how long you keep each category of personal information. If your dashboard reads from a table with no retention column, you cannot answer the question.

The CPRA also created the California Privacy Protection Agency, which now shares enforcement with the Attorney General. Two enforcers means two sets of expectations about documentation.

The California DOJ publishes broader privacy and data security guidance that shapes how these rules get read in practice, including expectations about reasonable security. See Privacy and Data Security | State of California - Department of Justice - Office of the Attorney General.

One more thing that trips up BI teams: the CCPA's definition of personal information is broad enough to cover device identifiers, IP addresses and pseudonymous IDs. Your hashed user key is probably in scope.

What this looks like in a data model

Most pipelines carry a user key, a timestamp, an event name and a set of dimensions. Under CCPA and CPRA, three of those become regulated fields.

The user key is personal information. The timestamp supports the retention clock. The dimensions can re-identify someone when combined, which is why cohort definitions need a minimum size.

A useful discipline is to treat every metric definition as a contract. Write down what it counts, what it excludes, how long the underlying rows live, and who can see the output. That document is what you hand an auditor.

If your organization is still deciding who owns those contracts, data governance as of 2027 covers how the ownership question is settling out across US analytics teams.

How the New York SHIELD Act changes breach and retention duties

The New York SHIELD Act is not a consumer rights statute like California's. It is a security and notification statute, and it applies to any business holding private information of a New York resident, whether or not that business is in New York.

That reach matters. A California company with New York customers is covered by both regimes at once, and the two do not line up neatly.

The SHIELD Act requires businesses to maintain reasonable safeguards for private information. It does not prescribe a specific control list, which means the standard is whatever a regulator decides is reasonable after an incident.

It also expands the definition of private information beyond the old combination of name plus Social Security number. Account numbers, biometric data and username or email plus password now count.

Breach notification is the operational core. If private information is exposed, the business must notify affected New York residents and report to the state in defined circumstances. The Report a Data Breach | New York Attorney General page explains the filing route and what the notice must contain.

For analytics, the notification duty turns access logs into a legal artifact. When a breach is suspected, the first question is who touched the data and when. If your warehouse query logs roll off after thirty days, you cannot answer.

Retention settings cut both ways here. Keep logs too briefly and you cannot investigate. Keep them too long and you are holding personal information with no purpose, which weakens your reasonable safeguards argument.

The workable answer is tiered retention. Keep raw access logs for a short window, keep aggregated access summaries longer, and keep the breach investigation record for the period your counsel specifies.

The security program expectation

Because the SHIELD Act does not name controls, most teams map to a recognized framework and document the mapping. That is how you show reasonableness without guessing.

The NIST Privacy Framework is the common choice for the privacy side because it separates data processing from data protection and gives you a vocabulary for both. The Privacy Framework | NIST is structured around identify, govern, control, communicate and protect functions.

A dashboard team rarely needs the whole framework. The govern and control functions usually cover what a BI group actually touches.

An undocumented control is indistinguishable from no control when a regulator asks.

Pending New York privacy bills and what they would add

New York has repeatedly come close to passing a comprehensive consumer privacy law and has not yet done so. Several bills have circulated in the legislature, and their shape has been consistent enough that you can plan against it.

The table below sets out the bills that matter most for planning and the rights each of them would add.

One of the two is no longer pending. The Child Data Protection Act was signed in 2024, so its duties belong in your compliance plan rather than your watch list.

Some versions would add a private right of action for certain violations. That single clause changes the risk calculus more than any other provision, because it invites litigation rather than waiting for a regulator.

Other versions would create a duty to conduct data protection assessments for processing that presents heightened risk. Profiling and large-scale sensitive data processing usually trigger that duty.

If a bill with assessments passes, your dashboard documentation becomes a regulated input. A metric that profiles individuals by inferred health status, for example, would need an assessment on file before launch.

The practical move is to build the pipeline so that access, correction and deletion are already supported, even if no New York law yet requires them. The cost of adding a deletion path later is far higher than building it now.

Bill numbers reset every two-year session, so check the current number before you cite it. What matters for planning is the rights list and the enforcement mechanism, not the branding.

A planning assumption that holds up

Assume New York lands somewhere between the SHIELD Act and the CPRA. That means a security duty you already have, plus consumer rights you probably do not.

Design for the stricter of the two states you operate in. If California and New York both apply, the California definitions are usually the binding constraint on metrics.

The approach in PIPEDA dashboard compliance metrics is a useful comparison for teams operating under more than one regime.

Metric definitions that must change: identifiers, cohorts and consent flags

This is where the law stops being a legal problem and becomes a data modeling problem. Three families of definitions need rewriting.

Identifiers

Any metric labeled unique users, visitors, devices or accounts is an identifier count. Under CCPA and CPRA, that count has to be reproducible after a deletion.

The fix is a deletion-aware counting method. Either you maintain a suppression list that the count excludes, or you recompute from a source that honors deletion. Counting from an immutable event log and subtracting nothing is the pattern that fails.

Name the metric honestly. "Unique users" implies a person count you cannot deliver. "Distinct active identifiers" describes what you actually measure.

Cohorts

Cohort metrics are re-identification risk in disguise. A cohort of three users in a small ZIP code is effectively a list of three people.

Set a minimum cohort size and enforce it in the query layer, not in a dashboard filter that an analyst can remove.

A defensible default is twenty active identifiers per published group. Twenty is large enough that one person rarely dominates a cell, and small enough that most segments still render. Raise the floor to fifty for sensitive categories, such as health data or precise location.

Also cap the number of dimensions that can be combined in a single breakdown. Re-identification usually comes from intersection, not from any single field.

Consent flags

Consent is not a boolean you set once at signup. Under the CPRA you need to distinguish consent to collect, consent to share, and the exercise of an opt-out of sale or sharing.

That means at least three fields, each with its own timestamp and source. A single consent_given column cannot answer a regulator's question about when a user opted out.

Sensitive personal information needs a fourth flag for the right to limit use. If you process precise geolocation or health data, that flag gates the metric, not just the record.

Consent flags also need to flow into the semantic layer. If a dashboard author can build a metric without joining the consent table, the control does not exist. See analytics foundations metrics for how teams are scoring that kind of coverage gap.

What to do with legacy metrics

You will not rewrite every metric at once. Rank them by whether they can identify a person, then by whether anyone outside the company sees them.

External reporting metrics come first. Internal exploratory metrics can wait, but they still need a cohort floor.

A worked example: a retail analytics team counted daily unique shoppers from a raw event table. After the CPRA retention disclosure, they added a suppression join and a documented ninety-day window on the raw table. The headline number dropped by roughly the share of shoppers who had requested deletion, and the definition now survives an audit.

Retention settings and access logs under California and New York rules

Retention is the connective tissue between the two states. California requires you to disclose it. New York requires you to be able to investigate within it.

Start with a category schedule. List each category of personal information your dashboards touch, the purpose, and the retention period. If a category has no purpose, delete it rather than scheduling it.

Then map the schedule to physical tables. A category schedule that does not name tables is a policy document, not a control.

These are typical starting points, not statutory requirements.

Each period is set by the purpose of the data, the investigation window your counsel requires, and what your published policy says.

Access logs need three properties to be useful. They must record who queried, what they queried, and when. They must be tamper-resistant enough to be credible. They must survive long enough to cover the investigation window.

Most warehouses give you query history by default, but the default window is often short. Check it before you assume it is adequate.

The last item is easy to miss. A suppression list is personal information about the people who asked to be suppressed.

Where the two states pull apart

California's retention duty is a disclosure duty. You must tell people how long you keep data, and keeping it longer than disclosed is the violation.

New York's retention pressure comes from the security side. Holding data longer than necessary weakens your reasonable safeguards position.

When the two conflict, write down the reasoning. A written justification for a retention period is the artifact that satisfies both.

Where the FTC safeguards rule overlaps with state privacy law

The FTC's privacy and security guidance applies to a wide range of businesses and sets expectations that state law tends to assume. The Privacy and Security | Federal Trade Commission materials lay out the agency's view of reasonable data practices.

The overlap is substantial. The FTC cares about data minimization, access control, retention limits and accurate privacy claims. California cares about the same things from a rights perspective. New York cares about them from a breach perspective.

The practical implication is that one control set can satisfy all three if you document it against each regime. Building three separate programs is wasted effort.

The FTC also polices claims. If your privacy policy says you retain data for one year and your warehouse keeps it for five, that gap is a deception issue, not just a retention issue.

That makes your retention documentation a marketing artifact as well as a compliance one. The number in the policy and the number in the DDL have to match.

For dashboards specifically, the FTC's interest in accuracy extends to reported metrics. A dashboard that overstates user counts because it ignores suppression is an accuracy problem with a legal edge.

One control set, three audiences

Access control satisfies the FTC expectation, the SHIELD Act safeguard and the CPRA limit-use right, provided the control is written down once and mapped explicitly to each regime.

Review that record annually and when a law changes. A record that has not been touched since the last legislative session is a liability.

This is also where accessibility and privacy documentation start to share a maintenance burden. Teams that already maintain dashboard accessibility standards for US agencies have the review cadence in place.

A dashboard sign-off checklist for two-state compliance

Run this before every dashboard release that touches consumer data. It takes an hour and prevents the rebuild that takes a quarter.

Step six is the one teams skip, and it is the only step that proves the pipeline works. A deletion path that has never been exercised is a claim, not a control.

Keep the sign-off record with the dashboard definition. When a regulator or an auditor asks how a number was produced, the record answers faster than any interview.

The skill mix shifts toward governance and documentation, which shows up in analytics careers 2027 as demand for roles that combine modeling with compliance literacy.

Sign-off steps

If no one owns the record, the sign-off becomes a formality and the checklist becomes decoration.

Common questions