Article 13: Information to be provided where personal data are collected from the data subject
GDPR Article 13 requires you, as a controller collecting personal data directly from the individual, to provide specific privacy information at the moment you collect the data (or before). Operationalize it by mapping every collection channel to an approved notice, embedding just-in-time disclosures into forms and flows, and retaining versioned evidence of what was shown, when, and to whom. (Regulation (EU) 2016/679, Article 13)
Key takeaways:
- You need an Article 13 notice for each direct collection context, delivered at collection time. (Regulation (EU) 2016/679, Article 13)
- “One privacy policy” rarely covers all channels; use layered + just-in-time notices tied to data intake points.
- Evidence matters: keep notice versions, deployment dates, and screenshots/logs that prove the notice was presented.
Article 13 is the GDPR’s “front door” transparency requirement for situations where the data subject gives you their data directly. If you collect personal data through a signup form, checkout, mobile app screen, lead-gen page, support intake, recruiting portal, or in-product telemetry prompts that ask the user for information, Article 13 is the rule that sets what you must tell them and when you must tell it. The timing requirement is the operational trap: the information must be provided “at the time when personal data are obtained.” (Regulation (EU) 2016/679, Article 13)
Compliance teams typically fail Article 13 in predictable ways: the notice exists but is not delivered in-channel; different products and regions show different text without governance; or the business cannot prove what notice a user saw on a given date. A workable program treats Article 13 like a release-managed control: defined triggers, approved content blocks, implementation patterns for each channel, and auditable evidence.
This page translates Article 13 into an operator checklist you can deploy across web, mobile, product, and offline collection. It also covers the artifacts auditors ask for and the handoffs you need between Legal/Privacy, Product, Marketing, HR, Security, and Engineering.
Regulatory text
Requirement (excerpt): “Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:” (Regulation (EU) 2016/679, Article 13)
Operator meaning: If you collect personal data directly from an individual (not via a broker or another controller), you must deliver an Article 13-compliant privacy notice at the point of collection (or before the user submits). Your control objective is twofold: (1) the right information is presented in the right channel at the right time, and (2) you can prove it happened for each collection surface. (Regulation (EU) 2016/679, Article 13)
Plain-English interpretation
Article 13 is the “tell people what you’re doing with their data” rule for direct collection. Practically, that means every time your organization asks a person for personal data, the person must be shown clear privacy information as part of the experience, not buried somewhere unrelated. The disclosure needs to be consistent, current, and tied to the actual processing that collection initiates. (Regulation (EU) 2016/679, Article 13)
This is not a “write a policy once” requirement. It is an operational requirement across intake workflows. Your success metric is coverage of all data collection touchpoints, with controlled content and provable delivery. (Regulation (EU) 2016/679, Article 13)
Who it applies to
Entity scope
- Controllers collecting personal data from data subjects. Article 13 assigns the obligation to the controller. (Regulation (EU) 2016/679, Article 13)
- Processors are in scope operationally because product and service teams that act as processors often run collection surfaces on behalf of controllers. Even if the legal duty sits with the controller, you still need an internal method to ensure the controller’s notice content is implemented where your service collects data.
Operational contexts (common triggers)
Treat these as “Article 13 trigger events” that require a notice review and placement decision:
- Web forms (signup, newsletter, demos, contact-us, gated content)
- Ecommerce checkout and account creation
- Mobile app onboarding and profile screens
- In-product “tell us about you” prompts and surveys
- Customer support intake (ticket forms, chat pre-forms, call scripts that collect identifiers)
- HR and recruiting (candidate portals, referrals, background check initiation)
- Events (badge scans, attendee lists, raffles)
- Offline collection (paper forms, in-store kiosks)
What you actually need to do (step-by-step)
1) Decide role and scope for each product/service line
Create a short, durable record of whether each collection context is performed as controller, joint controller, or processor, and what that means for notice ownership and approvals. This prevents teams from shipping forms without clear accountability.
Minimum output:
- Role decision per processing activity and surface
- Systems and owners
- Data categories collected and purpose summary
Daydream tip: track this as a role-and-scope register that connects intake surfaces to processing activities so you can spot gaps during releases and M&A.
2) Inventory every place you collect data from the person
Build a “collection surface inventory.” If you miss a surface, you miss compliance.
Do it like an operator:
- Start from traffic: marketing site, product UI, mobile screens, support portals, HR tools
- Add “shadow intake”: spreadsheets, email aliases, sales enablement tools, event tools
- For each surface, record: URL/screen, what fields are collected, whether optional/required, region/audience, and which privacy notice is displayed today (if any)
3) Define the Article 13 notice content model (layered + just-in-time)
Most organizations need two layers:
- Layer 1 (just-in-time): short disclosure placed at the field/form/screen, with key points and a link.
- Layer 2 (full notice): a full privacy notice page that contains the complete Article 13 disclosures.
Your operating requirement: ensure the user can access the required information at collection time in that context, in language that matches the audience and channel. (Regulation (EU) 2016/679, Article 13)
Implementation pattern examples
- Web lead form: a short statement under the submit button with a link to the full notice.
- Mobile: a “Privacy” link plus an expandable panel before “Create account.”
- Offline/paper: a printed short notice with a URL/QR code to the full notice.
4) Map each collection surface to an approved notice and verify timing
For each surface, answer three audit-grade questions:
- What notice is shown?
- Exactly when is it shown (before submission)?
- Does it match the actual processing that starts after submission?
If a surface collects data for a new purpose, routes data to a new third party, or changes retention, treat it as an Article 13 update trigger and route through privacy review.
5) Implement release governance so notices stay correct
Build a lightweight control that blocks releases that introduce new collection or new uses without updating notices.
A workable workflow
- Product/Marketing submits a “data collection change” ticket
- Privacy approves notice text or confirms no change
- Engineering implements using approved UI components
- QA verifies placement and link resolution
- Compliance archives evidence packet (see below)
Daydream tip: make this part of your intake/change management so teams answer the same questions every time, with named owners and approvals.
6) Establish an evidence-backed monitoring routine
You do not need perfection on day one; you need continuous detection of drift.
- Periodically re-scan high-risk surfaces (top funnels, onboarding, checkout, support, recruiting)
- Spot-check regional variants and A/B tests
- Review third-party forms embedded on your site (marketing tools, chat widgets). They can silently change UI and remove disclosures.
Required evidence and artifacts to retain
Auditors and regulators usually test “show me” rather than “tell me.” Keep an evidence packet per major surface or per release train.
Evidence checklist (practical minimum)
- Collection surface inventory (current state + owner)
- Role-and-scope register entries for the related processing activities
- Approved notice text (short + full) with version history and effective dates
- Screenshots or screen recordings showing the notice at collection time (pre-submit)
- Links to the full notice that resolve correctly (including mobile deep links)
- Change tickets showing privacy review/approval and implementation confirmation
- Exception log: any surfaces pending remediation, with dates, risk acceptance, and fix plan
Common exam/audit questions and hangups
- “Show me all places you collect personal data directly from individuals, including marketing, product, HR, and support.”
- “Prove the notice is provided at the time of collection, not only in a footer.”
- “Which notice version applied on a specific past date?”
- “How do you govern A/B tests and localized variants so required text is not removed?”
- “How do you ensure embedded third-party tools (chat, forms) maintain the disclosure?”
Hangup to expect: teams can produce a privacy policy, but cannot demonstrate channel-level delivery and versioned evidence.
Frequent implementation mistakes (and how to avoid them)
-
Mistake: treating the website privacy policy as sufficient for every collection.
Fix: require a just-in-time disclosure on the actual form or screen, with a link to the full notice. -
Mistake: missing “non-obvious” intake points (support, recruiting, events).
Fix: inventory by business function, not by system. Make leaders attest that all collection paths are listed. -
Mistake: no proof of what users saw.
Fix: archive screenshots per release and keep a notice version register with effective dates. -
Mistake: decentralizing notice edits with no governance.
Fix: control edits through a single approval workflow; ship notices as governed components rather than free-text fields in random tools. -
Mistake: role confusion (controller vs processor).
Fix: keep a role-and-scope register and make it the first step in any new collection initiative.
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for this page. The practical risk remains clear: Article 13 failures are easy to verify because the evidence is on the screen. If a regulator, customer, or litigant can reproduce a collection flow that lacks the required disclosures at collection time, you lose the defensibility you would otherwise have from internal policies. (Regulation (EU) 2016/679, Article 13)
Practical 30/60/90-day execution plan
First 30 days (stabilize and find gaps)
- Appoint a single owner for Article 13 operational compliance (often Privacy Ops or GRC).
- Build the collection surface inventory across Marketing, Product, Support, and HR.
- Stand up the role-and-scope register for the top products and business lines.
- Identify the highest-risk/highest-volume collection flows and add just-in-time disclosures where missing.
- Start an evidence repository structure (by surface, by release, with versioned notice text).
Days 31–60 (standardize and govern)
- Create approved notice templates (short + full) and a translation/localization workflow.
- Implement reusable UI components for just-in-time disclosures in web and mobile.
- Embed privacy review into change management for new forms, new fields, or new purposes.
- Add QA checks to release criteria: disclosure presence, link works, correct notice version.
Days 61–90 (prove and monitor)
- Run a formal internal audit: pick representative flows and produce evidence packets end-to-end.
- Add monitoring: periodic spot checks of top surfaces, including third-party embedded forms.
- Establish an exception process for legacy systems, with documented compensating controls and remediation tracking.
- Use Daydream to keep the inventory, approvals, and evidence packets tied together so you can answer “what did the user see?” without manual archaeology.
Frequently Asked Questions
Do we need to show the full privacy notice on the form itself?
You need to provide the required information at the time you obtain the data. A common operational pattern is a short just-in-time notice on the form plus a link to the full notice that contains the complete disclosures. (Regulation (EU) 2016/679, Article 13)
Does Article 13 apply to existing customers when we add a new profile field?
Yes, if you collect additional personal data directly from the person through a new field or screen, you should ensure Article 13 information is presented in that updated collection context at the time of collection. (Regulation (EU) 2016/679, Article 13)
What about data collected by a third-party form embedded on our site?
If you are the controller for that collection, you remain responsible for providing the Article 13 information at collection time even if a third party supplies the widget. Contractual controls help, but you still need to verify the user-facing experience and keep evidence. (Regulation (EU) 2016/679, Article 13)
Can we rely on a footer link to the privacy policy?
A footer link often fails the “at the time when personal data are obtained” expectation in practice because it is not clearly tied to the collection action. Place a disclosure at the point of submission or data entry and link to the full notice from there. (Regulation (EU) 2016/679, Article 13)
How do we handle A/B tests that change the signup flow?
Treat A/B tests as production releases. Require privacy review of variants that add fields, change purposes, or modify UI around notices, and archive screenshots of each variant’s notice placement.
What evidence should we keep for audits?
Keep versioned notice text, approval records, and screenshots (or recordings) showing the notice displayed before data submission for each major collection surface. Also retain an inventory that proves you didn’t miss channels.
Frequently Asked Questions
Do we need to show the full privacy notice on the form itself?
You need to provide the required information at the time you obtain the data. A common operational pattern is a short just-in-time notice on the form plus a link to the full notice that contains the complete disclosures. (Regulation (EU) 2016/679, Article 13)
Does Article 13 apply to existing customers when we add a new profile field?
Yes, if you collect additional personal data directly from the person through a new field or screen, you should ensure Article 13 information is presented in that updated collection context at the time of collection. (Regulation (EU) 2016/679, Article 13)
What about data collected by a third-party form embedded on our site?
If you are the controller for that collection, you remain responsible for providing the Article 13 information at collection time even if a third party supplies the widget. Contractual controls help, but you still need to verify the user-facing experience and keep evidence. (Regulation (EU) 2016/679, Article 13)
Can we rely on a footer link to the privacy policy?
A footer link often fails the “at the time when personal data are obtained” expectation in practice because it is not clearly tied to the collection action. Place a disclosure at the point of submission or data entry and link to the full notice from there. (Regulation (EU) 2016/679, Article 13)
How do we handle A/B tests that change the signup flow?
Treat A/B tests as production releases. Require privacy review of variants that add fields, change purposes, or modify UI around notices, and archive screenshots of each variant’s notice placement.
What evidence should we keep for audits?
Keep versioned notice text, approval records, and screenshots (or recordings) showing the notice displayed before data submission for each major collection surface. Also retain an inventory that proves you didn’t miss channels.
Authoritative Sources
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream