| Scope boundary | Storage of information on terminal equipment or access to information already stored there, including non-cookie tracking techniques when the Article 5(3) criteria are met. | Potential online-platform advertising transparency or disclosure work; detailed DSA trigger not stated here because no DSA grounding source was present in the ePrivacy folder. | Run the ePrivacy technical trigger before tags, pixels, SDKs, or identifiers fire. Open a DSA-specific source check for platform ad disclosures instead of using this page as DSA authority. |
|---|
| Covered actors | If consent is required, it must meet GDPR-standard consent quality: freely given, specific, informed, unambiguous, affirmative, demonstrable, and withdrawable as easily as it was given. | A DSA ad disclosure or transparency artifact should not be treated as consent for terminal-equipment storage or access unless a separate ePrivacy consent test is satisfied. | Keep consent buttons, preference centers, and consent logs separate from ad labels, sponsor disclosures, or transparency records, even if they are reviewed in the same launch gate. |
|---|
| Trigger | Third-party advertising cookies and operational advertising cookies are not within the consent exemptions described by WP29; analytics needs a separate purpose and safeguard assessment. | DSA ads work may use the same inventory to understand advertising flows, but this page does not validate DSA-specific repository, targeting, recommender, or platform-category duties. | Reuse the factual inventory, not the legal conclusion. The same tag map can support ePrivacy consent review and a later DSA ads review, but each obligation needs its own source. |
|---|
| Core obligations | Tracker inventory, purpose map, Article 5(3) classification, exemption analysis, consent UX screenshots, CMP settings, consent logs, reject and withdrawal tests, and proof that consent-requiring tools do not fire before consent. | Ad-disclosure screenshots, ad journey facts, sponsor or advertiser fields, targeting or measurement descriptions, and the DSA source used for any platform-specific conclusion once attached. | Label shared records with the obligation they support. An ad journey screenshot may help both teams, but it does not supersede consent logs or a DSA citation. |
|---|
| Evidence record | If the ad stack stores or reads terminal-equipment information and no narrow exemption applies, block the tag until consent is obtained and withdrawal is available. | If the team asserts a DSA ads obligation, require a DSA source in the record before naming the duty, deadline, repository, role, or enforcement path. | Do not merge the sign-off. ePrivacy approves or blocks terminal-equipment access; a DSA review should separately approve source-linked ad transparency. |
|---|
| Timing and deadlines | Set the ePrivacy check before launch, because tags and pixels should not start collecting until the terminal-equipment question and any required consent path have been resolved. | Treat DSA ads timing as a separate workstream that starts only after the relevant DSA source is attached and the platform-duty question is confirmed. | If the tracker can run now, the ePrivacy review comes first; if the disclosure is still hypothetical, park the DSA question for source-based follow-up rather than mixing the two on one deadline. |
|---|
| Enforcement | Use the ePrivacy file to determine whether a tracker may launch at all, and keep the consent evidence ready for audit or complaint review. | Use the DSA file only after a DSA source is attached, so any enforcement or supervisory question is tied to a cited DSA obligation rather than a generic ads label. | The practical question differs: ePrivacy asks whether collection is allowed now, while DSA asks whether the advertising disclosure record is supported by the right source. |
|---|
| Overlap and reuse | Reuse the tracker map, consent records, and screenshots for ePrivacy because they show what runs on the device and whether consent was captured. | Reuse only the same factual inventory for DSA until a DSA source is added; the legal answer and the evidence standard still have to be checked separately. | Shared materials can move between teams, but the legal test does not: facts can be reused, conclusions cannot. |
|---|
| Practical decision rule | If the launch depends on a cookie, pixel, SDK, or identifier touching terminal equipment, make the ePrivacy call first. | If the remaining question is ads disclosure on an online-platform workflow, send it to DSA review only after a DSA source is in the file. | Start with the rule that can actually be proved from the record. Here, that is ePrivacy; DSA stays a follow-up unless the source set changes. |
|---|