Dear All,

 

Please find below the input from ICANN Org on the questions that were raised by the EPDP meeting on the 9th, 13th, and 16th. The responses will get posted shortly here: https://community.icann.org/x/ahppBQ.

 

Best regards,

 

Caitlin, Berry and Marika

 

 

**

 

  1. Regarding Temporary Specification section 4.4.8 - Supporting a framework to address issues involving domain name registrations: the team requests additional specificity. Does this mean that registrars and registries must support a uniform access mechanism when approved or is there some present requirement?

RESPONSE: Section 4.4.8 identifies that addressing issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection using a framework to be developed is a legitimate purpose for the processing of registration data. With regard to the second question, section 4.4.8 does not by itself require that registrars and registries must support a uniform access mechanism when approved. Please note however that section 4.1 of Appendix A does have a requirement for registrars and registries to “provide reasonable access to Personal Data in Registration Data to third parties on the basis of legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.” Separately, section 4.2 of Appendix A requires registrars and registries to “provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful.” Section 4.2 of Appendix A further requires that registrars and registries “provide such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.”

 

  1. Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions?

RESPONSE: The data requested by ICANN Contractual Compliance will vary depending on the particular compliance issue. For example, for a registrant’s complaint that a renewal reminder email was not received, ICANN Contractual Compliance may request from the registrar of record a copy of the communication to the Registered Name Holder.

 

  1. Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?

RESPONSE: ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog.

 

  1. In section 5.7 of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”?

RESPONSE: “Reasonable access” is not defined in the Temporary Specification. Generally, compliance with the requirement for registrars and registries to provide reasonable access to non-public registration data is evaluated on a case-by-case basis, based on evidence provided by the requestor, including its request for access to non-public registration data, evidence of the requestor’s legitimate purpose for accessing the non-public registration data, the timing and content of the contracted party’s response to the request (if any), and any other information or evidence relevant to assessing the request and response.

 

  1. Believing that ICANN org has its own GDPR implementation plan in place, it would be helpful for our group to understand the elements and implementation status of the plan so that the Team can draw comparisons to the EPDP Team’s work.

RESPONSE: ICANN org has been open and transparent about its work to get ready for GDPR both in terms of domain registration data collected and processed by registrars and registries (which we refer to as “external” GDPR readiness), and personal data processed by ICANN org in the ordinary course of the organization’s operations such as finance, meetings, and human resources (which we refer to as “internal” GDPR readiness).  ICANN org’s plans and activities regarding “external” (domain registration data) GDPR compliance have been openly and transparently blogged and posted on the ICANN Data Protection page at <https://www.icann.org/dataprotectionprivacy>. On 5 June 2018, ICANN’s CEO and President, Göran Marby, shared information about ICANN org’s “internal” efforts to be GDPR compliant via a blog. In the blog, Göran shared that several of ICANN’s policies have been updated. These include an updated online Privacy Policy, a revised Terms of Service, a revised Cookies Policy, a new Notice of Applicant Privacy (relating to data processed for employment applications), and a revised New gTLD Program Personal Data Privacy Statement. Additionally, ICANN org has also rolled out internal changes to the way we handle personal data, from data processing arrangements with vendors to our various personnel policies. Read the full blog here.

 

  1. The Council envisioned, via the EPDP Charter, to have direct participation of ICANN org liaisons, within the EPDP Team. As we leave the Triage and head into substantive detail, do the ICANN liaisons see a role or specific set of actions for ICANN supporting the team?

RESPONSE: Section III of the EPDP Charter describes the role of ICANN org liaisons as “ICANN Staff Liaison: The ICANN Org GDD and Legal Liaisons are expected to provide timely input on issues that may require ICANN Org input such as implementation-related queries. The ICANN Staff Liaisons are not expected to advocate for any position and/or participate in any EPDP Team consensus calls.” In line with this description of ICANN org liaisons’ role, Göran Marby’s response to the GNSO Council regarding a request for appointment of ICANN org liaisons confirmed the scope of participation of the ICANN org liaisons as “Trang Nguyen from ICANN organization’s Global Domains Division and Dan Halloran from ICANN’s legal team will join the working group’s mailing list and the group’s calls to coordinate responses to requests for GDD or legal input as needed to support the working group’s deliberations. Such requests will ordinarily be responded to in writing, following consultation with internal and external experts as appropriate.”