Privacy Policy Generator for SaaS
Written for the controller/processor split, sub-processor lists, DPAs and enterprise security review.
A SaaS privacy policy should cover you as a controller and point clearly at the DPA for everything you handle as a processor. Making that boundary explicit in the first two paragraphs saves an enormous amount of time in security review, and it is the thing generic templates never do.
A SaaS company wears two hats simultaneously, and the single biggest failure in SaaS privacy documentation is not separating them. For your own marketing site, billing and support you are a controller. For the customer data your users push into the product you are a processor, acting on their instructions - and the disclosures, the rights, and the deletion obligations are completely different in each role.
That distinction is not academic. It determines who answers a data subject access request, who notifies a regulator after a breach, who signs which contract, and what your policy is allowed to promise. A privacy policy that describes customer-uploaded data as "your data that we use to improve our services" is describing processor data in controller language, and enterprise security reviewers will catch it.
The commercial layer matters as much as the legal one. Every enterprise deal now runs through a security questionnaire that asks for a data processing agreement, a published sub-processor list with change notification, a defined breach notification window, and a sub-processor change-objection right. Having those documents ready shortens sales cycles; not having them stalls deals at procurement.
What a privacy policy for a SaaS product has to cover
An explicit controller/processor boundary, with a link to the DPA for customer-uploaded data
Account, billing, support and product-usage data described as your own controller processing
Product analytics and session recording, including whether they can capture customer content
Sub-processors named, with the published list and change-notification commitment
Transfers, retention after cancellation, and how deletion or export is requested
If your product has AI features, say in the policy - not only in the DPA - whether customer content is sent to a model provider and whether it is used for training. It is the question that gets asked in every enterprise review, and answering it publicly removes a round trip.
How a SaaS product actually moves personal data
Customer-uploaded content (processor role)
Whatever your users put into the product, including personal data about their own customers and staff. You process it on instruction, you do not decide its purposes, and you cannot use it for your own ends without a separate basis.
Account, billing and usage data (controller role)
Names, work emails, plan, invoices, feature usage and login history. This is yours to decide about, and your privacy policy is the notice for it.
Product analytics and session recording
Tools like Amplitude, PostHog or a session recorder capture in-app behaviour - which frequently means capturing customer data as a side effect, turning an analytics decision into a processor problem.
Support tickets and screenshots
The fastest route by which processor data ends up in a controller system. A screenshot attached to a ticket lands in a helpdesk with a different retention policy.
AI features processing customer content
If your product sends customer data to a model provider, that provider is a sub-processor, and whether the data is used for training is the first question every enterprise reviewer asks.
Sales and marketing enrichment
Buying contact data and enriching leads is controller processing with a legitimate interests analysis and a notification duty under Article 14 to people whose data you did not collect from them.
Third parties the draft will ask you about
AWS or Google Cloud · Stripe · Twilio and SendGrid · Intercom or Zendesk · Amplitude or PostHog · Datadog or Sentry · HubSpot or Salesforce · OpenAI or Anthropic · Snowflake
The rules that apply
GDPR Article 28
Processor obligations: process only on documented instructions, confidentiality, security, sub-processor authorisation, assistance with rights and breaches, deletion or return at the end, and audit rights.
Sub-processor transparency
Not a statutory list requirement in itself, but the practical standard: a published list, and advance notice with an objection window before adding to it.
Transfer mechanisms in the contract chain
SCCs and the UK Addendum have to flow down to sub-processors, not just sit in the top-level agreement.
Breach notification, contractual and statutory
As a processor you notify your customer without undue delay; as a controller you notify the regulator within 72 hours in the UK and EU.
US state law service-provider terms
CCPA requires specific contract language for a recipient to count as a service provider rather than a sale.
What the generated privacy policy contains
Identity and contact details of the controller
Your legal entity, trading name, registered address and a working contact route - plus a representative or DPO where one is required.
Categories of personal data and their sources
What you collect directly, what you observe automatically, and what you receive from third parties such as payment providers or ad platforms.
Purposes and lawful basis, purpose by purpose
A table that pairs each processing purpose with its lawful basis rather than listing all six bases and hoping one fits.
Recipients and sub-processors
The categories of recipient, and for the ones that matter to users - payment, hosting, analytics, support - the named provider.
International transfers and their safeguards
Where data leaves its home jurisdiction, and the mechanism relied on: adequacy, standard contractual clauses, the UK addendum or IDTA.
Retention periods per data category
Concrete periods or the criteria used to set them, which is what regulators ask for first when a complaint lands.
Rights and how to exercise them
Access, rectification, erasure, portability, objection and restriction, with the actual route to make a request and the deadline you work to.
Complaints and supervisory authority
The regulator a user can escalate to, named, with a link - not a generic "your local authority".
The SaaS compliance document set
Separate the privacy policy from the DPA
The policy covers you as controller. The DPA covers you as processor. Different audiences, different content, different signatures.
Publish a sub-processor list with a subscribe option
Name, purpose, location. Offer email notification of changes and an objection window.
Write the security page procurement actually asks for
Encryption, access control, testing cadence, incident response, and whatever certification you hold - or an honest statement that you hold none yet.
Define the breach notification window in the DPA
A stated number of hours, and an internal process that can meet it.
Decide and document your AI data position
Whether customer content reaches a model provider, whether it is used for training, and how long the provider retains it.
Build deletion and export that actually work
Article 28 requires deletion or return at the end of the relationship, and enterprise contracts require proof.
Where this usually goes wrong
One document covering both roles
The privacy policy describes controller processing. Processor obligations belong in the DPA. Merging them produces a document that over-promises about customer data and under-explains your own.
Training on customer data without saying so
The single fastest way to lose an enterprise deal, and depending on your terms, a breach of the instruction limitation in Article 28.
A sub-processor list that is out of date
If the contract promises notice before adding a sub-processor, adding one silently is a breach of contract as well as a transparency failure.
Support tooling that copies processor data into controller systems
Screenshots, exported CSVs and debug logs move data out of the environment your DPA describes.
No defined breach notification window
"Without undue delay" is the statutory phrase, but enterprise contracts want a number. Not having one is a negotiation cost on every deal.
Free-tier and trial data treated casually
Trial accounts contain real customer data far more often than teams assume, and the same obligations apply.
Frequently asked questions
Is my SaaS company a controller or a processor?
Both, in different respects. You are a controller for your own account, billing, marketing and support data, and a processor for the data your customers put into the product. The documents you publish should make the boundary obvious.
Do I need a data processing agreement?
If you process personal data on behalf of business customers subject to GDPR or UK GDPR, yes - Article 28 requires it in writing. In practice enterprise customers will require one regardless of jurisdiction.
Do I have to publish a sub-processor list?
There is no free-standing statutory duty to publish one, but almost every enterprise DPA requires notice before you add a sub-processor, and a public list is the standard way to meet that.
Can I use customer data to train AI models?
Only with a lawful basis and, where you are a processor, only if your customer has instructed or permitted it. Doing it silently breaches the instruction limitation and, for most enterprise contracts, the agreement itself.
What breach notification window should I commit to?
Common commitments run from 24 to 72 hours from confirmation. Pick one your incident process can actually meet, because a missed contractual deadline is a breach of contract on top of the incident.
Is a privacy policy legally required?
If you process personal data, in almost every market yes. GDPR and UK GDPR require the disclosure at the point of collection, CCPA/CPRA requires a notice at collection plus an annually reviewed policy, and app stores and payment processors require a public policy URL before they will list or onboard you.
Can I copy another company’s privacy policy?
It is both a copyright problem and a compliance problem. A copied policy describes someone else’s data flows, processors and retention periods, so it is inaccurate the moment you publish it - and an inaccurate transparency notice is itself a breach of GDPR Article 13.
How often does a privacy policy need updating?
Whenever your processing changes - a new analytics tool, a new payment provider, a new market - and as a backstop, review it annually. CPRA makes the twelve-month review explicit.
Does PolicifyAI give legal advice?
No. PolicifyAI is a technology provider, not a law firm. The output is a structured, jurisdiction-aware draft that a qualified adviser should review before you rely on it.
Privacy Policy Generator for SaaS
Answer a short questionnaire and get a draft written for a SaaS product. Free to start, no card required.
Generate your privacy policyOther documents a SaaS product needs
Each one is written for the same context, not a generic template.
The same document, by business type
Go deeper
PolicifyAI is a technology provider, not a law firm, and this page is not legal advice. Generated documents are a structured starting point that a qualified adviser should review before you publish or rely on them.