How to write a GDPR-compliant privacy policy (2026 guide)

If you run a website, online store, or app that collects any personal data from a European user (an email, an IP, a name, an advertising cookie), you are required to publish a privacy policy. It is not optional, it is not a branding detail, and it is not solved by copying another company's. Spain's data protection authority (AEPD) has imposed over 50 million euros in fines in recent years against companies with missing, vague, or wrong-legal-basis policies.

This guide explains, in plain language, what your privacy policy must say to comply with the EU Regulation 2016/679 (GDPR) and Spain's LOPDGDD. You'll see the 12 mandatory elements, the 6 legal bases explained with real examples, the errors that void your document, a template you can copy, and at the end a shortcut if you'd rather not spend the afternoon drafting it.

What is a privacy policy and why is it mandatory under GDPR

A privacy policy is the document where you explain to your users what personal data you collect, what you use it for, who you share it with, how long you keep it, and what rights they have over it. The GDPR calls this "information to the data subject" and regulates it in Articles 13 and 14: the first when you collect data directly from the user, the second when you obtain it from a third party (a partner, a data broker, a public source).

The GDPR applies if you process data of people located in the European Economic Area, regardless of where your company is based. Your California-based SaaS selling to German customers is subject to GDPR. Your Mexican ecommerce with Spanish customers is too. This is what the regulation calls "extraterritorial scope" (Art. 3).

GDPR, LOPDGDD and ePrivacy: three overlapping rules

In Spain there are three regulatory blocks affecting your privacy policy:

• GDPR (EU Regulation 2016/679): the general European framework for personal data protection.
• LOPDGDD (Organic Law 3/2018): adapts GDPR to Spain. Adds nuances on minors' data (consent from age 14), data of deceased persons, digital rights, and the sanctions regime.
• ePrivacy Directive, transposed by LSSI-CE: regulates cookies and electronic communications. This is why your cookie banner needs granular consent.

Important: your privacy policy can mention cookies, but the cookie policy is usually a separate document. We'll cover that later.

When you are required to have one

If you do any of these, you need a privacy policy:

• You have a contact, subscription, or registration form.
• You use Google Analytics, Meta Pixel, Hotjar, or any analytics tool.
• You process payments (Stripe, PayPal, redsys).
• You send newsletters or marketing emails.
• You allow comments, reviews, or user accounts.
• You use cookies that aren't strictly necessary.

The 12 elements every privacy policy must include

Art. 13 GDPR is prescriptive: it lists the minimum information you must provide. Skipping any of these points is direct grounds for a fine. Here they are translated into "what to write, in what order, and at what level of detail."

1. Identity and contact details of the controller

Legal name of your company, tax ID, registered address, and a working contact email (not the typical info@ nobody checks). If you're a sole proprietor, your full name and tax ID.

2. Data Protection Officer (DPO) details

Only mandatory if you process data at large scale, sensitive data, or you are a public authority (Art. 37). For most startups and SMEs it is not mandatory, but if you appoint one voluntarily you must publish their details.

3. Purposes of processing

What you use each data category for. Bad: "to provide a better service." Good: "to process your order," "to send you the monthly newsletter you subscribed to," "to detect payment fraud."

4. Legal basis for each processing

One of the 6 bases in Art. 6. The next section is entirely about this, because it's where most errors happen.

5. Recipients or categories of recipients

Who else touches your data: hosting (AWS, Vercel), email (Resend, Mailchimp), payment processor (Stripe), CRM (HubSpot). List vendors by name or, if too many, by category with examples.

6. International transfers

If any vendor is outside the EEA (especially the United States), you must disclose it and explain the safeguard: standard contractual clauses (SCC), Commission adequacy decision (EU-US Data Privacy Framework for the US since July 2023), or binding corporate rules.

7. Retention period

How long you keep each type of data. "As long as needed" doesn't cut it: you must give numbers or criteria. Examples: "billing data, 6 years (tax obligation)," "registered user data, while the account is active plus 90 days after deletion."

8. Data subject rights

Access, rectification, erasure ("right to be forgotten"), objection, portability, restriction of processing. State how to exercise them (an email, a form, both) and promise to respond within the legal 1-month deadline.

9. Right to withdraw consent

Only applies when the legal basis is consent. It must be as easy to withdraw as to give. If you collected consent via checkbox, you must offer an equally visible unsubscribe link.

10. Right to complain to the supervisory authority

Literal mention of the relevant authority (in Spain: the AEPD) with its website. Saying "the competent authority" is not enough: you must name it.

11. Existence of automated decision-making, including profiling

If you use algorithms to make decisions producing legal effects (denying credit, calculating a premium, showing different prices), you must disclose this and explain the basic logic.

12. Source of data (Art. 14 only)

If you bought a list, scraped LinkedIn, or received data from a partner, you must say where it came from and whether it comes from publicly accessible sources.

The 6 legal bases explained with real examples

Every processing purpose needs a legal basis. There are only 6, listed in Art. 6.1 GDPR. Choosing the wrong basis is the error that generates the most sanctions. Let's go one by one.

a) Consent

The user says "yes" freely, specifically, informedly, and unambiguously. It must be an affirmative action: no pre-ticked boxes, no "by continuing to browse you accept." And you must be able to prove it (record IP, date, time, exact wording of the consent).

Example: newsletter subscription with double opt-in, installation of analytics cookies after clicking "Accept."

b) Performance of a contract

When the data is necessary to fulfil a contract with the user or to take pre-contractual measures at their request.

Example: postal address to ship an order. Bank details to process payment. Email to deliver the digital invoice.

c) Legal obligation

When a regulation forces you to process the data. You don't get to choose.

Example: keeping invoices for 6 years (Spain Commercial Code Art. 30). Reporting suspicious transactions to anti-money-laundering authorities. Notifying terminations to social security.

d) Vital interests

To protect a person's life. Exceptional, almost always healthcare or emergencies.

Example: medical history of an unconscious patient.

e) Public interest

For administrations and entities with a public service mission. Hardly applicable to private companies.

f) Legitimate interest

The "wildcard" most abused and that generates most sanctions. You can only use it if you pass the three-step balancing test:

1. Legitimate purpose: you pursue a real, not whimsical, interest.
2. Necessity: you cannot achieve the same goal with a less invasive alternative.
3. Balance: your interest does not override the user's rights.

You must document this test in writing and keep it. And you must offer the right to object prominently.

Quick table: situation → legal basis

Common errors that void your privacy policy

If your policy has any of these errors, you're not compliant even if the document is published:

1. Pre-ticked boxes. The CJEU invalidated them in Planet49 (C-673/17). Consent must be an affirmative action.
2. "You accept the terms = you accept data processing." Mixing consents makes none of them valid. Each purpose needs its own decision.
3. Policy copied from another company. If it mentions companies, tools, or jurisdictions that aren't yours, an inspection will catch it in five minutes.
4. "As long as needed" without more. You must give concrete deadlines per data category.
5. Not mentioning US transfers when you use Mailchimp, Stripe, Google Analytics, or any US-based SaaS.
6. No mechanism to withdraw consent. If you ask for consent, there must be an equally easy-to-find unsubscribe button.
7. Not naming the supervisory authority. "The competent authority" doesn't suffice.
8. Policy only in English when your site is in another language. It must be in the user's language.
9. Undated version with no change log. The user must be able to know when it was updated.
10. Citing GDPR articles generically without context. "Per Art. 6 GDPR..." without explaining which legal basis you actually apply doesn't inform, it hides.

Practical template: minimum viable structure

This structure covers the 12 elements of Art. 13 with no filler text. Copy it, replace the placeholders in brackets, and adapt each section to your case.

1. Data Controller
   - Legal name: [YOUR COMPANY, S.L.]
   - Tax ID: [B12345678]
   - Address: [street, number, ZIP, city]
   - Contact email: [privacy@your-domain.com]

2. Data Protection Officer (if applicable)
   - Name: [DPO name]
   - Email: [dpo@your-domain.com]

3. Processing purposes
   - Account management and service delivery
   - Payment processing
   - Marketing communications (only with consent)
   - Customer support
   - Statistical usage analysis

4. Legal basis per purpose
   - Account and service: performance of a contract
   - Payments: performance of a contract + legal obligation
   - Marketing: consent
   - Support: performance of a contract
   - Analytics: consent (cookies)

5. Recipients
   - Hosting: [Vercel Inc., USA - SCC + DPF]
   - Email: [Resend Inc., USA - SCC + DPF]
   - Payments: [Stripe Payments Europe Ltd., Ireland]
   - CRM: [HubSpot, Inc., USA - SCC + DPF]

6. Retention periods
   - Account data: lifetime + 90 days
   - Billing: 6 years (tax obligation)
   - Marketing: until consent withdrawal
   - Technical logs: 12 months

7. Rights
   - Access, rectification, erasure, objection, portability,
     restriction.
   - How to exercise: [privacy@your-domain.com]
   - Response time: 1 month.
   - Complaints: Spanish Data Protection Agency (www.aepd.es).

8. Changes
   - Version [1.0] - Last update: [date]
   - We'll notify material changes by email 15 days
     in advance.

This template is a starting point. No generic template absolves you of reviewing your actual processing: if you use a vendor not listed here, add it. If your retention period is different, adjust it. The policy must reflect your reality, not mine.

Cookies, forms, and tracking: the ePrivacy trap

The GDPR regulates any personal data. The ePrivacy Directive and Spain's LSSI-CE add an extra layer for cookies and similar technologies (pixels, fingerprinting, local storage used for tracking).

Why the cookie policy goes separately

Mixing privacy and cookie policy in one document hurts readability and, more importantly, hurts granular consent withdrawal. Best practice: a privacy policy explaining what you process and why, plus an additional cookie policy listing each cookie with its purpose, duration, and provider.

Consent banner: granular or nothing

The banner must allow accepting, rejecting, or configuring cookies with the same level of friction. A huge green "Accept all" button next to a tiny grey "Configure" link is illegal: regulators have already sanctioned dark patterns. Same-size buttons, same colour, same visual hierarchy.

Keep your policy alive: versioning and change log

A privacy policy isn't a document you fill in and forget. You must update it every time you add a new tool, change a vendor, launch a new feature, or modify a retention period.

The GDPR requires controllers to maintain a Record of Processing Activities (RoPA, Art. 30) internally documenting all processing. The public policy is the user-facing version; the RoPA is the regulator-facing version. Both must align.

How to notify material changes

Minor changes (fixing a typo, rewriting a sentence for clarity) don't require notification. Material changes do: new US vendor, new marketing purpose, extended retention, collection of a new data category. Best practice:

• Notify by email at least 15 days in advance.
• Display a prominent on-site notice for 30 days.
• If the legal basis was consent, request it again.
• Maintain an accessible history (version, date, what changed).

The shortcut: generate your GDPR privacy policy with Termerly

Drafting a policy from scratch and keeping it updated takes time most founders don't have. That's why we built Termerly: a free legal document generator with templates for GDPR, LOPDGDD, CCPA, and 30+ other jurisdictions, automatic versioning, and sync between your site and any changes you make.

The generator asks just enough (what data you collect, what vendors you use, where they're hosted) and produces a policy specific to your case, not a generic template. It's free, no card required, and exports the document as HTML for you to paste into your site or link directly.

Conclusion

Having a privacy policy isn't legal decoration: it's the documentary proof that you know what you do with your users' data and that you respect their rights. The three critical points you can't skip are:

1. Specificity over generality: name vendors, give exact retention periods, list concrete purposes. Vague phrasing is the leading cause of fines.
2. Correct legal basis per purpose: never use legitimate interest as a wildcard if you don't document the balancing test. And only use consent when you can prove it was free, specific, informed, and unambiguous.
3. Continuous maintenance: your policy must reflect today's reality, not the day it was drafted. Every new tool means revisiting the document.

If this is clear, open your current policy and compare it against the 12 elements of Art. 13. If something is missing, today is the day to fix it. If you're drafting your first one, use the Termerly guided template so you don't forget anything.

Frequently asked questions

Is a generic privacy policy copied from another company valid?

No. The policy must be specific to your case: your vendors, your retention periods, your purposes. A generic policy is the first red flag a regulatory inspection looks for and the most common cause of sanctions for incomplete information.

Do I need a Data Protection Officer in my startup?

Only if you process data at large scale, sensitive data (health, biometrics, ideology, sexual orientation), or you are a public authority. Most startups and SMEs don't need one, but if you appoint one voluntarily you must publish their contact in the policy.

What fine can I get if I don't have a privacy policy?

The GDPR allows fines up to 4% of global annual turnover or 20 million euros, whichever is higher. In practice Spanish AEPD fines on SMEs range from 900 to 60,000 euros for incomplete or absent information. The big fines (millions) are reserved for systemic violations or unsafeguarded international transfers.

Must the policy be in Spanish?

Not specifically Spanish, but in the language you communicate with your users. If your site is in Spanish, yes. If you have a multilingual site, you must offer the policy in each language. Authorities have sanctioned English-only policies when the target audience was Spanish-speaking.

Can I use the same policy for my website and my app?

Yes, as long as both platforms do the same processing. If the app collects extra data (geolocation, contacts, sensors), you must add that information in the relevant section or publish an app-specific policy.

How often do I need to update the policy?

There's no mandatory frequency. The rule is: every time something material changes (new vendor, new purpose, different retention) you must update it. As a minimum, it's good practice to review it once a year even with no changes.

Does the privacy policy replace the legal notice?

No. They're distinct documents with different regulatory frameworks: the legal notice is required by LSSI-CE (company details, terms of use), the privacy policy is required by GDPR. The standard is to publish three separate documents: legal notice, privacy policy, and cookie policy.