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

To comply with the article 14: information to be provided where personal data have not been obtained from the data subject requirement, you must proactively give individuals a privacy notice when you collect their personal data from another source (not from them). Operationally, this means mapping “indirect collection” sources, defining triggers and timelines, and producing auditable proof that the right notice content reached the right population. (Regulation (EU) 2016/679, Article 14)

Key takeaways:

• Article 14 is a controller transparency duty that activates on indirect collection. (Regulation (EU) 2016/679, Article 14)
• Execution hinges on a reliable trigger mechanism tied to onboarding, enrichment, acquisition, and data sharing flows.
• Keep evidence that you decided applicability, sent the notice, and managed exceptions with approvals.

Article 14 exists for a common operational reality: you often process personal data you did not receive directly from the individual. Think lead lists purchased from a third party, employer-provided employee data for benefits administration, credit/identity checks, data broker enrichment, referrals, M&A data ingestion, or contact data obtained from partners. In those cases, GDPR expects the controller to inform the individual rather than letting processing happen “in the dark.” (Regulation (EU) 2016/679, Article 14)

Compliance leaders usually struggle with Article 14 for two reasons. First, “indirect collection” happens across many systems and teams (marketing ops, sales ops, product, HR, security, finance), so the obligation gets lost between process steps. Second, even when a privacy notice exists, the organization cannot prove which individuals received which notice and when. Regulators and auditors test operational execution, not whether a policy statement exists.

This page translates Article 14 into a control you can run: determine scope and role, define triggers, standardize notice content, automate delivery where possible, and retain evidence packets that stand up in audits and customer diligence.

Requirement: Article 14 (indirect collection notice)

Plain-English interpretation
If your organization (as a controller) obtains personal data from someone other than the individual, you must provide the individual with required information about the processing. The practical expectation is simple: the person should not be surprised to learn you hold or use their data, and they should know how to exercise their rights. (Regulation (EU) 2016/679, Article 14)

Who it applies to (entity and operational context)

Applies to:

• Controllers that collect personal data indirectly (from a third party or another source) and then process it for their purposes. (Regulation (EU) 2016/679, Article 14)

Common operational contexts where Article 14 triggers:

• Third-party list acquisition (marketing leads, prospecting databases)
• Partner/referral programs where a partner provides contact data
• Data enrichment and identity verification where you append attributes from external sources
• M&A / asset purchase where you ingest customer/employee datasets
• Employer/plan sponsor feeds for benefits, payroll, or platform access
• Public sources intake (professional directories, public registers) when used to create a record for outreach or other processing

Role reality check (controller vs. processor):

• Article 14 is written as a controller obligation. If you act purely as a processor, your customer (the controller) typically carries the transparency duty.
• In practice, many third parties are “processor in contract, controller in fact” for some uses (analytics improvement, fraud detection, cross-customer benchmarking). Treat role determination as a gating step and document it.

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 translation:
You need an operating procedure that (1) detects when personal data enters your environment from a non-data-subject source, (2) identifies the affected individuals, and (3) issues the correct Article 14 notice content through a reliable channel, with retained proof. (Regulation (EU) 2016/679, Article 14)

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

Step 1: Build an “indirect collection” inventory tied to systems

Create a register of every processing activity where the source is not the individual. Minimum fields:

• Data source type (third party, affiliate, public source, acquired entity)
• Source name and contract owner
• Data categories (contact info, identifiers, employment, etc.)
• Purpose(s) for processing
• Systems of record and downstream recipients
• Controller/processor role determination for the activity (documented)

Why auditors care: without this, you cannot prove completeness. The inventory is your scoping evidence for Article 14. (Regulation (EU) 2016/679, Article 14)

Step 2: Define “trigger events” and embed them in workflows

Operationalize Article 14 with explicit triggers. Typical triggers:

• New third-party dataset onboarded
• New integration that imports contact/identity data
• New enrichment provider turned on for an existing dataset
• New acquisition data migration
• New internal use case that repurposes indirectly collected data

Implementation pattern:

• Add a mandatory check in your third-party intake / procurement workflow: “Will this involve personal data not obtained from the data subject?” If yes, route to privacy for Article 14 notice planning and sign-off.
• Add a mandatory check in your data engineering change process: “Does this pipeline ingest externally sourced personal data?” If yes, require an Article 14 control ticket.

Step 3: Standardize notice content and localize by use case

Create an Article 14 notice template that can be parameterized by:

• Business unit (HR, marketing, fraud, finance)
• Data source category (partner, broker, employer feed, acquisition)
• Channel (email, in-product message, postal mail, web notice)

Keep it modular so teams don’t rewrite legal text per project. Maintain version control.

Step 4: Decide delivery channels and prove delivery

Pick a delivery channel that matches how you can reliably reach the person:

• Email notice to the address obtained indirectly (common for leads and B2B contacts)
• In-app / portal notice at first account activation (common for employer-fed users)
• Letter notice when you only have postal address
• Notice at first communication (“first touch”) when you cannot reasonably notify earlier

Evidence expectation: logs that show who was sent which version of the notice and when.

Step 5: Handle exceptions with a documented decision record

Article 14 contains exceptions in the full text, but this page will not restate or paraphrase them without your internal legal review against the full article. Use a structured exception record whenever you do not provide notice:

• Claimed exception basis (refer to the full GDPR text for exact language) (Regulation (EU) 2016/679)
• Factual justification
• Approver (privacy/legal)
• Compensating controls (e.g., public notice, layered notice at first interaction)
• Reassessment date/event

Do not allow informal “we think it’s exempt” decisions in email threads. Auditors will ask for a clear rationale trail.

Step 6: Operational monitoring and periodic testing

Run recurring checks:

• Sampling test: pick indirectly sourced records and verify notice evidence exists
• Drift detection: new data sources added without a privacy review
• Bounce/undeliverable handling: track failure rates and alternate delivery paths

Step 7: Package evidence for audits and customer diligence

Create an “evidence packet” per indirect collection source:

• Source onboarding record (contract + data source description)
• Role and scope decision (controller/processor and in-scope systems)
• Approved notice content (versioned)
• Delivery proof (send logs, screenshots, system records)
• Exceptions and approvals
• Remediation tickets (if notice gaps discovered)

This matches what external auditors and enterprise customers typically request during GDPR due diligence.

Required evidence and artifacts to retain (audit-ready list)

• Role-and-scope register for Article 14 applicability across activities and systems
• Operating procedure with owners, triggers, and approval points
• Notice templates with version control and change history
• Distribution logs (who, when, which notice version, channel)
• Exception decision records with approvals and compensating controls
• Testing results (sampling, monitoring reports, remediation outcomes)

If you run your GRC program in Daydream, treat these as the standard evidence objects tied to each indirect collection processing activity so you can answer diligence requests without rebuilding history from scratch.

Common exam/audit questions and hangups

Auditors and regulators tend to focus on:

• “Show me your list of indirect data sources and the related processing activities.” (Regulation (EU) 2016/679, Article 14)
• “How do you ensure new third-party data feeds trigger an Article 14 review?”
• “Provide evidence that individuals were informed, not just that a privacy notice exists.”
• “How do you manage acquisitions or one-time data loads?”
• “What is your documented rationale for cases where notice was not provided?” (Regulation (EU) 2016/679)

Hangup to expect: teams confuse Article 13 (direct collection) and Article 14 (indirect collection). Your controls should route to the correct workflow based on data source.

Frequent implementation mistakes and how to avoid them

1. Mistake: One generic privacy policy and no delivery proof
   Fix: implement per-source notice triggers and retain delivery logs tied to individuals.

2. Mistake: Assuming procurement review covers everything
   Fix: add triggers in data engineering, marketing ops tooling, and M&A playbooks. Indirect collection often bypasses procurement (e.g., a team exports contacts from a partner portal).

3. Mistake: Unclear controller/processor role per use case
   Fix: require a written role determination in the role-and-scope register before processing begins.

4. Mistake: Exceptions handled informally
   Fix: use an exception template with privacy/legal approval and store it with the evidence packet.

Enforcement context and risk implications

No public enforcement case sources were provided in your source catalog, so this page does not list specific regulator decisions.

Risk to communicate internally:

• Article 14 failures are typically discovered through complaints, data subject access requests, or audits where the organization cannot explain how an individual would have been informed.
• The operational impact is often broader than the notice itself: a missing Article 14 workflow also signals weak data lineage, poor third-party data governance, and uncontrolled data sourcing.

Practical execution plan (30/60/90-day)

You asked for speed. Use phases rather than time-bound guarantees.

Next 30 days (Immediate triage)

• Assign an owner (privacy ops or GRC) and publish an Article 14 operating procedure draft. (Regulation (EU) 2016/679, Article 14)
• Identify your highest-risk indirect sources (data brokers, enrichment, acquisitions, partner feeds) and build the first version of the indirect collection inventory.
• Create an Article 14 notice template and approval workflow.

Next 60 days (Embed controls)

• Implement triggers in procurement and third-party onboarding.
• Implement triggers in data engineering change management and integration reviews.
• Stand up delivery evidence capture (email platform logs, in-product notice event logging, CRM tagging).

Next 90 days (Assurance and scale)

• Run a sampling audit across indirectly sourced records; open remediation tickets for gaps.
• Formalize exception handling with a standard decision record and approval routing.
• Operationalize reporting: new indirect sources added, notices sent, exceptions granted, and unresolved gaps.

Frequently Asked Questions

Does Article 14 apply if we get contact data from a business partner for referrals?

Yes, if you are a controller and the personal data was not obtained from the individual, you should plan for an Article 14 notice workflow tied to that referral intake. Document the source, trigger, and delivery proof. (Regulation (EU) 2016/679, Article 14)

We only have a work email from a third-party list. Is emailing the notice acceptable?

Email is often the most practical channel when email is the only reliable identifier you have. Your control should retain evidence that the email was sent and which notice version was used.

Do we need a separate notice for every third-party source?

You need complete information delivered to the data subject for the processing. Most teams use one template with source-specific fields and versioning so changes remain controlled and auditable. (Regulation (EU) 2016/679, Article 14)

How do we handle M&A data migrations where we ingest a large dataset at once?

Treat the acquisition as a distinct indirect source with its own evidence packet: scope, notice content, delivery plan, and exceptions if you cannot reach certain individuals. Keep decision records for any non-notification paths. (Regulation (EU) 2016/679)

What evidence is most persuasive in an audit?

Auditors typically accept system-generated logs that tie an individual identifier to a timestamp and a notice version, plus approvals for the template and exceptions. Screenshots alone are weak unless backed by immutable logs.

Our contract says we are a processor. Do we still need Article 14 controls?

If you truly act only on the controller’s documented instructions, the controller generally owns transparency. If you determine purposes for any processing, reassess role and document it; Article 14 may apply to those controller activities. (Regulation (EU) 2016/679, Article 14)