US State Privacy Laws and Signup Enrichment: A Compliance Playbook for PLG SaaS Teams

The patchwork is bigger than CCPA

Most PLG teams treat US privacy compliance as a single checkbox: "we handle CCPA." That was a defensible position in 2021. It is not one anymore.

By the end of 2026, more than fifteen states have their own comprehensive consumer privacy laws, and they do not share one definition of "personal information," one opt-out mechanism, or one threshold for who even has to comply. California's CCPA (as amended by the CPRA), Virginia's VCDPA, Colorado's CPA, Connecticut's CTDPA, Utah's UCPA, Texas's TDPSA, Oregon's OCPA, Montana's MTCDPA, and the laws that followed in Iowa, Indiana, Delaware, New Jersey, New Hampshire, Nebraska, Minnesota, Maryland, and Rhode Island each layer on their own wrinkle. A growth team running signup enrichment against a US user base is, in practice, operating under several of these laws at once, usually without having mapped out which ones apply.

Signup enrichment sits right in the middle of this because it does exactly what these laws regulate: it takes a piece of information a person gave you for one purpose (an email address, to create an account) and uses it to derive new information about them (job title, employer, seniority, LinkedIn profile, company size) for a different purpose (scoring, routing, personalization). That is squarely "processing personal information" under every one of these statutes, and under several of them it can also qualify as creating a profile used to evaluate the person, which triggers extra disclosure and opt-out rights.

None of this is a reason to stop enriching signups. It is a reason to build the workflow so it survives a regulator's attention, a user's access request, or a procurement questionnaire from an enterprise customer's legal team.

Where these laws actually overlap

Despite the patchwork, five obligations show up in almost every state law a PLG team is likely to trip:

1. Notice before or at collection

You need a privacy notice that describes what you collect, including inferred and enriched data, not just what the signup form itself asks for. If your form collects an email address but your enrichment pipeline adds company, title, and an ICP score, your notice has to say that. A notice that only describes the form fields understates what you actually hold on each user.

2. A right to access and know

Most of these laws give consumers the right to see what you have collected about them, including data from third-party enrichment providers. If a user requests their data and your enrichment results live in five different tables across EndUser, EnrichmentResult, and a vendor's own system, you need a way to assemble that into one answer within the statutory window, which runs 30-45 days depending on the state.

3. A right to delete

Deletion has to propagate. If you enriched a user through a provider, stored a LinkedIn URL, and pushed that profile into Salesforce or a CDP, deleting the EndUser record in your own database and leaving the rest in place does not satisfy the request. Map every downstream system your enrichment data flows into before you need the map in an emergency.

4. Opt-out of "sale" or "sharing"

This is the one PLG teams misjudge most often. Several of these laws define "sale" broadly enough to include sharing personal information with a third-party enrichment vendor in exchange for a service, even when no money changes hands for the data itself. If your enrichment provider uses the data you send them to build or improve their own database, that can count as a sale under CCPA/CPRA and several of its state cousins. Read your vendor's data processing terms, not just their marketing page, before you assume you are in the clear.

5. Data minimization

Several newer laws, including Colorado's CPA and Connecticut's CTDPA, codify data minimization as an affirmative obligation, not just a best practice. Collecting and enriching a field you will never use in a routing or scoring decision is no longer just unnecessary risk. In some states it is a compliance gap.

A playbook for running enrichment under this patchwork

Step 1: Classify your enrichment fields

Go through every attribute your enrichment pipeline writes and bucket it into one of three categories:

• Used in a live decision. ICP score inputs, routing rules, sales-assist triggers. Keep these, document why, and keep their retention tied to account lifecycle.
• Used for reporting only. Dashboards, cohort analysis. Keep these, but put a retention window on them and consider aggregating instead of storing raw values indefinitely.
• Collected because it was available. Nobody queries it, nobody routes on it. Stop collecting it. This category is almost always larger than teams expect once they actually audit it.

Step 2: Write down your "sale" and "sharing" exposure

For each enrichment provider in your stack, answer one question in writing: does this vendor use the data we send them for anything beyond fulfilling our specific request? If the answer is "we don't know," that's your next vendor call, not a risk to carry indefinitely. Vendors who train their own databases on customer traffic exist and are common in this space; using one isn't automatically disqualifying, but it changes your disclosure obligations and may trigger opt-out requirements you have not built yet.

Step 3: Build one honor-the-request workflow, not five

Rather than building separate processes for CCPA deletion, VCDPA access, and CPA opt-out, build a single internal workflow that can satisfy the strictest version of each: full data export, full deletion across every system the data touched, and a durable opt-out flag that suppresses future enrichment for that identity. Most teams find that satisfying the strictest state law automatically satisfies the lighter ones, which is cheaper than maintaining five parallel processes.

Step 4: Respect Global Privacy Control

California, Colorado, and Connecticut all require honoring the Global Privacy Control signal as a valid opt-out-of-sale request when a browser sends it, with no separate account-level request needed. If your enrichment trigger fires on signup before you have checked for a GPC signal, you have a gap. Check it as part of the same code path that decides whether to enrich at all.

Step 5: Keep provenance and confidence on every record

A field with no record of which provider supplied it, when, and how confident the match was is a liability during both a deletion request and a regulator inquiry, because you cannot show you minimized collection or verified accuracy. This is also good enrichment hygiene independent of compliance: it's the same discipline covered in enrichment confidence and false positives. Store source and confidence by default rather than retrofitting it after your first access request.

What this looks like for a growth manager, not a lawyer

Growth managers do not need to become privacy attorneys to run this well. They need three things from their enrichment stack:

1. A clear answer to "what do we collect and why" for every field feeding ICP scoring, teammate discovery, or routing.
2. A way to delete a user's enriched profile completely, on request, without a multi-day engineering ticket.
3. Vendor contracts that specify how the vendor uses the data you send them, so "sale" exposure is a known quantity instead of a surprise.

This is exactly the compliance layer that sits underneath PLG signup enrichment: what gets collected, what legal basis or disclosure covers it, and what happens the moment someone exercises a right the law gives them. Teams serving growth managers and RevOps at companies selling into regulated or privacy-sensitive buyers increasingly get asked about this during procurement, before a contract is signed, not after a complaint is filed.

The takeaway

CCPA compliance was never the whole job, and treating it as the whole job leaves a PLG team exposed in Colorado, Virginia, Connecticut, and a growing list of other states with their own rules and their own enforcement bodies. The fix is not to stop enriching signups. It's to classify what you collect, know exactly where it flows, build one deletion and opt-out workflow that satisfies the strictest law you're under, and keep provenance on every enriched field so you can answer "why do we have this" without guessing.

Groful's enrichment pipeline stores source and confidence on every field by default and ties enrichment to a single EndUser record, which covers most of the access and deletion groundwork automatically. If you want to see how the ICP scoring and routing benefits hold up against this compliance layer, check the pricing page or talk to us about your specific data residency and retention requirements.