US data privacy compliance checklist: CCPA/CPRA, CPA, CTDPA, UCPA, and VCDPA

US privacy compliance is no longer “just a California issue.” If you sell to or service customers across the US, you may need to comply with multiple state consumer privacy laws—each with overlapping (but not identical) definitions, notices, and consumer rights.

This checklist is designed to help you start with the fundamentals and turn them into repeatable operations—not one-off policy updates.

This guide covers:

How to determine whether you’re in scope for major state privacy laws
What “personal data” and “sensitive data” typically include
The consumer rights you need to support with real workflows
A practical checklist for notices, inventories, vendor contracts, and evidence

When you realize “privacy compliance” is now multiple states

GIF via GIPHY

Related guides:

Key takeaways

US privacy compliance is a multi-state program. Don’t treat it as a single policy update—treat it as workflows (intake, verification, fulfillment, logs, and recurring reviews).
Definitions matter operationally. You need a clear internal definition of “personal data” and “sensitive data” tied to your actual systems and vendors.
Consumer rights are the core obligation. Access, deletion, correction, and opt-out requests require end-to-end execution across product, CRM, support, and analytics tooling.
Web requirements are easy to miss. Global Privacy Control (GPC), opt-out signals, and “Do Not Sell/Share” style obligations can be technical—not just legal language.
Evidence is your leverage. If you can’t prove what you do (inventories, notices, contracts, training, security controls), you’ll struggle under audits and customer reviews.

Step 1 — Determine whether state privacy laws apply to you

State privacy laws often apply to for-profit organizations that do business in a state and meet certain thresholds (commonly tied to revenue, volume of personal data processed, or percentage of revenue from selling/sharing data).

Use this scoping checklist to start:

Markets: Do you collect personal data from residents of privacy-law states (commonly CA, CO, CT, UT, VA—and more may be added over time)?
Entity type: Are you a for-profit business (not a government agency or nonprofit)?
Thresholds: Do you meet one or more state thresholds (for example, annual revenue, number of consumers/households/devices, or data monetization)?

If you’re unsure, take an “assume in scope until proven otherwise” approach for your website and marketing stack—because those tools typically touch residents in many states.

Quick scoping table (what to capture)

Item	Why it matters	Example evidence
States where you have customers/users	Defines which laws are relevant	CRM and billing exports, geo analytics
Personal data volumes	Some laws are threshold-based	Data inventory counts, analytics totals
Revenue profile	Some laws hinge on data selling/sharing	Finance reporting + adtech contracts
Controller vs processor role	Responsibilities differ by role	DPAs, customer contracts, product docs

Step 2 — Define personal data (and sensitive data) in your context

Before you change notices or build request workflows, get explicit about what you treat as personal data. Across US state laws, “personal data” generally includes information that identifies, relates to, describes, or could reasonably be linked to an identifiable individual.

Common examples include:

Names
Email addresses
Phone numbers
Account identifiers and login credentials
IP addresses and device identifiers
Location data (especially precise geolocation)
Payment and billing information
Government identifiers (when collected)
Browsing activity and online interactions (depending on context)

Many state laws also create a special category for sensitive data (sometimes called “sensitive personal information”). Sensitive data often requires heightened notice and opt-out/consent expectations depending on the law and your processing purpose.

Typical sensitive categories include:

Account logins (often treated as sensitive in practice because compromise risk is high)
Financial information
Health information
Biometric identifiers
Precise geolocation
Information about minors (age/child data)
Religious or political affiliations (where collected)

Note: Some definitions and requirements vary by state and change over time. Treat this step as a living inventory tied to your systems, not a one-time list in a document.

Step 3 — Understand (and operationalize) consumer rights

Consumer rights are the backbone of US privacy compliance. While details vary by state, you should plan to support a core set of rights in a consistent workflow.

Common rights include:

Right to know/access: provide categories and specific pieces of data collected about a consumer
Right to delete: delete personal data (with exceptions)
Right to correct: correct inaccurate personal information
Right to opt out: opt out of sale/sharing (and often targeted advertising)
Right to non-discrimination: provide equal service and pricing when rights are exercised (within legal bounds)
Rights related to automated decision-making: in some states/contexts, consumers may opt out of certain profiling decisions with legal or significant effects

A practical rights workflow (the part teams underestimate)

To make rights real, you need:

Intake: web form + email (and in some contexts, phone)
Identity verification: enough to prevent fraud, but proportionate to the request
System discovery: which systems store data for that consumer (product, CRM, support, analytics, billing)
Fulfillment: export/delete/correct/opt-out with a consistent runbook
Decision logging: what you did, when, who approved exceptions, and what evidence proves it

If you want one simplifier: build a single internal “consumer request” pipeline and map each state’s timelines and nuances to it—rather than building five separate processes.

Step 4 — Update privacy notices, opt-outs, and web requirements

Most US privacy programs fail first in disclosures and web implementation (because the marketing website and adtech stack change faster than policy refresh cycles).

Use this checklist for your website/app notices:

Update your privacy policy to accurately describe:
- Categories of personal data you collect
- Purposes for collection/processing
- Categories of third parties you share with
- Retention periods (or criteria used to determine them)
- How consumers can submit requests (and how you verify identity)
Provide rights instructions that match reality (don’t promise what you can’t fulfill).
Make notices accessible (readability, disabilities, and multi-language if you serve multiple languages).
Add just-in-time notices where users wouldn’t reasonably expect collection (for example, certain mobile permissions or sensitive fields).

Don’t miss: opt-out signals and Global Privacy Control

Some state regimes expect businesses to honor universal opt-out mechanisms and browser signals. Two good starting references are:

https://allaboutdnt.com
https://globalprivacycontrol.org

Operationally, this usually means you need alignment between:

Your cookie/consent tooling
Your tag manager rules (what fires when an opt-out is present)
Your adtech partners (so “opt out” actually stops sharing where required)

Step 5 — Build a data inventory you can actually keep current

A data inventory is the foundation for almost everything else: notices, rights fulfillment, retention, vendor contracts, and security controls.

At a minimum, track:

Systems that store or process personal data
Systems that store or process sensitive data
Third-party vendors/subprocessors with access to data
Data sources (website forms, product, support, billing, marketing)
Retention rules and deletion mechanisms
Request fulfillment mappings (where to export/delete/correct)

Inventory template (minimal but effective)

System/vendor	Data categories	Sensitive data?	Purpose	Shares with	Retention	Owner	Evidence location
(example) CRM	Contact + deal info	Sometimes	Sales pipeline	Email provider	2 years after inactivity	RevOps	DPA + admin screenshots

Step 6 — Update vendor and processor agreements

State laws often require that you put obligations on vendors that process personal data on your behalf (processors/subprocessors). Even when the law’s language differs, the operational goal is consistent: vendors should be contractually bound to protect personal data and support your compliance workflows.

Common contract requirements to validate include:

Confidentiality obligations for anyone processing personal data
Security measures appropriate to the data and risk
Subprocessor controls (approval/notification, flow-down obligations)
Cooperation on consumer requests (export, delete, correct)
Incident notification expectations
Return/delete data at end of services (unless retention is legally required)
Audit or assessment rights (or third-party reports you can rely on)

If your vendor management is spreadsheet-driven, this step becomes a recurring pain point—because every new tool becomes a mini privacy project.

Step 7 — Implement “reasonable” security with evidence

US privacy laws frequently expect “reasonable” security measures. “Reasonable” is context-dependent, but you should be prepared to demonstrate baseline security controls and that they operate consistently.

A practical starting list:

Identity and access controls (MFA, least privilege, access reviews)
Logging and monitoring for key systems
Encryption in transit (and at rest where appropriate)
Secure SDLC practices for privacy-impacting changes
Incident response plan + exercises
Backup and recovery testing
Vendor risk assessment for high-impact processors

The key is evidence: if controls exist but aren’t documented (or are inconsistently applied), they won’t hold up under customer due diligence.

Step 8 — Train teams and run recurring reviews

Privacy compliance breaks when it’s only owned by legal or security. It needs cross-functional behavior change.

Checklist items that actually help:

Run annual (or role-based) training for employees and contractors who touch personal data
Create a “new vendor / new tracking” intake process that includes privacy review
Review privacy policy and notices on a defined cadence (commonly annual, plus when material changes occur)
Run periodic tag audits for your website and marketing stack
Test your consumer request workflow end-to-end (at least quarterly)

What to document (so you can prove compliance)

If you want your privacy program to scale, treat it like an evidence system. Here’s what buyers, auditors, and regulators commonly expect you to produce quickly:

Area	What good looks like	Typical evidence
Scoping	Clear applicability assumptions and thresholds	Scope memo, state matrix, decision log
Notices	Policy matches actual collection and sharing	Privacy policy, cookie list, change log
Rights	Requests are fulfilled on time with logs	Intake records, verification steps, fulfillment artifacts
Inventory	Systems and vendors are mapped and owned	Data inventory, vendor list, review cadence
Vendors	Contracts reflect privacy obligations	DPAs, subprocessors list, security addenda
Security	Controls are implemented and repeatable	Access reviews, MFA enforcement, incident runbooks

Streamline US privacy compliance with SecureSlate

US data privacy compliance is easiest when it’s run as operations: clear owners, repeatable workflows, and audit-ready evidence that stays current as systems and vendors change.

SecureSlate helps teams:

Centralize privacy documentation, inventories, and evidence in one place
Assign owners and due dates for rights workflows, policy refreshes, and vendor reviews
Track vendor agreements and assessments without spreadsheet churn
Maintain a clean audit trail for customers, internal reviews, and regulators

Get started for free to turn privacy requirements into trackable execution.

FAQ

Is US data privacy compliance just CCPA/CPRA?

No. California is a major driver, but other state laws (for example CO, CT, UT, and VA) add requirements and nuances. Many organizations treat this as a multi-state program with one consistent operational workflow.

Do we need to honor Global Privacy Control (GPC)?

In many implementations, you should plan to honor GPC (and similar opt-out signals) where applicable. The practical requirement is that your opt-out experience is consistent across your cookie tooling, tag manager rules, and adtech sharing behavior.

What’s the first step we should take?

Start with a data inventory and scoping matrix: which states you touch, what personal data you process, which systems/vendors touch it, and what your rights workflow needs to cover.

Do these laws apply to B2B data?

It depends on the state, the data type, and how the data is used. Many businesses handle consumer and business contacts under one unified privacy operations program, then apply legal nuance per jurisdiction where required.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to US state privacy laws and related regulations, you should consult a licensed attorney.