[Gnso-epdp-team] Updated building block E - retention and destruction of data

Mon Oct 7 16:03:38 UTC 2019

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.

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".

Thoughts?

Volker

Am 04.10.2019 um 23:14 schrieb Anderson, Marc via Gnso-epdp-team:
>
> EPDP Team,
>
> I’m still uncomfortable with the language in Building Block E on 
> retention and destruction of data.
>
> 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.
>
> /Comments / concerns / questions to be considered in relation to 
> building block e): /
>
> ·/How would this be enforced? Could accreditation be used to track and 
> enforce?///
>
> ·/Consider changing “such as GDPR” to “including the GDPR”. ///
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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:
>
>   * Requestors agree that they will store, protect and dispose of the
>     gTLD registration data in accordance with applicable law
>   * 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
>
> If that is what is meant here, the building block should state that.
>
> 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.
>
> Thanks,
>
> Marc
>
> *From:*Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> *On Behalf Of 
> *Caitlin Tubergen
> *Sent:* Friday, September 27, 2019 4:28 PM
> *To:* gnso-epdp-team at icann.org
> *Subject:* [EXTERNAL] [Gnso-epdp-team] Updated building block E - 
> retention and destruction of data
>
> Dear EPDP Team:
>
> Further to EPDP Support Staff’s action, please find the updated 
> version of Building Block E (retention and destruction of data) 
> <https://docs.google.com/document/d/1WMhllLz5Zgm42C4Jfjiqinu32Jwiu_lhuBorzeuBKuA/edit>. 
> The edits intend to capture the Team’s discussion from the last meeting.
>
> As the building block is in the form of a Google Doc, please provide 
> suggested edits directly in the document by *Monday, 7 October*.
>
> Thank you.
>
> Best regards,
>
> Marika, Berry, and Caitlin
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-- 
Volker A. Greimann
General Counsel and Policy Manager
*KEY-SYSTEMS GMBH*

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of 
Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin

Part of the CentralNic Group PLC (LON: CNIC) a company registered in 
England and Wales with company number 8576358.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191007/ea9a0fd5/attachment-0001.html>