[Gnso-epdp-legal] Reminder of Phase 2 legal committee action items

[Caitlin Tubergen]

Dear EPDP Phase 2 Legal Committee,

 

Here is a reminder of the action items from the last call. Text of the questions and updated questions has been included for ease of reference.

 

Thank you.


Best regards,

 

Marika, Berry, and Caitlin

 
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?

 
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? 
Note: Is the Team OK with this question as worded above?
Question 6: Brian King to collaborate with Georgios to fine tune Q6 by incorporating suggestions (e.g., 1. the requestee performs the evaluation, 2. some third party performs the evaluation?), factoring in the point regarding the controllership assumption.
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

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190815/c67cd09a/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/20190815/c67cd09a/smime-0001.p7s>