[Gnso-epdp-team] Updated building block E - retention and destruction of data
vgreimann at key-systems.net
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".
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
> ·/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
> meant, the building block should state as much.
> *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)
> 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
Volker A. Greimann
General Counsel and Policy Manager
T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
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...
More information about the Gnso-epdp-team