GDPR Privacy Policy Requirements: Articles 13 & 14 in Practice

1. What Articles 13 and 14 actually require

The GDPR does not use the phrase "privacy policy" anywhere. The transparency obligation lives in Articles 13 and 14, framed as a positive duty on the controller to provide information to the data subject — at collection, in writing, in clear and plain language. The published privacy policy is the artefact controllers use to discharge that duty. It is the single most-read document in the GDPR pack and the one a supervisory authority will pull up first.

The two Articles split on a single fact: where the data came from.

• Article 13 applies when personal data is collected from the data subject. The information must be provided at the time the data is obtained.
• Article 14 applies when personal data is obtained from anywhere else — a list, a public register, an enrichment service, a referral, a sub-processor feed. The information must be provided within a reasonable period and in any case no later than the deadlines in Art. 14(3).

The information set is largely the same. Article 14 adds two items the subject would otherwise not know — the categories of personal data being processed about them, and the source from which they came — and a small number of carve-outs in Art. 14(5) where the obligation does not apply (most narrowly: where provision proves impossible or would involve a disproportionate effort, with conditions).

EDPB Guidelines on Transparency (WP260 rev.01, endorsed by the EDPB in 2018 and still the operative interpretation) make three points worth memorising before drafting: the language must be understandable to the policy's audience, the lawful basis must be specified per processing operation, and a generic notice that does not reflect the controller's actual processing is not transparent — even if it cites every Article correctly.

3. Direct collection (Article 13)

Article 13 fires the moment the subject hands you their data — a checkout form, a contact form, an account signup, a customer support call, an in-shop enrolment for a loyalty programme. The information must be provided at the time the data is obtained. There is no grace period; if the subject walks away without seeing it, the obligation has been missed.

The two-layer pattern

The way most controllers actually meet Article 13 in practice is a layered notice — a short context-specific notice next to the form ("how we use your data") plus a link to the full policy. EDPB Guidelines on Transparency endorse layering explicitly, with the caveat that the first layer must contain the information "most relevant" to the subject in the context: identity of the controller, purposes, and the existence of subject rights. Hiding the lawful basis four clicks deep is not transparent.

The Article 13 timing trap

A common mistake is treating "at the time" as "at account confirmation" — the email that gets sent after the form submits. By then the data is already collected, written to the database, and likely already shared with at least the email service provider. The notice must be visible before the submit button, on the same screen as the form.

What changes for under-13s

Where you collect data from a child for an information-society service offered directly to children, Article 8 layers consent mechanics onto the Article 13 notice. The age threshold defaults to 16 but member states can lower it to 13; Germany applies 16, Poland 16, Lithuania 14. The privacy notice for child-facing processing must be drafted to be understandable to a child of the relevant age — not just a clean adult notice in smaller font.

4. Indirect collection (Article 14)

Article 14 fires whenever you obtain personal data from a source other than the subject. This is the article most templates underweight, and where transparency-notice fines cluster — because controllers underestimate how often they are actually in Article 14 territory.

You are in Article 14 territory if you:

• buy or rent a marketing list;
• enrich your CRM with data from a third-party provider (firmographics, role inference, intent signals);
• ingest data from a public register (companies house, professional registers, court bulletins) for due diligence or outreach;
• receive a CV from a recruiter or referral, rather than directly from the candidate;
• import contacts from a sub-processor or partner under a data sharing arrangement.

The Art. 14(3) deadline — three triggers, earliest wins

Article 14(3) does not give you a single window; it gives you three, and you have to meet whichever comes first:

1. Within a reasonable period after obtaining the data, and at the latest one month;
2. At the time of the first communication with the subject, if the data is used to communicate with them;
3. At the time of the first disclosure to a further recipient.

For B2B outreach this almost always means "the first email" — the moment you send the cold email is the deadline for the Article 14 notice. In practice this is met by including a short transparency block in the first email with a link to the full policy, plus a one-click opt-out.

The Art. 14(5) carve-outs and how narrow they are

Article 14(5) lists four cases where the Article 14 obligation does not apply: the subject already has the information; provision is impossible or involves a disproportionate effort; obtaining or disclosure is expressly laid down by law that the controller is subject to; or the data must remain confidential under a professional secrecy obligation. These are read narrowly. EDPB Guidelines on Transparency are explicit that "disproportionate effort" is a high bar — it is not avoidance of inconvenience, and it requires a documented assessment.

5. Lawful basis without legalese

Article 6(1) lists six lawful bases for processing. The privacy notice has to identify which basis applies to which processing purpose — and EDPB Guidelines on Transparency are explicit that a single blanket basis covering everything is not transparent. The practical consequence is that the lawful-basis section reads as a table or a per-purpose list, not a paragraph.

The six bases, in plain shape

• Art. 6(1)(a) — Consent. Specific, informed, freely given, unambiguous, withdrawable. Burden of proof is on the controller (Art. 7(1)).
• Art. 6(1)(b) — Contract.Necessary to perform a contract with the subject, or to take steps prior to entering one at the subject's request. "Necessary" is read strictly — convenience does not qualify.
• Art. 6(1)(c) — Legal obligation. The controller is subject to a Union or member-state law that requires the processing. Cite the law where you can.
• Art. 6(1)(d) — Vital interests. Necessary to protect the life of a natural person. Rare in commercial contexts.
• Art. 6(1)(e) — Public interest / official authority. Used by public bodies and bodies exercising delegated authority. Rare for SMBs.
• Art. 6(1)(f) — Legitimate interests. Necessary for the legitimate interests of the controller or a third party, weighed against the rights and freedoms of the subject. Requires a documented Legitimate Interests Assessment (LIA) — and the privacy notice must name the specific interest, not just cite the basis.

The per-purpose pattern

The clean shape for an SMB privacy notice is a list of processing purposes, each with: the purpose, the lawful basis, the data categories, and the retention period or criterion. For purposes relying on Art. 6(1)(f), add a one-sentence statement of the specific interest. For purposes relying on consent, add a one-sentence statement of how the subject can withdraw it.

Where the legitimate-interests trap is

Art. 6(1)(f) is overused as a default basis because it does not require a separate consent flow. It is also the basis the supervisory authority probes hardest. The notice must identify the specific interest and the processing must pass the three-part test (legitimate interest, necessity, balancing). For direct marketing, Recital 47 helpfully labels marketing as a legitimate interest capable of justification — capable, not automatic — and the ePrivacy Directive adds a prior-consent layer for electronic communications that does not go away just because Art. 6(1)(f) is satisfied.

6. Special-category and criminal data

Article 9 carves out a class of personal data — racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data for unique identification, health data, sex life, and sexual orientation — and prohibits processing unless one of the exceptions in Art. 9(2) applies. Article 10 does the same for criminal-conviction data, with a narrower set of bases.

For the privacy notice this means a second basis line wherever special-category data is in scope: an Art. 6(1) basis and an Art. 9(2) basis. Most templates miss the Art. 9 layer, particularly in three places:

• HR / recruitment. CVs and onboarding forms routinely include health information, trade-union membership, or special-category data inferred from leave records. Art. 9(2)(b) covers employment-law processing where authorised by Union or member-state law.
• Customer support. Support transcripts where a customer volunteers a health condition to explain a refund — that is special-category data, even when you did not ask for it. Art. 9(2)(a) explicit consent is the usual basis; the support team should know to flag and segregate it.
• Biometric login. Face / fingerprint authentication is biometric data for unique identification under Art. 9(1) and requires an Art. 9(2) basis — typically explicit consent, with a non-biometric alternative offered.

The privacy notice does not need to enumerate every special category that could appear, but it must disclose the categories the controller knowingly processes — and the Art. 9(2) basis for each.

7. International transfers post-Schrems II

Articles 13(1)(f) and 14(1)(f) require the privacy notice to disclose any transfers of personal data to third countries or international organisations, the existence or absence of an adequacy decision, the safeguard relied on, and the means by which the subject can obtain a copy or where the safeguards are made available.

Since CJEU C-311/18 (Schrems II, 2020), transfers to third countries without an adequacy decision require not just a transfer mechanism (typically the SCCs adopted by the Commission in 2021) but a documented Transfer Impact Assessment that evaluates the law and practice of the destination country. The TIA itself does not live in the privacy notice, but the notice is where its existence is referenced and where the subject is told how to ask for the safeguards.

The transfer-mechanism options, in order of preference

1. Adequacy decision (Art. 45). Transfers to a country the Commission has decided offers an adequate level of protection. Current adequate countries include Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, Uruguay, the United Kingdom, and the United States under the EU-US Data Privacy Framework for participating organisations only.
2. Standard Contractual Clauses (Art. 46(2)(c)). The Commission's 2021 SCCs, with the four modules (controller-to-controller, controller-to-processor, processor-to-processor, processor-to-controller) and the annexes filled out for each transfer relationship.
3. Binding Corporate Rules (Art. 47). For intra-group transfers; requires supervisory-authority approval and a long timeline. Rare for SMBs.
4. Article 49 derogations. Specific situations — explicit consent, contract performance with the subject, important reasons of public interest. EDPB Guidelines 2/2018 are emphatic that derogations are exceptional and not a substitute for SCCs in routine commercial transfers.

What the notice must actually say

The notice must identify (i) the third country or international organisation, (ii) whether an adequacy decision applies, (iii) if not, which safeguard mechanism is used, and (iv) how to obtain a copy of the safeguards. A common shortcut — "we may transfer data outside the EEA where adequate safeguards are in place" — fails on (i), (iii), and (iv).

8. Retention, recipients, rights — the gap-prone fields

Three fields collect most of the supervisory-authority criticism in published transparency-notice decisions. Each is easy to write badly and only marginally harder to write well.

Retention (Art. 13(2)(a) / 14(2)(a))

The notice must state the storage period, or — where that is not possible — the criteria used to determine it. The phrase "as long as necessary" on its own fails the criterion test. Acceptable shapes look like:

• A fixed period— "7 years from the date of invoice, to comply with §147 AO / Art. 70 of the Polish Tax Ordinance / Art. 12 of the Lithuanian Tax Administration Act".
• An event-anchored period— "3 years from the closure of the customer account".
• A documented criterion— "for the duration of the contract plus the limitation period for civil claims under the applicable national law", where the criterion is genuinely the operative rule.

The retention period in the public notice has to match the internal Data Retention Policy and the ROPA. A mismatch between the published period and the actual deletion practice is an Art. 5(1)(e) finding waiting to happen.

Recipients (Art. 13(1)(e) / 14(1)(e))

Categories are sufficient — "hosting providers", "email service providers", "payment processors", "analytics providers", "customer-support tools". Naming individual recipients becomes necessary in two cases: transfers to a third country (where the country and the mechanism must be linked to the recipient anyway), and disclosures the subject would not reasonably anticipate. For the rest, the public notice references categories and the full per-tool list lives in the ROPA.

Subject rights (Art. 13(2)(b)–(d) / 14(2)(c)–(e))

The notice must list the rights and explain how to exercise each. Six rights apply in some form to every controller: access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20), and objection (Art. 21). The right to withdraw consent is added wherever consent is the basis (Art. 7(3)). The right to lodge a complaint with a supervisory authority is mandatory in every notice. Best practice: a single contact email or form for all requests, with a one-month response window referenced (Art. 12(3)).

9. Layered notices and just-in-time disclosures

Article 12(7) explicitly contemplates standardised icons, and EDPB Guidelines on Transparency endorse layering as a way to balance completeness against readability. The pattern that scales for an SMB is two layers plus targeted just-in-time notices for specific friction points.

Layer 1 — context-specific notice

A short notice next to the form, the call-recording prompt, or the cookie banner. Identifies the controller, the purposes, the lawful basis, and links to the full policy. EDPB Guidelines are explicit that the first layer must contain the information most relevant to the subject in the context — not every Article 13/14 item, but enough that the subject can decide.

Layer 2 — full privacy policy

The full document with all eleven information items. Linked from the footer of every page, the bottom of every form, the confirmation email, and the cookie banner. Versioned with a "last updated" date and a changelog of material changes.

Just-in-time notices

Used wherever processing happens that the subject would not reasonably anticipate from the surrounding context — a call being recorded, a security camera with audio, a profiling decision driving an offer. The just-in-time notice supplements the policy; it does not replace it.

Where layering goes wrong

The most common failure mode is a Layer 1 that says nothing actionable ("we care about your privacy — see our policy for details") and a Layer 2 that has all the information but is unreachable from the form. A well-drafted Layer 1 can be three sentences; the test is whether the subject can answer "who is collecting this and why?" from Layer 1 alone.

11. Penalties under Article 83

Failures of the transparency obligation — Articles 12, 13 and 14 — sit in the higher fining tier under Article 83(5): up to €20 million or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher. This is the same tier as breaches of the lawfulness principles in Article 5 and the rights provisions in Articles 15–22. Notification failures (Art. 33/34) sit in the lower tier — transparency failures do not.

For SMBs the practical risk is rarely a headline fine. It is the compounding administrative findings that follow a missing or generic privacy notice: the supervisory authority opens an investigation, requests the ROPA, finds the lawful basis is not specified per purpose, requests the Data Retention Policy, finds the published retention does not match practice, and issues a corrective order with a deadline and a follow-up audit. By the time the audit closes, the cost of remediation far exceeds the cost of getting the notice right at launch.

Recent EU enforcement against transparency failures has clustered on three fact patterns: privacy policies that do not specify lawful basis per purpose; policies that mention third-country transfers without a mechanism; and policies that have not been updated in years and no longer reflect actual processing. Avoiding all three is mostly a drafting problem, not a compliance-budget problem.