What a SaaS privacy policy must include: the GDPR Article 13 list
GDPR Article 13 lists what a SaaS privacy policy must say: who you are, each purpose and legal basis, every recipient, transfers, retention and rights.
LLaunchScaler·Published ·9 min read
A SaaS privacy policy must give the information GDPR Article 13 lists: who you are and how to contact you, each purpose you process personal data for with its legal basis, who receives the data, whether it leaves the EU and under what safeguard, how long you keep it, and the rights people have, including withdrawing consent and complaining to a regulator. Everything on that list applies from the moment you collect data, which for a SaaS is the signup form, the analytics tag and the server log.
The part that is easiest to get wrong is recipients. Your policy has to cover every company that receives visitor or customer data, and the quickest test is to compare the third-party hosts your pages actually contact with the names in your policy. This guide walks the Article 13 list item by item, then shows that test.
What must a SaaS privacy policy include under GDPR?
Article 13 sets a closed list, split into two paragraphs. Paragraph 1 covers who you are, why you process data, on what basis, who receives it and whether it is transferred abroad. Paragraph 2 covers retention, rights, withdrawal, complaints, whether data is required and automated decisions. The table maps each item to what a SaaS usually writes.
Article 13 item
What it requires
What a SaaS usually writes
13(1)(a)
Identity and contact details of the controller, and of its EU representative where applicable
Company legal name, address, a privacy contact email
13(1)(b)
Contact details of the data protection officer, where applicable
The DPO's email, or nothing if you are not required to have one
Questions, answered
What people ask about this
01
What must a GDPR privacy policy include?
Article 13 requires your identity and contact details, the DPO's contact where you have one, each purpose with its legal basis, any legitimate interests relied on, the recipients, international transfers and their safeguards, retention periods, the data subject rights, the right to withdraw consent, the right to complain to a supervisory authority, whether providing data is required, and any automated decision-making.
One line per purpose, each with its Article 6 basis
13(1)(d)
The legitimate interests pursued, where that is the basis
The actual interest, such as "preventing fraud on paid accounts"
13(1)(e)
Recipients or categories of recipients
Hosting, payments, email, analytics, support and error-monitoring vendors
13(1)(f)
Transfers to third countries, the safeguard, and how to get a copy
For example, US vendors under the Data Privacy Framework or standard contractual clauses
13(2)(a)
Retention period, or the criteria that set it
A period per data type
13(2)(b)
Rights of access, rectification, erasure, restriction, objection and portability
How to use each right, and the contact to write to
13(2)(c)
The right to withdraw consent at any time, where consent is the basis
How to withdraw, for example the cookie settings link
13(2)(d)
The right to complain to a supervisory authority
That right, ideally with your lead authority named
13(2)(e)
Whether providing data is a statutory or contractual requirement, and what happens if not
"We need your email to create an account"
13(2)(f)
Automated decision-making, including profiling, and its logic
Usually "we do not make decisions based solely on automated processing"
Article 12(1) adds how to write it: in a concise, transparent, intelligible and easily accessible form, using clear and plain language. A policy that covers every item in dense legal prose still falls short of that.
How do you state purposes and legal bases?
One purpose per line, each with one legal basis. The EU's transparency guidelines (WP260) give examples of phrasing that is not clear enough, including "We may use your personal data to develop new services" and "We may use your personal data to offer personalised services," because the reader cannot tell what the processing is.
For a typical SaaS, the purposes and bases look like this:
Purpose
Data
Usual legal basis
Creating and running the customer's account
Name, email, password hash, workspace data
Performance of a contract, Art. 6(1)(b)
Taking payment and issuing invoices
Billing name, address, VAT number, payment status
Contract, plus legal obligation for keeping tax records, Art. 6(1)(c)
Security and abuse prevention
IP addresses, login events, server logs
Legitimate interests, Art. 6(1)(f), stating the interest
Product analytics with cookies
Usage events, device data, a cookie ID
Consent, Art. 6(1)(a), collected through your banner
Marketing emails
Email, open and click data
Consent, Art. 6(1)(a), unless your national e-marketing rules provide another route
Customer support
Messages, attachments, account ID
Contract
When you rely on legitimate interests, Article 13(1)(d) makes you name the interest. "Our legitimate interests" alone does not meet it; "keeping accounts secure by detecting repeated failed logins" does.
Consent-based purposes connect the policy to your banner. Anything you load only after consent should appear here as consent-based, with the withdrawal route from 13(2)(c). The rules for the banner side are in the guide to cookie banner requirements.
Who counts as a recipient, and how do you find them all?
Every company that receives personal data from you or from your visitors' browsers is a recipient: your processors (hosting, payments, email delivery, support desk, error monitoring) and any third party whose script or pixel loads on your pages. Article 13(1)(e) lets you disclose recipients or categories of recipients, but the transparency guidelines say that in practice the most meaningful information will generally be the named recipients.
If you use categories instead, WP260 asks you to be as specific as possible: the type of recipient by the activities it carries out, its industry, sector and sub-sector, and its location. "Service providers" is not a category a reader can act on. "Payment processor based in the United States" is.
Your backend processors are in your contracts and your billing. The browser-side ones are easy to miss, because every font, map, chat widget and pixel receives the visitor's IP address when it loads. Run this test on your homepage, pricing and signup pages:
Open the page in a fresh Chrome profile and open DevTools on the Network panel.
Right-click the column headers and add the Domain column. Reload, then accept your cookie banner so consent-gated tags load too.
Sort by Domain and write down every host that is not yours. Group hosts by company (several Google hosts are one company).
Walk the signup and checkout flow and add any new hosts, because payment and captcha scripts often load only there.
Add your server-side processors from your vendor list: hosting, database, email, support, error tracking, payments.
Compare the list with your policy's recipients section. Every company on the list must be named or covered by a specific category. Remove any tag you cannot justify.
Repeat the test whenever someone adds a script. The same list feeds your cookie banner's third-party disclosure and your Google tag setup, which the guide to Google Consent Mode v2 covers.
How do you disclose international transfers?
Say which recipients are outside the EU or EEA, which safeguard covers each transfer, and how the reader can get a copy of it, as Article 13(1)(f) requires. For a SaaS the common case is a US vendor, and there are two usual safeguards.
The first is the EU-US Data Privacy Framework. The European Commission adopted its adequacy decision on 10 July 2023, and it covers transfers to companies in the United States that participate in the framework, which is administered by the US Department of Commerce. Confirm each US vendor participates before you rely on it; its own privacy policy should say so.
The second is the standard contractual clauses the Commission issued on 4 June 2021, for transfers to recipients outside the EU or EEA that are not themselves subject to the GDPR. If a vendor relies on them, its data processing agreement will say so. Your policy can state that transfers to a named vendor rely on the SCCs and that a copy is available on request from your privacy contact.
What do retention, rights and complaints need to say?
Retention needs a period per data type, or the criteria that decide it. WP260 is direct that it is not sufficient to state that data "will be kept as long as necessary for the legitimate purposes of the processing," and that different periods should be stated for different data and purposes.
A workable SaaS retention section reads like this: account data for the life of the account and a stated number of days after closure; invoices for the period your tax law requires; server logs for a stated number of days; support tickets for a stated period after the last message; analytics data for the retention you set in your analytics tool. Pick the numbers, write them down and make your systems match them.
The rights section lists access, rectification, erasure, restriction, objection and portability, and says how to exercise them: an email address or a settings page. Article 12(3) sets the clock. You answer without undue delay and within one month of receiving a request, extendable by two further months for complex or numerous requests if you tell the person within the first month. Article 12(5) makes it free of charge except for manifestly unfounded or excessive requests.
Close the list with the right to withdraw consent at any time, where consent is a basis, and the right to lodge a complaint with a supervisory authority.
Do you need a DPO or an EU representative?
Most early-stage SaaS companies need neither, but check both. Article 37 requires a data protection officer when you are a public body, when your core activities require regular and systematic monitoring of people on a large scale, or when they involve large-scale processing of special categories of data. If you appoint one, Article 37(7) requires you to publish the DPO's contact details.
A company outside the EU that offers its service to people in the EU, or monitors their behaviour there, falls under Article 3(2), and Article 27 then requires a written designation of a representative in the Union. The exception is processing that is occasional, does not involve large-scale special-category or criminal-offence data, and is unlikely to result in a risk to people's rights. A SaaS that serves EU customers every day is unlikely to count as occasional, so a non-EU founder should expect to name a representative in 13(1)(a).
Where should the privacy policy live?
On its own URL, linked from the footer of every page with the word "Privacy", and linked again at each point of collection: the signup form, the newsletter box, the checkout. Article 13 applies at the time the data is obtained, so the link has to be there when the form is, not only in a footer the visitor never scrolls to.
Keep it in sync with the site. A policy is accurate on the day it is written and drifts with every new vendor, so review it whenever you add a script, change a processor or start a new use of data. The same review is a good time to check the headers that protect the data in transit, listed in the security headers checklist.
Compare your policy with the hosts your pages contact
The recipients test above is the one that takes longest by hand. To have it run against your live site, run the free scan first, then open the full audit. The free LaunchScaler scan needs only your URL and no account, and its compliance category includes "Privacy policy present and reachable", "Article 13 mandatory disclosure elements", which flags required topics missing from the policy text, and "Third-party data recipients vs. disclosed recipients", which loads your page in a real browser and compares the third-party hosts it contacts with the recipients your policy names.
The free run shows each verdict. The full audit, $19 one time for your domain, opens every check to its evidence and exact fix, including the list of hosts your page contacted that the policy does not cover. These are signals, not a legal opinion: a policy can mention every topic and still need a lawyer to confirm the substance.
02
Does a SaaS privacy policy have to name every third party?
Article 13 allows recipients or categories of recipients. The EU's transparency guidelines say the most meaningful information will generally be the named recipients, and that categories, if used, should be as specific as possible about the recipient's activity, sector and location.
03
Can I use a privacy policy generator for my SaaS?
A generator gives you the structure, but it cannot know which vendors your pages and servers send data to. Check its recipient list against the third-party hosts your pages actually contact and the processors your backend uses.
04
How long do I have to answer a GDPR data request?
One month from receipt under Article 12(3). You can extend by two further months for complex or numerous requests, but you must tell the person within the first month, and the response is free of charge.
05
Does a small SaaS need a data protection officer?
Only if its core activities involve regular and systematic monitoring of people on a large scale, or large-scale processing of special categories of data, or it is a public body. If you appoint one, publish the DPO's contact details in the policy.
