US State Privacy Laws Beyond CCPA: Virginia, Colorado, and the Growing Patchwork

“

Meerako — helping US businesses architect software that adapts to a genuinely fragmented privacy law landscape.

For years, "US privacy compliance" effectively meant one thing: California's CCPA, later strengthened by the CPRA. That's no longer true. Virginia's Consumer Data Protection Act (VCDPA) took effect January 1, 2023, Colorado's Privacy Act (CPA) followed on July 1, 2023, and Connecticut's data privacy act took effect the same year — and since then, a steady stream of additional states have passed their own comprehensive privacy laws, each with its own effective date, its own scope thresholds, and its own specific requirements that don't map cleanly onto any other state's. The number of states with a comprehensive consumer privacy law now sits well into the double digits, with more added most legislative sessions, and the trend line points toward this patchwork only getting more complex, not less, in the absence of a single federal privacy law that would preempt it.

For any business operating online and serving customers across state lines — which, practically, describes almost every business with a website — this patchwork is a genuine operational problem, not an abstract legal curiosity. A single "one-size-fits-all" privacy policy and consent flow built around CCPA alone is very likely non-compliant with several other states' requirements, each of which carries its own enforcement mechanism and, in some cases, its own private right of action.

• Why "just comply with CCPA" is no longer a sufficient strategy for a US-facing business.
• The core similarities most state privacy laws share.
• The specific differences that actually matter for implementation — thresholds, opt-in vs. opt-out defaults, and enforcement.
• How this patchwork affects real software architecture decisions.
• A practical approach to building software that adapts to changing state requirements rather than needing a rebuild each time a new law passes.

Despite real differences in the details, most comprehensive state privacy laws share a common structural core, largely because later state laws were drafted with a close eye on Virginia's VCDPA as a template. Consumers generally get the right to access the personal data a business holds about them, the right to request deletion, the right to correct inaccurate data, and the right to obtain a portable copy of their data. Businesses generally must provide a clear, accessible privacy notice describing what's collected and why, and most laws require a documented process for verifying a request actually comes from the consumer it claims to be from, rather than accepting deletion or access requests at face value.

The similarities largely end at that core structure. Applicability thresholds differ meaningfully from state to state — some trigger compliance obligations based on the number of state residents' data processed annually, others add a revenue threshold, and the specific numbers vary enough that a business squarely covered in one state might fall entirely outside another state's scope. Opt-in versus opt-out defaults for sensitive categories of data also differ: some states require affirmative opt-in consent before processing sensitive data (health information, precise geolocation, data revealing certain protected characteristics) at all, while others permit opt-out-based processing by default, which is a materially different consent flow to build and maintain. Enforcement mechanisms diverge as well — most state laws give exclusive enforcement authority to the state attorney general, but a handful include, or have debated including, a private right of action allowing individual consumers to sue directly, which changes the practical risk calculus considerably for a business operating in that state, since a large corpus of individual claims carries very different exposure than a smaller number of AG-initiated actions.

It's tempting to reason that if a business builds to California's standard — often perceived as the strictest — it's automatically covered everywhere else. This isn't reliably true. Some other states' laws include specific provisions CCPA doesn't have in the same form, such as more restrictive rules around processing sensitive data by default, or a broader statutory right to opt out of profiling used for certain kinds of automated decisions. A CCPA-only compliance posture also tends to assume opt-out-based defaults for everything, which doesn't hold in states requiring affirmative opt-in consent for sensitive data categories — meaning a business that's genuinely compliant in California can still be materially out of compliance in another state simply because it built one uniform flow around the wrong state's rules.

This is where the legal complexity becomes a genuine engineering problem, not just a legal or policy one. A consent management system built to handle a single state's rules well doesn't automatically generalize — supporting multiple states properly generally requires the software to determine which state's rules apply to a given user (typically via IP-based or account-address-based geolocation, sometimes combined with an explicit residency declaration), and then apply the correct consent flow, retention rules, and rights-request handling for that specific state, rather than a single flow applied uniformly to everyone regardless of location.

Data mapping becomes correspondingly more important as well: to respond correctly to an access or deletion request under any of these laws, a business genuinely needs to know exactly where a given consumer's personal data lives across every system it touches — the CRM, the analytics platform, the marketing automation tool, any data warehouse or backup system — not just the primary application database. Building and maintaining an accurate, current data map is unglamorous, ongoing work, but it's the foundation every other compliance obligation depends on; a business that can't answer "where does this specific customer's data actually live" cannot reliably fulfill a deletion request even if the request-handling workflow itself is otherwise well built.

Given that new state privacy laws are a near-certainty most legislative sessions, the most durable approach is architecting privacy logic as a configurable layer rather than hard-coding a single state's rules directly into application logic. A rules engine that maps jurisdiction (determined per-user) to a specific set of requirements — consent defaults, retention periods, applicable rights — lets a business add support for a new state's law by adding configuration, not by rewriting core application code. This is meaningfully more maintainable than scattering state-specific conditional logic (if state == 'CA', if state == 'VA') directly across the codebase, which becomes increasingly fragile and hard to audit as the number of covered states grows.

Consent management platforms — whether a specialized third-party tool or an in-house-built system — genuinely earn their cost here, since they're built specifically to centralize exactly this kind of jurisdiction-aware logic in one place rather than replicated inconsistently across every application and integration a business runs.

Start with an honest audit of which states' laws actually apply to your business today, based on where your customers and users genuinely reside, not just where the company is headquartered. From there, map personal data flows across every system that touches customer data, not just the primary application. Build (or configure) a consent and rights-request system that's jurisdiction-aware rather than uniform. Establish a documented process for identity verification before honoring access or deletion requests, since an improperly verified request is itself a real compliance and security risk. And build a recurring review cadence — quarterly is reasonable for most businesses — to catch newly effective state laws before they create a compliance gap, since the patchwork changes more often than most companies' internal privacy review processes do.

Non-compliance under these laws isn't a purely theoretical risk. State attorneys general have shown a genuine willingness to open investigations and pursue enforcement actions against businesses with plainly deficient privacy practices — a privacy notice that doesn't disclose what's actually collected, a "do not sell my data" mechanism that doesn't functionally work, or a pattern of ignoring verified deletion requests are exactly the kinds of concrete, demonstrable failures that draw regulatory attention, since they're easy for a regulator (or a motivated researcher) to test and document directly. Beyond direct enforcement, there's real reputational exposure: privacy failures tend to surface publicly through security researchers, journalists, or simply frustrated customers posting about a company that ignored their deletion request, and that kind of public failure is considerably harder to walk back than the underlying technical fix would have been to build correctly the first time.

There's also a genuine operational cost to treating compliance reactively rather than architecturally. A business that bolts on ad-hoc, state-specific exceptions each time a new law passes accumulates exactly the kind of fragile, hard-to-audit logic described above — and eventually reaches a point where nobody on the team can confidently say what the system actually does for a resident of a specific state without tracing through a tangle of conditionals. That's a genuinely expensive position to be in, both because it's a compliance risk in itself and because it makes every future change slower and riskier than it needs to be.

One recurring failure pattern is treating privacy compliance as purely a legal deliverable — counsel reviews the requirements, produces a policy document, and hands it to engineering to "implement," with the actual translation from legal requirement to system behavior left underspecified. This handoff works far better when legal and engineering collaborate on a shared, concrete specification: not just "support the right to deletion" as a policy statement, but a specific, testable definition of what deletion means for this business's actual systems — does it include backups, does it include data already shared with a third-party processor, what's the actual timeline a request must be honored within, and how is the requester's identity verified before the request is honored at all. Getting this translation right the first time, with both legal and engineering input in the same conversation, is meaningfully cheaper than discovering the gap during an actual regulatory inquiry or a customer complaint.

The days of a single privacy compliance standard being sufficient for a US-facing business are over, and the patchwork of state laws is very likely to keep growing rather than consolidate. Businesses that architect their consent, data-mapping, and rights-request systems as a configurable, jurisdiction-aware layer — rather than hard-coding one state's rules — are positioned to absorb new state laws as they pass, instead of facing a costly rebuild with each new legislative session.

Need software architected to handle a genuinely multi-state compliance landscape? Let's talk.