[Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion

Fri Feb 8 17:23:43 UTC 2019

Isn’t “legally binding” required, even for “agreement”?

From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> On Behalf Of Emily Taylor
Sent: Friday, February 8, 2019 5:06 AM
To: Alan Woods <alan at donuts.email>
Cc: GNSO EPDP <gnso-epdp-team at icann.org>
Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion

Hi all

I support Alan's point of view. While I understand the need to retain flexibility, and to avoid overly restrictive language that will cause problems later on, the word 'arrangement' could mean almost anything - from something that imposes legal benefits and responsibilities to something that's very informal, undocumented and just a way of working.

So, I support use of the word 'agreement' instead of 'arrangement'.

Best wishes

Emily

On Fri, Feb 8, 2019 at 1:02 PM Alan Woods <alan at donuts.email<mailto:alan at donuts.email>> wrote:
Just to be exceptionally clear and although I do not wish to belabor the point any farther, I still submit, on the record, that the correct term to be used in the recommendation is 'AGREEMENT'

Whereas I appreciate that ICANN have mirrored the GDPR language of Art 26 in their use of the word of 'arrangement' I believe it would make more sense to consider the subsequent interpretation of their lead DPA (i.e Belgium, as confirmed by the Belgian Autorité de Protection des Données (APD) letter of 15th January 2019 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-15jan19-en.pdf>  and the therein referenced letter of September 26th, 2018<https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-26sep18-en.pdf> ).

I would therefore respectfully submit that it remains more proper for our recommendation to therefore consider and mirror the Belgian legislatures and the APD's interpretation of the GDPR as being our  guiding, if not determinative factor:

1)  Article 52 of the  Loi relative à la protection des personnes physiques à l’égard des traitements de données à caractère personnel (30 July 2018)<http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&chercher=t&choix1=ET&fr=f&choix2=ET&numero=12&table_name=LOI&fromtab=loi_all&imgcn.x=32&DETAIL=2018073046/F&nm=2018040581&imgcn.y=3&ddda=2018&sql=dt+contains++%27LOI%27+and+dd+=+date%272018-07-30%27and+actif+=+%27Y%27&rech=12&tri=dd+AS+RANK+&trier=promulgation&dddj=30&cn=2018073046&row_id=1&caller=image_a1&dddm=07&la=F&pdf_page=10&pdf_file=http://www.ejustice.just.fgov.be/mopdf/2018/09/05_1.pdf> (see page 27 of the Gazette as linked) requires

 " Un accord définit de manière transparente les obligations respectives des responsables conjoints de traitement, " [emphasis added],

Which translates to "an agreement which defines the respective obligations of the joint controllers" [emphasis added]

2) The  APD have also released a legal notation of the July 2018 law<https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/documents/Notions_RT_ST.pdf>, and they note the joint controller requirement as being "par voie d’accord' (see page three under heading   or again to translate, is an "by agreement". (see page 3 under the heading "Responsables conjoints de traitment")

Therefore I still believe and submit that the ePDP teams original wording of "agreement" should stand, and I don't believe that ICANN's reference to their past statement i.e.  "arrangement” could take the form of an agreement, a policy, or a specification" is sufficient as it dilutes the expectation of the APD. This is not sufficiently specific in the circumstances; nor does it provide the comfort that the ePDP team is seeking in this recommendation from ICANN.

Kind regards,

Alan

[Donuts Inc.]<http://donuts.domains>

Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
________________________________
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Ireland

[http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://www.facebook.com/donutstlds>  [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc>   [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh at gmail.com<mailto:kavouss.arasteh at gmail.com>> wrote:
Dear Kurt
I have indicated at several occasions that when we refer to an action to be performed by two parties / entities ,we need to indicated " as mutually agreed" The proposed text to be amended to read as below
The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties, "AS MUTUALLY AGREED "  that determine the purpose and means of the processing. [Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.]
Action:
Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed.
Deadline: Monday, 28 January, additional email discussion might follow depending on responses.
Please kindly insert that in the text
Regards
Kavouss

On Thu, Jan 24, 2019 at 12:23 AM Kurt Pritz <kurt at kjpritz.com<mailto:kurt at kjpritz.com>> wrote:
Hi Everyone:
With the goal of progressing on issues via email, the leadership team has considered the discussion provided during the Toronto meeting and suggests the following compromise language to address the different positions expressed. (This is a resend of an earlier email with only the subject line of the email updated.)
Discussion
The language below is the same language proposed by the small team that reviewed the comments, but modified:

  *   as suggested by Diane during the meeting to reflect that GDPR Art 28 is unlikely to apply in this situation, and
  *   by an addition (bracketed & bolded below) to reference the analysis in the Final Report that this team recommends the creation of Joint Controller Agreements, to appropriately influence the negotiation of GDPR-compliant agreements.

This language is intended to strike a balance between those preferring to leave some flexibility for ICANN Org and Contracted Parties to consider the appropriate agreements and those preferring to be specific about the type of agreement to be pursued.
I understand this is a complex topic that might require additional discussion but it is also possible that we cannot be dispositive on this issue prior to a lengthy contract formation discussion that extends well beyond our time frames. For that reason, we are taking the liberty of making this recommendation and hope you accept it in the spirit it is offered.
Proposed Recommendation #13 Language
The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. [Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.]
Action:
Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed.
Deadline: Monday, 28 January, additional email discussion might follow depending on responses.
Sincerely,
Kurt

_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team

--

Emily Taylor

CEO, Oxford Information Labs
MA (Cantab), Solicitor (non-practising), MBA,

Associate Fellow, Chatham House; Editor, Journal of Cyber Policy

Lincoln House, Pony Road, Oxford OX4 2RD | T: 01865 582885
E: emily.taylor at oxil.co.uk<mailto:emily.taylor at oxil.co.uk> | D: 01865 582811 | M: +44 7540 049322

[https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQpU8&export=download]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[https://docs.google.com/a/oxil.co.uk/uc?id=0B7sS_6djDxsHNm92d21jM21HMDQ&export=download]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>

Registered office: Lincoln House, 4 Pony Road, Oxford OX4 2RD. Registered in England and Wales No. 4520925. VAT No. 799526263

.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190208/95ad4d3c/attachment-0001.html>