[Gnso-epdp-legal] ICANN EPDP Questions

[Kurt Pritz]

Hello Ruth: 

I hope you and Gabe are well. Thank you both for the answers to the previous question set, I found them clear and they have been distributed to the full Team and are being used in the formulation of our Final Report. 

Below find three additional questions from the ICANN EPDP Team. If you don’t mind, please review them and come back to us with any questions or uncertainty. If you would, please provide us with an estimated timetable for your responses as we are managing the timing of our final report - day by day. 

We stand by to help in any way, so please let us know if a conference call with the legal team or additional written explanation would be helpful. 

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? Iss 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?
To provide some background for this question, the answer to this question could affect the meaning of the following sections of the Temporary Specification: 

Section 2.1	Registry Operator (except where Registry Operator operates a "thin" registry) and Registrar MUST apply the requirements in Sections 2 and 4 of this Appendix to Personal Data included in Registration Data where:
the Registrar or Registry Operator is established in the European Economic Area (EEA) as provided in Article 3(1) GDPR and Process Personal Data included in Registration Data;
the Registrar or Registry Operator is established outside the EEA and offers registration services to Registered Name Holders located in the EEA as contemplated by Article 3(2) GDPR that involves the Processing of Personal Data from registrants located in the EEA; or
the Registrar or Registry Operator is located outside the EEA and Processes Personal Data included in Registration Data and where the Registry Operator or Registrar engages a Processor located within the EEA to Process such Personal Data.
Again, let us know if this is clear of if we can provide additional information. 

Best regards,

Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190205/0bda31af/attachment.html>