Dear EPDP Team, Following up on an action item from today’s call, please find the questions recently sent to the outside legal counsel: Registration Data Redaction from Public Whois Database - City Name of the Registered Name Holder 1a. Is the data provided by the Registered Name Holder for the “City” field in the RNH’s address personal data? To what extent is there a risk under GDPR that the publication and/or disclosure of the RNH-identified “City” could result in inadvertent disclosure of personal data (which may affect the the policy of whether it should be redacted from the data that is made publicly available in Whois), or contribute to making the Registered Name Holder more identifiable? Please note that the EPDP is considering a recommendation to allow the publication of the City, State/Province and Country, while redacting the contact’s name, street address, email address, postal code, telephone number. What are the bases in the GDPR, its official advisories and interpretations, and in practices similar to our own for making such a determination? 1b. If the city field is personal data and therefore must be redacted, is there a lawful basis under Art. 6(1)f for publishing a subset of the data submitted by the registered name holder that includes the city name, where the legitimate interest is that those pursuing legal claims can determine jurisdictional issues prior to asserting the claim where that interest overcomes the rights of all registrants in not having their personal data published. (This proposed legitimate interest was gleaned from the transcript in Toronto.) GDPR Data Accuracy Requirement 2. Some EPDP Team members cite Art. 5.1(d) of GDPR as a requirement for the EPDP Team to examine how accuracy is currently defined in ICANN’s 2013 Registrar Accreditation Agreement (the contract with registrars) and possibly require changes. Some EPDP Team members cite the accuracy requirement in Art. 5.1(d) GDPR as support for additional accuracy related policies, such as a requirement for registrars to validate the correctness of the data as provided by the data subject or a requirement to validate when the accuracy is being challenged. Others maintain that the Art. 5.1(d) GDPR requirement is to accurately record, maintain and process the data provided by the data subject and to update that information as informed by the data subject. Is the accuracy requirement limited to correction at the request of the data subject or is it a broader requirement? Please advise on how the accuracy requirements of GDPR impact the contracted parties and ICANN. GDPR Reach 3. In light of the EDPB Guidance on territorial scope of GDPR, how do ICANN’s stable establishments within the EU impact its responsibilities as a data controller. The EDPB Guidance appears to suggest that ICANN, as a controller with stable establishments within the EU, might be required to comply with GDPR? Is this the case even if the majority of processing activities (including registrar/reseller collection of data from RNH) take place outside of the EU? . Specifically: Do any of ICANN’s operations within the EU qualify as Establishments, as defined by Recital 22 of the GDPR? If ICANN is found to have Establishments within the EU, do these Establishments require ICANN (as a controller of gTLD Registration Directory Services related processing activities) to be subject to article 3.1 of the GDPR? Do the answers to the above questions impact ICANN’s, and/or any associated controllers’ or processors’, ability to distinguish between Registered Name Holders (RNH)/data subjects based on the geographic location of the RNHs in determining the geographic scope of GDPR? Thank you. Best regards, Marika, Berry, and Caitlin