What Your SaaS Company Needs in a Privacy Policy

The generic privacy policy template most SaaS founders use early on was written for a product that does not exist, or at least not yours. It covers data categories your product does not touch and says nothing about the ones it does. Worse, it was probably last updated before the current round of state privacy laws came into effect.

A mismatched or outdated privacy policy is not just a compliance problem. It is a liability. When your actual data practices diverge from what the policy says, the gap becomes evidence in an enforcement action or litigation.

Here is what a SaaS privacy policy typically needs to address.

What data you actually collect

Start here, not with what a template says you collect, but what your product actually collects.

For most SaaS products, this means account data (name, email, sometimes billing information), product usage data (feature interactions, session logs, error events), device and technical identifiers (IP address, browser type, operating system), and potentially payment data (usually tokenized through a processor, but that needs to be stated).

If your product includes integrations with third-party services, communications features, or file storage, the data inventory grows. Each additional category needs to be reflected in the policy.

The accuracy requirement is real. Privacy regulators at the federal level (the FTC), in California (the CPPA), and across a growing list of state attorneys general have authority to take action based on a privacy policy that does not match actual practices. “We collect the data described in this policy” only protects you if the policy is accurate.

Describing what you collect is step one. Describing what you do with it is where most SaaS policies get vague in ways that create problems.

Your policy should cover the primary purposes (providing the service you signed customers up for), secondary uses (analytics, product improvement, aggregate analysis), and whether you share data with sub-processors and service providers. That last category is where scrutiny has increased substantially.

Vague language (“we may share your information with partners to improve our services”) no longer satisfies most regulators or enterprise procurement teams. If you use Stripe for payments, Segment for analytics, Intercom for customer support, and AWS for infrastructure, those relationships should be described at a level that a customer or regulator can actually evaluate.

This does not require naming every vendor in the policy body, but the structure of relationships and the purpose of sharing should be clear. Many companies publish a sub-processor list at a separate URL and link to it from the policy.

User rights and how to exercise them

Data subject rights are no longer a California-only concern. CCPA (California), Virginia CDPA, Colorado CPA, Connecticut CTDPA, Texas TDPSA, and a growing number of other state laws give users rights to access, delete, correct, and in some cases port the data you hold on them.

Your privacy policy needs to describe what rights users have, which laws confer those rights, and, critically, how they actually exercise them. A statement that “you may request deletion of your data” without a working mechanism for doing so does not satisfy the requirement.

For B2B SaaS where your customers are companies rather than individuals, the analysis shifts. Your direct obligations run to your customers (the “businesses”), not their end users. But your customers’ obligations run to their users, and they will pass data subject requests through to you. Your Data Processing Agreement structure and your policy language both need to account for this.

Children’s data

If your product is intended for general consumers and there is any possibility that users under 13 are among them, COPPA applies. The analysis is not limited to products marketed to children. The “actual knowledge” standard means that if you know or have reason to know a child is using the product, COPPA obligations kick in.

This is worth a deliberate review. If you are not certain whether your product reaches children, a COPPA risk assessment is not optional. The consequences of getting it wrong (FTC enforcement with substantial civil penalties) are significant. A separate post covers COPPA compliance for app developers in more detail.

Retention and deletion

How long do you keep user data? Most privacy laws require that you keep data for no longer than necessary for the purposes for which it was collected, the purpose limitation principle.

“No longer than necessary” is not a precise answer, which is why your policy should articulate actual retention periods or the criteria you use to determine them. Account data may be kept for the life of the account plus some reasonable period after termination. Log and analytics data might be retained for a shorter period. Backup retention schedules need to be addressed separately.

Retention schedules also matter for deletion requests. If a user requests deletion and your policy says you retain data for 90 days post-termination, the request does not automatically override that retention policy, but the policy needs to explain the relationship between your retention practices and deletion rights.

When the template stops being enough

The practical reality is that a generic privacy policy is a starting point, not a solution. At some threshold of product maturity, data complexity, or enterprise customer scrutiny, the template diverges enough from your actual practices that it needs to be rebuilt rather than patched.

That threshold is different for every company. Some SaaS products have simple data models and straightforward disclosure requirements. Others (those handling health-adjacent data, financial data, children’s data, biometric identifiers, or data from users in multiple jurisdictions) reach the rebuild point earlier.

Privacy policy requirements vary by jurisdiction, product type, and the data you actually collect. If you want a policy reviewed against your current data practices or drafted from the ground up, reach out to MB Legal.

This post is informational and does not constitute legal advice. Privacy law requirements vary by jurisdiction and fact pattern. For guidance specific to your product and data practices, consult a licensed attorney.