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

What to take away

• Intelligence dashboard metrics built on US consumer data now carry legal weight in two states: California's CCPA and CPRA, and New York's SHIELD Act.
• CCPA and CPRA force you to rename and rescope identifier counts, cohort definitions and consent flags so a deletion request can actually be honored.
• The SHIELD Act adds breach notification duties plus a security program expectation, which turns access logs and retention settings into evidence you must keep.
• Pending New York privacy bills would add consumer rights closer to California's, so build the pipeline once and switch on the rights later.
• The FTC safeguards rule overlaps with both states and can be satisfied by the same controls if you document them once.
• A two-state sign-off checklist, run before every dashboard release, is cheaper than rebuilding metric definitions after a complaint.

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 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.

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.

What matters is that the mapping is written down and dated. 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 recurring proposals would give New York consumers rights to access, correct, delete and port their data, plus a right to opt out of targeted advertising and sales. That is the California package with different labels.

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.

Track the bills by number and sponsor rather than by nickname, because coverage tends to blur them together. 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.

This is the same logic Canadian insurers use when they reconcile federal and provincial rules. 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. Common thresholds range from five to twenty-five depending on the sensitivity of the underlying data.

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.

Metric family	Common definition today	Definition under CCPA and CPRA
Unique users	Count of distinct user keys	Distinct active identifiers, excluding suppression list
New users	First event per key	First event per key with a valid collection consent flag
Cohort size	Any grouping of keys	Grouping with minimum size enforced in the query layer
Consent rate	Share with consent_given true	Share with collection, sharing and limit-use flags resolved
Retention	Rows kept until table cleanup	Rows kept per documented category schedule
Access log	Query history, 30 days	Query history, tiered, with investigation record retained

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.

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.

• Category schedule names every table holding personal information
• Each category has a stated purpose and a retention period
• Deletion requests propagate to every downstream table and aggregate
• Access logs capture user, query text, timestamp and row count returned
• Log retention window is documented and matches the investigation policy
• Aggregated outputs are covered by the same schedule as raw data
• Suppression list is itself retained and access-controlled

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, but holding logs too briefly defeats breach investigation.

When the two conflict, document 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

Write the control once, then map it. Access control satisfies the FTC expectation, the SHIELD Act safeguard and the CPRA limit-use right, provided the mapping is explicit.

Review the mapping annually and when a law changes. A mapping 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.

1. Confirm the data source. Identify every table behind the dashboard and mark which ones hold personal information under CCPA and CPRA definitions.
2. Check the metric definitions. Every identifier count must be deletion-aware, and every cohort must have an enforced minimum size.
3. Verify consent joins. Confirm the semantic layer requires consent flags for any metric that depends on collection or sharing.
4. Inspect retention settings. Compare the live table retention against the disclosed category schedule and flag any mismatch.
5. Confirm access logging. Verify user, query, timestamp and row count are captured, and that the retention window covers the investigation policy.
6. Test the deletion path. Submit a test deletion and confirm the dashboard output changes within the stated window.
7. Record the sign-off. Store the review with the mapping to NIST, the FTC guidance and the state requirements.

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.

Teams building this habit early tend to find it changes how they hire and train. 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.

Who signs

The analytics manager owns the metric definitions. Legal owns the mapping to statute. Someone has to own the join between them, and that is usually the data governance lead.

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

Common questions

Does the CCPA apply to dashboards that only show aggregated numbers? It can, because aggregation does not remove personal information from the underlying pipeline. The dashboard output may be safe while the source tables are still in scope, and retention and deletion duties follow the source data.

Is the New York SHIELD Act limited to companies in New York? No. It applies to any business holding private information of a New York resident. A company based in California or Texas with New York customers is covered for those records.

Do pending New York privacy bills change anything today? Not directly, since they are not law. They change planning, and building access, correction and deletion support now is cheaper than retrofitting it after a bill passes.

How long should access logs be kept? There is no single number. The window has to cover your breach investigation policy and match what you disclose. Many teams keep raw logs briefly and aggregated access summaries longer.

Can one retention schedule satisfy both California and New York? Yes, if it is documented per category with a stated purpose and a written justification for the period. The two states push in different directions, so the reasoning matters as much as the number.

What is the minimum cohort size we should enforce? There is no statutory threshold in either state. Common practice runs from five to twenty-five depending on data sensitivity. Pick one, enforce it in the query layer, and document why.