Two privacy laws on, one rulebook paused: compliance by capability map

The week

If you wanted a single week that captured why American privacy compliance gives general counsels headaches, the first week of July 2023 would do nicely. Two deadlines arrived exactly on time. A third vanished the day before it was due.

On July 1, 2023, the Colorado Privacy Act and Connecticut’s Data Privacy Act took effect. They joined Virginia’s law, which had been in force since January. All three belong to a new family of state laws that give residents rights over the personal information companies hold about them. These include the right to see it, correct it and delete it, and to say no to having it sold or used for targeted advertising. In the absence of a single federal privacy law, these state statutes were becoming the country’s rulebook, one state at a time.

Neither law arrived as a surprise. Colorado’s was signed in July 2021 and Connecticut’s in May 2022, giving organizations a long runway. Colorado’s attorney general had also finished detailed implementing rules in the spring of 2023. They spelled out what a data protection assessment must cover, how consent must be obtained and refreshed, and how a universal opt-out mechanism would be recognized. Colorado’s law required controllers to honor such a mechanism from July 1, 2024. Both states’ laws were enforced by their attorneys general, with no private right of action, and both gave businesses a period in which they could cure a violation after notice before facing penalties.

The two laws were close cousins, with differences that mattered. Each applied to businesses handling the data of at least 100,000 state residents a year, or fewer if they earned money from selling data. Connecticut exempted nonprofits, while Colorado’s law did not. Connecticut exempted financial institutions subject to the Gramm-Leach-Bliley Act and entities covered by HIPAA outright. Both carved out personal data governed by those federal laws. Connecticut’s legislature had also passed amendments that spring adding protections for consumer health data and for children’s data online, so the law was changing even as it took effect.

California was further along. Its consumer privacy law had been strengthened by the CPRA amendments. The state’s dedicated privacy regulator, the California Privacy Protection Agency, had finalized detailed regulations under those amendments at the end of March 2023. Enforcement of those rules was due to start on July 1.

That timetable had already slipped once. The ballot measure that created the agency in 2020 had set a deadline of July 1, 2022 for its rules and July 1, 2023 for enforcement. The agency finalized its first package of rules on March 29, 2023, nine months late. Several required topics, including cybersecurity audits, risk assessments and automated decision-making, were still unwritten. The California Chamber of Commerce sued, arguing that businesses had been promised a year between final rules and enforcement.

Then, on June 30, a California superior court ruled in that challenge. The court held that the agency could not enforce them until a year after they were finalized. That pushed enforcement of the new rules to late March 2024. Rules not yet written would likewise wait a year from their own completion. Enforcement of the statute itself, the underlying law passed by voters, was left in place. So companies still had legal duties in California; what moved was the timetable for the agency’s more detailed rules. California’s attorney general had been enforcing the original consumer privacy law since 2020. In August 2022 it had settled with the retailer Sephora for $1.2 million, partly over a failure to honor browser opt-out signals.

Meanwhile, other states had passed their own privacy laws that spring, each with a later start date and its own particular twists. Iowa, Indiana, Tennessee, Montana and Texas all enacted comprehensive laws in the first half of 2023, with start dates spread from 2024 to 2026. Utah’s, passed the year before, was due at the end of 2023. Washington had passed a separate law aimed specifically at consumer health data.

In one week, then, two laws went live and one set of rules moved. For a compliance team that had planned its year around fixed dates, the calendar had just been redrawn. The week also showed why the privacy budget never seems to settle down: the rules were multiplying, and their dates could not be relied on.

For a compliance team, that week was a planning lesson in miniature. Two deadlines arrived on schedule. A third moved by nine months, a day before it was due, through a lawsuit few teams had modeled. More state laws were queued behind them with their own dates and twists.

A program run as a series of go-live projects would have spent the summer rebuilding its plan. A program built around capabilities would have updated a mapping table. The second approach is cheaper, and much easier for a board to oversee.

Set the statute-by-statute reading aside for a moment and ask what a program needs to be able to do, whatever the state. We see four capabilities: knowing the data, answering people, justifying processing, and proving all of it. Each new law then becomes a set of settings on those four, rather than a new project.

The argument proceeds in order. First, why a capability map beats a law-by-law plan, and where it does not. Then each of the four capabilities in turn, with what it takes to build and who it applies to. Then one request followed through all four, how to run the map and report it, the signs of a program that will cope, and a short test against a moved deadline.

Why a capability map beats a law-by-law plan

Most organizations first meet a new privacy law as a deadline. Someone in legal reads the statute, a project is opened, consultants are hired, and a go-live date goes on the calendar. When the next law arrives, the cycle repeats. Each project produces its own spreadsheet, its own notice, its own process.

That works for one law. It fails at five, and it fails badly when dates move. The team ends up maintaining parallel processes that do nearly the same thing, and nobody can say with confidence which version is current.

A capability is something the organization can reliably do, with people, process and systems behind it, regardless of which law is asking. A hospital emergency department works this way. It does not build a new department for each type of injury. It builds triage, imaging, surgery and records once, and adjusts how they are used for each patient. The state privacy laws are, mostly, different patients presenting with similar symptoms. They differ in thresholds, deadlines and definitions, but they ask for the same underlying abilities.

Seen this way, each law becomes a short list of parameters, meaning the settings that differ from state to state. Examples are how many days to respond to a request, which data counts as sensitive, and whether an appeal is required. Change the law, change the settings. The machinery stays the same.

Who is in scope, by type of organization

The map starts with a plain question for each legal entity in the group: is this entity covered by this law at all? The answer varies more than many leaders expect.

• Banks, credit unions and broker-dealers are financial institutions under the Gramm-Leach-Bliley Act. Several states, Connecticut and Virginia among them, exempt such institutions entirely. California exempts only the data collected under that federal law, so the same bank’s website and marketing data can be in scope there.
• Wealth managers and fintechs need entity-by-entity analysis. A registered adviser handling client accounts is usually a financial institution under the federal law. A marketing subsidiary or a consumer app in the same group may not be.
• Health systems and ambulatory networks are HIPAA covered entities for their clinical operations. Connecticut exempts covered entities outright. Colorado exempts protected health information but, unlike Connecticut, does not exempt nonprofits, so a nonprofit system’s non-clinical data can fall within it.
• Life sciences companies often hold research and clinical trial data, which several states carve out, alongside marketing and patient-support data, which they generally do not.
• State and local agencies are exempt from these laws. Their privacy duties come from public records laws, state agency privacy statutes and program rules instead. They meet these laws mainly as buyers, when their vendors are covered.

Getting this layer right avoids two expensive errors: building compliance for an entity that is exempt, and assuming exemption for one that is not.

Where the analogy breaks

The strongest objection to a capability map is that the laws are not all the same patient. Some obligations are genuinely different in kind. California’s law reaches employee and business-contact data, which most other state laws exclude. California also requires specific notices at the point of collection and a defined set of contract terms with service providers. A map that forces every rule into four boxes will lose some of them.

The answer is an exceptions register alongside the map: a short list of obligations that do not fit a parameter, each with an owner and a process. In most programs that list stays short. If it grows long, the capability design is wrong and needs another look.

A second objection is about money. Law-by-law projects have a clear budget line and an end date, which finance teams like. A capability program needs a standing budget and permanent owners. Such a budget is harder to win in year one and cheaper by year three, once several laws have arrived. A chief compliance officer making the case should show the projected cost of each approach over the next several laws, not the next one.

Capability one: knowing the data

Every state law depends on facts about data the organization may not have. Which personal data it holds, about whom, from which source, for what purpose, and shared with whom.

Colorado and Connecticut both treat certain categories as sensitive, including health conditions, precise location in Connecticut’s case, and data revealing racial or ethnic origin. Each sensitive category triggers extra duties, such as getting a person’s consent before using it, or carrying out a formal assessment of the risks.

The capability here is a maintained data inventory tied to systems, not a spreadsheet produced once for a privacy notice. A data inventory is simply a living catalog: for each system, what personal data is in it, where it came from, why it is used and who receives it. You cannot protect, delete or disclose what you do not know you have.

In practice that means a named data owner for each system and a classification scheme that includes each state’s sensitive categories. It also means a change process that updates the inventory when a new marketing tool or analytics feed goes live, so the catalog does not drift out of date.

For banks and health systems, the inventory must also record which data falls under GLBA, the federal law governing financial privacy, or HIPAA, its counterpart for health information. This matters because the states built their exemptions two ways. Some exempt the institution: Connecticut, like Virginia, exempts financial institutions subject to GLBA and HIPAA covered entities outright. Others exempt only the data: California’s law covers a bank, but not the personal information it collects under GLBA. Its loan files may be exempt there; its website visitor data may not be. And an affiliate that is neither a GLBA financial institution nor a covered entity gets no institutional exemption anywhere.

The inventory therefore needs two layers. An entity map records each legal entity, its federal status and whether each state’s law applies to it. A data map records each system and field, and whether the data is governed by GLBA, HIPAA, the Fair Credit Reporting Act or another carve-out. Together they answer the question each request and each assessment begins with.

The gaps tend to sit outside core systems. A bank’s mortgage marketing site, a health system’s foundation donor database and a wealth manager’s event registration tool all hold personal data that no federal exemption covers. Discovery tools that scan cloud storage and SaaS applications (software rented over the internet, such as a hosted email marketing platform) help find this data. But they find data, not purposes. Purpose still has to come from the business owner, so the inventory needs a quarterly attestation, a signed confirmation from each owner, as well as a scanner.

Sensitive data and inferences

Sensitive categories need particular care, because they trigger consent. The categories go beyond obvious health records. They include data revealing health, ethnicity or religion, which can mean purchase histories, location trails or app usage from which those traits can be inferred. Colorado’s rules address such inferences directly.

That turns classification into an analytics question. A model that infers that a customer is pregnant or managing a chronic condition may create sensitive data from ordinary inputs. The inventory should record derived fields and the models that produce them, with the same ownership and attestation as raw data. Banks running marketing propensity models and health systems running patient engagement analytics are the most exposed here.

What it costs

Building the inventory is the most expensive of the four capabilities and the one most often skipped. The heavy cost is people’s time: interviews with system owners, reconciliation with the asset register, and the first round of attestations. Scanning tools reduce the effort but add licensing and tuning. The cost falls after year one, provided the inventory is wired into change management. Without that link, it decays and must be rebuilt, which is the most expensive outcome of all.

Capability two: answering people

All the new laws give consumers rights to access, correct, delete and port their data, and to opt out of targeted advertising, sale and certain profiling. “Port” means receiving a copy in a usable format so it can be taken elsewhere. “Profiling” means using automated analysis of someone’s data to predict or judge things about them.

The details differ between states: response deadlines, appeal processes, how identity is verified and which data is in scope.

Some parameters are common. California, Colorado and Connecticut all set a 45-day response period that can be extended once by a further 45 days in defined circumstances. Others differ: Connecticut gives a business 60 days to decide an appeal, and California’s law has no formal appeal right at all. The workflow should hold these as settings, not as code written for each state.

The capability is one intake and fulfillment workflow with configurable rules per state, run much like a good customer service ticketing system. A request comes in through a web form, phone line or authorized agent. The system verifies the person’s identity to a standard proportionate to the request; you need more proof before handing over someone’s full file than before removing them from a mailing list. It routes the request to the data owners named in the inventory, tracks the deadline that applies in that person’s state, and records the outcome.

Appeals, which Colorado and Connecticut require, are a second queue with a different reviewer. If a person is unhappy with the answer, someone other than the original handler looks again.

Verification without over-collection

Identity verification is where rights workflows most often go wrong in both directions. Too little proof and the organization hands one person’s data to another, which is itself a breach. Too much and it obstructs a legal right, which regulators treat as a violation.

The workable rule is proportionality. Opt-outs of sale and targeted advertising generally need no verification at all, because the downside of honoring a false request is small. Deletion needs a reasonable match. A request for a full copy of someone’s file needs the strongest match the organization can perform with data it already holds. Asking for new sensitive data, such as a Social Security number, merely to process an opt-out runs against the purpose of the law.

For a bank or health system, the best verification tool is usually the authenticated customer or patient portal. A request made from a logged-in session can be matched to the account without collecting anything new. Requests from people with no account need a separate, lighter path.

Measuring the workflow

The workflow should report on itself. Useful operating measures include request volume by type and channel, time to verify, time to close, the share closed within the deadline, and the share of verification attempts that fail. A rising failure rate usually means the verification step is too demanding, and that is a regulatory risk as well as a service problem. A sudden spike in volume usually means an authorized agent service or a news story, and the team needs a way to add capacity quickly.

Authorized agents

Several laws let consumers act through an authorized agent, including commercial services that submit requests in bulk. The workflow needs a way to verify the agent’s authority and to handle volume spikes when a service sends many requests at once. Organizations that built only a consumer-facing web form found agent traffic arriving by email, outside the tracked queue, with deadlines already running.

Opt-out preference signals belong here too. These are automatic messages a person’s web browser can send to every site they visit, saying in effect “do not sell or share my data.” The person no longer has to click through each site’s settings. Colorado’s law required controllers, the businesses that decide how personal data is used, to honor a recognized universal opt-out mechanism from July 1, 2024.

The most widely used signal, Global Privacy Control, is technically simple. A participating browser adds a header to each web request and exposes a flag to scripts on the page. The website must read it and treat that browser as opted out of sale and targeted advertising. If the visitor is logged in, the opt-out should attach to the account as well.

Honoring a browser signal is an engineering task on websites and tag managers (the tools that control which tracking and analytics code runs on a web page), not a policy statement. Teams that treated it as a parameter of the rights workflow could switch it on by state. Teams that treated it as a legal footnote discovered late that their marketing technology had no off switch.

The engineering work is specific. The tag manager must check the signal before firing advertising and analytics tags. Server-side data sharing with advertising partners must honor the same flag. Consent management tools must record the signal as an opt-out with a timestamp, so the evidence exists later. Each of these touches a different team, which is why it takes longer than expected.

Capability three: justifying processing

The newer laws require data protection assessments for higher-risk processing, such as targeted advertising, sale, profiling with significant effects and sensitive data. An assessment is a structured, written look before you leap. It records what the organization plans to do with the data and what benefits it expects. It also records what could go wrong for the people involved and what safeguards it will put in place.

The laws also require consent before processing sensitive data. Colorado’s attorney general issued detailed rules on what an assessment must contain, which made Colorado the de facto template for the other states.

Colorado’s rules also tightened what counts as consent. Consent must be freely given, specific, informed and unambiguous. Under both Colorado’s and Connecticut’s laws, agreement obtained through a dark pattern, a design that steers people toward a choice they did not intend, does not count as consent. Colorado’s rules add requirements to refresh consent for sensitive data over time. A consent banner designed for conversion rates can fail every one of these tests.

The capability is a standard assessment that satisfies the most demanding state and is triggered by the inventory. When a team proposes a new use of sensitive or profiled data, the assessment runs before launch, records the benefits and risks, and names the person who approved it. Consent capture for sensitive data sits alongside it, with records that show what the person agreed to and when.

The trade-off is effort. A single “high-water-mark” assessment, written to the strictest standard, costs more for low-risk projects than a lighter form would. It is still cheaper than maintaining several assessment templates and arguing about which applies. And it removes a recurring source of internal friction: product teams get one form, one process and one answer.

Profiling and significant decisions

The new laws also give people the right to opt out of profiling that produces legal or similarly significant effects. Examples include decisions about credit, housing, insurance, health care or employment. For a bank, much of that territory is already governed by fair lending law and the Fair Credit Reporting Act, and the data involved may be exempt. For a health system or insurer, care management algorithms and eligibility tools can fall closer to the line.

The assessment is the right place to decide. It should record what the model decides, what data it uses, whether a human reviews the outcome, and which exemptions apply. That record does double duty: it satisfies the state laws and gives model risk and clinical governance teams the documentation they need anyway.

Who signs

Each assessment needs an accountable approver with authority to say no. In most organizations that is the business owner of the processing, with the privacy office as reviewer rather than decision-maker. Where the privacy office both writes and approves, the assessment tends to become paperwork. Where the business owner signs, the trade-offs are owned by the person who benefits from the processing, which is where they belong.

Suppose a regional health insurer wants to use members’ location data to recommend nearby clinics. Under a law-by-law approach, the team would ask which states’ members are involved, look up each state’s rules and draft separate analyses. Under a capability approach, the inventory flags location as sensitive, the standard assessment is triggered automatically, and the privacy office reviews one document that already meets the strictest requirement. The launch date depends on the quality of the idea, not on how many state statutes someone has to read.

Capability four: proving it

Regulators rarely ask whether a policy exists. They ask for evidence. That means request logs with timestamps, assessment records, processor contracts with the terms each law requires, and privacy notices that match actual practice.

The capability is a record set produced as a by-product of the other three, so that evidence is never assembled by hand after an inquiry arrives. If the rights workflow logs every request automatically, and the assessment process stores every approval, the evidence file builds itself. The alternative, a frantic fortnight of emailing colleagues for screenshots after a regulator’s letter, is both expensive and unconvincing.

What an attorney general would ask for

State regulators have mostly opened with letters and cure notices rather than lawsuits. A typical inquiry asks for a short list of things. A program should be able to produce each within days:

• The privacy notice in force on a given date, and evidence that it matched the organization’s actual practices.
• Request logs showing receipt, verification, response dates and outcomes, including denials and their reasons.
• Evidence that opt-out signals were honored on a given date, such as tag manager configuration history.
• Data protection assessments for the processing in question, with approval dates.
• Processor contracts and the deletion confirmations received at the end of service.

Retention of the records themselves is part of the design. California’s regulations, for example, require businesses to keep records of consumer requests and their responses for at least 24 months. Keeping logs for the longest required period across states is simpler than tracking several retention rules.

Processor contracts deserve attention. A processor is a vendor that handles personal data on the organization’s behalf, such as a payroll provider or a cloud email service. Each law specifies terms these contracts must include: confidentiality, deletion at the end of service, assistance with assessments and the right to object to subprocessors (the processor’s own vendors). A single contract addendum written to the strictest state is easier to maintain than a library of state-by-state riders.

The addendum is half the job. The other half is knowing which vendors hold personal data, which the inventory supplies, and confirming that they do what the contract says. For high-risk processors, that means periodic attestations, a review of their subprocessor list, and a deletion certificate at the end of the relationship. Procurement should refuse to onboard a vendor that will not sign the standard addendum, unless the privacy office approves an exception and records it.

For banks, this work overlaps with the third-party risk management that prudential regulators already expect. Folding privacy terms into that existing process, rather than running a separate privacy vendor review, saves effort and gives one view of each vendor.

How the four work together: one request, start to finish

Follow a single request through the machinery. Suppose a customer of a mid-sized wealth manager, living in California, emails to ask what personal data the firm holds about her and to have her information deleted from its marketing lists.

The request lands in the intake workflow. The system notes her state and applies California’s settings: the response deadline, the level of identity proof needed, and the fact that California’s law has no formal appeal right. Because she is asking for a copy of her data, the firm asks for more proof of identity than it would for a simple marketing opt-out. Once she is verified, the workflow consults the inventory, which shows that her data sits in the client relationship system, the event registration tool and the email marketing platform. Each system’s named owner receives a task with a due date.

Some of her data, such as account records, may fall under GLBA. The inventory says so at field level, so the team knows which parts of the request the state law covers and which it does not. It can explain that clearly in its reply rather than guessing. The marketing data is deleted. The email platform, a processor, is instructed to delete its copy under the terms of the firm’s standard contract addendum.

Every step is logged with a timestamp. If she disagrees with any part of the answer, the firm still sends her challenge to a different reviewer. It runs one appeal queue for every state, because Colorado and Connecticut require one and a single process is simpler. If California’s privacy agency later asks how the firm handles requests, the evidence already exists.

Notice what did not happen. Nobody opened the statute. Nobody built a California-specific process. The capabilities did the work, and California’s law simply supplied the settings. Had a comparable customer of a non-exempt business lived in Colorado, the appeal rules and sensitive categories might have differed slightly, but the path would have been identical. That is the practical meaning of mapping laws onto capabilities: new states change the inputs, not the plumbing.

The entity map would have changed one thing had she lived in Connecticut. Connecticut exempts financial institutions subject to GLBA as entities, so the firm would have no statutory duty to answer her there. Many firms answer anyway, as a matter of policy and client service. The capability approach makes that a cheap choice: the same workflow runs, flagged as voluntary, with the same evidence.

Ownership follows the same logic. The privacy office owns the map and the standards. Business owners own their systems’ entries in the inventory and answer the tasks routed to them. Technology owns the workflow tools and the website engineering. Legal reviews the parameters as each law changes. Internal audit tests the evidence. Each group knows its part, and no group has to understand every statute to do it.

Running the map, and reporting it to the board

This structure also changes how a chief compliance officer reports to the board. The question stops being “which laws are live?” and becomes “how mature is each of the four capabilities?” Maturity can be measured with numbers the business already understands: request volumes, deadline performance, assessment coverage and contract coverage. When a court moves a date, the dashboard does not change. Only the mapping does.

The mapping itself needs an owner, usually in the privacy office. It also needs a short format. For each law: the effective date, the thresholds that bring the organization into scope (many state laws apply only above a certain number of residents’ records), and the parameter values for each capability. Legal counsel should review it as each law or rule changes. That review is a few days of work per law, rather than a new program each time.

What the mapping table holds

A workable map is a single table, one row per law, with a small set of columns:

• Status and dates: enacted, effective, rules finalized, enforcement start, cure period end.
• Scope: thresholds, entity-level and data-level exemptions, and which of the organization’s legal entities are covered.
• Knowing the data: sensitive categories, including any unusual ones.
• Answering people: rights granted, response and extension periods, appeal period, opt-out signal requirement and date.
• Justifying processing: assessment triggers, consent requirements, profiling rules.
• Proving it: record retention, contract terms, regulator and enforcement mechanism.
• Exceptions: anything that does not fit, with a link to the exceptions register.

The table is useful to people outside the privacy office too. Engineering reads the opt-out signal column. Procurement reads the contract column. Internal audit tests against the whole row.

Board metrics that mean something

Board reporting should show a handful of measures, trended over time and broken out by capability. Useful ones include the share of rights requests closed within the applicable deadline and the share of systems with a current attestation. Two more are the share of launches touching sensitive data that had an approved assessment before go-live, and the share of in-scope vendors on the standard addendum. Each has an owner and a target. None of them changes when a court moves a date, which is exactly why they are useful.

Return to the week in question. A team with this map, on hearing of the June 30 ruling, would have changed one cell: the enforcement date for California’s new regulations. Its Colorado and Connecticut settings would already have been switched on. Nothing else would need to move.

The same team would also have known what not to do. It would not have paused work on California readiness, because the statute stayed enforceable and the rules were likely to come back. A team that treated the ruling as a reprieve and redeployed its staff would have had to rebuild momentum when the appeal court reversed the decision.

Signs of a program that will cope

A mature program has a few recognizable features. The inventory is tied to real systems and refreshed when systems change. Rights requests run through one workflow, with deadlines tracked by state. One assessment template serves every launch that touches sensitive or profiled data. Vendor contracts carry one privacy addendum. And the board sees a small set of capability measures, trending over time.

The habits that undermine a program are just as easy to spot:

• Treating each law as a project. It feels responsive, but it creates duplicate processes that drift apart.
• Assuming the exemption works the same everywhere. Some states exempt the institution, others only its GLBA or HIPAA data, and affiliates outside those laws often get no exemption at all.
• Building the inventory once. A catalog that is not updated when systems change is out of date within months.
• Leaving opt-out signals to the lawyers. Honoring them is a website engineering job, and it takes time.
• Reporting laws instead of performance. A list of statutes tells the board nothing about whether the organization is actually meeting them.

Signs of trouble also show up in day-to-day work. Product teams ask the privacy office which states a launch must comply with, instead of filling in the standard assessment. Rights requests arrive in shared mailboxes. The marketing team cannot say which tags fire when an opt-out signal is present. Contract negotiations restart from scratch with each vendor. Each symptom points to a capability that has not been built, and each can be fixed without reading another statute.

When the organization is the buyer

Public agencies and exempt institutions are not off the hook in practice, because their vendors often are covered. A state agency’s call center contractor, a credit union’s marketing agency or a health system’s patient engagement platform may each be a business under these laws in its own right, for data it handles on its own account. The exempt organization’s exposure then runs through its contracts. Its procurement team should ask vendors how they map the state laws, whether they act as processor or as an independent business for each data flow, and how they will support requests that reach them directly. The capability map gives the buyer a ready set of questions, even when the buyer’s own obligations come from elsewhere.

The program also needs a way to absorb surprises. Courts, legislatures and regulators will move dates and add duties. A standing monthly review of the mapping table, with legal, privacy, technology and audit in the room, turns those surprises into routine updates. The review takes an hour when nothing has changed and a day when something has.

Testing the program against a moved deadline

• If a court or legislature moved a privacy deadline tomorrow, what in our program would have to change? Is it one table, or several projects?
• Do we have a current inventory of personal data, by system, with a named owner for each? When was it last confirmed?
• Which of our data is covered by GLBA or HIPAA, and which is not? How do we know?
• Do our websites honor browser opt-out signals today, and can we switch that on state by state?
• Could we produce evidence of all this for a regulator within a week, without asking anyone to rebuild it by hand?

Answering these takes the privacy office, the system owners and the technology team together. The answers should be written down, dated and kept, because the next time a date moves they become the baseline for what changed.

The privacy calendar is not going to settle down. The organizations that cope best will be those that stopped chasing the calendar and built the machinery instead.

With hindsight

The calendar kept moving. In February 2024 a California appeals court reversed the June 2023 ruling, letting the California Privacy Protection Agency enforce its regulations without the one-year delay. Teams that had planned around late March 2024 found the ground shifting once more. Those that had kept building through the delay lost nothing; those that had paused had a few weeks’ notice to catch up.

The agency went on to bring enforcement actions and to adopt further rules on risk assessments, cybersecurity audits and automated decision-making, meaning decisions about people made wholly or largely by software. Those rules were approved in September 2025 and took effect on January 1, 2026, with compliance dates for several obligations phased in over the following years. Each of those rules mapped neatly onto the capabilities described above: risk assessments onto justifying processing, audits onto proving it, and automated decision-making onto both.

The early enforcement record showed where programs actually failed. The agency’s first fines, against American Honda in March 2025 and the retailer Todd Snyder in May 2025, concerned how consumer requests and opt-outs were handled. Later actions included a $1.35 million fine against Tractor Supply in September 2025 and, with the state attorney general and district attorneys, a $12.75 million penalty against General Motors in May 2026. In August 2026 the agency, now calling itself CalPrivacy, brought its first action under both the consumer privacy law and the Delete Act. The data broker involved had required the last four digits of a Social Security number before letting people opt out. It was exactly the over-collection failure in verification that the rights workflow is meant to prevent. The same year, the state launched its platform letting residents ask all registered data brokers to delete their data in one request.

More states passed comprehensive privacy laws in 2023, 2024 and 2025, each with its own exemptions, sensitive categories and protections for minors. By 2026 the count was approaching 20 states. Universal opt-out signals moved from a Colorado provision to a requirement in several states; Connecticut’s took effect on January 1, 2025. An organization that had built the browser signal into its rights workflow as a per-state setting simply switched it on as each law arrived. One that had not faced a fresh engineering project each time.

Colorado and Connecticut both kept amending their laws. Colorado added provisions on biometric data and on minors. Connecticut broadened its law in 2025, lowering the thresholds that bring a business into scope. The cure periods in both states expired at the turn of 2025, so regulators could act without first giving notice and time to fix. Connecticut’s attorney general published annual enforcement reports describing the notices it had sent.

Other states began enforcing too. In January 2025 the Texas attorney general sued the insurer Allstate and its data analytics subsidiary, Arity, over driving data collected through mobile apps. It was widely described as the first lawsuit under a state comprehensive privacy law. The case was a pointed reminder that an affiliate’s activities can fall outside a parent’s assumed exemption.

Not every assumption in this article aged equally well. Maryland’s law, which took effect in October 2025, imposed data minimization standards that differ in kind from the consent-and-opt-out model of the earlier states. A “strictest state” template written to Colorado did not automatically meet it. Programs with an exceptions register absorbed it as one; programs without one had to rethink their templates.

Federal preemption, which would have collapsed the map into one row, did not arrive. A bipartisan draft federal privacy bill circulated in 2024 and stalled. The state-by-state approach remained the working reality through 2026.

Each new law tested the same four capabilities with different parameters. That is the strongest case for organizing around capabilities rather than around statutes: the statutes kept changing, while the capabilities they demanded did not.

Exemption analysis for affiliates and health-adjacent data remained a common source of surprise. A bank’s non-financial subsidiary, or a consumer wellness app run outside a health system’s covered entity, often sat outside the exemptions that leaders assumed covered the whole group.

The episode also says something about how to read regulatory change. A moving deadline is no reason to pause; the work that lasts is the ability to know your data, answer people, justify what you do with their information, and prove it on request. Laws will keep arriving. Those four abilities are what each of them will ask for.