Dear EPDP Team, During the upcoming EPDP Team meeting, León will present the questions the Legal Committee has thus far agreed to send to outside counsel. As a reminder, the Legal Committee has been reviewing draft legal questions related to an SSAD that were submitted by members of the EPDP Team. Please note the Legal Committee is still in the process of reviewing several questions, including an anchor question related to contracted party liability. The text of the additional questions will be forthcoming. The below text has been reviewed, edited, and agreed to by a representative group of EPDP Team Members, and, as such, EPDP Leadership would ask the EPDP Team to review the questions with a level of deference and apply the “cannot live with” standard when reviewing the below text. Thank you. Best regards, Marika, Berry, and Caitlin -- 1. To what extent, if any, are contracted parties liable when a third party that accesses non-public WHOIS data under an accreditation scheme where by the accessor is accredited for the stated purpose, commits to certain reasonable safeguards similar to a code of conduct regarding use of the data, but misrepresents their intended purposes for processing such data, and subsequently processes it in a manner inconsistent with the stated purpose. Under such circumstances, if there is possibility of liability to contracted parties, are there steps that can be taken to mitigate or reduce the risk of liability to the contracted parties? 2. Assuming that there is a policy that allows accredited parties to access non-public WHOIS data through an SSAD (and requires the accredited party to commit to certain reasonable safeguards similar to a code of conduct), is it legally permissible under Article 6(1)(f) to: · define specific categories of requests from accredited parties (e.g. rapid response to a malware attack or contacting a non-responsive IP infringer), for which there can be automated submissions for non-public WHOIS data, without having to manually verify the qualifications of the accredited parties for each individual disclosure request, and/or · enable automated disclosures of such data, without requiring a manual review by the controller or processor of each individual disclosure request. In addition, if it is not possible to automate any of these steps, please provide any guidance for how to perform the balancing test under Article 6(1)(f). For reference, please refer to the following potential safeguards: · Disclosure is required under CP’s contract with ICANN (resulting from Phase 2 EPDP policy). · CP’s contract with ICANN requires CP to notify the data subject of the purposes for which, and types of entities by which, personal data may be processed. CP is required to notify data subject of this with the opportunity to opt out before the data subject enters into the registration agreement with the CP, and again annually via the ICANN-required registration data accuracy reminder. CP has done so. · ICANN or its designee has validated the requestor’s identity, and required that the requestor: o represents that it has a lawful basis for requesting and processing the data, o provides its lawful basis, o represents that it is requesting only the data necessary for its purpose, o agrees to process the data in accordance with GDPR, and o agrees to standard contractual clauses for the data transfer. · ICANN or its designee logs requests for non-public registration data, regularly audits these logs, takes compliance action against suspected abuse, and makes these logs available upon request by the data subject. In light of the 3 May 2019 correspondence from the European Commission [icann.org], are any updates on the previous memo on 6(1)(b) necessary?