A SaaS privacy policy is harder than a shop's because the company is in two positions at the same time. The data about your own users, the people who sign up and pay, is yours to decide about. The data your customers put into the product about their own customers is not yours at all: you hold it on instructions. Writing one document that blurs the two is the most common defect in this category, and it is the one that costs a deal at security review.
Two roles, two documents
For your own account holders you are the controller: you decided to collect their email, you decided to run analytics, you decide how long to keep the record. Your privacy policy is about them. For the data inside a customer's workspace you are the processor: your customer decided what to collect and why, and you act on their instructions. What governs that is the data processing agreement, not the privacy policy. Saying so plainly in the policy, in one paragraph near the top, saves an enormous amount of explaining later.
What the policy has to say
The account-holder half is an ordinary privacy notice: what you collect at sign-up and in use, the product telemetry, the support conversations, the billing records, why you hold each, who receives it, how long you keep it and what rights the person has. The part SaaS policies usually skip is product telemetry, because it is collected by the engineering team rather than by a form, and it is personal data whenever it is tied to an account.
The sub-processor list is part of the promise
Your customers are answerable for the chain behind you. That means your hosting, your email sender, your error tracker, your support desk and your analytics are, in their eyes, their sub-processors. Publish the list, give notice before you add to it, and keep the notice period you promised. A sub-processor added quietly is a breach of your own agreement long before it is a privacy problem, and it is the single thing enterprise buyers check.
Deletion on churn, stated as a period
Say what happens when a customer leaves: how long the workspace stays recoverable, when it is deleted, what is kept for legal or accounting reasons and for how long, and what happens in backups. Backups are where vague policies fail, because deletion from live systems is quick and expiry from backups is not. A policy that says data is deleted immediately and a backup regime that keeps it for a month are a contradiction somebody will eventually read out to you.
Questions people ask about SaaS privacy policy
Do we need both a privacy policy and a DPA?
Yes. They cover different data in different roles. The policy is published to the world about your own users; the DPA is signed with each customer about their data.
Is product telemetry personal data?
When it can be tied to an identified account or device, yes. Aggregate counts that cannot be traced back to a person are not, but most product analytics keep a user identifier, which settles it.
What about data our customers put in that we did not ask for?
It is still yours to protect and theirs to decide about. The agreement should say what the service is intended for, and the policy should not pretend you cannot see data you can see.
Does a free plan change anything?
Not the obligations. It often changes the retention and the support access, and if it does, the policy should say so rather than describing the paid experience for everyone.