If your SaaS company sells to customers in more than one state, and most do by design, you are likely already subject to more than one state’s privacy law, whether or not your company is headquartered in that state. What began with California’s Consumer Privacy Act (“CCPA”) has grown into a patchwork of approximately twenty (20) comprehensive state privacy laws, with more states adopting similar frameworks each year. This year alone Indiana, Kentucky, and Rhode Island joined the list. For SaaS companies, “we’re not based there” is no longer a reliable answer to “do we have to comply there.”
Why Your Home State Doesn’t Determine Your Obligations
Most state privacy laws apply based on where your customers or users are located, and how much of their personal data you process, not where your company is incorporated or headquartered. A SaaS company based in Oklahoma serving customers in California, Colorado, Virginia, Connecticut, and a dozen other states can find itself subject to all of those states’ requirements simultaneously. It’s a bit of a compliance nightmare right now with little hope for a unified federal data privacy law coming to tame the masses. As for current state laws, applicability thresholds vary (some laws apply based on revenue, others based on the number of residents’ records processed), so the analysis has to be done state by state.
The Common Threads Across State Laws
Despite the patchwork, most comprehensive state privacy laws share a core set of requirements: consumers get rights to access, correct, delete, and in some cases port their personal data; consumers can opt out of the sale of personal data and certain targeted advertising; companies must maintain reasonable data security safeguards; and companies must have data processing agreements in place with vendors and subprocessors who touch personal data on their behalf. If your SaaS product already has a privacy policy and a standard Data Processing Agreement (“DPA”) in its commercial contract stack, you have a foundation. The question is whether that foundation actually reflects the specific obligations that apply to your current customer footprint.
Where SaaS Companies Typically Get Tripped Up
Three recurring gaps show up again and again: DPAs that were drafted years ago and never updated to reflect current state law requirements or the company’s current subprocessor list; privacy policies that describe data practices in the abstract but don’t actually match what the product does today; and no internal process for tracking which states trigger new obligations as the customer base grows, so compliance becomes reactive instead of built in.
A Practical Starting Point
Before assuming you need a state-by-state legal opinion for every jurisdiction, most SaaS companies benefit from three concrete steps: mapping what personal data the product actually collects and where it flows, including subprocessors; reviewing the current DPA and privacy policy against that map; and building a lightweight internal process to flag new state obligations as the customer base expands. From there, targeted legal review can focus on the states and data types that create the most real exposure, rather than trying to solve every jurisdiction at once.
Multi-state privacy compliance is manageable when it’s built into how a SaaS company already reviews and negotiates its commercial contracts, rather than treated as a separate project. If your DPA or privacy policy hasn’t been reviewed against your current customer footprint, that’s a good place to start the conversation.
This post is provided for general informational purposes only and does not constitute legal advice. Reading this post does not create an attorney-client relationship. Contact ME to discuss your company’s specific circumstances.







