Jurisdictional Compliance: Why One Framework Is Never Enough
Most enterprise privacy programs were built for one regulatory framework.
For companies with meaningful European operations, that framework was GDPR. For US-only companies, it was CCPA when California led the compliance conversation. Some organizations built around HIPAA if their primary data sensitivity issue was health information.
These were reasonable starting points. The problem is that the regulatory landscape has not stayed where it was when those programs were designed.
As of early 2026, 144 countries have active privacy regulatory frameworks. Twenty US states have passed comprehensive consumer privacy laws, with more advancing through legislative processes. The EU's regulatory architecture has expanded to include sector-specific requirements beyond GDPR. State attorneys general across the US are actively enforcing their frameworks, with documented enforcement actions in California, Colorado, Texas, Oregon, and Connecticut.
A privacy program built around one or two frameworks is not a program with a gap. It is a program with multiple gaps: each corresponding to a jurisdiction where your users, employees, or customers have legal rights you may not be honoring.
The Architecture Problem
When an organization builds a privacy program around a single framework, the architecture reflects that choice. Consent mechanisms are designed to meet the requirements of the anchor framework. Privacy policies are written to satisfy the disclosure requirements of the primary regulatory regime. Data retention schedules, data subject rights workflows, and vendor management practices are calibrated to the anchor standard.
This works well within the anchor jurisdiction. It creates systematic problems everywhere else.
The GDPR consent model (explicit opt-in for non-essential data collection, granular consent categories, right to withdraw) is more protective than most US state frameworks. But meeting GDPR requirements does not mean meeting CPRA requirements, which have specific opt-out mechanisms, universal opt-out signal requirements, and sensitive data protections that operate differently than GDPR's consent regime.
Meeting GDPR and CPRA does not mean meeting BIPA, which requires written consent for biometric data collection before collection begins: a higher standard than either European or California law for that specific data category.
Meeting all three does not mean meeting Texas TDPSA requirements around health data, or Oregon's comprehensive coverage of nonprofits, or the vendor coverage requirements in Colorado's CPA.
The frameworks are not interchangeable. Each has provisions the others do not. A compliance program designed to satisfy one, or even two, is systematically non-compliant with the rest, not by negligence, but by design.
The User Population Problem
The architectural problem is compounded by the user population problem.
Most enterprise organizations do not have clean, single-jurisdiction user populations. A US-headquartered software company serving enterprise clients almost certainly has European users. Its employees may include Illinois residents (BIPA), California residents (CPRA), and Texas residents (TDPSA). Its consumer-facing properties likely serve users across multiple US states and potentially multiple countries.
The regulatory obligations for each user segment are determined by the regulations applicable to that user's location, not by where the company is headquartered. A company based in Delaware serving California consumers has CPRA obligations. The same company serving Illinois employees has BIPA obligations. The same company serving German users has GDPR obligations.
The obligation attaches to the user, not to the organization.
This means that an accurate jurisdictional compliance assessment requires knowing where your actual users are located, mapping each jurisdiction's requirements to the specific data practices affecting those users, and identifying where current practices create compliance gaps for specific segments.
What Outside-In Assessment Adds
Jurisdictional compliance is commonly addressed through inside-out analysis: internal documentation review, gap assessment against a checklist of applicable requirements, and remediation planning based on what the privacy team believes about current practices.
The limitation of this approach is the same limitation that affects all inside-out privacy work: it reflects what the organization knows and has documented, not what is actually observable from the outside.
A consent mechanism that meets GDPR requirements on paper may present differently to users in practice. The consent banner may render correctly in Chrome on a desktop but fail to function as intended on mobile or in Firefox. The opt-out mechanism for California users may technically exist but be so unintuitive that it functionally denies users the right the law grants.
Regulators evaluate compliance from the outside. The CPPA's enforcement methodology starts with loading the website and testing the user experience. The ICO begins with observable consent behavior. State attorneys general initiate investigations based on technical research that documents actual observable practices.
Outside-in assessment provides the view that regulators use: what does the consent mechanism actually do for a user in California? Does the opt-out signal recognized under CPRA actually work when a Colorado user sends one from their browser? Are the biometric disclosures required under BIPA actually reaching Illinois employees in the workflow where biometric data is collected?
These questions cannot be answered by reviewing documentation. They require testing the actual user experience from outside the organization.
The Highest-Risk Gaps
Jurisdictional compliance gaps are not equally distributed across frameworks and data types. Several categories account for a disproportionate share of the exposure.
Biometric data across US jurisdictions. BIPA, Texas biometric privacy law, and Washington's My Health MY Data Act create overlapping biometric requirements that differ in meaningful ways. Organizations that have addressed BIPA but not the newer state-level biometric frameworks often have unresolved exposure in states where employees or customers are located.
Video content and VPPA. The Video Privacy Protection Act applies to any online platform sharing video viewing data with third parties. The litigation landscape in 2025-2026 has made clear that it applies broadly to enterprise SaaS, media, education, and e-commerce video content. Companies that have not assessed their video analytics stack against VPPA in the last 18 months have likely not assessed it in light of current enforcement.
Sensitive data categories under state laws. Colorado, Virginia, Texas, Oregon, and other states have broad definitions of sensitive personal data that include health data, genetic data, and in some cases financial data. The requirements for sensitive data (including data protection assessments, heightened consent standards, and data minimization obligations) create compliance obligations that GDPR-anchored programs may not have fully mapped.
Opt-out signal recognition. California's universal opt-out signal requirement, adopted in whole or in part by several other states, requires that websites recognize and honor browser-level privacy signals. Many organizations have implemented user-facing opt-out mechanisms but have not technically implemented universal opt-out signal recognition. This is an observable gap that regulators can verify directly.
Building a Jurisdictional Map That Stays Current
A jurisdictional compliance assessment has three components that need to work together to produce an accurate picture.
The first is user population mapping: where are your actual users, employees, and customers located, and which regulatory frameworks apply to each segment?
The second is requirement mapping: for each applicable framework, what specific obligations apply to your data practices, and where does the current program create gaps?
The third is observable verification: do the technical implementations of your consent mechanisms, opt-out workflows, and data practices actually work as required from the outside?
The third component is what most jurisdictional compliance assessments skip. The first two are documentation exercises. The third requires outside-in assessment: testing the actual user experience against the regulatory standard applicable to each user segment.
Most programs have at least one jurisdiction where the gap between what the program documents and what users actually experience is material. Finding it before a regulator does is the difference between a remediation project and an enforcement response.
