Volker, thanks for this input. I really like the language you have proposed and I support its inclusion. -- Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, 7. October 2019 18:03, Volker Greimann <vgreimann@key-systems.net> wrote:
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@icann.org>](mailto:gnso-epdp-team-bounces@icann.org) On Behalf Of Caitlin Tubergen Sent: Friday, September 27, 2019 4:28 PM To: gnso-epdp-team@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_lhuBorzeuB...). 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@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.