The Privacy Patchwork Reaches 20 States
As of January 1, 2026, twenty US states enforce consumer privacy statutes. California, Virginia, Colorado, Connecticut, Utah, Iowa, Indiana, Tennessee, Montana, Texas, Oregon, Delaware, New Hampshire, New Jersey, Nebraska, Minnesota, Maryland, Kentucky, Rhode Island, and Florida have enacted laws that grant consumers rights over their personal data. Each law has different definitions of personal data, different consent requirements, different opt-out mechanisms, and different enforcement timelines.
For a web application serving customers across the United States, this means 20 different legal frameworks governing how the application collects, stores, processes, and deletes personal data. A visitor from California has different rights than a visitor from Texas. A data subject access request from Maryland has a different response deadline than one from Oregon. The web framework must handle each correctly, or the operating company faces enforcement action from 20 different state attorneys general.
What Each Request Requires
A data subject access request (DSAR) under California's CCPA requires the business to provide all personal information collected about the consumer within 45 days. Virginia's CDPA requires a response within 45 days with a possible 45-day extension. Texas's TDPSA requires 45 days. Oregon's Consumer Privacy Act requires 45 days. The deadlines sound similar. The definitions of 'personal information,' 'sale,' 'processing,' and 'consumer' differ across all 20 statutes.
To fulfill a DSAR, a web application must: identify the consumer across all data stores, aggregate all data associated with that consumer, format the data for delivery, verify the consumer's identity, log the request and response, and delete data if requested — all within the state-specific timeline and definition of personal data. This is not a feature request. It is an infrastructure requirement that touches the database schema, the API layer, the authentication system, and the application's data model.
A web framework with built-in user data management, role-based access control, and data export APIs makes DSAR compliance an operational task. A legacy CMS where user data is scattered across core tables, plugin tables, meta tables, and third-party integrations makes DSAR compliance an engineering project — repeated for every request.
WordPress and the Scattered Data Problem
WordPress stores user data across wp_users, wp_usermeta, wp_comments, wp_posts (for custom post types), and the tables created by every plugin that collects data. WooCommerce adds wp_wc_orders, wp_wc_order_items, and wp_wc_customer_lookup. A contact form plugin stores submissions in its own table. An analytics plugin stores behavioral data in another. A newsletter plugin stores subscription preferences in yet another.
When a consumer from Maryland submits a data subject access request, the site operator must query every one of these tables, aggregate the results, determine which fields constitute 'personal data' under Maryland's definition, and deliver the response within the statutory deadline. WordPress added a basic 'Export Personal Data' tool in version 4.9.6, but it relies on each plugin registering its data with the export system. Plugins that do not register — and many do not — are invisible to the export tool. The data exists but cannot be found through official channels.
The Framework Compliance Advantage
Django provides a built-in User model with a documented data schema, a permissions system, and a data export framework that captures all model-linked data. Rails provides ActiveRecord associations that make it possible to trace all data related to a user through model relationships. Next.js applications with a structured ORM (Prisma, Drizzle) store user data in explicitly defined schemas where every field is documented and queryable.
These frameworks do not automatically comply with 20 state privacy laws. No framework does. But they provide the architectural foundation that makes compliance achievable: centralized user data models, structured data access layers, and the ability to programmatically enumerate all data associated with a user. The difference between a 2-hour DSAR response and a 2-week DSAR project is the framework's data architecture.
The Cost Compounds
At 20 states and counting, the compliance burden is not static. It is cumulative. Each new state adds another set of definitions, another set of consumer rights, another set of enforcement mechanisms. Federal privacy legislation has been proposed repeatedly and has not passed. The patchwork grows. The compliance cost grows with it.
For organizations running legacy CMS platforms, each new state privacy law increases the operational cost of every data subject request. The cost is not in the legal analysis — that scales with legal counsel. The cost is in the engineering work required to locate, aggregate, and delete user data scattered across dozens of database tables maintained by independent plugin developers who may or may not have anticipated privacy compliance.
Framework choice is compliance infrastructure. The organization that selected a framework with structured data models and user data management in 2023 handles 20-state compliance as an operational process. The organization that selected WordPress with 30 plugins in 2023 handles 20-state compliance as a recurring engineering crisis. The framework choice was a compliance decision. It just was not recognized as one at the time.
