Article 14: Information to be provided where personal data have not been obtained from the data subject

GDPR Article 14 requires you, as a controller, to proactively give a privacy notice to people when you obtained their personal data from somewhere else (not from them), and to include specific details about what you collected, why, the legal basis, who you share with, and where you got the data. Your fastest path to compliance is to map “indirect collection” data flows, define notice triggers, and implement a repeatable notice-and-exceptions process. (Regulation (EU) 2016/679, Article 14)

Key takeaways:

• Article 14 is about indirect collection and mandatory transparency content, not consent. (Regulation (EU) 2016/679, Article 14)
• You need an operational trigger tied to intake events (data broker file, partner feed, scraped/public source, M&A list migration, referrals). (Regulation (EU) 2016/679, Article 14)
• Build an evidence packet: data source records, notice templates, delivery logs, and exception decisions with approvals. (Regulation (EU) 2016/679, Article 14)

Article 14 is the GDPR’s “you didn’t get it from me” transparency requirement. If your organization receives personal data from a third party, buys a list, enriches records, imports contacts after an acquisition, pulls data from public sources, or otherwise collects personal data without interacting with the individual first, Article 14 is the rule that tells you what information you must provide to that individual. (Regulation (EU) 2016/679, Article 14)

For a Compliance Officer, CCO, or GRC lead, the problem is rarely drafting a privacy notice. The problem is operational: identifying which processing activities are “indirect collection,” setting the trigger for when notice must be provided, coordinating between business teams that acquire the data and the teams that can actually deliver notice, and tracking exceptions in a way that survives audit and regulator scrutiny. (Regulation (EU) 2016/679, Article 14)

This page is written to help you implement Article 14 as a control: defined scope, named owners, concrete workflow steps, and evidence you can produce on demand. It avoids legal theory and focuses on what you have to build so the requirement runs continuously, even as new third parties, new data sources, and new products appear. (Regulation (EU) 2016/679, Article 14)

Regulatory text

Excerpt (provided): “Where personal data have not been obtained from the data subject, the controller shall provide the data subject with the following information:” (Regulation (EU) 2016/679, Article 14)

Operator interpretation: if your systems ingest personal data from a source other than the individual, you must have a mechanism to (a) detect that event, (b) provide the required notice content to the individual, and (c) prove you did it or document a defensible exception. The control objective is repeatable transparency for indirect collection, not a one-time privacy policy refresh. (Regulation (EU) 2016/679, Article 14)

Practical note: the excerpt you provided is the opening clause. In implementation, teams typically treat Article 14 as “Article 13-style notice, plus source-of-data disclosure,” triggered by indirect collection. Keep your legal team aligned on the full notice content required under Article 14, then operationalize the trigger, delivery, and logging. (Regulation (EU) 2016/679, Article 14)

Plain-English requirement (what Article 14 is asking for)

You must tell people, within your normal operating workflow, that you have their personal data even though you did not collect it directly from them. Your notice has to be specific enough that a reasonable person can understand what you’re doing with their data and where it came from. (Regulation (EU) 2016/679, Article 14)

Common “Article 14” scenarios:

• You receive leads or contact lists from a channel partner or affiliate.
• You buy marketing lists or data enrichment from a data broker (a third party).
• You import customer or employee data during an acquisition or carve-out.
• You ingest public-source data into a risk, fraud, or due diligence workflow.
• A customer shares their end-user data with you and you act as a controller for part of the processing (role clarity matters). (Regulation (EU) 2016/679, Article 14)

Who it applies to (entity and operational context)

Entities

• Controllers processing personal data covered by the GDPR, when the data were not obtained from the data subject. (Regulation (EU) 2016/679, Article 14)
• Processors are not the direct addressee of Article 14 notices, but processors often run the systems and pipelines that must enable the controller’s compliance. Expect Article 14 duties to show up as contractual requirements and operational tickets. (Regulation (EU) 2016/679)

Operational contexts to scope explicitly

Create a scope statement that lists:

• Which business units can introduce indirect-collection data (Marketing, Sales Ops, Partnerships, Risk/Fraud, HR, Corporate Development).
• Which systems can ingest it (CRM, marketing automation, data warehouse, enrichment tools).
• Which third parties provide it (brokers, affiliates, resellers, data platforms, background check providers). (Regulation (EU) 2016/679, Article 14)

A fast way to make this auditable is a role-and-scope register that names the controller/processor role per activity, data categories, affected systems, and third-party sources. This reduces “we thought we were a processor” confusion during diligence. (Regulation (EU) 2016/679, Article 14)

What you actually need to do (step-by-step)

Step 1: Identify and classify “indirect collection” intake paths

Inventory every intake path where personal data enters without a direct interaction:

• File drops from third parties
• API feeds from partners
• Purchased lists
• Enrichment appended to existing records
• M&A migrations
• Public-source collection (if applicable) (Regulation (EU) 2016/679, Article 14)

Output: a list of intake paths with owners, systems, and data elements.

Step 2: Decide and document your role for each path

For each intake path, record whether you are acting as a controller (or joint controller) for the downstream processing that triggers the notice obligation. If the role differs by use case, split the use case; don’t write one ambiguous entry. (Regulation (EU) 2016/679)

Output: role decision records linked to processing activities and contracts.

Step 3: Define the “trigger event” and workflow owner

Pick a concrete trigger that creates a ticket or automated event, such as:

• “New contact record created with source = partner/broker/public”
• “New dataset onboarded to warehouse from third party”
• “Enrichment vendor appended attributes to existing profiles” (Regulation (EU) 2016/679, Article 14)

Assign an owner for the trigger and for notice delivery (often Privacy Ops, Marketing Ops, or Customer Trust).

Output: an operating procedure with named owners, triggers, and approvals. (Regulation (EU) 2016/679, Article 14)

Step 4: Build the notice content as modular templates

Operationally, templates beat bespoke writing. Maintain:

• A base “Article 14 notice” template
• Variants by product/processing purpose
• A “source-of-data” module that can name categories of sources and, where appropriate, the specific third party source (align with counsel) (Regulation (EU) 2016/679, Article 14)

Output: controlled templates with version history and approval records.

Step 5: Implement delivery and logging

Choose delivery methods that match how you can reach the individual:

• Email to the address received
• In-product message at first login (if you can link identity reliably)
• Physical mail (rare, but sometimes necessary)
• Layered notice via a privacy center plus a direct message pointing to it (Regulation (EU) 2016/679, Article 14)

Then log:

• Which template version was used
• When it was sent/shown
• Which audience segment or individual identifiers were targeted
• Bounce/undeliverable outcomes and retry/alternative steps (Regulation (EU) 2016/679, Article 14)

Output: delivery logs that are exportable for audit.

Step 6: Manage exceptions as a controlled process

Article 14 includes conditions and exceptions in the full text; your implementation must treat exceptions as formal decisions, not informal Slack messages. Put a gate in the workflow:

• Exception request form (why notice can’t or shouldn’t be provided)
• Privacy review and approval
• Documentation of the basis and scope (which dataset, which period, which individuals)
• Reassessment trigger when conditions change (Regulation (EU) 2016/679, Article 14)

Output: exception register with approvals and expiry/reevaluation.

Step 7: Continuously monitor and test

Build recurring checks:

• Sampling: pick recent indirectly sourced records and confirm notices were sent or exceptions documented.
• Drift detection: watch for new “source” values, new third-party connectors, or new acquisition imports. (Regulation (EU) 2016/679, Article 14)

Output: periodic control testing results and remediation tickets.

Required evidence and artifacts to retain

Keep an “Article 14 evidence packet” you can hand to auditors, customers, or regulators:

• Role-and-scope register for indirect collection activities (controller/processor role, systems, data categories). (Regulation (EU) 2016/679, Article 14)
• Operating procedure with triggers, owners, approvals, and exception handling. (Regulation (EU) 2016/679, Article 14)
• Data source records: third-party contracts, data dictionaries, intake specs, and source attribution fields in systems. (Regulation (EU) 2016/679)
• Notice templates with version control and approval history. (Regulation (EU) 2016/679, Article 14)
• Delivery logs and evidence of execution (send logs, in-product event logs, mail vendor confirmations where applicable). (Regulation (EU) 2016/679, Article 14)
• Exception register with rationale and sign-off. (Regulation (EU) 2016/679, Article 14)
• Testing results and remediation records. (Regulation (EU) 2016/679, Article 14)

If you use Daydream to manage third-party risk and due diligence, this requirement maps cleanly into a requirement-specific procedure, an evidence packet workflow, and recurring control attestations so your “we do this” claim is backed by artifacts, not a policy PDF. (Regulation (EU) 2016/679, Article 14)

Common exam/audit questions and hangups

Expect these:

1. “Show us all sources of personal data not obtained directly from individuals.” Auditors look for completeness across business units and shadow tools. (Regulation (EU) 2016/679, Article 14)
2. “How do you know when Article 14 applies?” They want an intake trigger tied to systems, not tribal knowledge. (Regulation (EU) 2016/679, Article 14)
3. “Prove notices were provided for a sample of records.” You need logs that connect record source to notice delivery. (Regulation (EU) 2016/679, Article 14)
4. “How do you handle undeliverable notices?” You need a defined follow-up path, or an exception decision. (Regulation (EU) 2016/679, Article 14)
5. “Where did you get this person’s data?” You must trace provenance to a third party, partner, public source, or internal transfer such as M&A migration. (Regulation (EU) 2016/679, Article 14)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating Article 14 as “we have a privacy policy”	Article 14 is event-driven and record-source-driven	Build intake triggers and delivery logs tied to source attribution. (Regulation (EU) 2016/679, Article 14)
No field for “data source” in core systems	You cannot consistently detect indirect collection	Require source tagging in CRM/warehouse schemas and connector configs. (Regulation (EU) 2016/679, Article 14)
One generic notice for all indirect data	Different purposes and sources need accurate description	Use modular templates with variants per processing purpose and source category. (Regulation (EU) 2016/679, Article 14)
Exceptions handled informally	Exceptions become unprovable during audits	Use an exception register with approval and periodic review. (Regulation (EU) 2016/679, Article 14)
Role confusion (controller vs processor)	The notice duty attaches to controllers	Maintain role decision records per processing activity and keep contracts aligned. (Regulation (EU) 2016/679)

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for this requirement, so this page does not list specific cases. The practical risk remains: Article 14 is a transparency obligation that can surface quickly through complaints (“How did you get my data?”), partner due diligence, or regulator inquiries following broader investigations into marketing practices, enrichment, and data sharing. (Regulation (EU) 2016/679, Article 14)

Operationally, the highest-risk pattern is indirect collection at scale without reliable source attribution and without provable notice delivery. Your control design should assume you will need to reconstruct provenance and notice history for a specific individual on short notice. (Regulation (EU) 2016/679, Article 14)

Practical 30/60/90-day execution plan

First 30 days: get to a defensible baseline

• Name an executive owner (often Privacy Officer/CCO) and an operational owner (Privacy Ops/GRC). (Regulation (EU) 2016/679, Article 14)
• Build the first version of the role-and-scope register focused only on indirect collection paths. (Regulation (EU) 2016/679, Article 14)
• Add or validate a data source attribute in the systems of record (CRM, marketing platform, warehouse ingestion metadata). (Regulation (EU) 2016/679, Article 14)
• Draft the operating procedure: trigger events, approvals, exception intake, and evidence retention. (Regulation (EU) 2016/679, Article 14)

Days 31–60: implement workflow + evidence

• Stand up notice templates and approvals, including a source-of-data module. (Regulation (EU) 2016/679, Article 14)
• Implement at least one automated trigger (for example, new records with non-direct source). (Regulation (EU) 2016/679, Article 14)
• Turn on logging and create an “Article 14 evidence packet” folder structure with required artifacts. (Regulation (EU) 2016/679, Article 14)
• Train the teams that onboard third parties and data feeds (Partnerships, Sales Ops, Marketing Ops, Corp Dev). (Regulation (EU) 2016/679, Article 14)

Days 61–90: validate, close gaps, and make it repeatable

• Run a sample-based test: trace a set of indirectly sourced records from intake to notice to log entry (or exception). (Regulation (EU) 2016/679, Article 14)
• Expand coverage to remaining intake paths and retire manual steps where possible. (Regulation (EU) 2016/679, Article 14)
• Establish ongoing monitoring for new third-party connectors, new list purchases, and M&A migrations. (Regulation (EU) 2016/679, Article 14)
• If you manage compliance evidence in Daydream, configure recurring control attestations and exception workflows so you can produce an audit-ready packet without chasing screenshots. (Regulation (EU) 2016/679, Article 14)

Frequently Asked Questions

Does Article 14 apply if we got the data from a third party, but we never contact the person?

Yes, Article 14 is triggered by indirect collection, not by whether you plan to message the person. You still need an operational decision: deliver notice via available channels or document a valid exception through a controlled process. (Regulation (EU) 2016/679, Article 14)

Is posting a privacy policy on our website enough to satisfy Article 14?

Usually not by itself, because Article 14 is about providing information to the data subject when you did not obtain data from them. You should treat a web notice as a component, then implement triggers and proof of delivery (or exceptions). (Regulation (EU) 2016/679, Article 14)

What systems should be in scope first for Article 14 operationalization?

Start where indirect data lands first and then spreads: CRM, marketing automation, data warehouse ingestion pipelines, and enrichment tools. If you cannot tag and track “source,” you cannot consistently trigger notice or prove compliance. (Regulation (EU) 2016/679, Article 14)

How do we prove compliance during an audit?

Produce your role-and-scope register, operating procedure, approved templates, delivery logs, and an exception register with approvals. Auditors typically ask you to trace a sample record from source to notice evidence. (Regulation (EU) 2016/679, Article 14)

We acquired a company and imported their contacts. Is that “not obtained from the data subject”?

Often, yes in practice, because you received the data through a corporate transaction rather than directly from the individuals. Treat M&A migrations as a defined intake path with a trigger, notice plan, and documented exceptions where needed. (Regulation (EU) 2016/679, Article 14)

What’s the single control that reduces Article 14 risk fastest?

A mandatory “data source” attribute enforced at ingestion, with workflow automation that routes indirectly sourced records into a notice-or-exception process and captures logs. Without source attribution, Article 14 compliance becomes guesswork. (Regulation (EU) 2016/679, Article 14)