[Gnso-epdp-legal] Notes and action items from EPDP Phase 2 Legal Committee Meeting #4 - 20 August 2019

[Caitlin Tubergen]

Dear EPDP Phase 2 Legal Committee,

 

Below, please find the notes and action items from today’s call.

 

As a reminder, the next EPDP Phase 2 Legal Committee meeting will be Tuesday, 27 August at 14:00 UTC.

 

Thank you.


Best regards,

 

Marika, Berry, and Caitlin

 

--

 

EPDP Phase 2 Legal Committee Meeting #4

Tuesday, 20 August 14:00 UTC

Action Items
Brian to clarify the language regarding “opt out” in the second bullet point of Question 2/5.
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. 
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. 
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.
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. 
Support Staff to build the first batch of questions to be submitted to the EPDP Team for final sign-off. 
 

Notes

 
Roll Call & SOI Updates 
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.
 
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?
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. 
 

 
Updated Question 12 and 13: LC to review simplified question before sending to EPDP Team for sign off: In light of the 3 May 2019 correspondence from the European Commission, are any updates on the previous memo on 6(1)(b) necessary? 
 
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

 
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.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190820/4f3a65fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190820/4f3a65fc/smime-0001.p7s>