The Patchwork Problem No Federal Law Has Solved
As of 2026, the United States still has no comprehensive federal privacy statute. What it has instead is a growing stack of state laws that share vocabulary but differ in almost every operational detail. The California Consumer Privacy Act, the Virginia Consumer Data Protection Act, the Colorado Privacy Act, the Connecticut Data Privacy Act, the Utah Consumer Privacy Act, the Texas Data Privacy and Security Act, and the Delaware Personal Data Privacy Act are all live. More are in pipeline.
Each law grants residents rights over their personal data. Each law defines "personal data," "controller" and "processor" differently. Each law sets different applicability thresholds. Each law draws its own line between opt-in and opt-out consent for sensitive categories. Each law gives its attorney general a different enforcement budget and penalty ceiling.
For a software engineer building a user-rights management system, this is not a policy nuisance. It is an architectural constraint. The user's residence state is now a first-class attribute in your access control model. Ignoring it means you are either over-sharing data in states with weak rights or under-serving rights in states with strong protections. Both outcomes carry legal risk.
This article maps the landscape from an engineering perspective. The focus keyword throughout is state privacy law compliance engineering, specifically what your team has to build when users cross state lines.
Law-by-Law Breakdown: Rights, Thresholds and Enforcement Teeth
Before designing a system, engineers need to understand which laws are structurally similar and which diverge in ways that break naive implementations.
California: CCPA as Amended by CPRA
The California Privacy Rights Act amended and substantially expanded the original CCPA. The California Privacy Protection Agency now has independent rulemaking and enforcement authority separate from the attorney general. The law applies to for-profit businesses meeting any one of three thresholds: annual gross revenue over $25 million, buying or selling personal data of 100,000 or more consumers or households, or deriving 50 percent or more of annual revenue from selling personal data.
Unique to California: a right to correct inaccurate personal information, a right to limit use and disclosure of sensitive personal information, and opt-out rights for automated decision-making that produces significant effects. Sensitive data categories require explicit opt-in for consumers under age 16. The private right of action for data breaches is also unique among state laws.
Virginia: CDPA
The Virginia Consumer Data Protection Act applies to controllers that process data of 100,000 or more Virginia residents annually, or 25,000 residents if the entity derives more than 50 percent of gross revenue from selling personal data. Virginia's law requires data protection assessments for high-risk processing, mandates processor contracts, and grants rights to access, correct, delete, portability and opt out of targeted advertising, sale and profiling for significant decisions. Virginia has no private right of action. The attorney general enforces with a cure period before penalties.
Colorado: CPA
The Colorado Privacy Act mirrors Virginia structurally but adds universal opt-out mechanism requirements. Controllers must honor opt-out preference signals, including browser-based global privacy controls, by a specific deadline under the attorney general's technical specifications. Colorado also requires consent for processing sensitive data, not just opt-out. That is a meaningful architectural difference: opt-in flows must be built for Colorado sensitive categories, not just a suppression flag.
Connecticut: CTDPA
Connecticut's law closely tracks Colorado, including the universal opt-out mechanism obligation. One notable difference is the treatment of dark patterns: Connecticut explicitly prohibits consent mechanisms that use deceptive design to obtain agreement. Your UX consent flows face Connecticut-specific legal scrutiny that Virginia's law does not impose with the same precision.
Utah: UCPA
Utah has the most business-friendly framework of the early-enacting states. No consent requirement for sensitive data processing, only an opt-out right. No data protection assessment requirement. Narrower applicability thresholds. Utah's law applies to controllers with annual revenue of $25 million or more that also meet data volume thresholds. Engineers building for a Utah-only user base face the lightest obligation set, but that does not mean Utah users can be ignored in a multi-state system.
Texas: TDPSA
The Texas Data Privacy and Security Act applies to any entity that conducts business in Texas or produces products or services consumed by Texas residents and processes or sells personal data, subject to size exemptions for small businesses as defined by the Small Business Administration. Texas requires opt-in consent for sensitive data and mandates data protection assessments. Texas applies to nonprofit organizations in certain circumstances, which most state laws exempt entirely.
Delaware: DPDPA
Delaware's Personal Data Privacy Act lowers the applicability threshold to 35,000 consumers annually, one of the lowest in the current state law stack. That threshold matters for smaller platforms that might have assumed they were below compliance thresholds under CCPA or Virginia's law. Delaware also includes a 60-day cure period for violations before penalties attach.
What Changes When a User Moves States
This is the engineering question that most compliance guides skip. What actually happens in your system when a user who was a California resident becomes a Texas resident?
The answer depends on what rights were granted, what consent was collected, and what data was processed under the prior jurisdiction's rules. At minimum, moving states triggers three classes of change:
Right Set Reassignment
California residents have a right to limit sensitive personal information use. Texas residents do not have that specific right in the same form. If your system granted a California user the ability to set a "limit SPI" flag and that flag suppressed certain processing, moving to Texas means the legal obligation to honor that flag may no longer exist under Texas law. Your system must decide whether to continue honoring it as a contractual commitment or remove it as an available control.
The conservative engineering answer is to honor the most restrictive prior consent as a persisted user preference even after jurisdiction changes. That approach is defensible and avoids re-consent flows that create friction. But it is a design decision, not a legal requirement, and it must be documented in your privacy policy.
Consent Basis Migration
California under CPRA and Colorado under CPA require opt-in consent for processing sensitive categories. Utah requires only opt-out. If a user who opted in for sensitive data processing under California law moves to Utah, the legal basis for processing that data shifts. The prior opt-in remains valid as a consent record, but your system must now evaluate whether the processing continues to require that consent under the new jurisdiction or whether opt-out is now the applicable standard.
Data minimization principles suggest keeping the consent record active regardless. But the consent receipt format needs to capture the jurisdiction under which consent was obtained, the timestamp, the specific purposes covered and the mechanism used. Without that metadata, you cannot reason about consent migration at all.
Automated Decision-Making and Profiling
California's CPRA creates the strongest opt-out right for profiling that produces significant effects. Colorado and Connecticut have similar provisions. Virginia has a profiling opt-out but with a narrower scope. Utah and Texas have more limited automated decision-making provisions.
A user who opted out of profiling in California and then moves to Texas may find that your system's profiling opt-out flag is no longer legally required. How your ABAC model handles that flag after jurisdiction reassignment is a concrete implementation question with real downstream effects on ad targeting pipelines, recommendation systems and risk scoring models.
Attribute-Based Access Control for Jurisdiction-Dependent Rights
Attribute-based access control (ABAC) is the natural architectural pattern for state privacy law compliance. In ABAC, access decisions are made by evaluating a set of attributes associated with the subject, the resource, the action and the environment. Jurisdiction is an environment attribute. User rights are subject attributes derived from that environment attribute.
The Policy Engine Design
Your ABAC policy engine needs to evaluate at minimum:
- Subject attributes: user ID, current residence state, consent records by purpose and jurisdiction, age category, opt-out flags and their originating jurisdiction
- Resource attributes: data category (general personal data vs. sensitive), processing purpose, data age, source of collection
- Action attributes: read, share with third party, sell, use for profiling, use for targeted advertising, retain beyond stated period
- Environment attributes: current date, applicable state law version, enforcement effective date
The XACML standard (OASIS eXtensible Access Control Markup Language) provides a formal language for expressing these policies. NIST Special Publication 800-162 provides the reference guide for ABAC in federal contexts, and many of its architectural patterns translate directly to commercial compliance systems. The W3C's work on ODRL (Open Digital Rights Language) offers a complementary vocabulary for expressing data usage policies as machine-readable constraints.
Jurisdiction Resolution Logic
Jurisdiction assignment is not as simple as reading a zip code. Users travel. Users have multiple residences. Users lie. Users use VPNs. State laws define residency based on domicile, not IP geolocation.
A robust jurisdiction resolution service should maintain a verified residence state from onboarding (self-declared and supported by payment address, shipping address or identity verification data) and allow users to update it with appropriate audit logging. The system should never use real-time geolocation as the primary jurisdiction signal for rights decisions, though it may use it as a secondary validation signal.
Jurisdiction assignment records should be immutable and append-only. When a user updates their state, the prior jurisdiction record is retained with its effective date range. This is essential for responding to retroactive data subject rights requests that span a period when the user lived in multiple states.
Consent Receipts and Portability Across Jurisdictions
The Kantara Initiative's Consent Receipt Specification provides a technical format for recording consent in a structured, portable way. Each consent receipt should capture the controller identity, the processing purposes, the data categories, the legal basis, the jurisdiction under which consent was obtained and a timestamp.
When a user exercises a data portability right under CPRA or CDPA, exporting their data should include their consent receipt history. This allows the user to understand not just what data you hold but under what legal basis you collected it. It also provides an audit trail that your legal team can reference in enforcement proceedings.
For engineers building to the W3C Verifiable Credentials Data Model, consent receipts are a natural fit for the credential format. A user could hold a verifiable credential asserting that they provided opt-in consent for sensitive data processing under California law on a specific date. That credential could be presented to downstream processors as proof of lawful basis, reducing the need for those processors to independently obtain consent.
This is the architecture that MyDataKey explores in the context of personal data asset origination: treating consent as a cryptographically verifiable artifact that travels with the data rather than living only in the controller's database. Dr. Patrick Fisher's work in The Invisible Data traces how consent opacity became a structural feature of the surveillance economy, and how consent receipts as verifiable credentials begin to reverse that dynamic.
A Pragmatic Engineering Roadmap for Multi-State Compliance
Building a system that handles all eight laws discussed here from day one is not realistic for most teams. The roadmap below reflects the priority order that makes architectural sense given overlap between the laws.
Phase 1: Data Inventory and Classification
You cannot implement jurisdiction-dependent access control without a complete data map. Every data element your system processes needs a classification: general personal data or sensitive category. Every processing activity needs a documented purpose. Without this foundation, ABAC policies are guesswork.
Sensitive category definitions vary by state. California's list includes geolocation, health data, genetic data, biometric data, financial data, sexual orientation and immigration status among others. Texas and Virginia have similar but not identical lists. Build your classification schema against the union of all state sensitive category lists so that a data element classified as sensitive under any applicable law is treated as sensitive everywhere.
Phase 2: Jurisdiction-Aware Identity Layer
Add jurisdiction resolution to your identity service. Store verified residence state as a user attribute with an effective date. Build the append-only audit log for jurisdiction changes. Wire jurisdiction into your session context so downstream services can evaluate it without re-querying the database on every request.
Phase 3: Rights Request Infrastructure
Build a unified rights request intake that routes to jurisdiction-specific fulfillment workflows. California requires 45-day response with a 45-day extension option. Virginia requires 45 days with a 45-day extension. Colorado requires 45 days with a 45-day extension. Connecticut requires 45 days. Response timelines are harmonized enough that a single SLA system works, but the rights available in each workflow differ.
Track every rights request against the submitting user's jurisdiction at time of submission. If a user submits a deletion request as a California resident and your system is still processing it when they move to Texas, California law governs that request because it was submitted under California residency.
Phase 4: Universal Opt-Out Signal Handling
Colorado and Connecticut require honoring the Global Privacy Control (GPC) signal as a legally binding opt-out. California's CPPA has also issued guidance treating GPC as a valid opt-out signal under CPRA. The GPC specification is implemented as an HTTP request header and a JavaScript API. Your web infrastructure needs to detect this signal, resolve the user's jurisdiction, and apply the appropriate opt-out action based on what that state law requires the signal to trigger.
For California, GPC triggers opt-out of sale and sharing. For Colorado, it triggers opt-out of sale, targeted advertising and profiling for significant decisions. For Connecticut, the scope mirrors Colorado. Handling GPC as a single boolean flag is incorrect. It must be mapped to jurisdiction-specific opt-out rights.
Phase 5: Data Protection Assessments as Living Documents
Virginia, Colorado, Connecticut and Texas require data protection assessments (DPAs) for high-risk processing activities. These are not one-time documents. When your system adds a new processing purpose, a new data category or a new sharing arrangement, the DPA must be updated. Build DPA generation into your change management process, not your annual compliance review cycle.
Treat the DPA as a structured artifact linked to specific processing activities in your data map. When a processing activity is modified, the linked DPA enters a review queue. When the DPA is approved, the processing activity is cleared. This creates an auditable record that a regulator can inspect and that your legal team can use to demonstrate good-faith compliance efforts.
The fragmentation of US state privacy law is not going to resolve quickly. A federal privacy law has been debated for years without passage. Engineers building systems today need to treat multi-jurisdictional compliance as a permanent architectural requirement, not a temporary workaround. The teams that build clean ABAC models, structured consent receipt systems and jurisdiction-aware identity layers now will carry a significant compliance advantage as additional state laws activate in 2026 and beyond.