Dear EPDP Team:

Please find below the notes and action items from today’s meeting.

The next EPDP Phase 2 meeting will be Thursday, 28 May at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. EPDP Team members to review and provide input on the discussion table for Recommendation 15 (financial sustainability) and review the updated Recommendation 19 (evolutionary mechanism) and include “cannot live with items” in the chart within the document by COB Tuesday, 26 May.
2. EPDP Support Staff to update Recommendation 10, 12, 13, 14, and 17 based on the EPDP Team’s recent discussions and post the updated recommendations by Friday, 29 May.

EPDP Phase 2 - Meeting #60

Proposed Agenda

Tuesday 26 May 2020 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

3. Welcome and housekeeping issues (Chair) (5 minutes)

• As a result of the discussion during the last meeting, Janis sent questions to ICANN org re: ICANN’s interaction with the SSAD

4. Recommendation #13 Terms of Use (15 min)

1. Review discussion items gleaned from input provided on terms of use discussion table

• The Privacy Policy SHOULD or SHALL:
• Could members that disagree with the use of SHOULD please speak up? Should seems to better reflect the way the group is moving in terms of flexibility
• Should the group try and agree upon a minimum set of standards here and create a floor rather than a ceiling? If there is a SHOULD, it is not enforceable, which means it would have very little utility.
• To address the earlier concern, these should be a requirement that is enforceable by ICANN. The flexibility is how this is interpreted by the contracted party.
• This is in reference to the privacy policy with SSAD users – want to clarify that we are all talking about the same thing.
• What privacy policy is this talking about? Is it how the SSAD will treat requestors’ data?
• This seems like chapters of a privacy policy – all of these items have to be in there.
• Should the follow bullets be added? Transparency requirements, Data security requirements, Accountability measures (privacy by design, by default, DPO above certain size, etc)
• No objections.
• Relevant data protection principles, for example
• Delete the bullet point, but reword the intro sentence: The EPDP recommends, at a minimum, relevant data protection principles, for example:
• Further consideration should be given during implementation whether updates to the RAA are necessary to ensure compliance with these recommendations. – Should this sentence be removed?
• This is likely captured somewhere else. Registrars are required to notify data subjects about when their data is collected. This language is needed.
• When the Team is finished, this policy will be amending the RAA, and someone should be going over the RAA with a fine-tooth comb.
• Proposal is to remove this sentence from this rec and include it in a preamble somewhere else in the policy.
• A consensus policy is incorporated into the RAA and RA by reference.
• Caution the use of the word “amend” – while it would require modifications to the contract, the word amend is incorrect
• “further consideration should be given in implementation” – this does not mean the IRT will draft amendments to the RAA and RA. This needs to be triggered by the CPs
• This sentence should be deleted.
• Based on this conversation, this sentence should be deleted.
• Agree to keep “SHALL” and not have “SHOULD”
• Change to from controllers to requestors
• Is the last set of bullets required for Contracted Parties or requestors?
• Believe this is for the SSAD as it relates to disclosures via the system
• The agreement is with the SSAD and Contracted Parties should be at the table for this discussion.
• The last four bullets are part of the overall terms of use of SSAD and will be applied as a blanket requirement to all requests after disclosure.

2. Confirm next steps

5. Recommendation #17 Logging (15 min)

1. Review discussion items gleaned from input provided on logging discussion table

• What specific items should be logged be the CGM?
• In the context of reporting requirements, there are requirements for reporting that needs to be reported upon.
• With respect to the retention period should not say “as long as is necessary” – we should set a task that the retention period needs to be set in a concrete and transparent way for the data subject to know how long the data will be retained.
• We need to be exceptionally careful as to what is in the logs. If the log has to be kept centrally, CPs will have an issue – a lot of liability will be added to who is holding the data. We need to be careful what additional liabilities we are creating here. We need to set realistic expectations of what we can achieve here.
• It is sufficient to say: the logs will have no personal data. If you maintain an index of requestors, you don’t need to maintain personal data. Microsoft, for example, could be #999. If there is a ticketing system, you could work backwards from the ticket number.
• Even if you use an index number, that could be considered private data if you could use the index number to trace back to an individual. (maybe use a hash that is not traced back to a specific requestor).
• A hash number can be an index number. Privacy by design – the two tables you do not want joined have to be segregated. The segregation and prevention of easy joining is the concept of privacy by design.
• Need to better understand who will be doing the auditing here – is it ICANN, the DPAs, the Contracted Parties?
• Do not understand the reference to auditing here.
• If there are six purposes for auditing and no agreement to how the data will be pseudonymized or anonymized – there needs to be more clarity around this.
• The question is: for the moment, the CGM would perform logging regarding the query and the results of the query, including the status. Should the CGM also keep logs of the disclosure and nondisclosure and recommendations of the CGM.
• If it’s OK with the group, will send a draft DPIA to the group.
• Proposal to add three bullet points in the question to the logging of the CGM.
• For question 2, it should be MAY. Logged data is not required in all circumstances all the time.
• Some logged data must be disclosed under certain circumstances and other logged data will be available under other circumstances. For example, you do not need to see what the disclosure rates are to see if the system is functioning properly, but you may need to see it in other circumstances.
• This applies the whole log must be disclosed, but we are only talking about specific entries. This should be a MAY b/c we do not mean that you are disclosing everything all the time. The AND should be changed to a BUT. Logged data will remain confidential BUT MAY be disclosed in the following circumstances.
• We have where legally permissible sprinkled all of the way through these policy recommendations, which permits operators and jurisdictions that do not have data protection law to ignore things where a data protection authority or data protection law does not apply. and that can allow people to get out of compliance with the law.
• Logged data is not shared by default, but it may be disclosed in very specific circumstances the team identified.
• Logged data MUST remain confidential, BUT relevant logged data MUST be disclosed where legally permissible in the following circumstances: (first 3 bullet points). Relevant logged data must be disclosed for general technical operations to ensure proper running of the system.
• There may be other circumstances where logged data can be disclosed – want to make sure this would not preclude ICANN org from publishing reports based on the logged data.
• Not clear whether reporting recommendation overrides this – unless it is clear that reporting overrides this, we may need a fifth requirement here – the logs may be used in the reporting recommendation.
• Do not understand why ICANN would need the rationale since this is about the procedure, not the decision itself. Not comfortable putting any decision-making in escrow. There is a lot of duplication here, and we should not be considering escrow – that is up to the individual controller.
• Handing an edge case may not warrant putting this data in escrow.
• This sentence can be deleted.
• Suggest that “disclosure decision including written rationale must be stored” be kept and the rest of the sentence be deleted.
• The issue of who bears the cost of audits is not something that needs to be further considered at this time – it is a necessary part of the SSAD.
• “decisions” should be replaced by adherence to the process
• The point seems to be that all CPs follow the same standardized approach
• “structured” should be deleted from this bullet point, and support to keep commonly used machine readable format
• Already addressed question 8 – if all personal info has been removed from logs, is there any issues here? The logged info would be used in the context of reporting.

2. Confirm next steps

6. Recommendation #18 Audits (15 min)

1. Review discussion items gleaned from input provided on audits discussion table

• Question 2 will be cross-checked once the new GAC version is completed
• In the new version, there will be auditing of accredited governmental entities, but not by ICANN
• Question 3: expense of auditing requirements should be considered further? If you have recommendations that auditing takes place, there may not be further need to elaborate on this.
• Auditing is part of operational cost
• There are already a number of auditing requirements that are included in the RA and the RAA – is it necessary to include these obligations in this, or only the auditing obligations that do not exist by data protection laws?
• With respect to Question 4, prefer to leave as is and sort this out in implementation.

2. Confirm next steps

7. Implementation guidance I (15 min)

1. Review discussion items gleaned from input provided on implementation guidance i discussion table
2. Confirm next steps

8. Recommendation #15 Financial Sustainability (25 min)

1. Review discussion items gleaned from input provided on Financial Sustainability discussion table
2. Confirm next steps

9. Recommendation #19 Evolution Mechanism (20 min)

1. Review follow-on draft of Evolution Mechanism and Discussion Table as reference
2. Confirm next steps

10. Wrap and confirm next EPDP Team meeting (5 minutes):

1. Thursday 28 May at 14.00 UTC. Topic to be addressed: high level review of public comments received on the addendum.
2. Confirm action items

1. Confirm questions for ICANN Org, if any