The Patchwork Problem No Federal Law Fixes
As of 2026, more than a dozen US states have enacted comprehensive consumer privacy statutes. There is still no federal omnibus privacy law. That gap is not a policy footnote. It is an engineering constraint that every product team operating at scale must encode directly into their data systems.
The compliance burden is not just legal. It is architectural. Each state statute defines its own set of consumer rights, its own thresholds for applicability, its own opt-out mechanisms and its own timelines for responding to data subject requests. When a user in your system moves from California to Texas, or from Colorado to Utah, the rights that user holds against your platform change. Your system has to know that, track it and respond to it in real time.
This article maps the engineering surface area of the major state privacy laws currently in force, explains the jurisdiction assignment problem that arises when users change their state of residence and introduces attribute-based access control (ABAC) as the architectural pattern best suited to managing jurisdiction-dependent rights at scale.
Law by Law: What Each State Demands at the Code Level
Each statute creates a distinct rights surface. Here is a working summary that engineering teams can use as a requirements input.
California: CCPA as Amended by CPRA
The California Consumer Privacy Act, substantially expanded by the California Privacy Rights Act, remains the most demanding statute in force. It applies to businesses meeting any one of three thresholds: annual gross revenue above $25 million, personal information of 100,000 or more consumers or households processed annually, or revenue derived from selling or sharing personal information of 50,000 or more consumers. The amended law introduced a new category of sensitive personal information with its own opt-out right, created data minimization obligations and established the California Privacy Protection Agency as an independent enforcement body. Engineers must implement: a "Do Not Sell or Share" signal that honors Global Privacy Control (GPC), a separate sensitive PI opt-out, 15-business-day response windows for opt-out requests, 45-calendar-day windows for access and deletion, and a data retention schedule enforced at the record level.
Virginia: CDPA
The Virginia Consumer Data Protection Act applies to controllers processing personal data of 100,000 or more Virginia residents annually, or 25,000 residents if the company derives over 50 percent of gross revenue from personal data sales. Virginia does not have a private right of action. Enforcement rests with the Attorney General. Rights include access, correction, deletion, portability and opt-out of targeted advertising. The correction right is notable because it requires a data pipeline capable of propagating corrections across downstream processors, not just the primary store.
Colorado: CPA
The Colorado Privacy Act mirrors Virginia closely in threshold structure but adds a universal opt-out requirement that explicitly recognizes browser-level signals including GPC. Colorado also mandates data protection assessments for high-risk processing activities. For engineers, this means assessment records must be generated and retained programmatically when processing triggers defined risk categories.
Connecticut: CTDPA
The Connecticut Data Privacy Act is substantively close to Colorado but with one important engineering note: it applies to processors of data from 100,000 Connecticut residents or 25,000 residents where more than 25 percent of gross revenue comes from data sales. Connecticut explicitly exempts employee data from most provisions. Your residency tagging system needs to handle state-level carve-outs at the data category level, not just the user level.
Utah: UCPA
The Utah Consumer Privacy Act has the highest applicability thresholds of any state law currently in force: $25 million annual revenue and either 100,000 consumer records or 25,000 consumer records with more than 50 percent revenue from data sales. Utah does not recognize a correction right and does not require data protection assessments. Its opt-out scope is narrower. For large platforms, Utah-resident users trigger a meaningfully thinner compliance obligation than California or Colorado users.
Texas: TDPSA
The Texas Data Privacy and Security Act, which took effect in 2024 and remains in force in 2026, applies to businesses that process personal data of Texas residents and do not qualify as small businesses under federal SBA definitions. Texas includes a cure period before enforcement action. Rights include access, correction, deletion, portability and opt-out of targeted advertising and profiling. Texas also includes a sensitive data processing consent requirement, similar to CPRA's sensitive PI framework.
Delaware: DPDPA
The Delaware Personal Data Privacy Act carries a low applicability threshold: 35,000 consumers annually, or 10,000 if more than 20 percent of revenue derives from data sales. Delaware includes a right to opt out of profiling that produces legal or similarly significant effects. The lower threshold means platforms that are not yet thinking about state compliance at scale likely still have Delaware obligations.
When a User Moves States: The Jurisdiction Assignment Problem
Most privacy compliance documentation treats users as static. A California user is a California user. But real systems have users who move. A user who registered in Utah, moved to Colorado last year and is currently residing in California presents a non-trivial compliance engineering problem.
The core question is: which law applies?
Most state statutes use residency, not IP address, as the jurisdictional trigger. That is an important distinction. IP-based location is a proxy. Residency is a fact. A user who is traveling internationally but remains a California resident retains CCPA/CPRA rights. A user who has permanently relocated from California to Utah loses their California rights and gains Utah's narrower set.
This creates three engineering requirements:
- A residency attribute must be stored per user record and treated as a compliance-critical field, not a demographic preference.
- The residency field must be updateable by the user through a rights request workflow, not just an address form.
- The rights surface available to a user must be computed dynamically from the current residency attribute, not hardcoded at account creation time.
There is also a data retention implication. If a user was a California resident when they exercised a data access right, the records generated by that request may carry California-specific retention rules even after the user has moved. Your system needs to tag rights request records with the jurisdiction in force at the time of the request, not just the user's current residency.
Attribute-Based Access Control as a Compliance Architecture
Role-based access control (RBAC) is insufficient for multi-jurisdictional privacy compliance. RBAC assigns permissions based on a user's role in your system. But the permission set a user holds against your platform is not determined by their role. It is determined by attributes: their state of residence, the categories of data you hold about them, the processing activities those categories are involved in and the legal basis claimed for each processing activity.
Attribute-based access control (ABAC) is the correct architectural pattern here. In an ABAC model, access decisions are made by a policy engine that evaluates a set of attributes at request time. For privacy compliance, those attributes include:
- Subject attributes: User's current state of residence, account creation date, prior residency history.
- Resource attributes: Data category (sensitive vs. non-sensitive), legal basis for collection, downstream processor list, retention schedule.
- Environment attributes: Current timestamp, applicable law version, opt-out signal status (GPC).
- Action attributes: Type of DSR (access, deletion, correction, portability, opt-out).
The policy engine maps this attribute set to a rights determination. A request from a Colorado resident to opt out of targeted advertising triggers a different policy path than the same request from a Utah resident, because Colorado law requires honoring GPC signals while Utah's statute does not include the same universal opt-out obligation.
The ABAC policy layer should be externalized from application code. Embedding jurisdiction logic in application logic creates a maintenance catastrophe as new state laws take effect. A dedicated policy decision point (PDP), queried by application services at DSR intake, decouples the compliance logic from the product codebase. NIST SP 800-162 provides the reference architecture for ABAC implementation in federal contexts. The same architectural principles apply directly to commercial privacy compliance engineering.
Consent Receipts and Cross-State Portability
Several state statutes include data portability rights that require you to deliver personal data in a portable, commonly used format. That is a data export problem. It is also a consent provenance problem.
When a user exports their data, the export should carry with it the consent record that authorized each category of processing. This is the concept of a consent receipt: a structured, machine-readable record of what the user agreed to, under what law, at what time and for what purpose. The W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) has published vocabulary specifications that support this kind of structured consent documentation.
A consent receipt attached to a data export allows the receiving party (another controller, an attorney, a regulator) to evaluate whether the original processing was lawful under the applicable state statute. It also provides the user with an auditable record of their own data history, which is foundational to what Dr. Patrick Fisher describes in The Invisible Data as genuine data legibility: the condition under which a person can actually understand and contest what has been done with their information.
Where PDAOS Fits: Personal Data Asset Origination as Jurisdiction-Aware Infrastructure
The Personal Data Asset Origination System (PDAOS), developed as part of the Own Your Data Inc research program, treats personal data records as first-class assets with provenance, consent and jurisdiction metadata attached at the point of origination. This is not just a philosophical framing. It is an engineering specification.
In a PDAOS-compliant system, every personal data record carries a jurisdiction tag at creation time. When applicable law changes for a user (because the user has moved states, or because a new statute has taken effect), the PDAOS policy layer can re-evaluate the rights surface for that record without requiring application-level changes. The data itself knows what law governs it, because the law was encoded into its origination metadata.
This connects directly to the MyDataKey model of cryptographic identity, where a user's self-sovereign identifier anchors a set of verifiable credentials that include residency attestations. A residency credential issued to a user's DID can serve as the authoritative input to the ABAC policy engine, replacing the fragile pattern of trusting user-supplied address fields in a product database.
The combination of PDAOS-originated records, DID-anchored residency credentials and an externalized ABAC policy engine produces a system that can handle the jurisdiction assignment problem correctly at scale, without requiring human review for each state transition.
What Engineering Teams Should Build Now, Not After a Lawsuit
The practical build list for a team managing multi-state privacy compliance in 2026 is as follows.
Jurisdiction Tagging at Ingestion
Tag every personal data record with the user's verified state of residency at the time of collection. Do not rely on IP geolocation. Use account-level residency attributes updated through a formal workflow. Store prior residency history for DSR record attribution purposes.
Externalized Policy Decision Point
Build or adopt a dedicated ABAC policy engine that evaluates DSR requests against current residency, data category and processing activity attributes. Do not embed state-specific logic in application handlers. As new state laws take effect, you should update policy files, not application code.
GPC Signal Processing
California, Colorado and Connecticut explicitly require honoring the Global Privacy Control signal. Your web properties and APIs must detect the GPC header and route it to the opt-out workflow without requiring the user to take an additional action. The FTC has noted GPC compliance as an indicator of good faith in enforcement contexts.
Correction Propagation Pipeline
Correction rights under Virginia, Colorado, Connecticut, Texas and Delaware require that corrections flow to downstream processors. Build a correction event bus that notifies all registered processors holding the affected user's data. Retain delivery confirmations as DSR completion records.
Consent Receipt Generation
At every consent collection point, generate a structured consent receipt that records the applicable law, the data categories covered, the processing purposes stated and the timestamp. Attach receipt identifiers to the personal data records they govern. This is the audit trail that makes portability requests meaningful and provides defense in depth against enforcement actions.
DSR Intake with Jurisdiction Routing
Build a single DSR intake endpoint that routes requests based on the user's current jurisdictional attribute. The response timeline, the rights available and the required response format should all be determined by the policy engine, not by hardcoded conditionals in the intake handler.
The fragmentation of US state privacy law is a real cost. It is also a design constraint that, when handled architecturally rather than reactively, produces data systems that are more honest about what they collect, more responsive to the people those collections represent and more resilient to the next round of legislative change that is already moving through state capitols. Building for fragmentation is not a burden. It is a specification.