<div>Volker, thanks for this input. I really like the language you have proposed and I support its inclusion.<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>-- Ayden <br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Monday, 7. October 2019 18:03, Volker Greimann <vgreimann@key-systems.net> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><p>In fact this raises an interesting question as processing "in
accordance with applicable law" may not be sufficient, for example
if the strict rules of a data protection regime the disclosing
party is subject to for some reason does not apply to the
requesting party. <br></p><p>The standard that we do want, and which I think is appropriate is
" in accordance with data protection standards equal/equivalent to
or greater than the standards applicable to the data subject and
the disclosing party".<br></p><p>Thoughts?<br></p><p><br></p><p>Volker<br></p><div class="moz-cite-prefix">Am 04.10.2019 um 23:14 schrieb
Anderson, Marc via Gnso-epdp-team:<br></div><blockquote type="cite"><div><p><span style="font-size:11pt">EPDP Team,</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">I’m still
uncomfortable with the language in Building Block E on
retention and destruction of data.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt"> </span><br></p><p style="margin-left:.5in"><span style="color:black">The EPDP Team recommends that requestors
must confirm that they will store, protect and dispose of
the gTLD registration data in accordance with applicable
law. The requirements for data retention and destruction may
differ based on the purpose for which the data is retained;
accordingly, data processing arrangements (for example,
arrangements between the requestor and its accrediting body
or arrangements between the requestor and the controller)
are expected to contain further details with regard to the
requirements for the retention and destruction of gTLD
registration data. </span><span style="font-size:11pt"></span><br></p><p style="margin-left:.5in"><span style="font-size:11pt"> </span><br></p><div style="mso-element:para-border-div;border:solid black
1.0pt;border-bottom:none;padding:1.0pt 4.0pt 0in
4.0pt;margin-left:.5in;margin-right:0in"><p style="border:none;padding:0in"><i><span style="color:black">Comments / concerns / questions to
be considered in relation to building block e): </span></i><span style="font-size:11pt"></span><br></p></div><div style="mso-element:para-border-div;border-top:none;border-left:solid
black 1.0pt;border-bottom:none;border-right:solid black
1.0pt;padding:0in 4.0pt 0in
4.0pt;margin-left:.5in;margin-right:0in"><p style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo1;vertical-align:baseline;border:none;padding:0in"><span style="color:black"><span style="font-family:Symbol"><span style="font-size:10pt"><span style="mso-list:Ignore">·<span style="font-family:"Times New Roman""><span style="font-size:7pt"> </span></span></span></span></span></span><i><span style="color:black">How would this be enforced? Could
accreditation be used to track and enforce?</span></i><i><span style="color:black"><span style="font-family:"Arial", sans-serif"><span style="font-size:11pt"></span></span></span></i><br></p></div><div style="mso-element:para-border-div;border:solid black
1.0pt;border-top:none;padding:0in 4.0pt 1.0pt
4.0pt;margin-left:.5in;margin-right:0in"><p style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo1;vertical-align:baseline;border:none;padding:0in"><span style="color:black"><span style="font-family:Symbol"><span style="font-size:10pt"><span style="mso-list:Ignore">·<span style="font-family:"Times New Roman""><span style="font-size:7pt"> </span></span></span></span></span></span><i><span style="color:black">Consider changing “such as GDPR” to
“including the GDPR”. </span></i><i><span style="color:black"><span style="font-family:"Arial", sans-serif"><span style="font-size:11pt"></span></span></span></i><br></p></div><p style="margin-left:.5in"><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">I’m ok with
the first sentence. The language updated to read “in
accordance with applicable law” is an improvement and
addresses the second bullet point from the comments/concerns
box. To note, we haven’t addressed the first bullet in the
comments/concerns box on enforcement yet.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">One concept
we have discussed but isn’t captured here is that the gTLD
registration data should be retained only as long as
necessary to achieve the purpose stated during the
disclosure request. The first sentence may be meant to
imply that, but I think this building block would benefit
from having that explicitly stated.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">The second
sentence I have a hard time following and a harder time
figuring out how it would be implemented in practice. The
first bit seems to be aimed at stating our agreed
understanding that we cannot define in policy fixed
durations around the retention and destruction of the data.
Some requests may not require any retention while others may
need years. There seems agreement that retention will need
to be determined on a case by case basis. This seems like
more of a foundational concept better suited to a Principle
than part of a Building Block. I suggest creating a new
Principle for this concept and removing it from the Building
Block.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">We are
expected to define the requirements for retention and
destruction but the second bit seems to avoid that
altogether saying some yet to be defined data processing
arrangements will contain the details of the requirements.
I have a particularly hard time imagining what an
implementation team would make of that sentence.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">In
parenthesis are two examples, the first being a potential
arrangement between the requestor and its accrediting body.
I don’t recall that we’ve discussed this in terms of a data
processing arrangement, but we have discussed how in order
to be accredited, an accrediting body might require
adherence to a code of conduct. Such a code of conduct
might include specifics on data retention and destruction.
For example:</span><br></p><p><span style="font-size:11pt"> </span><br></p><ul style="margin-top:0in" type="disc"><li style="margin-left:0in;mso-list:l0 level1 lfo2"><span style="font-size:11pt">Requestors agree that they will
store, protect and dispose of the gTLD registration data
in accordance with applicable law</span><br></li><li style="margin-left:0in;mso-list:l0 level1 lfo2"><span style="font-size:11pt">Requestors agree that they will
only retain the gTLD registration data for as long as
necessary to achieve the purpose stated in the disclosure
request</span><br></li></ul><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">If that is
what is meant here, the building block should state that.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">The second
example seems to suggest a data processing arrangement
between the requestor and the controller. I don’t recall
this being something we discussed specifically and could
potentially become unwieldy if it means every requestor
needs a contract with the controller. If on the other hand
this could be accomplished by including something along the
lines of the above bullet points in a Terms of Use document,
that might work. Again if this is what is meant, the
building block should state as much.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">Thanks,</span><br></p><p><span style="font-size:11pt">Marc</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt"> </span><br></p><div><div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in"><p><b><span style="font-size:11pt">From:</span></b><span style="font-size:11pt"> Gnso-epdp-team <a href="mailto:gnso-epdp-team-bounces@icann.org"><gnso-epdp-team-bounces@icann.org></a> <b>On Behalf Of </b>Caitlin Tubergen<br> <b>Sent:</b> Friday, September 27, 2019 4:28 PM<br> <b>To:</b> <a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a><br> <b>Subject:</b> [EXTERNAL] [Gnso-epdp-team] Updated
building block E - retention and destruction of data</span></p></div></div><p> <br></p><p><span style="font-size:11pt">Dear EPDP
Team:</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">Further to
EPDP Support Staff’s action, please find <a href="https://docs.google.com/document/d/1WMhllLz5Zgm42C4Jfjiqinu32Jwiu_lhuBorzeuBKuA/edit"> the updated version of Building Block E (retention and
destruction of data)</a>. The edits intend to capture the
Team’s discussion from the last meeting.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">As the
building block is in the form of a Google Doc, please
provide suggested edits directly in the document by <b>Monday, 7 October</b>.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">Thank you.</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">Best
regards,</span><br></p><p><span style="font-size:11pt"> </span><br></p><p><span style="font-size:11pt">Marika,
Berry, and Caitlin</span><br></p><p><span style="font-size:11pt"> </span><br></p><p> <br></p></div><div><br></div><pre wrap>_______________________________________________
Gnso-epdp-team mailing list
<a href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.<br></pre></blockquote><div><div>-- <br></div><div> Volker A. Greimann<br></div><div> General Counsel and Policy Manager<br></div><div> <b>KEY-SYSTEMS GMBH</b><br></div><div> <br></div><div> T: +49 6894 9396901<br></div><div> M: +49 6894 9396851<br></div><div> F: +49 6894 9396851<br></div><div> W: <a href="http://www.key-systems.net">www.key-systems.net</a><br></div><div> <br></div><div> Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835<br></div><div> CEO: Alexander Siffrin<br></div><div> <br></div><div> Part of the CentralNic Group PLC (LON: CNIC) a company registered
in England and Wales with company number 8576358.<br></div></div></blockquote><div><br></div>