GDPR Article 13 is the part of GDPR most often confused with "GDPR compliance" as a whole. The article doesn't define compliance — it lists the specific things your privacy policy has to disclose when you collect personal data directly from the data subject. Get the disclosures right and you've covered a large fraction of what regulators check first; get them wrong and your policy fails before anyone looks at the substance.
We see Article 13 disclosure gaps in roughly 70% of the policies we audit. This walkthrough covers each item with what compliant language looks like, what non-compliant language looks like, and what regulators flag first. Use it as a checklist.
Quick context: when Article 13 vs Article 14 applies
Article 13 = when you collect the personal data directly from the individual. Sign-up forms, support tickets, contact forms, account creation — these are Art. 13 territory.
Article 14 = when you obtain personal data about an individual from somewhere other than them. Buying a marketing list, getting data from a partner integration, scraping public profiles, receiving data from an analytics reseller — Art. 14.
The disclosure lists are similar but Art. 14 adds two items (categories of personal data + source). For most SMB SaaS, Art. 13 covers 90% of the surface; Art. 14 applies to specific integrations. We focus on Art. 13 here.
The 12 items
Article 13(1) lists six core disclosures; Article 13(2) adds six more "where necessary to ensure fair and transparent processing". The "where necessary" qualifier is interpreted broadly — the EDPB treats all 12 as expected unless you have a specific reason one doesn't apply.
Article 13(1)(a) — Identity and contact details of the controller
Who is the legal entity collecting the data? What's the contact address? For a non-EU controller serving EU users, you also need to name an EU representative under Article 27.
Compliant:
"Acme Workflows Inc. is the controller of your personal data. Our registered office is at 123 Main Street, San Francisco, CA 94110, USA. You can contact us at [email protected]. For EU users, our EU representative is RepEU GmbH, Friedrichstraße 1, 10117 Berlin, Germany (contact: [email protected])."
Non-compliant:
"We are a privacy-conscious company committed to protecting your data."
The non-compliant version says nothing about WHO. Regulators want a name, an address, a contact path. The flowery language costs you a finding without buying you anything.
Article 13(1)(b) — DPO contact details (where applicable)
If you're required to appoint a Data Protection Officer (Article 37 thresholds — large-scale monitoring or large-scale sensitive data processing), name them. If you're not required and haven't appointed one, you can skip — but if you HAVE appointed a DPO voluntarily, name them.
Compliant:
"Our Data Protection Officer is Jane Doe ([email protected])."
Non-compliant:
"We have a Data Protection Officer."
If you don't have a DPO, the cleanest move is to omit this item entirely (it's "where applicable"). Don't say "we have one" without naming them.
Article 13(1)(c) — Purposes of processing AND the legal basis under Article 6
This is the most-flagged item in our audits. You need TWO things: the purposes (why you process the data) and the legal basis from Article 6 (consent, contract, legal obligation, vital interests, public task, legitimate interests). The basis has to be per-purpose — generic "we have a lawful basis" fails.
Compliant:
"We process your personal data for the following purposes:
- To provide the Service (contract basis under Art. 6(1)(b))
- To send service-related emails (contract basis)
- To respond to support requests (legitimate interest in providing support)
- To send marketing emails (consent — you can withdraw at any time)
- To detect and prevent fraud (legitimate interest in security)
- To comply with legal obligations including tax records (legal obligation)"
Non-compliant:
"We process your personal data based on a lawful basis to provide our services."
The non-compliant version doesn't tell anyone WHICH basis or WHICH purposes. The compliant version pairs each purpose with its specific basis. If you claim legitimate interest, describe the specific interest (EDPB Guidelines require this).
Article 13(1)(d) — Legitimate interests pursued (where (f) of Art. 6 is the basis)
If you claim "legitimate interests" as your basis under Article 6(1)(f), you have to describe the specific interest. EDPB Guidelines 9/2019 require this. "We have a legitimate interest" is insufficient — what IS the interest?
Compliant:
"We rely on legitimate interest for security logging and fraud prevention. Our specific interest is protecting our Service and our users from unauthorized access, account takeovers, and abuse. We have determined that this interest is not overridden by your privacy rights because the data we log (IP address, user agent, request timestamps) is the minimum necessary and is retained only as long as needed for incident response."
Non-compliant:
"We may process some data based on legitimate interest."
Article 13(1)(e) — Recipients or categories of recipients
Who else gets your data? Best practice is to name specific recipients (Stripe, Intercom, AWS). Acceptable fallback is to name categories specific enough that a user could identify them ("payment processor", "customer support platform", "cloud hosting provider"). Generic "service providers" fails.
Compliant:
"We share personal data with the following third parties:
- Stripe (payment processing — your card details and billing info)
- Intercom (customer support — your name, email, and conversation history)
- PostHog (product analytics — your usage events and account ID)
- AWS (cloud hosting — all data, stored in EU-West-1)"
Non-compliant:
"We may share data with service providers as necessary to provide the Service."
Article 13(1)(f) — International transfer details
If data leaves the EEA, you need to:
- State that data is transferred.
- Name the recipient country or organization.
- Reference the legal mechanism: an adequacy decision, Standard Contractual Clauses (which version), Binding Corporate Rules, or an Article 49 derogation.
- Mention how to obtain a copy of the safeguards.
Compliant:
"Your personal data is transferred outside the EEA to the United States, where Stripe (payment processing) and PostHog (analytics) are based. We rely on the 2021 Standard Contractual Clauses (SCC modules 1 and 2 as applicable) as the legal safeguard for these transfers. You can request a copy of the SCCs by emailing [email protected]."
Non-compliant:
"We may transfer your data internationally with appropriate safeguards."
Post-Schrems II, "appropriate safeguards" without naming the mechanism is a real gap. Regulators expect you to name SCCs (the most common mechanism) or the specific alternative.
Article 13(2)(a) — Retention period
How long do you keep the data? Best practice is per-category retention — different data categories have different timelines. Acceptable fallback is "as long as necessary for the purposes" + criteria you use to determine that. Just "as long as necessary" alone is borderline.
Compliant:
"We retain personal data for the following periods:
- Account data: for the lifetime of your account plus 30 days after deletion (so you can recover from accidental deletion)
- Billing records: 7 years from transaction (tax law requirement)
- Support conversations: 3 years from last contact
- Server logs (IP, user agent): 90 days
- Marketing email engagement: until you unsubscribe plus 30 days"
Non-compliant:
"We retain your data as long as necessary."
Article 13(2)(b) — Data subject rights
You have to enumerate the rights. All eight of them:
- Right of access (Art. 15)
- Right to rectification (Art. 16)
- Right to erasure / "right to be forgotten" (Art. 17)
- Right to restriction of processing (Art. 18)
- Right to data portability (Art. 20)
- Right to object (Art. 21)
- Right to withdraw consent (Art. 7(3)) — for purposes based on consent
- Right to lodge a complaint with a supervisory authority (Art. 13(2)(d) — see below)
Compliant:
"You have the following rights regarding your personal data:
- Access — request a copy of the data we hold
- Rectification — ask us to correct inaccurate data
- Erasure — ask us to delete your data (subject to legal retention obligations)
- Restriction — ask us to limit how we process your data
- Portability — receive your data in a machine-readable format
- Objection — object to processing based on legitimate interest
- Withdraw consent — at any time for processing based on consent
- Lodge a complaint with a supervisory authority Email [email protected] to exercise any of these rights."
Non-compliant:
"You have rights under GDPR including access and deletion."
Listing only some of the rights fails. The most-omitted rights in our audits are restriction (Art. 18) and the right to lodge a complaint (Art. 13(2)(d)).
Article 13(2)(c) — Right to withdraw consent (for consent-based processing)
If you process any data based on consent, you have to explicitly mention the right to withdraw and that withdrawal doesn't affect the lawfulness of processing before withdrawal.
Compliant:
"Where we process your data based on your consent (for example, marketing emails), you can withdraw your consent at any time by clicking the unsubscribe link in any marketing email or by emailing [email protected]. Withdrawing your consent does not affect the lawfulness of processing we did before you withdrew."
Non-compliant:
"You can unsubscribe at any time."
Article 13(2)(d) — Right to lodge a complaint with a supervisory authority
This is the most-missed disclosure in our audits — we see it absent in roughly 60% of policies we audit. GDPR requires you to inform users they can complain to a supervisory authority.
Compliant:
"You have the right to lodge a complaint with a data protection supervisory authority. For EU users, this is typically the supervisory authority in the EU member state of your habitual residence, place of work, or where the alleged infringement took place. The European Data Protection Board maintains a list at edpb.europa.eu/about-edpb/about-edpb/members_en. UK users can complain to the Information Commissioner's Office (ico.org.uk)."
Non-compliant:
[No mention of the complaint right at all]
Article 13(2)(e) — Whether providing the data is statutory or contractual
For each data category, is the user obligated to provide it (by law or by contract), and what happens if they don't?
Compliant:
"Providing the personal data is a contractual requirement (you cannot use the Service without an account). If you choose not to provide it, we cannot create your account. Specific fields marked as optional in our forms are not required and can be left blank without affecting service access."
Non-compliant:
[No mention]
This item is widely skipped and the EDPB has been lenient on it for SMB SaaS — but it costs nothing to include and a thorough audit will flag missing language.
Article 13(2)(f) — Existence of automated decision-making, including profiling
If you make decisions based solely on automated processing that produces legal or similarly significant effects, disclose it. For most SaaS this doesn't apply — your in-product algorithms don't typically produce legal effects on users. But you have to evaluate.
Compliant (if you do it):
"We use automated decision-making in the following situations: [describe]. The logic involved is [describe at a high level]. The significance and consequences are [describe]. You have the right to obtain human intervention, express your point of view, and contest the decision under Article 22 GDPR."
Compliant (if you don't do it):
[Either omit or explicitly state: "We do not use automated decision-making with legal or similarly significant effects on users."]
How to verify your own policy
Three approaches:
1. Free audit (15 seconds). Paste your URL into our free privacy audit — the audit checks against each of these 12 items individually. The report tells you which are present, which are missing, and which are incomplete.
2. Manual checklist (30 minutes). Print this article, print your privacy policy, walk through each item. Mark each as present / missing / partial. For each missing item, our GDPR privacy policy generator generates compliant language you can adapt.
3. Lawyer review (paid). For high-risk processing — large EU user base, sensitive data, regulated industry — pay a privacy lawyer to review the policy against Articles 13 and 14 specifically. Typical engagement: €300-€1,500.
What regulators check first
In enforcement actions and complaint investigations we've reviewed, the first three items checked are nearly always:
- Right to lodge a complaint (Art. 13(2)(d)) — present or absent.
- Lawful basis per purpose (Art. 13(1)(c)) — generic or specific.
- International transfer mechanism (Art. 13(1)(f)) — named or vague.
If your policy passes those three, you've cleared the first regulator filter. The other nine matter too but the first three are the gate.
Related reading
- CPRA 2026 Amendments: What Changed and What You Have to Update — California's equivalent regulatory update.
- 10 Best Privacy Policy Generators in 2026 — generators that handle the Article 13 checklist (and ones that don't).
- Free privacy policy audit — paste a URL, get the Article 13 checklist results in 20 seconds.