[IRT.RegDataPolicy] One Doc follow up on Escrow

[Anderson, Marc]

Dennis and IRT/IPT members,

A couple meetings ago we discussed Section 9 in the One Doc covering Rec 8 (escrow).  We don't seem to have finished that discussion and the One Doc currently contains two different versions.  The first section in Rec #8 covers the important recommendation that ICANN Org enter into legally-compliant data protection agreements with the data escrow providers.  Can you provide an update on the status of that recommendation?  Implementation of that recommendations is important for all parties in complying with GDPR.

In looking at the different proposed versions of the policy language, I note inconsistencies with the policy recommendations.  The new version in particular takes the approach of if the data is collected, it MUST be escrowed.  This is not what the policy recommendations say.  For context, the working group took into account the GDPR principles of privacy by design and data minimization.  For each processing activity, the working group carefully considered what data (elements) is necessary to achieve the purpose.  In the case of escrow, the processing activity is the transfer of data from registry/registrar to the escrow provider (and if conditions are met, disclosure of that data).  The purpose is captured in Rec #1 section 4) "Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure of a Registrar or Registry Operator, or unavailability of a Registrar or Registry Operator, as described in the RAA and RA, respectively".  The if you collect the data, you MUST escrow it approach, does not reflect the work of phase 1 EPDP to update policies and contractual requirements to help enable compliance with GDPR.

To provide a specific example, the new section 9.1 (9.1.13, 9.1.14 and 9.1.15) and the previous section 9.2 (9.2.1, 9.2.2 and 9.2.3) state that the Registrar MUST escrow the Tech Name, Phone and Email fields IF collected or generated.  The table in Rec 8 on pages 10 and 11 of the final report lists each of those fields as optional.  The working group did not determine that processing those 3 fields is necessary to achieve the purpose.

As noted in the recommendations, the workbooks in Annex D provide additional information.  The table on page 122 is specific to this example.  For the Tech Name, Phone and Email fields, the "collection" of each of those data elements is O-RNH (Registered Name Holder) meaning it is up to the Registered Name Holder to decide if they want to supply data for those fields.  For "transmission" each of those data elements is O-CP (Contracted Party) meaning it is up to the Contracted Party to decide if data for those fields will be transmitted to the escrow provider.

I hope that context helps in drafting policy language consistent with the policy recommendations.

Best,
Marc