Most CPRA vs. VCDPA summaries restate the statutes in plain English. That is useful for a lawyer preparing a memo. It is not useful for the product manager who needs to know whether Virginia users get a different opt-out flow than California users, or for the engineer who has to build the rights-request queue.
This article covers the operational deltas — the places where CPRA, VCDPA, and CTDPA actually require different product behavior. This is not legal advice. Consult qualified legal counsel for compliance decisions.
The threshold problem: who each law covers
Before you build anything, you need to know whether your product is even in scope.
CPRA (California): Applies to for-profit businesses that collect personal information of California residents AND meet one of: (1) annual gross revenue over $25M, (2) buy/sell/share personal info of 100,000+ consumers or households per year, (3) derive 50%+ of revenue from selling/sharing personal info. The 100K threshold dropped from 50K at CCPA but is still the most common trigger for SaaS companies.
VCDPA (Virginia): Applies to controllers that either (1) control or process personal data of 100,000+ Virginia consumers per year, or (2) control or process data of 25,000+ consumers and derive 50%+ of gross revenue from selling personal data. Critically, Virginia exempts employees and B2B contacts — your CRM data may not be in scope if it is purely business contact information.
CTDPA (Connecticut): Nearly identical thresholds to Virginia (100K consumers or 25K+ with 25%+ revenue from data sales). Connecticut added a lower sales revenue threshold (25% vs. VCDPA's 50%) which catches more data brokers but rarely changes scope for SaaS companies.
Practical implication: Most B2B SaaS products serving US enterprise customers will be CPRA-scoped first. If you cross the 100K threshold for Virginia or Connecticut residents separately, you need state-specific handling.
Consumer rights: where the laws diverge in product behavior
This is the section that matters most for engineering and product.
| Right | CPRA | VCDPA | CTDPA |
|---|---|---|---|
| Right to know / access | Yes | Yes | Yes |
| Right to delete | Yes | Yes | Yes |
| Right to correct | Yes | Yes | Yes |
| Right to portability | Yes | Yes | Yes |
| Right to opt out of sale | Yes | Yes | Yes |
| Right to opt out of targeted advertising | Yes | Yes | Yes |
| Right to opt out of profiling | Yes (automated decision-making) | Yes (significant decisions) | Yes (significant decisions) |
| Right to limit sensitive data use | Yes — distinct "Limit Use" right | No — covered under opt-out | No — covered under opt-out |
| Private right of action | Yes (data breaches) | No | No |
The "Right to Limit Use of Sensitive Personal Information" is the sharpest CPRA-specific product requirement. California gives consumers the ability to tell you to use their sensitive data only for the purpose of delivering the service — not for cross-context behavioral advertising, analytics for third parties, or inferring characteristics. Virginia and Connecticut do not have this as a separate right. That means your opt-out UX for California users may need a distinct "Limit Use of Sensitive Info" toggle that Virginia and Connecticut users do not see.
Sensitive data: different categories, different obligations
CPRA sensitive categories include: SSN, driver's license, passport, financial account credentials, precise geolocation, racial/ethnic origin, religious beliefs, union membership, genetic data, biometric data for identification, health data, sex life/sexual orientation data, and contents of mail/email/text unless the business is the intended recipient.
VCDPA and CTDPA use a nearly identical list but add children's data (under 13 for VCDPA, under 13 and 13–15 for CTDPA with different consent requirements). Connecticut also added a requirement around processing data for purposes "not reasonably necessary or compatible" with the disclosed purpose — meaning your privacy notice needs to accurately describe how you actually use data, not just list every possible use as a hedge.
What this means in practice: If you collect precise geolocation (under CPRA) or biometric identifiers, you need a consent mechanism for California users that is separate from your general privacy consent. VCDPA and CTDPA require opt-in consent for sensitive data processing, which is actually stricter than CPRA's opt-out model for some categories.
Opt-out UX: what you must build and where
All three laws require an opt-out from "sale or sharing" of personal data. CPRA extended this from CCPA to include "sharing for cross-context behavioral advertising" — you cannot just opt users out of data sales and leave retargeting pixels running.
The Global Privacy Control (GPC) signal is mandatory to honor under CPRA. Virginia and Connecticut require honoring it as well as of their current amendments. In practice: if a user sends a GPC browser signal, you need to treat it as a valid opt-out request automatically — no confirmation flow required.
For product teams, this means:
- Your cookie consent layer needs to detect the GPC header and suppress analytics/ad pixels accordingly.
- Your data processing pipeline needs a flag for each user record indicating their opt-out status across California, Virginia, and Connecticut separately.
- If you use a CMP (consent management platform), verify it handles GPC signal detection and jurisdiction-based policy branching. Many CMPs claim GPC support but only apply it to one jurisdiction.
Vendor contracts: what changes by state
CPRA requires data processing agreements (DPAs) or "service provider" contracts with any vendor that processes personal information on your behalf. These must include specific prohibited uses — the service provider cannot use California consumer data for their own commercial purposes.
VCDPA and CTDPA use the processor/controller model from GDPR. Your vendor contracts need to include a list of required provisions: processing purpose limitations, confidentiality obligations, subprocessor notification requirements, and data subject rights assistance obligations. The specific required clauses differ from CPRA's service provider contract requirements.
The practical gap: If you negotiated your vendor DPAs to be CCPA/CPRA-compliant in 2020, those contracts may be missing VCDPA/CTDPA processor clauses. Review any vendor that touches Virginia or Connecticut resident data — particularly your CRM, analytics platform, and customer support tool.
What to build first
If you are starting from scratch and need a prioritized backlog:
- State residency detection at intake — you cannot apply jurisdiction-specific rules without knowing where users are located. IP geolocation at signup plus a user-declared state field covers most cases.
- Rights request queue with jurisdiction routing — a single intake form that routes to different response workflows based on state. California requests have a 45-day response window (extendable 45 days with notice); Virginia and Connecticut have the same.
- GPC signal handling in your middleware — detect the header, set an opt-out flag, suppress tracking.
- Sensitive data consent flows for California — separate from your general consent, specifically for the categories that trigger CPRA's Limit Use right.
- Vendor DPA audit — list every third-party processor, confirm you have a current DPA, and flag any that are missing VCDPA/CTDPA processor clauses.
Use the US State Privacy Policy Generator to draft state-specific policy language as a starting point. Every policy still needs legal review before it goes live — but having a structured first draft that maps to the correct statutory requirements cuts the legal review cycle significantly.
The goal is not to build three separate compliance programs. It is to build one privacy infrastructure that handles jurisdiction branching cleanly — so that when Iowa or Indiana adds its own law next year, you are adding a row to a routing table, not rebuilding from scratch.