Who tells people when a recipient obtains their data?

Name the controller and the actual receipt event

A receiving team often inherits a delivery date without inheriting a workable transparency plan. Identify who determines the receiving purpose and means, which personal data they obtain, and when that happens. A record batch, a changed purpose and an onward disclosure may create different questions. Have the controller’s privacy owner establish the applicable obligations rather than assigning every task to whichever person operates the transfer.

Article 14 addresses personal data not obtained from the individual. Its information includes the controller, purposes and basis, relevant categories and recipients, retention, rights, source and other applicable items. The WP29 transparency guidelines expressly discuss indirect sources including brokers and public material. A source being public does not by itself resolve the recipient’s transparency obligation.

Make the plan specific to the recipient’s processing. A supplier’s notice may be useful evidence, but ask whether people already have the required information about this recipient and use. Keep the answer and supporting material in the file. Do not quietly substitute a commercial warranty for that factual examination.

Work the timing from the earliest applicable event

Under Article 14(3), information is due within a reasonable period and no later than one month after obtaining the data; first communication with the person or first envisaged disclosure to another recipient can bring that deadline forward. The guidelines explain that these earlier events shorten the general maximum rather than extending it. One month is not a generic thirty-day timer.

Hypothetical example: controller C receives a batch on 10 October 2026. It plans its first communication with a person on 18 October and its first onward disclosure on 15 October. Its calendar-month maximum would be 10 November, but its plan needs to address the earlier 15 October disclosure. The following register is deliberately complete enough to reveal the release dependency, while leaving the legal conclusion to the responsible reviewer.

An exception needs its own evidence

Article 14(5) contains defined exceptions, with conditions that differ. The guidelines caution against routinely relying on disproportionate effort outside the specified archiving, research and statistical context. A large batch, a missing email address or an expensive workflow is not a completed exception assessment. If a reviewer considers an exception, record the precise provision, the actual impediment, relevant safeguards and the evidence supporting that conclusion.

A useful exception file has a decision maker and a review trigger. For example, if a claimed inability to identify a contact route changes when a new source arrives, the earlier reasoning may need to be reopened. If the controller relies on the person already having the information, retain the actual version and coverage analysis; a screenshot of an unrelated privacy policy cannot answer who knew what.

Use the rights review tool to identify missing evidence and the due diligence tool to ask the receiving party who owns this plan. Keep permission for a named introduction, permission for a sample and permission for the receiving processing distinct. VOID’s referral service does not replace the recipient’s controller duties. This guide is an EU transparency planning aid, not a determination of GDPR applicability, a complete notice template, an exception approval or an international transfer assessment.