Dear EPDP Team, Below, please find the notes and action items from today’s call. As a reminder, the next EPDP Team call will be Thursday, 26 September 2019 at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #20 Tuesday, 24 September 2019 at 14.00 UTC Action Items EPDP Team Members to send a message to EPDP Leadership ASAP to let the leaders know the status of outstanding homework so that Leadership can plan the upcoming meetings accordingly. Support Staff to review feedback received during today’s meeting, and update Building Block D and H (acceptable use policy) accordingly. Support Staff to review feedback received during today’s meeting, and update Building Block K (receipt of acknowledgement) accordingly. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #20 Agenda Tuesday, 24 September 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · Please state your name before speaking for transcription purposes. · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Reminder - the EPDP Team members to populate the contents of the lawful basis table by Wednesday 25 September (see https://docs.google.com/document/d/1U9jt9nOHs9QMjWTDl7UPaT--9aD2lHZI/edit) · Please remember to refer to outstanding action items from the F2F here: https://mm.icann.org/pipermail/gnso-epdp-team/2019-September/002495.html · Action: EPDP Team Members to send a message EPDP Leadership to let Janis know the status of the homework so that Leadership can plan the next meeting accordingly. b) Reminder - submit alternate form if members are not attending the Jan 2020 F2F meeting 4. Acceptable Use Policy (building block d and h) (first reading) (30 minutes) a. Initial discussion b. Feedback from EPDP Team EPDP Team Feedback Building Block D · Suggest deletion of the word “and enforced by” in the first bullet point. This is not for individual requests - the requirements have to be enforced, or there is no need to have requirements, so enforced does need to remain. While an enforcement action does not need to happen for each individual case, an enforcement mechanism needs to be in place. Concerned with “enforced” language, but perhaps Volker can put forward with alternate language. Language proposal: "Enforced based on periodic audits and reports of mis-use" - note this did not receive the support of the Team, but is a suggestion for Support Staff as it produces next draft Subpoint A No access to historic data, but only to current data - change for the second reading Subpoint B No need for no bulk access parenthetical here There is no need for reference to no bulk access; however, if bulk access is referenced, the citation needs to be included. Support Staff to see if clearer formulation, underlying that each request is unique needs to be rewritten This means no wildcard requests, but not sure it makes sense to say you cannot submit three requests in the same packet. Meaning is that each request is unique. Subpoint C Consider update - “must represent that the requestor will only use the data for the purpose requested.” - if this is accepted, then delete subpoint E Curious of intent in this proposed edit - only requirement is that there will be representation that the data will be used for the purpose for which it was requested, but actually using it with that purpose is no longer a requirement? The order is incorrect - the current E, the requestor must state what it plans to use the data for, and the current C notes that the requestor can only use the data for that purpose. Both of these should appear, but in the correct order. Agree with the above point. The purpose of C is one of the principles within GDPR that you can only use personal data for the purpose you lawfully obtained it under. The other point gets to necessity. Both points need to be there, but the sequence should change. The word “only” is problematic with point E. If you are looking into a cybersecurity event, and there is also trademark infringement, the requestor should not be prohibited from investigating the trademark infringement. Disagree with the removal of the word “only”. Keeping the word only - ensures if someone is requesting data for trademark infringement and processes the data for another purpose that may be inconsistent with data protection law. Would the Team consider adding a concept - that if during the investigation, it appears that the requested data may be used for another lawful purpose, this should be made known to the contracted party? Several Team members have noted in the chat options such as “compatible with” and “consistent with” Uneasy about saying that anyone that requests data is giving blanket permission to be audited from an unknown entity - this needs to be clarified Proposal to use the language from GDPR 5(b): "not further processed in a manner that is incompatible with those purposes" Agree with using 5(b) - using GDPR language is probably the best way to go GDPR language is OK, but there are other legislations that may apply. Rather than relying on a legal framework, the text should hinge on underlying principles. Use of data and purpose for requesting it is very important for the disclosing entity in its balancing test. There may be instances where data under another purpose would fail the balancing test. For example, data processed for trademark infringement cannot then be used for capital punishment. Notification to the disclosing entity is not enough - the Team needs to be careful that we do not allow using data for additional purposes. Agree with above. 5(b) has no bearing on this discussion. The Team is discussing third party purposes for processing data. 5(b) cannot be used as a legal reference for this discussion. 5(b) is concerned with controller’s purposes for processing, not the third party’s purposes for processing. Disagree with the above “switcharoo” example. Processing data under trademark infringement and using the data to execute someone is not a compatible purpose. In the request, the requestor may need to put in “trademark, cybersecurity, etc.” Each request should be unique and based on a lawful purpose. You cannot use data that is incompatible/inconsistent with the purpose requested - could that be used instead of the 5(b) language? Subpoint d Perhaps use more general language, not GDPR - perhaps use applicable data protection law Subpoint e Comments addressed above EPDP Team Feedback Building Block H · Subpoint A · This point should say “disclose” instead of “supply” · Subpoint B · Update “return” with “disclose” · The addition to Subpoint B is extraneous. It is trivially easy to supply the public data at the same time as the redacted data. · Remove “subset thereof” · Data protection law should be changed to applicable law · Subpoint C · There was a note about requesting only redacted data, not public data. Was this removed? Support Staff to check. · Subpoint D · What level of detail should be included here, or should it be left to the contracted party? · Spelling out what needs to be logged could be useful for when the policy recommendations are implemented. · Anything logged is subject to GDPR since there is personal data, so the Team may want to consider discussing retention in the policy and guidance. · Subpoint E · This needs to be separate - the data subject’s challenge should be addressed in a separate recommendation. When we talk about erasure, do not understand what that means. · This should be split into two parts - not sure what erasure means in this context. · The second sentence seems to go beyond what GDPR requires - this does not give the requestor a veto right - this is an overapplication of the law and is not appropriate to apply to all cases. · Put second sentence in brackets for now. · “Must define and perform balancing test” - is it the responsibility of the disclosing party to define the balancing test since that rules out the community’s ability to define a balancing test at a high-level? Parties should not define their own process each time as that is not transparent or predictable. · Rights to object to erasure refer to specific rights that data subjects have under GDPR - this should not be deleted, but rather, discussed further. · If a data subject or registrant discovers that its data is not current, that is a situation where the data could be erased and replaced with accurate data. · When the right to object under GDPR is exercised, the data subject has to give a specific reason. This is not a veto right - there is no guarantee that the data subject’s right to object will be granted. · Every time someone’s data is used, we do not need to go to them each time and ask if it is OK. The term “where applicable” should be replaced by “where required by law”. · Regarding “veto,” it is unclear where this challenge happens. Would be helpful to have a better understanding of what this means. · Replace “where applicable” with “in cases of 6(1)(f)”. Objection may come in at the point in time when the data is requested. · Subpoint F · As law enforcement, what are the expectations of confidentiality of a data request like this? · This needs work so that investigations will not be obstructed. · Does the Team need to be more clear about what data is asked for but not specific about who the requestor was - open question. · There may be situations where confidentiality is not just desirable, but necessary. Would this be a situation where LEA would go through the SSAD or just to the controller directly. · Subpoints F and G are dealing with the same problem. If there are investigations, they need to be logged. There is an issue of when the disclosure of when the investigation is happening. · Realistically, the LEA needs to satisfy its own internal requirements, so every request would have a form of confidentiality. ⅔ of requests generally require confidentiality - that is not confidentiality forever, but just during the pending investigation. · With respect to what data would be sent to the data subject, article 15(1)(c) of the GDPR informs this discussion. Third parties must be named . · LEA generally have the power to compel the disclosing entity not to disclose to the data subject. · This conversation hinges on reasonable request. · Suggestion of a new item for item H - “Must provide [non personal] non-public data for data subjects that are legal persons or otherwise not subject to data protection laws.” · Disagree with the inclusion of this since some entities have constitutional protections that would prevent this · When the EPDP Team recommended that the differentiation of legal and natural persons, that was about the redaction, not disclosure. Need more time to consider adding the word “must”. · There are laws that identify entities that are legal entities that are still eligible for privacy - there could be carve-outs here, but do not support elimination of this point entirely. · Uncomfortable with H - there may be unintended consequences of the language, as written. This does not appropriately take into account the nuances. · This language seems to indicate that legal persons are not subject to data protection laws - this is not correct. Legal persons’ data may still contain personal data of natural persons. · Proposals for how to update point H can be sent to staff for the second reading. c. Confirm next steps · Action item: Support Staff to review feedback received during the call, and update Building Block D and H (acceptable use policy) accordingly. 5. Receipt of Acknowledgment (building block k) (first reading) (30 minutes) a. Initial discussion · Ayden proposed an update that generated significant discussion. b. Feedback from EPDP Team · Clarification on the lack of consensus for Ayden’s proposal, since there were multiple parts of the proposal. The notice to the data subject that the disclosure has been requested seems reasonable. · The Staff proposal includes language from Phase 1. · The building block should focus on the receipt of acknowledgment to the requestor. In terms of specifics of receipt of acknowledgment, this should be instantaneous when a web service like RDAP is used. · If someone fills out a webform and does not get an instant response that it was received, they may assume the website is broken. Acknowledgement should be virtually instantaneous. · There is value in the first part of Ayden’s proposed text in what precisely the acknowledgement letter should contain. In FOIA requests, there is a standard acknowledgement letter that is sent back - this allows the requestor to correct any issues. This letter would provide a point of contact for the requestor as well. · Whatever system is built - it should be as automated as allowable under the law. · Talk about notice to data subject under a separate building block c. Next Steps Support Staff to review feedback received during the call, and update Building Block K (receipt of acknowledgment) accordingly. 6. Who should be responsible for disclosure decision (15 minutes) a. Review additional team input (see https://docs.google.com/document/d/10VRZRziGDXvckC_y3ob_SGB- 1NN9WrL6Y6A3XQuniv8/edit [docs.google.com]) · ALAC · Believe there should be classes of requests that should be handled instantaneously, irrespective of who is deciding. Examples are included in the submission. · GAC · This does not include everything, but points to consider. The GAC did not comment on the data trust concept since there are too many variables that are unknown at this time. For both, there needs to be legal agreements in place that articulate roles, responsibilities, corresponding recognition of risk associated. · There needs to be timeframe for acknowledgement of receipt and disclosure. · There needs to be a community-agreed balancing test. · ICANN needs to respond regarding risk. b. Consider team input and approach forward c. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a. Thursday 26 September 2019 at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any