GDPR Articles 13 & 14 — Privacy Notice Requirements: What SaaS Developers Must Disclose at Every Data Collection Point

Post #872 in the sota.io EU Cyber Compliance Series

GDPR Articles 13 and 14 are the transparency spine of the entire Regulation. Every other compliance obligation — lawful basis, data subject rights, DPA processor agreements — depends on data subjects knowing what is happening to their data. Without complete, timely, and accessible disclosures, even technically flawless data processing is unlawful.

The distinction between the two articles is simple but consequential: Article 13 applies when you collect personal data directly from the data subject (signup forms, product usage, support tickets). Article 14 applies when you obtain personal data indirectly — from third parties, from public sources, from business partners who share data with you, or from enrichment providers who layer on additional data.

Most SaaS developers know they need a privacy policy. Far fewer have mapped which processing activities require Art.13 disclosures, which require Art.14 disclosures, and whether their timing compliance holds up to scrutiny.

The Architecture of Transparency: Art.13 vs Art.14

The two articles share the same disclosure items but differ on when disclosure must happen:

Both articles require the same core information, but Art.14 adds one additional item: the categories of personal data obtained (because the controller cannot assume the data subject knows what data was collected about them).

Article 13 — Mandatory Disclosure Items

When you collect personal data directly from a person — through a sign-up form, a cookie, a product interaction, a support email — you must provide the following at the moment of collection:

Group 1: Controller Identity and Contact Details (Art.13(1)(a))

What you must disclose:

• The name and contact details of the data controller
• If you have appointed a Data Protection Officer (DPO), their contact details (Art.13(1)(b))
• If you have a representative in the EU (required for non-EU controllers targeting EU users under Art.3(2)), their contact details (Art.13(1)(a))

SaaS practice note: Many SaaS products buried the controller identity deep in a privacy policy linked from the footer. DPA enforcement treats this as insufficient for collection-point disclosures. The controller identity must be accessible at or before the point of collection — not just somewhere on the website.

The Irish DPC audit framework explicitly checks whether users can identify the controller before submitting a registration form.

Group 2: Purpose and Lawful Basis (Art.13(1)(c))

What you must disclose:

• The purpose(s) for which the personal data are processed
• The legal basis for each purpose

This is where most SaaS products fail. "We use your data to improve our services" is not a purpose. Under EDPB guidance, purposes must be specific, explicit, and legitimate — not generic descriptions that cover every conceivable use.

Correct approach:

Where you rely on legitimate interests as the basis, you must also disclose that (see Art.13(2)(b) below).

Group 3: Legitimate Interests (Art.13(1)(d)) — If Applicable

When you rely on Art.6(1)(f) (legitimate interests) as your lawful basis, you must state what those legitimate interests are. A privacy notice that says "legitimate interests" without explaining what they are fails this requirement.

Example of compliant disclosure: "We process usage data (page views, feature interactions, error logs) to identify usability problems and prioritize development of features that benefit our customers. Our legitimate interest is improving the product; we have assessed this interest as not overriding user privacy because the data is pseudonymised and not used for individual profiling."

Group 4: Recipients (Art.13(1)(e))

What you must disclose:

• The recipients or categories of recipients of the personal data

You do not need to list every sub-processor by name in the privacy notice itself (though your DPA under Art.28 requires this). Categories are sufficient: "cloud infrastructure providers," "analytics platforms," "customer support tooling," "payment processors."

However, where you share data with third-party controllers (not processors acting on your behalf), the distinction matters: they receive data for their own purposes and are themselves responsible for informing data subjects about their processing.

Group 5: Third-Country Transfers (Art.13(1)(f))

What you must disclose:

• If you transfer personal data to a country outside the EEA, the transfer mechanism you rely on and a reference to appropriate safeguards

For transfers to the US:

• If your cloud provider participates in the EU-US Data Privacy Framework (DPF): disclose the DPF adequacy decision
• If you rely on Standard Contractual Clauses (SCCs): reference the SCCs
• If your cloud provider is US-based: you must address this, even if the data is processed on EU servers, because the CLOUD Act creates a legal pathway for US government access that exists independently of where servers are located

The sota.io difference: EU-native hosting eliminates this disclosure category entirely. No US parent company = no CLOUD Act nexus = no transfer safeguard requirement. The controller's privacy notice is simpler and the risk surface is eliminated.

Article 13(2) — Additional Items "Where Applicable"

Beyond the mandatory Group 1-5 items, Art.13(2) requires the following additional information "where applicable":

Retention Period (Art.13(2)(a))

What you must disclose:

• How long personal data will be stored, or if that is not possible, the criteria used to determine the retention period

"We keep data for as long as necessary" fails this requirement. You must either state a concrete period (e.g., "account data is deleted 90 days after account closure") or explain the criteria that drive the determination (e.g., "data is retained for the duration of the contractual relationship plus 3 years for legal claims limitation purposes").

Practical approach for SaaS:

Data Subject Rights (Art.13(2)(b))

What you must disclose:

• The right of access (Art.15)
• The right to rectification (Art.16)
• The right to erasure (Art.17)
• The right to restriction of processing (Art.18)
• The right to data portability (Art.20) — where applicable
• The right to object (Art.21) — where applicable

For rights that are subject to conditions (portability only applies to processing based on consent or contract; objection is absolute for direct marketing), the notice should reflect those conditions accurately.

The right to withdraw consent (Art.13(2)(c)): If you rely on consent as a lawful basis, you must specifically inform users that they can withdraw consent at any time, and that withdrawal does not affect the lawfulness of processing before withdrawal.

The right to lodge a complaint (Art.13(2)(d)): You must inform data subjects of their right to complain to a supervisory authority. Best practice is to name the lead supervisory authority (determined by your main establishment or, for non-EU controllers, the SA in the member state where users are targeted).

Right to Object and Automated Decision-Making (Art.13(2)(e)(f))

What you must disclose:

• If you use automated decision-making, including profiling, under Art.22: the fact of such processing, the logic involved, and the significance and envisaged consequences for the data subject
• This applies to credit scoring, risk assessment, content personalization that produces legal or similarly significant effects, and algorithmic filtering

For most SaaS products, Art.22 does not apply because automated decisions do not produce legal or similarly significant effects. But AI-powered products — credit assessment, insurance underwriting, hiring tools, fraud scoring — must carefully evaluate whether their automation falls within Art.22.

Article 14 — Indirect Data Collection

Article 14 covers the scenario where you did not collect the data directly from the person. This is increasingly common in SaaS through:

• Lead enrichment: You obtained an email from a prospecting tool (Apollo.io, ZoomInfo, LinkedIn Sales Navigator) and enriched it with company, role, and contact data
• Partner data sharing: A business partner sends you their customer list for co-marketing
• Purchased lists: You buy an email list for outreach
• Public sources: You scraped LinkedIn, government registries, or business directories
• Referral chains: A user refers a friend and provides their email before the friend has interacted with your service

Art.14's Additional Item: Categories of Personal Data

Art.14(1)(d) requires disclosure of the categories of personal data obtained. This item does not appear in Art.13 because when data is collected directly, the data subject knows what they provided. When data is obtained indirectly, they do not.

This means an Art.14 notice must list the data categories (email address, job title, company name, inferred demographics) rather than just the purposes and bases.

Art.14 Timing Requirements

The timing rule for Art.14 is more complex than Art.13's "at collection":

Under Art.14(3), disclosure must occur within:

1. One month of obtaining the personal data, OR
2. At first communication with the data subject (if you contact them), whichever is earliest, OR
3. Before disclosure to another recipient, if you plan to share the data

The "one month" rule applies even if you never contact the data subject. If you build a prospect list from enrichment data and then decide not to reach out, you still owe an Art.14 notice within one month of compiling the list.

The operational challenge: Automating Art.14 notices at scale is technically possible but rarely implemented correctly. A common violation pattern: prospecting tools export hundreds of contacts, a sales team imports them into a CRM, and no Art.14 notice is ever sent before the first cold email — which is itself supposed to contain the Art.14 disclosure.

Art.14(5) — The Exception That Swallows B2B Prospecting

Art.14(5)(b) creates a significant exception: Art.14 disclosure is not required if providing the information would involve disproportionate effort, particularly for processing for statistical purposes or research purposes, or if the obligation is likely to render impossible or seriously impair the achievement of the objectives of processing, provided that appropriate safeguards are in place.

However, the EDPB position (Guidelines on Transparency, WP260 rev.01) explicitly states that B2B marketing prospecting does not qualify for this exception. The "disproportionate effort" threshold applies to situations like population registries or historical archives where individual contact is genuinely impractical — not to commercial prospecting.

This means most B2B cold email campaigns built on enrichment data require Art.14 notices either within the first contact or within one month, whichever comes first. The practical implementation is including an Art.14 disclosure paragraph in cold outreach emails.

Layered Notice Strategy

The EDPB Guidelines on Transparency (WP260 rev.01) endorse a layered approach to privacy notices that accommodates the Art.13/14 timing requirements without overwhelming users:

Layer 1 — Just-in-Time Notice (at collection point):

• Controller identity
• Purpose and legal basis
• Link to full privacy policy

This is the checkbox text, tooltip, or inline disclosure at the moment of data collection. It must be specific to the processing being triggered — not a generic "by using this service you accept our privacy policy."

Layer 2 — Full Privacy Policy:

• All Art.13(1) and Art.13(2) mandatory items
• All Art.14 items for indirect data sources
• Data subject rights in detail
• Retention periods by data category
• Sub-processor list (by category)
• Transfer mechanisms

Layer 3 — DPA (Art.28 Agreement):

• Technical and organisational measures
• Sub-processor list (specific names)
• Processor obligations and controller instructions

This separation means users are not overwhelmed at the point of collection, but have access to full disclosure on demand. Supervisory authorities accept layered notices provided Layer 1 is genuinely informative — not just a link.

Common Art.13/14 Violations in SaaS Products

1. Purpose Descriptions That Are Not Purposes

Non-compliant: "We use your data to provide and improve our services." Compliant: "We process your email address and name to create your account and authenticate you (Art.6(1)(b) — contract performance). We process pseudonymised usage events to measure feature adoption and identify usability issues (Art.6(1)(f) — legitimate interests: product improvement)."

The CNIL (French DPA) has issued enforcement action specifically against "vague and generic purpose descriptions" in cases involving Clearview AI and multiple French publishers.

2. Missing Legal Basis

Many privacy notices describe processing activities without stating the legal basis. Art.13(1)(c) requires both purpose AND basis. "We use your email for marketing" without stating the basis is incomplete.

3. No Mention of Data Subject Rights

A privacy policy that describes what data is collected but contains no section on how to exercise rights (access, erasure, portability, objection, complaint to SA) fails Art.13(2)(b), (c), and (d).

4. Retention Periods Missing or Vague

"We keep data for as long as necessary to provide the service" does not satisfy Art.13(2)(a). The EDPB expects either a concrete duration or specific criteria that produce a deterministic period.

5. Transfer Disclosures That Do Not Match Reality

Privacy notices frequently list EU/EEA sub-processors only, when the actual infrastructure includes US-based sub-processors (AWS us-east-1, Google Cloud us-central1). This mismatch between notice and practice is a frequent finding in DPA audits, particularly post-Schrems II.

6. Art.14 Notice Never Sent for Enrichment Data

Sales teams using Apollo.io, ZoomInfo, or similar enrichment tools are processing personal data obtained from third parties. Art.14 requires a notice within one month or before first contact. Most cold email campaigns do not include Art.14 disclosures, creating systematic non-compliance across B2B SaaS marketing functions.

Implementation Checklist

For Art.13 (Direct Collection)

□ Controller name and contact details at each collection touchpoint
□ DPO contact details (if DPO appointed — see Art.37)
□ EU representative contact (if non-EU controller targeting EU users)
□ Specific purpose for THIS collection event (not generic)
□ Legal basis for THIS purpose
□ If legitimate interests: description of those interests
□ Categories of recipients (by category, not necessarily by name)
□ Third-country transfer mechanism (if applicable)
□ Retention period OR criteria
□ Link to full privacy notice containing all Art.13(2) items
□ Right to withdraw consent (if consent-based processing)
□ Right to lodge complaint with SA
□ Whether data is subject to automated decision-making (Art.22)

For Art.14 (Indirect Collection)

□ All items above PLUS:
□ Categories of personal data obtained (not just purposes)
□ Source of the data (or that it came from publicly available sources)
□ Notice sent within 1 month OR at first contact, whichever is earlier
□ Assessment: does the Art.14(5)(b) exception genuinely apply?
□ If prospecting: Art.14 disclosure included in first outreach

Privacy Notice Structure Check

□ Layer 1: Just-in-time disclosure at each collection point
□ Layer 2: Full privacy policy accessible from Layer 1 link
□ Layer 3: DPA/processor agreement with sub-processor details
□ Privacy policy version history maintained (with dates)
□ Mechanism for re-notification on material changes

Python Implementation: Privacy Notice Completeness Checker

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class ProcessingActivity:
    name: str
    data_categories: list[str]
    purpose: str
    legal_basis: str
    recipients: list[str]
    retention_period: str
    third_country_transfer: Optional[str] = None
    legitimate_interests_description: Optional[str] = None
    is_automated_decision: bool = False

@dataclass
class PrivacyNotice:
    controller_name: str
    controller_contact: str
    dpo_contact: Optional[str] = None
    eu_representative: Optional[str] = None
    activities: list[ProcessingActivity] = field(default_factory=list)
    includes_rights_section: bool = False
    includes_sa_complaint_right: bool = False
    includes_withdrawal_right: bool = False  # Required if any consent-based processing

def check_art13_completeness(notice: PrivacyNotice) -> dict:
    issues = []

    if not notice.controller_name or not notice.controller_contact:
        issues.append("FAIL: Art.13(1)(a) — Controller identity or contact missing")

    for activity in notice.activities:
        if not activity.purpose or len(activity.purpose) < 20:
            issues.append(f"FAIL: Art.13(1)(c) — Purpose too vague for '{activity.name}'")
        if not activity.legal_basis:
            issues.append(f"FAIL: Art.13(1)(c) — Legal basis missing for '{activity.name}'")
        if activity.legal_basis == "legitimate interests" and not activity.legitimate_interests_description:
            issues.append(f"FAIL: Art.13(1)(d) — LI description missing for '{activity.name}'")
        if not activity.retention_period or activity.retention_period in ["as long as necessary", "indefinitely"]:
            issues.append(f"FAIL: Art.13(2)(a) — Retention period vague for '{activity.name}'")
        if activity.third_country_transfer and "mechanism" not in activity.third_country_transfer.lower():
            issues.append(f"WARN: Art.13(1)(f) — Transfer mechanism not specified for '{activity.name}'")

    consent_activities = [a for a in notice.activities if "consent" in a.legal_basis.lower()]
    if consent_activities and not notice.includes_withdrawal_right:
        issues.append("FAIL: Art.13(2)(c) — Withdrawal right not disclosed for consent-based activities")

    if not notice.includes_rights_section:
        issues.append("FAIL: Art.13(2)(b) — Data subject rights section missing")
    if not notice.includes_sa_complaint_right:
        issues.append("FAIL: Art.13(2)(d) — Right to complain to SA not disclosed")

    automated = [a for a in notice.activities if a.is_automated_decision]
    for a in automated:
        issues.append(f"REVIEW: Art.13(2)(f) — Automated decision logic must be disclosed for '{a.name}'")

    return {
        "compliant": len([i for i in issues if i.startswith("FAIL")]) == 0,
        "issues": issues,
        "activities_checked": len(notice.activities),
    }

# Example usage
notice = PrivacyNotice(
    controller_name="Acme SaaS GmbH",
    controller_contact="privacy@acme.io",
    dpo_contact="dpo@acme.io",
    activities=[
        ProcessingActivity(
            name="Account registration",
            data_categories=["email", "name", "password_hash"],
            purpose="Create and authenticate user account to deliver the contracted SaaS service",
            legal_basis="contract (Art.6(1)(b))",
            recipients=["cloud infrastructure provider (EU-hosted)"],
            retention_period="Account active period plus 90 days post-closure",
        ),
        ProcessingActivity(
            name="Product usage analytics",
            data_categories=["pseudonymised user id", "feature interactions", "session duration"],
            purpose="Measure feature adoption to prioritise product development and identify usability issues",
            legal_basis="legitimate interests",
            legitimate_interests_description="Improving product quality; pseudonymised data; no individual profiling",
            recipients=["analytics sub-processor (EU)"],
            retention_period="24 months in pseudonymised form",
        ),
    ],
    includes_rights_section=True,
    includes_sa_complaint_right=True,
)

result = check_art13_completeness(notice)
print(f"Compliant: {result['compliant']}")
for issue in result['issues']:
    print(f"  {issue}")

Enforcement Context

The CNIL imposed a €150,000 fine on a French operator in 2023 for inadequate transparency in cookie consent flows — specifically, the notice did not explain the purpose with sufficient specificity and the retention period was missing. The CNIL called this an Art.13 violation rather than an ePrivacy one, establishing that transparency obligations are enforced even in contexts where ePrivacy also applies.

The Austrian DSB found in 2024 that a SaaS product's privacy notice failed Art.13(1)(c) because its purpose descriptions were "circular" — "we use data to provide the service" was treated as inadequate without specifying which processing activities were necessary for which aspects of service delivery.

The German DPAs (conference of Landesdatenschutzbehörden) issued a joint position in 2025 that Art.14 notices in cold B2B marketing must be included in the first contact email, not relegated to a subsequent follow-up or link to a privacy policy.

How EU-Native Hosting Simplifies Art.13/14 Compliance

Every third-country transfer disclosed under Art.13(1)(f) or Art.14(1)(f) adds compliance surface:

• You must identify the mechanism (SCCs, DPF, BCRs)
• You must verify the mechanism is still valid (post-Schrems II invalidation precedent)
• You must update the notice if the mechanism changes or is challenged
• You must explain this to data subjects in a way they can understand

EU-native infrastructure eliminates this entirely. A SaaS product hosted exclusively on EU servers, with EU-based sub-processors and no US parent company, has no Art.46 transfer mechanism to document. The Art.13/14 privacy notice is materially shorter and simpler — and one less thing to update when the US legal landscape changes.

Key Takeaways

1. Art.13 is triggered at every data collection point, not just at account registration. Each form, cookie, API call, and tracking pixel is a separate collection event that requires at-collection disclosure.

2. Art.14 applies to enrichment and prospecting workflows that most B2B SaaS marketing teams run without transparency notices. The Art.14(5)(b) exception does not cover commercial prospecting.

3. Purpose descriptions must be specific: "to improve our services" is not a purpose. Each processing activity needs a distinct, explicit, legitimate purpose statement.

4. Retention periods must be concrete or criteria-based: vague language fails Art.13(2)(a) regardless of what DPAs have previously accepted.

5. The layered notice approach is EDPB-endorsed and the only practical way to provide just-in-time disclosure without overwhelming users.

6. Art.22 automated decision-making requires special disclosure wherever algorithms produce legal or similarly significant effects on data subjects — increasingly relevant for AI-powered SaaS.