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
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> 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_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
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> *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_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@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.
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.
Thanks all for the discussion on this. The core question what is this statement actually safeguarding? Taken at its simplest, we are asking the disclosee to undertake, on the record, that they shall process the data as per the law permits. (the question of 'proper' retention periods is a mere subset of this); unless we have evidence to the contrary, which tends to confirm that this is not the case (past complaints of conviction etc), it is not in our power to verify this statement (unless of course we are so empowered by the relevant national powers that be). I agree with Marc, we must place a realistic emphasis on the ability to enforce, (as the gating questions rightly noted). If we merely are paying lip service to a confirmation that the entity or person to whom we are disclosing data to is 'compliant' with applicable data protection law. A 'tick box' assertion is of little value in assessing legality. We would require some form of objective proof for this assertion to mitigate* legal liability.* Definitely agree that it is worthwhile to get the assertion as a matter of *contractual obligation*, as it enables a disclosing controller to call in an indemnity for a breach this condition in the contract; but it provides little or no comfort to the disclosing controller as to whether that disclosure is legally permitted or not. This is falling into that trap of legal liability vs getting an indemnification in the contract . In short I approve of us asking the question, 'are you compliant with the law?' It is a good assertion to get on the record, *BUT* I would suggest having the answer does not really make our action to disclose more likely to be 'legally sound', it just makes it easier for us to claim indemnification for a breach of contract. Sorry - long winded but I think we should get our 'safe-guard' priorities straight here ! Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Mon, Oct 7, 2019 at 5:03 PM 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> <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_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 listGnso-epdp-team@icann.orghttps://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. _______________________________________________ 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.
With respect to enforcement, presumably some complaint process and usage monitoring would be in place and the operator would retain the right to cut someone off if they were abusing the system? On Mon, Oct 7, 2019 at 1:48 PM Alan Woods <alan@donuts.email> wrote:
Thanks all for the discussion on this. The core question what is this statement actually safeguarding?
Taken at its simplest, we are asking the disclosee to undertake, on the record, that they shall process the data as per the law permits. (the question of 'proper' retention periods is a mere subset of this); unless we have evidence to the contrary, which tends to confirm that this is not the case (past complaints of conviction etc), it is not in our power to verify this statement (unless of course we are so empowered by the relevant national powers that be).
I agree with Marc, we must place a realistic emphasis on the ability to enforce, (as the gating questions rightly noted). If we merely are paying lip service to a confirmation that the entity or person to whom we are disclosing data to is 'compliant' with applicable data protection law. A 'tick box' assertion is of little value in assessing legality. We would require some form of objective proof for this assertion to mitigate* legal liability.* Definitely agree that it is worthwhile to get the assertion as a matter of *contractual obligation*, as it enables a disclosing controller to call in an indemnity for a breach this condition in the contract; but it provides little or no comfort to the disclosing controller as to whether that disclosure is legally permitted or not. This is falling into that trap of legal liability vs getting an indemnification in the contract .
In short I approve of us asking the question, 'are you compliant with the law?' It is a good assertion to get on the record, *BUT* I would suggest having the answer does not really make our action to disclose more likely to be 'legally sound', it just makes it easier for us to claim indemnification for a breach of contract.
Sorry - long winded but I think we should get our 'safe-guard' priorities straight here !
Alan
[image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
<https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Mon, Oct 7, 2019 at 5:03 PM 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> <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_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 listGnso-epdp-team@icann.orghttps://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. _______________________________________________ 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.
_______________________________________________ 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.
participants (6)
-
Alan Woods -
Anderson, Marc -
Ayden Férdeline -
Becky Burr -
Caitlin Tubergen -
Volker Greimann