The US state privacy patchwork: what a GDPR-compliant SaaS still has to build

The expensive mistake we see most often is a European SaaS that has done GDPR properly, wins its first serious US customers, and assumes it is covered. It is about half covered. The privacy notice, the data map, the subprocessor list and the deletion pipeline all transfer. The opt-out architecture does not, and that is the part that shows up in a regulator's sweep letter.

The mirror-image mistake is a US company treating this as a one-time legal review: a "Do Not Sell or Share My Personal Information" link pointing at a form nobody reads, never wired into the ad stack that created the exposure.

The list of states with comprehensive privacy laws in force grows every legislative session, so any post that enumerates them is stale within months. What is stable is the pattern, and the pattern is what you build against.

California is the template and the rest are variations

The California Consumer Privacy Act, as amended by the California Privacy Rights Act, is the reference implementation. Almost every state law that followed borrowed its structure: applicability thresholds based on revenue and consumer volume, a set of consumer rights, an obligation to honour opt-outs, contract terms flowing down to vendors, and a "sensitive data" category with extra handling.

The variations cluster in predictable places. Whether sensitive data and targeted advertising need opt-in consent or only an opt-out. Whether there is a cure period before enforcement, and whether it expires. Whether employee and B2B contact data are in scope, where California is the outlier that covers them and most states carve them out. How broadly sale and sharing are defined. Whether a data protection assessment is mandatory for high-risk processing.

California also stands alone in having a dedicated regulator with rulemaking authority. Elsewhere, enforcement sits with the state attorney general.

The thresholds are lower than people assume

The typical trigger is doing business in the state plus either revenue in the tens of millions, or personal data on a threshold number of state residents, commonly tens of thousands. Several states add a lower bar when a majority of revenue comes from selling personal data. Check the current figures before relying on them; they get amended.

Thresholds are per state, so you are in scope in some and not others, which is unworkable as an engineering model. Almost everyone applies the strictest reasonable configuration everywhere, and that should be a recorded decision rather than a default you drift into.

Global Privacy Control is the requirement teams discover late

California requires businesses to honour opt-out preference signals sent by the browser, and Global Privacy Control is the signal that exists. Several other states have followed suit.

This is engineering work, not a banner change. The signal arrives as an HTTP header or a JavaScript property on the first request. Honouring it means detecting it before any tag fires, suppressing the advertising and analytics tags that constitute a sale or share rather than merely recording a preference, persisting the choice against the authenticated user so it survives a device change, and propagating it to ad platforms and to any warehouse that syncs audiences.

A consent platform handles the first two if configured correctly. The last two are yours. Test with the signal enabled and watch the network tab: plenty of implementations record the preference and fire the pixel anyway.

"We do not sell data" is usually wrong

The definitions are broad on purpose. Sale covers disclosing personal information to a third party for monetary or other valuable consideration. Sharing, in California, covers disclosure for cross-context behavioural advertising with no money involved at all.

In practice, an advertising pixel passing identifiers to an ad network for retargeting is treated as a sale or share, as is a lookalike audience upload. The service provider exemption exists, but only holds if the contract carries the required restrictions and the vendor genuinely does not use the data for its own purposes.

So the first step is an inventory of every tag, SDK and server-side integration that receives an identifier, with a recorded decision per destination: service provider, or sale and share. That inventory is also the evidence you will be asked for, so keep it where the rest of your control artefacts live. This is the argument for mapping one control set across frameworks rather than running privacy as a separate track: if you already automate SOC 2 evidence collection, the same pipeline should be producing it.

What GDPR gives you, and what it does not

Already done if your GDPR programme is real: the processing inventory, retention schedule, deletion and export mechanics, subprocessor register and vendor due diligence. The state data protection assessment is close enough to a DPIA to extend the same template, the way an ISO 27001 Statement of Applicability gets reused rather than rewritten.

Not done: opt-out signal handling, the sale and share classification, the right to limit use of sensitive personal information which has no clean GDPR analogue, the notice-at-collection formatting rules, the service provider contract clauses, and the response deadlines. Most states set 45 days with one extension, tighter in practice than GDPR's month because the clock starts on receipt and there is little tolerance for slow identity verification.

One difference in kind: GDPR wants a lawful basis before processing. US state laws generally do not, regulating instead what you disclose and what the consumer can stop. A team trained to ask "what is my basis" has to start asking "have I disclosed this, and can the consumer switch it off".

Things teams forget

• Authenticated request handling. A logged-in user files a deletion request through a public form and gets treated as a stranger, pushing verification onto support. Put the rights flow inside the product, where identity is already established.
• Deletion has to reach the warehouse. Removing rows from production while a year of event data sits in analytics and its downstream models is the most common failure, and the deadline is shorter than GDPR's.
• Authorised agents. Several states let a third party file on a consumer's behalf, in bulk. Intake has to absorb volume without a human triaging each one.
• Minors. Opt-in applies to sale and sharing for consumers under 16, and knowing the age is your problem, not theirs.

What to do this week

Enable Global Privacy Control in a browser, load your marketing site with the network tab recording, and check whether the advertising and analytics tags still fire. Ten minutes, and it answers the question a regulator asks first. Turning that into a maintained control set is what our security and compliance work covers.