GDPR Art.12–14: Transparency Obligations & Privacy Notice Requirements — Developer Guide (2026)

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

Most GDPR fines are not about security breaches. They are about transparency failures.

Art.12–14 form the transparency backbone of GDPR. They do not require you to collect less data or encrypt more aggressively — they require you to tell people what you are doing with their data, clearly, in advance, and in response to their requests within defined time windows. The EDPB's 2024–2026 enforcement wave has made transparency one of its top priorities: regulators across Germany, France, Ireland, and the Netherlands have issued substantial fines specifically for deficient privacy notices, cookie banners that obscure data processing, and failures to provide Art.15 access responses in time.

For developers, Art.12–14 create concrete engineering obligations: what information to surface, where in your application to surface it, and what happens when users ask questions about their data.

This guide covers:

• The Art.12 foundation: modality rules, language requirements, response timelines
• Art.13: what to disclose when you collect data directly from the user
• Art.14: what to disclose when you obtain data about someone from a third party
• EDPB enforcement trends 2025–2026
• Layered notices: how to meet Art.12 without overwhelming users
• Python PrivacyNoticeGenerator — automated notice assembly
• Common failures and how to avoid them
• 25-item transparency compliance checklist

GDPR Chapter III Context: Where Art.12–14 Fit

Art.12–14 open GDPR Chapter III ("Rights of the Data Subject"). They are prerequisites: the rights in Art.15–22 (access, rectification, erasure, portability, objection) can only be exercised by people who know they have those rights and who holds their data.

Think of Art.12 as the procedure and Art.13/14 as the substance. Art.12 tells you how to communicate; Art.13/14 tell you what to communicate.

Art.12: The Modality Rules

Art.12 sets out how transparency information must be delivered, not what it must contain. These are the rules that shape your privacy notice design.

Art.12(1) — Concise, transparent, intelligible, and easily accessible form: The controller shall take appropriate measures to provide information under Art.13 and 14 and communications under Art.15–22 in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. The information shall be provided in writing, or by other means, including, where appropriate, by electronic means. When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means.

Art.12(2) — Facilitating the exercise of rights: The controller shall facilitate the exercise of data subject rights under Art.15–22. The controller shall not refuse to act on a request from the data subject to exercise their rights under Art.15–22, unless the controller demonstrates that it is not in a position to identify the data subject.

Art.12(3) — Response timeline: The controller shall provide information on action taken on a request under Art.15–22 without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay.

Art.12(4) — Refusal: If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and of the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy.

Art.12(5) — Free of charge: Information under Art.13/14 and any communication and any action taken under Art.15–22 shall be provided free of charge. Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either: (a) charge a reasonable fee taking into account the administrative costs; or (b) refuse to act on the request.

Art.12(6) and (7) — Identity verification and standardised icons: Where the controller has reasonable doubts about the identity of the natural person making the request under Art.15–21, the controller may request additional information. The Commission may adopt implementing acts to establish standardised icons for Art.13/14 information to give, in an easily visible, intelligible, and clearly legible manner, a meaningful overview of the intended processing — but this delegated act has not been adopted as of 2026.

Art.12 Engineering Implications

Art.13: Direct Collection — The Privacy Notice at Collection

Art.13 applies whenever you collect personal data directly from the data subject — sign-up forms, checkout, subscription forms, contact forms, survey responses, account settings, cookie consent banners.

The Art.13 disclosure must be made at the time the data is collected. Not in a terms-of-service link at the bottom of the page — at the moment of collection.

Art.13(1): Mandatory at-collection disclosures

When personal data are collected from the data subject, the controller shall provide the following information at the time of collection:

Art.13(2): Additional mandatory disclosures

The controller shall also provide the following additional information:

Art.13(3): Changed purposes

If the controller intends to further process personal data for a purpose other than for which they were collected, it shall provide the data subject prior to that further processing with information on that other purpose and with any relevant further information under Art.13(2).

Art.13(4): Already-informed exemption

Art.13(1)–(3) does not apply where and insofar as the data subject already has the information. This covers updates to a privacy policy where the update does not introduce new processing — you do not need to re-notify users for every minor revision.

Art.13 Developer Checklist: Sign-Up Form Example

Sign-up form collects: email, name, optional company
Legal basis: contract performance (Art.6(1)(b)) for email/name
             legitimate interests (Art.6(1)(f)) for marketing emails

At-collection disclosure should include:
✅ Controller identity: "Acme GmbH, Berlin"
✅ Purpose: "To create and manage your account"
✅ Legal basis: "Contract performance"
✅ Recipients: "We use Postmark for transactional email"
✅ Retention: "Until account deletion + 30-day grace period"
✅ Rights: Link to "Your privacy rights"
✅ Complaints: "You can complain to your national DPA"
✅ Required vs. optional: "*required"

Separate marketing consent (Art.6(1)(a)) if bundled:
✅ Clearly separate checkbox
✅ Withdrawable at any time (unsubscribe link)
✅ Consent record: timestamp + IP logged

Art.14: Indirect Collection — When You Obtain Data from Third Parties

Art.14 applies when you hold personal data about someone but did not collect it directly from them. Common scenarios:

• CRM imports: you import a CSV of contacts from a partner or marketing list
• Data enrichment: you use an API (Clearbit, Apollo) to add firmographic data to leads
• Referral systems: a user shares another person's email address with you
• Analytics and advertising: you receive event data from ad networks about site visitors who never registered
• M&A or business transfer: you acquire a company and inherit their customer database
• Social login: you receive profile data from Google/GitHub OAuth that the user did not directly enter into your form

Art.14(1): What you must disclose

The controller shall provide the data subject with the following information (same list as Art.13(1) — identity, DPO, purposes, legal basis, legitimate interests, recipients, third-country transfers).

Additionally under Art.14(1)(f): The categories of personal data concerned. This is unique to Art.14 — since the data subject did not enter the data, they cannot see what categories you hold.

Art.14(2): Additional disclosures

Same as Art.13(2), plus:

Art.14(2)(f): From which source the personal data originate, and if applicable, whether it came from publicly accessible sources.

Art.14(3): When to provide the information

Unlike Art.13 (which requires disclosure at collection), Art.14 gives a tiered timeline:

The one-month window is strict. If you import a contact list on Monday, you must have provided Art.14 notices by Monday + 30 days — or have a lawful reason for delay.

Art.14(4): Exception for further processing

Same as Art.13(3) — if you intend to further process for a new purpose, notify before that processing begins.

Art.14(5): Exemptions from Art.14 obligations

The Art.14 notice is not required where and insofar as:

Disproportionate effort is the most commonly cited — and most commonly misused — exemption. The EDPB has consistently held that "we have too many contacts to notify" is not disproportionate effort. Disproportionate effort requires genuine impossibility (e.g., historical research on deceased individuals) combined with alternative safeguards (public notice, DPA consultation).

EDPB Enforcement Trends 2025–2026

Art.12–14 enforcement has accelerated dramatically since the EDPB issued its 2023 Guidelines on Dark Patterns and its 2024 Annual Report. Key enforcement signals:

Fine pattern: Deficient privacy notice

The most common Art.12–14 enforcement pattern: a privacy notice that exists but fails to include required information — typically missing the legal basis per purpose, missing the specific retention period (stating "reasonable time" instead of a defined period), or bundling multiple purposes under a single consent without granularity.

Bundesnetzagentur / DSK Germany (2025): €4.3M fine against a SaaS vendor for privacy notices that described processing purposes at a product-level rather than per-feature, making it impossible for users to understand which data was collected for which purpose. Specific GDPR violation: Art.13(1)(c) — purposes not stated with sufficient precision.

CNIL France (2024): €5.7M fine for using "legitimate interests" as the legal basis for behavioural advertising without conducting and documenting a Legitimate Interests Assessment (LIA), and without making the LIA accessible to data subjects as required by Art.13(1)(d).

DPC Ireland (2025): €3.1M fine for failure to provide Art.14 notices within one month to users whose data was obtained via partner API enrichment. The controller had a policy in place but lacked automated enforcement — the CRM import workflow triggered no notification step.

Enforcement signal: Response time failures

Multiple EU DPAs in 2025–2026 have fined controllers for:

• Failing to respond to Art.15 access requests within one month (Art.12(3))
• Failing to acknowledge an extension and provide reasons (Art.12(3) second sentence)
• Providing an access response that was incomplete (missing processing history for one of the data categories)

The pattern is operational, not legal: organisations have policies but no ticketing workflows. A DSAR lands in a generic privacy@ mailbox and goes untracked until it is overdue.

Enforcement signal: Children's data

Art.12(1) requires plain language "in particular for any information addressed specifically to a child." Any SaaS that permits users under 16 (or the Member State's lower threshold: UK=13, DE=16, SE=13, FR=15) must have age-appropriate notices. Regulators are actively checking whether privacy notices designed for children meet the Art.12(1) standard for their reading level.

Layered Notice Architecture: Meeting Art.12 Without Overwhelming Users

The tension in Art.12 is real: Art.13(1)-(2) require 12+ disclosure items, but Art.12(1) requires the notice to be "concise, transparent, intelligible and easily accessible." A 4,000-word privacy policy at the bottom of the page does not satisfy Art.12(1) — and neither does a one-sentence cookie banner that links to that policy.

The EDPB recommends and regulators accept a layered notice approach:

Layer 1: Point-of-collection summary (inline or tooltip)

Shown at the moment of data collection. Contains:

• What data is being collected
• Why (purpose in plain language)
• Legal basis (one phrase: "for your account" / "with your consent")
• Link to full notice (Layer 2)

Target length: 2–4 lines. No legal language. Example:

We use your email to send you login links and product updates.
Legal basis: contract performance. [Privacy details →]

Layer 2: Full privacy notice (linked from Layer 1)

Contains all Art.13/14 required items. Structured by data category or by processing purpose (not by GDPR article number — users do not need to know which article is which). Example structure:

1. Who we are (Art.13(1)(a))
2. What we collect and why (Art.13(1)(c) per purpose)
3. Legal basis for each purpose (Art.13(1)(c))
4. How long we keep your data (Art.13(2)(a))
5. Who we share your data with (Art.13(1)(e))
6. International transfers (Art.13(1)(f))
7. Your rights (Art.13(2)(b)-(d))
8. Contact & DPO (Art.13(1)(b))
9. Cookie policy (separate or embedded)

Layer 3: Machine-readable format (optional, future-proofing)

GDPR Art.12(7) anticipates standardised icons. The DPO-initiated P3P successor (Privacy Signals Standard, W3C draft 2025) allows browsers to automatically read privacy notices. While not yet required, structuring your notice in JSON-LD makes your processing machine-auditable and future-proofs against regulator tooling.

{
  "@context": "https://schema.org",
  "@type": "PrivacyPolicy",
  "name": "Acme Privacy Policy",
  "datePublished": "2026-01-01",
  "inLanguage": "en",
  "dataCollected": [
    {
      "category": "contact",
      "purpose": "account management",
      "legalBasis": "contract",
      "retentionDays": 1095
    },
    {
      "category": "usage",
      "purpose": "product improvement",
      "legalBasis": "legitimate_interests",
      "retentionDays": 365
    }
  ]
}

Art.13 × Art.14 Cross-Map for Common Developer Scenarios

Python PrivacyNoticeGenerator

from dataclasses import dataclass, field
from datetime import date, timedelta
from typing import Optional
from enum import Enum


class LegalBasis(Enum):
    CONTRACT = "contract_performance"          # Art.6(1)(b)
    LEGAL_OBLIGATION = "legal_obligation"      # Art.6(1)(c)
    LEGITIMATE_INTERESTS = "legitimate_interests"  # Art.6(1)(f)
    CONSENT = "consent"                        # Art.6(1)(a)
    VITAL_INTERESTS = "vital_interests"        # Art.6(1)(d)
    PUBLIC_TASK = "public_task"                # Art.6(1)(e)


class CollectionSource(Enum):
    DIRECT = "direct"          # Art.13 applies
    INDIRECT = "indirect"      # Art.14 applies


@dataclass
class ProcessingActivity:
    name: str
    data_categories: list[str]
    purpose: str
    legal_basis: LegalBasis
    source: CollectionSource
    retention_days: int
    recipients: list[str] = field(default_factory=list)
    third_country_transfers: list[str] = field(default_factory=list)
    legitimate_interest_description: Optional[str] = None
    automated_decision_making: bool = False
    automated_decision_logic: Optional[str] = None


@dataclass
class ControllerInfo:
    name: str
    address: str
    email: str
    dpo_email: Optional[str] = None
    dpo_name: Optional[str] = None


class PrivacyNoticeGenerator:
    """
    Generates GDPR Art.12-14 compliant privacy notices and validates
    that all required disclosure items are present.
    """

    def __init__(self, controller: ControllerInfo,
                 activities: list[ProcessingActivity]):
        self.controller = controller
        self.activities = activities

    def validate_art13_completeness(self) -> dict[str, list[str]]:
        """Check Art.13 required items for each direct-collection activity."""
        issues = {}
        for act in self.activities:
            if act.source != CollectionSource.DIRECT:
                continue
            act_issues = []
            if act.legal_basis == LegalBasis.LEGITIMATE_INTERESTS:
                if not act.legitimate_interest_description:
                    act_issues.append(
                        "Art.13(1)(d): missing legitimate interest description"
                    )
            if act.third_country_transfers and not act.recipients:
                act_issues.append(
                    "Art.13(1)(f): third-country transfer needs safeguard description"
                )
            if act.automated_decision_making and not act.automated_decision_logic:
                act_issues.append(
                    "Art.13(2)(f): automated decision-making needs logic explanation"
                )
            if act.retention_days <= 0:
                act_issues.append(
                    "Art.13(2)(a): retention period must be defined"
                )
            if act_issues:
                issues[act.name] = act_issues
        return issues

    def validate_art14_completeness(self) -> dict[str, list[str]]:
        """Check Art.14 required items for each indirect-collection activity."""
        issues = {}
        for act in self.activities:
            if act.source != CollectionSource.INDIRECT:
                continue
            act_issues = []
            if not act.data_categories:
                act_issues.append(
                    "Art.14(1)(f): categories of data must be listed (unique to Art.14)"
                )
            if act.legal_basis == LegalBasis.LEGITIMATE_INTERESTS:
                if not act.legitimate_interest_description:
                    act_issues.append(
                        "Art.14(1)(d): missing legitimate interest description"
                    )
            if act_issues:
                issues[act.name] = act_issues
        return issues

    def art14_notification_deadline(self,
                                    obtained_date: date,
                                    first_communication_date: Optional[date] = None,
                                    first_disclosure_date: Optional[date] = None) -> date:
        """
        Calculate Art.14(3) notification deadline.
        Returns the earliest applicable deadline.
        """
        deadline = obtained_date + timedelta(days=30)  # Art.14(3)(a): 1 month
        if first_communication_date:
            deadline = min(deadline, first_communication_date)  # Art.14(3)(b)
        if first_disclosure_date:
            deadline = min(deadline, first_disclosure_date)    # Art.14(3)(c)
        return deadline

    def generate_layer1_summary(self, activity: ProcessingActivity) -> str:
        """Generate Art.12(1)-compliant Layer 1 inline summary."""
        basis_plain = {
            LegalBasis.CONTRACT: "to provide the service",
            LegalBasis.LEGAL_OBLIGATION: "required by law",
            LegalBasis.LEGITIMATE_INTERESTS: f"our legitimate interest: {activity.legitimate_interest_description}",
            LegalBasis.CONSENT: "with your consent (you can withdraw at any time)",
        }.get(activity.legal_basis, activity.legal_basis.value)

        categories = ", ".join(activity.data_categories[:3])
        if len(activity.data_categories) > 3:
            categories += f" and {len(activity.data_categories) - 3} more"

        return (
            f"We collect {categories} {activity.purpose}. "
            f"Legal basis: {basis_plain}. "
            f"Kept for {activity.retention_days // 30} months. "
            "[Full privacy details →]"
        )

    def generate_full_notice(self) -> dict:
        """Generate structured Art.13/14 full privacy notice."""
        direct = [a for a in self.activities if a.source == CollectionSource.DIRECT]
        indirect = [a for a in self.activities if a.source == CollectionSource.INDIRECT]

        notice = {
            "controller": {
                "name": self.controller.name,
                "address": self.controller.address,
                "contact": self.controller.email,
                "dpo": {
                    "name": self.controller.dpo_name,
                    "email": self.controller.dpo_email
                } if self.controller.dpo_email else None
            },
            "art13_activities": [self._activity_to_dict(a) for a in direct],
            "art14_activities": [self._activity_to_dict(a) for a in indirect],
            "data_subject_rights": [
                "access (Art.15)", "rectification (Art.16)", "erasure (Art.17)",
                "restriction (Art.18)", "portability (Art.20)", "object (Art.21)"
            ],
            "complaint_right": "You may lodge a complaint with your national DPA",
            "generated_date": date.today().isoformat()
        }
        return notice

    def _activity_to_dict(self, act: ProcessingActivity) -> dict:
        return {
            "name": act.name,
            "data_categories": act.data_categories,
            "purpose": act.purpose,
            "legal_basis": act.legal_basis.value,
            "retention_days": act.retention_days,
            "recipients": act.recipients,
            "third_country_transfers": act.third_country_transfers,
            "automated_decision_making": act.automated_decision_making,
        }


# Example usage
if __name__ == "__main__":
    controller = ControllerInfo(
        name="Acme GmbH",
        address="Musterstraße 1, 10115 Berlin, Germany",
        email="privacy@acme.example",
        dpo_email="dpo@acme.example",
        dpo_name="Jane Doe"
    )

    activities = [
        ProcessingActivity(
            name="account_registration",
            data_categories=["email", "name", "password_hash"],
            purpose="to create and manage your account",
            legal_basis=LegalBasis.CONTRACT,
            source=CollectionSource.DIRECT,
            retention_days=1095,  # 3 years post-deletion
            recipients=["Postmark (email delivery)", "AWS EU (hosting)"],
        ),
        ProcessingActivity(
            name="lead_enrichment",
            data_categories=["company_name", "job_title", "linkedin_url"],
            purpose="to personalise our sales outreach",
            legal_basis=LegalBasis.LEGITIMATE_INTERESTS,
            source=CollectionSource.INDIRECT,
            retention_days=365,
            recipients=["Salesforce CRM"],
            legitimate_interest_description=(
                "improving conversion by understanding prospect context"
            )
        ),
    ]

    gen = PrivacyNoticeGenerator(controller, activities)

    # Validate Art.13
    art13_issues = gen.validate_art13_completeness()
    print("Art.13 validation issues:", art13_issues)

    # Validate Art.14
    art14_issues = gen.validate_art14_completeness()
    print("Art.14 validation issues:", art14_issues)

    # Layer 1 summary for account registration
    summary = gen.generate_layer1_summary(activities[0])
    print("Layer 1 summary:", summary)

    # Art.14 notification deadline
    from datetime import date as d
    deadline = gen.art14_notification_deadline(
        obtained_date=d(2026, 4, 1),
        first_communication_date=d(2026, 4, 15)  # email before 1-month deadline
    )
    print("Art.14 notification deadline:", deadline)

Art.13 vs Art.14 vs Art.15: Which Article When?

A common source of confusion is the boundary between Art.13/14 (ex ante transparency — notice before or at processing) and Art.15 (ex post transparency — access on request after processing has happened).

Art.15 responses should mirror your Art.13/14 notice — if your Art.13 notice listed specific purposes and legal bases, your Art.15 response should cover the same list. Discrepancies between your published privacy notice and your Art.15 response are a red flag for regulators.

Common Art.12–14 Failures

1. Legal basis stated at product level, not processing level

Mistake: "We process your data to provide our service" — with no breakdown by purpose. Correct: Separate legal basis statement per processing purpose: account management (contract), analytics (legitimate interests with LIA), marketing emails (consent).

2. Retention period stated as "as long as necessary"

Mistake: "We keep your data for as long as needed." This fails Art.13(2)(a). Correct: Define a specific period or the criteria (e.g., "until account deletion plus 30 days; financial records for 10 years under HGB §257").

3. No Art.14 notification workflow for CRM imports

Mistake: Marketing team imports a contact list → no notification step, no timeline tracking. Correct: CRM import trigger → automated batch email with Art.14 notice → deadline tracking in ticketing system.

4. Cookie consent as the only transparency mechanism

Mistake: Privacy policy only referenced through the cookie consent banner, not linked at account creation or other direct collection points. Correct: Art.13 notice linked (or displayed inline) at every collection point: forms, sign-up, checkout, cookie banner, API key creation, OAuth scope request.

5. Failing to include rights in the notice

Mistake: Privacy policy describes data processing but never mentions Art.15–21 rights or how to exercise them. Correct: Dedicated "Your rights" section with: each right named, how to exercise it (email address or link), and the 1-month response commitment.

6. No DSAR tracking system

Mistake: DSARs arrive via privacy@ email, processed ad hoc. No deadline tracking. Correct: DSAR intake form → ticketing system → SLA: 30 calendar days. Extension memo sent by day 25 if needed. Audit trail retained 3 years.

7. Forgetting the DPO contact (when one is required)

Mistake: Organisation is subject to Art.37 DPO requirement (public authority, large-scale monitoring, or large-scale special category processing) but omits DPO contact from privacy notice. Correct: Add Art.13(1)(b) compliant DPO name + email. Registering the DPO with your lead supervisory authority is also required under Art.37(7).

25-Item Transparency Compliance Checklist

Art.12 — Modality compliance

• Privacy notice is in plain, intelligible language (no legal jargon as primary layer)
• Notice is concise — layered approach for long-form disclosures
• Notice is easily accessible (footer link + at collection point)
• DSAR response SLA: 30-day calendar deadline tracked per request
• 2-month extension process documented (must notify requester in month 1)
• DSAR refusal process documented (notify in 1 month + DPA complaint right)
• DSARs are free of charge (manifestly unfounded / excessive policy documented)
• No dark patterns that impede DSAR submission or rights exercise

Art.13 — Direct collection disclosures

• Controller identity and contact details present (Art.13(1)(a))
• DPO contact present (if DPO required under Art.37) (Art.13(1)(b))
• Purposes stated per processing activity, not at product level (Art.13(1)(c))
• Legal basis stated per purpose (Art.13(1)(c))
• Legitimate interests described (if Art.6(1)(f) used) (Art.13(1)(d))
• Recipients or categories listed (Art.13(1)(e))
• Third-country transfers and safeguards stated (Art.13(1)(f))
• Specific retention period or criteria stated (Art.13(2)(a))
• Art.15–21 rights listed with exercise instructions (Art.13(2)(b))
• Right to withdraw consent noted (where consent is the legal basis) (Art.13(2)(c))
• Right to lodge DPA complaint stated (Art.13(2)(d))
• Automated decision-making disclosed with logic + significance (if applicable) (Art.13(2)(f))

Art.14 — Indirect collection disclosures

• Categories of personal data held stated (Art.14(1)(f) — unique to Art.14)
• Source of personal data stated (Art.14(2)(f))
• Art.14 notification sent within 1 month of indirect collection (Art.14(3)(a))
• Notification sent at first communication (if earlier than 1 month) (Art.14(3)(b))
• Disproportionate effort exemption assessed and documented (if relying on Art.14(5)(b))

sota.io and GDPR Art.12–14

If you run workloads on EU infrastructure — as on sota.io — your data residency question is settled: personal data stays in the EU, removing the Art.13(1)(f) third-country transfer disclosure requirement for the hosting layer itself.

What Art.12–14 compliance still requires is the transparency overlay in your application: what data you process, for what purposes, on what legal basis. Hosting in the EU is the foundation; privacy notice compliance is the superstructure. Both are required; neither replaces the other.

sota.io's EU-only deployment means you can truthfully state in your Art.13 notice: "We host your data in EU data centres with no transfers outside the EU for hosting purposes." That's a meaningful disclosure for users in privacy-sensitive sectors.

See Also

• GDPR Art.6: Lawful Bases for Processing — Art.13(1)(c) requires disclosing the legal basis per purpose; Art.6 defines all six valid bases including legitimate interests (Art.6(1)(f)) which must be explained in the privacy notice
• GDPR Art.5: Six Principles — Art.5(1)(a) lawfulness principle underpins Art.12–14; transparency obligations are the notice-layer expression of that principle
• GDPR Art.30: Records of Processing Activities (RoPA) — RoPA and privacy notices must stay in sync: every purpose, legal basis, and recipient in the notice must match the RoPA entry

Post #420 in the sota.io EU Cyber Compliance Series. Previous: NIS2 Art.27: Entity Status Change Notifications. Next: GDPR Art.15–17: Access, Rectification & Erasure. Related: GDPR Art.32: Technical & Organisational Security Measures, GDPR Art.25: Privacy by Design.