US State Privacy Laws, Explained for Small Product Teams

The United States has no single federal consumer privacy law comparable to the GDPR. Instead there is a patchwork: a handful of sector-specific federal statutes, a general federal enforcer in the Federal Trade Commission, and a growing set of state laws that began with California and now covers roughly twenty states with more taking effect each year. For a small team building a product with US users this looks alarming and is mostly manageable, provided you learn the pattern rather than trying to memorise each act.

This is engineering guidance, not legal advice, and it cannot be. Whether a specific statute applies to you depends on where your users are, your revenue, your data volumes and what you do with the data. The wording of a privacy notice, a data processing addendum or a compliance claim to a customer is lawyer work, and you should pay a lawyer qualified in the relevant states to do it. What follows is the part your engineers and product people have to build regardless of what the lawyer says.

Why the patchwork exists

Congress has not passed a comprehensive federal privacy law, so states have filled the gap individually. At the federal level you get narrow statutes covering specific contexts: HIPAA for protected health information held by covered entities and their business associates, GLBA for financial institutions, COPPA for children under thirteen, FERPA for education records. Outside those, the FTC polices privacy through its general authority over unfair and deceptive practices, which in practice means that saying something untrue in your privacy policy is itself the violation.

That last point is the one small teams underestimate. The fastest way into trouble is not failing to have a policy, it is having a policy that describes a product you do not actually ship. If you claim you do not share data with third parties while a marketing tag is loading on every page, you have created the problem yourself.

Does any of this apply to a small team in Nepal?

Indirectly, and that is enough to matter. These laws generally attach to the business that determines why and how personal data is processed, and most of them have thresholds based on revenue or the number of consumers whose data you handle, so a small vendor is rarely the regulated party on its own. But if you build and run a product for a US client, that client is regulated, and the obligations arrive at your door through their contract. Expect to sign a data processing addendum, to be listed as a subprocessor, to commit to a breach notification window and to delete data on termination.

In practice this is a competitive advantage rather than a burden. A team that can answer procurement questions about data location, deletion and subprocessors without a two-week delay wins work from teams that cannot. It is one of the things we set up as standard on outsourced engineering engagements, and it is the same commercial hygiene that decides whether a US buyer takes you seriously at all.

The common shape of the state laws

Most of the state statutes rhyme, because most were drafted from similar templates. Learn the shape and you can read any individual act quickly.

• A right for a consumer to know what personal data you hold about them and to get a copy of it.
• A right to have it corrected, and a right to have it deleted, within a defined response window with a limited extension.
• A right to opt out of the sale of personal data and of targeted advertising, and in most states of certain automated profiling.
• Heightened treatment of sensitive categories such as health, precise geolocation, biometrics, immigration status, racial or ethnic origin and children's data. Several states require opt-in consent for these.
• A requirement to publish a privacy notice that plainly states what you collect, why, who you share it with, and how to exercise rights.
• A prohibition on discriminating against someone for exercising their rights.
• Data protection assessments for higher-risk processing such as targeted advertising, sale of data or profiling with legal effects.
• In a growing number of states, an obligation to honour a browser-level universal opt-out signal, which in practice means Global Privacy Control.

Enforcement is by state attorneys general in most states. Cure periods, where a regulator has to give you a chance to fix something before acting, exist in several statutes and are expiring in others, so do not treat one as a plan.

Where California is different

California's law is the oldest and the strictest, and it uses vocabulary the other states do not. The CCPA, as amended by the CPRA, adds a concept of "sharing" for cross-context behavioural advertising alongside "sale", so passing identifiers to an advertising platform can be in scope even with no money changing hands. It gives consumers a right to limit the use of sensitive personal information rather than a blanket opt-in. It extends rights to employees and to business contacts, not just consumers. It created a dedicated regulator, the California Privacy Protection Agency, alongside the attorney general. And it carries a limited private right of action for certain data breaches, which is unusual: elsewhere, individuals mostly cannot sue you directly under these statutes.

The laws with real teeth that teams forget

• Illinois BIPA. Biometric identifiers, including face and fingerprint data, with a private right of action and statutory damages per violation. It has produced very large settlements. If your product touches face or fingerprint data, get advice before you write the feature, not after.
• Washington's My Health My Data Act. A broad definition of consumer health data with a private right of action. "Health data" is wider than most engineers assume and can capture wellness, fitness and inference.
• COPPA. If under-thirteens can plausibly use your product, the rules are strict and the FTC enforces them actively.
• Breach notification. Every state has a breach notification law, with different definitions and deadlines. This applies regardless of the comprehensive-privacy thresholds.

What this means in the codebase

Most of the work is architectural rather than legal. If you can answer "where does this user's data live" with a query rather than a search of three systems and a spreadsheet, you are most of the way there.

• A stable internal user identifier that every store keys against, so a request can be executed rather than investigated.
• A written inventory of every place personal data lands: primary database, analytics, error tracking, email tool, CRM, support inbox, logs, backups, exports on someone's laptop, and every third-party API you post data to.
• A deletion path that actually reaches all of them, including your analytics vendor and your support tool, with a documented, defensible position on backups.
• Retention windows enforced by a scheduled job, not stated in a policy document nobody runs.
• Consent and opt-out state stored server side against the user record, not only in a cookie that vanishes when they switch device.
• An intake route for rights requests that a real person monitors, with the response clock tracked.

A deletion request is a test of your data architecture. Most teams fail it the first time.

The stable-identifier point is worth planning for early, because retrofitting it is painful. It belongs in the same conversation as choosing a database for a small product, and it is much cheaper to decide once than to reconcile three systems later.

The trackers are the usual failure

Analytics and advertising tags are where small teams get caught, because they were added incrementally by whoever needed a number that week and nobody has audited them since. Open the network tab on your own site and list what is loading. Remove anything nobody reads. For what is left, confirm that the opt-out you advertise genuinely stops it and that a Global Privacy Control signal is honoured, because advertising a control that does nothing is exactly the deceptive-practice case. Our piece on analytics after third-party cookies covers how to keep the numbers you need with a much smaller data footprint, and passkeys for small product teams covers removing stored passwords, which is the cheapest way to shrink what a breach could expose.

The cheap things to do this month

• Collect less. Every field you do not store is a field you never have to find, secure, disclose or delete.
• Write the data inventory. It takes an afternoon and it is the input to every other decision here.
• Set and enforce retention windows in code.
• Rewrite the privacy notice so it describes what the product actually does, then keep it accurate as the product changes.
• Build the rights-request route and test it on yourself end to end.
• Then take the whole thing to a lawyer. The engineering work is what makes that conversation short and cheap.