📋 What We'll Cover
- Article 13 — the legal requirement
- The Article 13 checklist (all 12 required disclosures)
- Legal bases cheat sheet
- Retention periods — how to write them
- International transfers — post-Schrems II reality
- Your privacy policy as a living document
- Common Article 13 violations (from actual enforcement)
- Using our GDPR privacy policy generator
Article 13 — The Legal Requirement
GDPR Article 13 is the section of the General Data Protection Regulation that tells you what must be in your privacy policy when you collect personal data directly from a person. It is not optional. It is not a suggestion. It is the law, and enforcement authorities across the EU check privacy policies against an Article 13 checklist during investigations.
The critical phrase in Article 13 is "at the time the data are obtained." This means the information must be presented before or at the moment you collect the data — not buried in a PDF you email later, not hidden in a "Terms and Conditions" link nobody clicks. The privacy policy link next to the sign-up button needs to contain all of Article 13's required elements.
If your privacy policy is missing any of the 12 items listed below, you are technically non-compliant. The DPA (Data Protection Authority) in your member state can issue fines of up to €20 million or 4% of annual global turnover — whichever is higher — for violations of Articles 13 and 14 (the right to be informed).
This checklist is the one regulators use. Cross-check your policy against every item.
The Article 13 Checklist — All 12 Required Disclosures
Here is every item Article 13 requires in your privacy policy. Go through this list item by item with your current policy. Any gap is non-compliance.
(a) Identity and Contact Details of the Controller
You must state who "the controller" is — the entity that decides why and how personal data is processed. For most businesses, this is your company.
Controller: ACME GmbH Registered Address: Musterstrasse 12, 10115 Berlin, Germany Email: privacy@acme.com Phone: +49 30 1234567
Your company name must match your commercial register entry. Your address must be a physical address — a PO box alone is not sufficient under GDPR. Include at least an email address where data subjects can reach you. A contact form on your website qualifies, but a direct email address is better practice.
What regulators check: Does the company name match the legal entity registered in the member state? Is the address real? Do they respond to the email within a reasonable time (30 days is the guideline)?
(b) Contact Details of the Data Protection Officer (DPO)
You need a DPO if any of these apply:
- You are a public authority or body (excluding courts)
- Your core activities involve large-scale, regular, and systematic monitoring of individuals (e.g., online behavioral advertising, CCTV networks covering cities)
- Your core activities involve large-scale processing of special category data (health, biometrics, political opinions, religious beliefs, sexual orientation) or criminal conviction data
If you do not meet any of these criteria, you are not legally required to appoint a DPO. You can still voluntarily appoint one — many businesses do for trust reasons. If you have one, include their contact details. If you do not, simply skip this section or state "we have not appointed a Data Protection Officer as we are not legally required to do so."
(c) Purposes of Processing and Legal Basis for Each Purpose
This is where most privacy policies fail. You must list each purpose for which you process personal data and the specific legal basis for that purpose. Saying "we may process your data for marketing and service delivery" — without matching each purpose to a legal basis — is non-compliant.
| Purpose | Legal Basis | How to State It |
|---|---|---|
| Order processing | Contractual necessity (Art 6(1)(b)) | "We process your name, address, and payment details to fulfill your order. This processing is necessary for the performance of our contract with you." |
| Marketing emails | Consent (Art 6(1)(a)) | "We send marketing emails only if you have given us your explicit consent. You can withdraw this consent at any time." |
| Fraud prevention | Legitimate interest (Art 6(1)(f)) | "We process transaction data to detect and prevent fraudulent activity. This is in our legitimate interest of protecting our business and our customers." |
| Tax records | Legal obligation (Art 6(1)(c)) | "We retain invoice data for 10 years as required by German tax law (Abgabenordnung §147)." |
One purpose, one legal basis. Do not list multiple legal bases for the same purpose — it signals that you haven't properly determined which one applies. And do not use "consent" as a catch-all for everything. If processing is necessary for your contract (like shipping an order), consent is the wrong legal basis — contractual necessity is the right one.
(d) Legitimate Interests (If You Rely on This Basis)
If you use legitimate interest as a legal basis for any processing, you must:
- State what the specific legitimate interest is — "our legitimate interest in preventing fraud," "our legitimate interest in direct marketing to existing customers," "our legitimate interest in network security"
- Explain that you have balanced this interest against the data subject's rights and freedoms
- Provide a way for the data subject to object to this processing (this is the right to object under Article 21)
Legitimate interests: - Fraud prevention: We process transaction pattern data to detect and block fraudulent orders. We have assessed that this interest does not override your rights because the processing is limited to transaction-level data and does not involve profiling. - Direct marketing to existing customers: We may send you product recommendations based on your purchase history. You can opt out at any time.
You must also document a Legitimate Interest Assessment (LIA). This is an internal document, not published in your privacy policy, but regulators can request it during an investigation. The LIA documents: (1) the purpose, (2) the legitimate interest, (3) whether the processing is necessary, (4) the impact on the individual, and (5) safeguards you have in place.
(e) Recipients or Categories of Recipients
You must disclose who has access to the personal data. You can name specific companies or categories of recipients. Categories are more practical for most businesses — you don't need to update your policy every time you switch CRM providers.
| Category | Examples | What to Say |
|---|---|---|
| Payment processors | Stripe, PayPal, Mollie | "Payment processing services (Stripe Inc., PayPal Europe)" |
| Hosting providers | Vercel, AWS, Hetzner | "Web hosting and infrastructure providers" |
| Email services | Mailchimp, SendGrid, Mailgun | "Email delivery and marketing platforms" |
| Analytics | Google Analytics, Plausible, Matomo | "Website analytics providers" |
| Customer support | Zendesk, Intercom, Freshdesk | "Customer support platform providers" |
| Legal/accounting | External tax advisor, legal counsel | "Professional advisors (tax consultants, lawyers)" |
(f) International Transfers and Safeguards
If personal data is transferred to a country outside the European Economic Area (EEA), you must disclose:
- Which countries the data goes to
- What safeguard you rely on to make the transfer lawful
We cover this in detail in section 5 below, but this is what it looks like in your policy:
International data transfers: - United States: We use Mailchimp (Intuit Inc.) for email marketing. Mailchimp is certified under the EU-US Data Privacy Framework (DPF). - United States: Our hosting provider Vercel Inc. processes data in the US under Standard Contractual Clauses (2021 SCCs), supplemented by a Transfer Impact Assessment. - India: Our customer support provider Zoho Corporation processes data in India under Standard Contractual Clauses (2021 SCCs).
(g) Retention Periods
You must state how long you keep each category of personal data. "As long as necessary" without specifics is the most common Article 13 violation — every regulator we have reviewed flags this. See section 4 for how to write retention periods properly.
(h) Data Subject Rights — All 8 of Them
Article 13(2)(b) requires you to inform data subjects of their rights under Articles 15–22 and Article 77. You must list all eight rights and explain how to exercise each one:
| Right | Article | What It Means |
|---|---|---|
| 1. Right of access | Art 15 | You can request a copy of all personal data we hold about you |
| 2. Right to rectification | Art 16 | You can ask us to correct inaccurate or incomplete data |
| 3. Right to erasure ("right to be forgotten") | Art 17 | You can request deletion of your data, subject to legal retention requirements |
| 4. Right to restriction of processing | Art 18 | You can ask us to stop processing your data (but keep it stored) |
| 5. Right to data portability | Art 20 | You can receive your data in a machine-readable format (CSV, JSON) |
| 6. Right to object | Art 21 | You can object to processing based on legitimate interest or direct marketing |
| 7. Rights related to automated decision-making | Art 22 | You can contest decisions made solely by automated means, if they have legal or significant effects |
| 8. Right to lodge a complaint with a supervisory authority | Art 77 | You can complain to your local DPA if you believe we have violated your rights |
How to exercise your rights: Send an email to privacy@acme.com with the subject "Data Subject Request." We will respond within 30 days (as required by Article 12(3)). We may ask for proof of identity before processing your request. All requests are free of charge unless they are manifestly unfounded or excessive (Article 12(5)).
(i) Right to Withdraw Consent
If you rely on consent as a legal basis for any processing, you must state that the data subject has the right to withdraw consent at any time — and that withdrawal does not affect the lawfulness of processing carried out before withdrawal. Crucially, Article 7(3) requires that withdrawing consent must be "as easy as giving it."
If a user gave consent by ticking a checkbox on your website, the withdrawal mechanism must be equally simple — ideally an email unsubscribe link, a settings toggle, or a one-click link. You cannot require users to write a formal letter or call a phone number during business hours.
Withdrawing consent: If you have given us consent to send marketing emails, you can withdraw this consent at any time. Click the "unsubscribe" link at the bottom of any marketing email, or email privacy@acme.com with "Withdraw consent" in the subject line. Withdrawing consent does not affect the lawfulness of processing based on consent before its withdrawal.
(j) Right to Lodge a Complaint with a Supervisory Authority
You must name the supervisory authority (DPA) for your jurisdiction and explain that data subjects can lodge complaints there. For most EU countries:
You have the right to lodge a complaint with your local Data Protection Authority. In Germany (our lead supervisory authority): Berliner Beauftragte für Datenschutz und Informationsfreiheit Alt-Moabit 59-61, 10555 Berlin, Germany Email: mailbox@datenschutz-berlin.de You can also complain to the DPA in your country of residence. A list of all EU DPAs is available at: https://edpb.europa.eu/about-edpb/about-edpb/members_en
(k) Statutory or Contractual Requirement to Provide Data
If providing personal data is a legal or contractual requirement (or a requirement necessary to enter into a contract), you must:
- State that the data subject is obliged to provide the data
- Explain the consequences of not providing it
Requirement to provide data: - Shipping address: You must provide a delivery address to receive products ordered from our store. Without this information, we cannot fulfill the contract. - Payment information: You must provide valid payment details to complete your purchase. Without valid payment, the transaction cannot proceed. - Tax identification: If you are a business customer in Germany, you must provide your VAT ID as required by §14 UStG.
(l) Automated Decision-Making and Profiling
If you use automated decision-making (including profiling) that produces legal effects or similarly significant effects on the data subject, Article 13(2)(f) requires you to provide:
- Meaningful information about the logic involved
- The significance and envisaged consequences for the data subject
Automated decision-making: We use automated decision-making for credit assessment when you purchase on invoice. Logic: Our system evaluates your order value, purchase history, and publicly available credit scoring data. Consequences: If the automated assessment results in a negative decision, we will notify you and offer manual review by a human agent. You can contest the decision by emailing credit@acme.com.
Legal Bases Cheat Sheet
Choosing the wrong legal basis is one of the most common privacy policy mistakes. Here is a quick-reference guide to each basis under Article 6(1):
| Legal Basis | Article | When to Use | When NOT to Use |
|---|---|---|---|
| Consent | 6(1)(a) | Marketing emails (outside the soft opt-in exception), non-essential cookies, processing special category data, selling data to third parties | Order processing, account creation, fraud prevention, tax compliance |
| Contractual necessity | 6(1)(b) | Processing needed to fulfill a contract: shipping addresses, payment processing, account management, customer support for paying customers | Marketing, analytics, behavioral advertising, any processing not strictly necessary for the contract |
| Legal obligation | 6(1)(c) | Tax records (10 years for most EU countries), anti-money-laundering checks, responding to court orders, employer obligations under labor law | Marketing, analytics, customer communication — unless a specific law requires it |
| Vital interests | 6(1)(d) | Life-or-death situations: processing medical data in an emergency, locating a missing person | Almost everything else. This is rarely the right basis for standard business operations |
| Public interest / official authority | 6(1)(e) | Public sector: processing necessary for a task carried out in the public interest or in the exercise of official authority | Private sector businesses. You generally cannot use this unless you exercise official authority |
| Legitimate interest | 6(1)(f) | Fraud prevention, network and information security, direct marketing to existing customers (B2B and B2C with balancing), basic analytics, intra-group data transfers for administrative purposes | Public authorities (cannot use legitimate interest), processing where the data subject would not reasonably expect it, processing special category data (requires explicit consent or an Article 9 exception) |
Legitimate Interest Assessment (LIA) — The Document Regulators Ask For
If you use legitimate interest as a legal basis, you need a documented LIA. This is not published in your privacy policy but must exist internally. Regulators request it during investigations. The LIA has three parts:
- Purpose test: What is the legitimate interest? Is it specific, demonstrable, and understood?
- Necessity test: Is the processing necessary to achieve that purpose? Could you achieve it with less intrusive means?
- Balancing test: Do the data subject's interests, rights, and freedoms override the legitimate interest? Consider: the nature of the data, the relationship with the data subject, safeguards in place, and the data subject's reasonable expectations.
LIA Example — Fraud Prevention: Purpose test: Our legitimate interest is preventing fraudulent transactions on our e-commerce platform. Fraud costs our business approximately €12,000/month in chargebacks and lost inventory. Necessity test: Processing transaction pattern data (amount, frequency, IP geolocation, shipping address) is necessary to distinguish legitimate orders from fraudulent ones. No less intrusive alternative achieves the same level of detection. Balancing test: We only process transaction-level data, not browsing behavior or location tracking. We do not share this data outside the transaction processing chain. Data subjects would reasonably expect a merchant to take steps to prevent fraud. Result: legitimate interest outweighs individual impact.
Retention Periods — How to Write Them
"We retain your personal data for as long as necessary to fulfill the purposes for which it was collected."
This sentence — or something like it — appears in roughly 80% of privacy policies we have reviewed. And it is non-compliant. GDPR Article 5(1)(e) requires that data be kept "for no longer than is necessary for the purposes for which the personal data are processed." The Article 29 Working Party (now EDPB) has consistently stated that policies must specify concrete retention periods, not vague statements.
Here is how to write retention periods that satisfy regulators:
| Data Category | Specific Retention Period | Legal Basis for Retention |
|---|---|---|
| Customer account data (name, email, address) | Duration of the account + 2 years after last activity | Contractual necessity + legitimate interest in re-engagement |
| Order/invoice records | 10 years from the end of the financial year | Legal obligation (tax law in most EU countries) |
| Marketing consent records | Until the data subject withdraws consent | Consent — withdrawal ends lawful processing |
| Support emails / ticketing | 2 years from the last communication | Legitimate interest (improving service quality) |
| Website analytics (Google Analytics) | 26 months (GA default) or 14 months (recommended) | Consent (under ePrivacy Directive for cookies) + legitimate interest |
| Job applicant data | 6 months after the position is filled (or rejected) | Legitimate interest (defending against legal claims) |
| CCTV footage | 30 days (varies by member state; Germany: max 72 hours without incident) | Legitimate interest (security) |
| Cookie/tracking data | As specified in your Cookie Policy (typically 13 months for analytics cookies) | Consent (under ePrivacy Directive) |
| Payment data (processed by third party) | Not stored by us — processed by Stripe/PayPal per their retention policy | State that you do not store it and link to the processor's policy |
International Transfers — Post-Schrems II Reality
Since the Schrems II ruling (July 2020) invalidated the EU-US Privacy Shield, the landscape for international data transfers has changed significantly. Here is the current state of play:
EU-US Data Privacy Framework (DPF)
Effective July 2023, the DPF replaced the invalidated Privacy Shield. US companies can self-certify under the DPF, and transfers to certified organizations are treated as adequate under Article 45. Check if your providers are DPF-certified at dataprivacyframework.gov. If they are, you can list DPF as your transfer safeguard.
Standard Contractual Clauses (SCCs)
The European Commission adopted new SCCs in June 2021 (Decision 2021/914). Old SCCs from 2010 are invalid for new contracts since September 2021 and must be replaced in existing contracts by December 2022 (if you have not done this, you need to do it urgently). The 2021 SCCs require a Transfer Impact Assessment (TIA) — a document analyzing whether the legal framework in the destination country provides essentially equivalent protection to EU law.
UK International Data Transfer Agreement (IDTA)
For transfers from the UK (post-Brexit), you need either the IDTA or the EU SCCs with a UK Addendum. These are separate from the EU SCCs. If you process data from both EU and UK data subjects, you likely need both frameworks.
What Your Policy Must Say
For every country outside the EEA where data is transferred, state the country and the safeguard:
International transfers: We transfer personal data to the following countries outside the EEA: | Country | Service | Safeguard | |---------|---------|-----------| | United States | Email marketing (Mailchimp) | EU-US DPF certification | | United States | Hosting (Vercel) | Standard Contractual Clauses (2021) + TIA | | India | Customer support (Zoho) | Standard Contractual Clauses (2021) + TIA | | Canada | Analytics (Plausible) | Adequacy decision (Art 45 — Canada has adequate protection) | You can request a copy of the relevant safeguards by emailing privacy@acme.com. Note: Standard Contractual Clauses may be redacted for commercial confidentiality.
Your Privacy Policy as a Living Document
A privacy policy is not a one-time writing exercise. It must evolve with your data processing activities. Here is how to manage it properly:
Version History
Add a "Last updated" date and version number. If regulators investigate, they will ask: "What was your privacy policy on [date of alleged violation]?" You need to know exactly which version was live at that time.
Version history: - v2.3 — May 15, 2026: Updated international transfers section (added DPF certification for Mailchimp) - v2.2 — January 10, 2026: Added retention periods for customer account data - v2.1 — August 1, 2025: Updated DPO contact information - v2.0 — March 1, 2025: Complete rewrite for 2021 SCC compliance - v1.0 — May 25, 2018: Original policy (GDPR effective date)
Notification of Changes
If you change how you use data, Article 13 requires you to inform data subjects. The GDPR does not specify a time period, but the EDPB guidelines suggest prior notice for material changes. "We'll email you 30 days before changes take effect" is best practice. Material changes — new processing purposes, new data categories, new third-party sharing — may require fresh consent.
Archiving Old Versions
Keep PDF copies of every version of your privacy policy. The CNIL (France), ICO (UK), and DPC (Ireland) all ask for historical versions during investigations. A simple approach: maintain an archive page with links to all previous versions and their effective dates.
Common Article 13 Violations — From Actual Enforcement
These are the most frequently cited Article 13 violations from real DPA enforcement actions across the EU. Check your policy against every single one:
| Violation | What Regulators Found | Example |
|---|---|---|
| "May" language | "We may use your data for marketing purposes" — "may" is not a statement of what you actually do. Recital 39 requires "transparent processing." Either you do it or you don't. | CNIL fined a company €150,000 for using "may" to describe marketing processing. The policy must say "we use" or "we do not use." |
| No retention periods | Policy said "we retain data as long as necessary." The EDPB explicitly states this is insufficient. Same for "we retain data in accordance with legal requirements" without specifying the requirements. | DPC Ireland cited this in multiple enforcement actions in 2023-2024. Fines ranged from €50,000 to several million. |
| Missing legal basis per purpose | Policy listed all legal bases in a block (consent, contractual necessity, legitimate interest, legal obligation) without matching them to specific purposes. | The Hamburg DPA (Germany) issued €200,000 fine for a policy that listed legal bases without linking them to processing purposes. |
| Vague third-party sharing | "We share data with trusted third parties." You must say which categories of third parties and why. "Trusted" is not a legal category. | ICO UK fined a company €80,000 for "we share data with partners" without specifying who the partners are or what they do with the data. |
| Missing DPO | Company processed large-scale health data but had no DPO contact in the policy. DPO was mandatory under Article 37. | CNIL France issued a €400,000 fine to a health data processor for not appointing a DPO despite legally being required to. |
| English-only policy for non-English users | Article 12 requires the policy to be "in a concise, transparent, intelligible, and easily accessible form, using clear and plain language." For users in Germany, the policy must be in German. For users in France, in French. | The Belgian DPA (APD/GBA) fined a company whose privacy policy was only in English despite serving Dutch and French-speaking customers in Belgium. |
| Incomplete rights information | Policy listed only right of access, rectification, erasure (the "big three") but omitted portability, restriction, objection, automated decision-making, or complaint rights. | Multiple DPAs have issued warnings and fines for incomplete rights lists. All eight rights must be mentioned. |
| No withdrawal mechanism for consent | Policy said "you can withdraw consent" but provided no method to do so, or provided a method that was harder than giving consent. | The DPC Ireland found a company required users to write a letter to withdraw consent while consent was given via a one-click checkbox. Fine: €90,000. |
Using Our GDPR Privacy Policy Generator
Writing a GDPR-compliant privacy policy from scratch is time-consuming and error-prone. Our Privacy Policy Generator walks you through a structured questionnaire and outputs a complete Article 13-compliant privacy policy.
The generator asks about:
- Your company details (name, address, contact information)
- Every purpose for which you process personal data
- The legal basis for each purpose
- Which third-party services you use (payment processors, analytics, hosting, email, etc.)
- Which countries data is transferred to and what safeguards apply
- Your retention periods for each data category
- Whether you use automated decision-making
- Whether a DPO is required (and if so, their contact details)
The generator produces a policy that covers all 12 Article 13 disclosure requirements, written in clear, plain language that satisfies Article 12's transparency requirements. You can customize the output, add your branding, and publish it directly on your website.
Need a more comprehensive compliance framework? Read our GDPR Compliance Guide for the full picture — including data processing agreements, data breach notification procedures, Records of Processing Activities (ROPA), and Data Protection Impact Assessments (DPIA).
Ready to generate your GDPR-compliant privacy policy?
Generate Privacy Policy →