The next meeting of the EPDP– Phase 2 PDP Legal subteam is scheduled on Tuesday, 20 August 2019 at 14:00 UTC for 75 minutes 

07:00 PDT, 10:00 EDT, 16:00 Paris CEST, 19:00 Karachi PKT, 23:00 Tokyo JST, (Wednesday) 00:00 Melbourne AEST

For other times: https://tinyurl.com/y4roz8v9

PROPOSED AGENDA


  1. Roll Call & SOI Updates
  2. Continued Substantive Review of Priority 1 (SSAD) Legal Questions Submitted to Date

          a) Substantive review of SSAD questions (beginning where LC left off last week)

  • Updated Merged Questions 2 and 5: LC to continue reviewing the updated text and suggest changes (if any) in advance of the next LC meeting on Tuesday, 20 August 2019. LC to be prepared to discuss the text and proposed updates during next LC call.

 Updated Merged Questions 2 and 5: Consider a System for Standardized Access/Disclosure where contracted parties “CPs” are required to disclose personal data over RDAP to requestors either directly or through an intermediary request accreditation/authorization body. Assuming the following safeguards are in place, what risk, if any, would the CP face for the processing activity of disclosure in this context? If any risk exists, what improved or additional safeguards would eliminate[1] this risk. In this scenario, would the CP be a controller or a processor[2], and to what extent, if at all, is the CP’s liability impacted by this controller/processor distinction? 

  • 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.


  • Updated Question 4: Brian and Volker to work together on redrafting question 4, specifically with respect to clarifying whose legal basis for processing the question refers to.


            Updated Question 4: European LEAs need to have a legal basis for requesting disclosure. Based on that, they approach the contracted party, which can then disclose based on Art. 6 I c GDPR to fulfil a legal obligation.

          Where no legal basis for requesting data exists, no disclosure can take place.

 

         Art. 6 I c GDPR is limited to European laws. As a consequence, non-EU LEA cannot use a European legal basis for requesting data and the contracted party can therefore not disclose based on 6 I c GDPR.

 

That would leave us with disclosure based on 6 I f GDPR and to the potentially problematic situation in which a domestic European LEA must be able to base its request on a national law while non-EU LEA “only” needs to have a legitimate interest. Remember that even public authorities must not base their processing on 6 I f GDPR in performing their core activities. I trust there is common understanding that investigating crime is the core activity of LEAs and thus it might be a contradiction to have domestic European LEAs blocked from basing their requests on 6 I f GDPR, while non-EU LEA can use that para as a legal basis and also to have the contracted party disclose based on 6 I f GDPR, while in domestic EU cases, only 6 I c GDPR would be applicable.

 

Remember that disclosing data to LEA is much more impactful for the data subject than in civil cases and that therefore, the law makers have included the aforementioned safeguards into the GDPR, which we might be bypassing by using 6 I f GDPR.

I am not saying this cannot be made work, but we should get confirmation that such disclosure is lawful.


  • Updated Question 9: Hadia and Margie to work together to redraft the question to clarify ambiguities. (Note: in redrafting Q9, Hadia and Margie may want to consider the text of updated Q2/5.


           Updated Question 9: 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 possible to have automated disclosures to third parties that have requested access under 6(1)(f)? If it is possible, please provide any guidance for how this can be accomplished. For example, is it legally permissible to define specific categories of requests (e.g. rapid response to a malware attack or contacting a non-responsive IP infringer) to identify types of user groups or processing activities that reduce the need for manual review?  In addition, please describe the circumstances (if any) where a manual review is required under 6(1)(f), and any guidance for how to perform this balancing test.


  • Updated Question 11: Question on hold for now. Margie to update the text of the question to include a specific use case.

Note: On the list, León proposed submitting the question with a summary of the situation that the use case tries to address. Would someone like to volunteer to do this? (The draft below includes Margie’s update + Volker’s proposed addition).

Updated Question 11: Can legal counsel be consulted to determine whether in [completely defined Scenario X] a fast automated, and non-rate limited responses (as described in SSAC 101) to nonpublic WHOIS data for properly credentialed security practitioners (as defined in SSAC 101), who have agreed on appropriate safeguards would be permissible under the GDRP and not cause any liability in data controllers/processors with regard to unrightful disclosures? Or would any automated disclosure carry a potential for liability of the disclosing party? Can counsel provide examples of safeguards (such as pseudonymization/anonymization) that should be considered?


Note: Is the Team OK with this question as worded above?

 

  • Question 6: Within the context of an SSAD, in addition to determining its own lawful basis for disclosing data, does the requestee (entity that houses the requested data) need to assess the lawful basis of the third-party requestor? (Question from ICANN65 from GAC/IPC)

[1] “Here it is important to highlight the special role that safeguards may play in reducing the undue impact on the data subjects, and thereby changing the balance of rights and interests to the extent that the data controller’s legitimate interests will not be overridden.“ (https://iapp.org/media/pdf/resource_center/wp217_legitimate-interests_04-2014.pdf)

[2] https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/obligations/controller-processor/what-data-controller-or-data-processor_en


     b) Discussion on submission of questions – submit as complete batch or as available?

     c) Agree on next steps


   3. Wrap and confirm next meeting to be scheduled

     a) Confirm action items

     b) The next LC Meeting will take place on Tuesday, 3 September at 14:00 UTC.


BACKGROUND DOCUMENTS



PARTICIPATION


Attendance 

Apologies: Tatiana Tropina

Alternates: Stephanie Perrin

Notes/ Action Items


Action Items

  1. Brian to clarify the language regarding “opt out” in the second bullet point of Question 2/5.
  2. Brian and Thomas to review Question 2/5, taking into account today’s conversation, and propose new language and distribute to the Team in advance of the next Legal Committee call on Tuesday, 27 September.
  3. Thomas to submit additional language for Question 4 with respect to whether 6(1)(f) can be deployed by non-European authorities or public authorities in the disclosure of data to them.
  4. Support Staff to add the safeguard bullet points from Q2/5 to Q9 and submit this to the legal list for final review by the group off-line.
  5. Margie to add a footnote to question 11, regarding SSAC-defined security practitioners. Following Margie’s addition to question 11, Support Staff to add the bullets from Q2/5 to Q11 and submit this to the Legal list for final review by the group off-line.
  6. Support Staff to build the first batch of questions to be submitted to the EPDP Team for final sign-off.


Notes


  1. Roll Call & SOI Updates
  2. Continued Substantive Review of Priority 1 (SSAD) Legal Questions Submitted to Date


           a) Substantive review of SSAD questions (beginning where LC left off last week)


  • Updated Merged Questions 2 and 5: LC to continue reviewing the updated text and suggest changes (if any) in advance of the next LC meeting on Tuesday, 20 August 2019. LC to be prepared to discuss the text and proposed updates during next LC call.

Updated Merged Questions 2 and 5: Consider a System for Standardized Access/Disclosure where contracted parties “CPs” are required to disclose personal data over RDAP to requestors either directly or through an intermediary request accreditation/authorization body. Assuming the following safeguards are in place, what risk, if any, would the CP face for the processing activity of disclosure in this context? If any risk exists, what improved or additional safeguards would eliminate[1] this risk. In this scenario, would the CP be a controller or a processor[2], and to what extent, if at all, is the CP’s liability impacted by this controller/processor distinction? 

 

  • 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.


Notes from Call:

  • The intent of the safeguards list was to be extensive but not exhaustive.
  • The detailed background on the safeguards is helpful. It may be helpful to add Question 9 to this question.
  • It may be helpful to add the bullets to the last version Question 9.
  • Action item: Support Staff to add the bullets from Question 2/5 to the end of Question 9.
  • Safeguards is a loaded term – there are legal safeguards, procedural safeguards, and IT safeguards. Not sure how the terms safeguards is used in the GDPR – should the safeguards be desegregated in this way?
  • The safeguards list is not meant to be comprehensive, but rather, to provide background to outside counsel.
  • The question was designed to include legal safeguards and procedural safeguards. Technical safeguards were purposely omitted from this list as technical safeguards would likely require a lot of work on every contracted party.
  • With respect to the second bullet regarding “opt out” – could registrant opt out of having its data provided to law enforcement? What is this meant to mean?
  • The concept that was trying to be captured is that a registrant knows going into registering a domain name that data will be processed, so the registrant could choose to use P/P services or not register a domain name at all.
  • Proposed edit: If any risks exist, what safeguards could be implemented to mitigate this risk?
  • Risk can never be eliminated but could be mitigated. If you ask for legal advice and ask for a laundry list of safeguards – what are we really asking here? Are we asking legal counsel to tell us what we have to do to mitigate the risk enough to remove liability? If that is the case, we need to sort the safeguards since legal counsel is unlikely to provide guidance on technical safeguards. Here, we are talking about processing that is quite vague, i.e., disclosure to a party. The registrant has no choice when a legal actor comes for data, but we do not what other use cases are relevant.
  • What we are trying to ask here – under a scenario in which a standardized access/disclosure model is adopted, and safeguards are in place, what are the risks for contracted parties in this scenario?
  • Objections to signing off this question and sending to the plenary for outside counsel?
  • Suggest that the text should be clarified re: what opt out means (that a registrant knows going into registering a domain name that data may will be processed, so the registrant could choose to use P/P services or not register a domain name at all).
  • Action: Brian to clarify the language regarding “opt out” in the second bullet of this question.
  • What are we trying to get as an answer to this question? No lawyer in the world would be able to give you an answer that there is no risk if the criteria mentioned in the question are met. If the risk for the data subject stemming from certain processing activities is low, the measures are low for safeguard. If the risks are high, you have to take extraordinary measures to protect the data subject. Without spelling out concrete scenarios, it is unlikely we will get a positive response to this question.
  • Would it be best if instead of asking what the risk level outside counsel perceives under this scenario?
  • Spell out what data is being requested and what safeguards are being used to protect the request – to see if the safeguards we are considering are correspondent to the risk.
  • For the sake of brevity, assumed outside counsel would know some facts, like the type of data that would be in play. Does it make sense to take this back once more to think about what other facts and safeguards are appropriate to add to this question.
  • Adding data that is disclosed is helpful, but also discuss the grounds upon which the data is requested.
  • Action item: Brian and Thomas to review this question again, taking into account today’s conversation and finetune the language.


  • Updated Question 4 (proposed by Brian and Volker): Under the GDPR, a data controller can disclose personal data to law enforcement of competent authority under Art 6 1 c GDPR provided the law enforcement authority has the legal authority to create a legal obligation under applicable law.

 

      1. Can law enforcement agencies of other jurisdictions than the data controller/processor therefore not rely on Art 6 1 c GDPR as a legal basis for the data controller to disclose protected data? Under what circumstances could Art 6 1 c GDPR apply to the disclosure of data in such a context?
      2. Do other legal bases for disclosure exist, besides Art 6I f), that the data controller/processor can rely on for such "foreign" LEAs that lack power to legally compel the data controller/processor?

Notes from Call:

 

  • Propose adding one question on whether 6(1)(f) can be deployed at all by non-European authorities or public authorities in the disclosure of data to them at all.
  • Action: Thomas to submit additional language with respect to whether 6(1)(f) can be deployed by non-European authorities or public authorities in the disclosure of data to them.


  • Updated Question 9 (proposed by Margie): 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).

 

Notes from Call:

 

  • Propose adding a bullet under the first bullet – automatically conduct the balancing test under 6(1)(f)
  • How does this question differ from 2/5? Is this focused more on an automatic 6(1)(f) determination? Is this better as a direct piggyback question? This seems to rely on the same background information on questions 2/5.
  • Maybe make the first question focus on the legality of an accreditation system and the second question focusing on the types of requests being made
  • The difference b/w the two questions – the first one relates more to risk, but this question was written specifically to focus on automated and high-volume requests.
  • If this scenario is permissible, it should be that this would be automated, otherwise the system could be intentionally slowing down.
  • You can automate accreditation and authentication and decide reputationally that certain third parties can be trusted more than others, but not sure how you can meet the requirements of any data protection legislation. You have to look at the precise case – you cannot automate the question.
  • We cannot create a system that is abuse-proof, and this is not something we can try to create or that the law requires.
  • It is important to spell out the automation of the 6(1)(f) balancing test
  • There is no one-size-fits-all solution- what we are trying to find the solution for – can we have a pre-fabricated balancing test for certain scenarios? Is this is feasible, and how can it be operationalized?
  • There is value in keeping questions 2/5 separate from Question 9. After adding bullets from Q2/5, will this question be ready for the plenary?
  • Action: Support staff to add the bullets from Q2/5 to Q9 and submit this to the Legal list for final review by the group off-line.


  • Updated Question 11 (proposed by Margie): Is it permissible under GDPR to provide fast, automated, and non-rate limited responses (as described in SSAC 101) to nonpublic WHOIS data for properly credentialed security practitioners (as defined in SSAC 101)  who are responsible for defense against e-crimes (including network operators, providers of online services, commercial security services, cyber-crime investigators) for use in investigations and mitigation activities to protect their network, information systems or services (as referenced in GDPR Recital 49) and have agreed on appropriate safeguards? Or would any automated disclosure carry a potential for liability of the disclosing party, or the controllers or processors of such data? Can counsel provide examples of safeguards (such as pseudonymization/anonymization) that should be considered?


Notes from Call:

 

  • The same safeguards included in Q2/5 should be repeated here.
  • The description of who would be able to access this automated system is too broad – it could apply to anyone. This needs to be limited to specifically-defined circle of users that has to be tightly controlled.
  • This concern is more of a policy question, rather than a legal question. Would it help to remove the “including text”?
  • Action: Margie to add a footnote to the question regarding security practitioners. Following Margie’s added footnote, Support Staff to add the bullets from Q2/5 to Q11 and submit this to the Legal list for final review by the group off-line.

 


 

  • This question will be sent to the EPDP Team for final sign-off.

 

  • Question 6: Within the context of an SSAD, in addition to determining its own lawful basis for disclosing data, does the requestee (entity that houses the requested data) need to assess the lawful basis of the third-party requestor? (Question from ICANN65 from GAC/IPC)

 


[1] “Here it is important to highlight the special role that safeguards may play in reducing the undue impact on the data subjects, and thereby changing the balance of rights and interests to the extent that the data controller’s legitimate interests will not be overridden.“ (https://iapp.org/media/pdf/resource_center/wp217_legitimate-interests_04-2014.pdf)

[2] https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/obligations/controller-processor/what-data-controller-or-data-processor_en




          b) Discussion on submission of questions – submit as complete batch or as available?

  • Is there an objection to submit questions in batches, or should they be submitted in batches?
  • Action: Support Staff to build the first batch of questions to be submitted to the EPDP Team.

          c) Agree on next steps


     3. Wrap and confirm next meeting to be scheduled

           a) Confirm action items

           b) The next LC Meeting will take place on Tuesday, 27 August at 14:00 UTC.




  • No labels