Registration Data Policy

Registration Data Policy

1. Introduction
2. Scope
3. Definitions and Interpretation
4. Policy Effective Date
5. Data Protection Agreement
6. Collection of Registration Data
7. Transfer of Registration Data from Registrar to Registry Operator
8. Transfer of Registration Data to Data Escrow Providers
9. Publication of Domain Name Registration Data
10. Disclosure Requests
11. Log Files
12. Retention of Registration Data

Addendum I

Addendum II

Implementation Notes

1. Processing of Registration Data
2. Transfer of Registration Data
3. Transfer of Registration Data to Escrow Providers
4. Publication of Registrant Organization
5. Response to Reasonable Requests for Lawful Disclosure
6. Retention of Registration Data
7. Affiliated and Accredited Privacy or Proxy Services
8. Creation Date
9. Updated Date

Background

Registration Data Policy

1. Introduction

   The Registration Data Policy ("Policy") is an ICANN Consensus Policy that describes requirements for Processing Registration Data for each ICANN-accredited Registrar ("Registrar") and gTLD Registry Operator that has an agreement with ICANN ("Registry Operator").

2. Scope

   2.1. This Policy applies to each ICANN-accredited Registrar and Registry Operator that has an agreement with ICANN.

   2.2. Registry Operator's and Registrar's Processing of Personal Data contained in Registration Data for purposes other than the purposes identified in the Data Protection Agreement required by Section 5 is beyond the scope of this Policy.

3. Definitions and Interpretation

   3.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

   3.2. "Consent" of a Data Subject means any freely given, specific, informed, and unambiguous indication of the Data Subject's wishes in which the Data Subject, by a statement or by a clear affirmative action, signifies agreement to the Processing of Personal Data relating to the Data Subject.

   3.3. "Personal Data" means any information relating to an identified or identifiable natural person (a "Data Subject").

   3.4. "Processing" means any operation or set of operations which is performed on Personal Data or on sets of Personal Data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.

   3.5. "Publication", "Publish", and "Published" means to provide Registration Data in the publicly accessible Registration Data Directory Services.

   3.6. "Registration Data" means the data element values collected from a natural or legal person or generated by Registrar or Registry Operator, in either case in connection with a Registered Name in accordance with Section 6 of this Policy.

   3.7. "Reasonable Requests for Lawful Disclosure" ("Disclosure Requests") refers to requests submitted to a Registry Operator or Registrar for the disclosure of non-public Registration Data in accordance with the requirements of Section 10.

   3.8. Terms capitalized but not defined in this Policy SHALL have the meaning given to them in the Registry Agreement or Registrar Accreditation Agreement, as applicable.

   3.9. When Registry Operator and Registrar are referenced together in a provision of this Policy, each such provision represents a separate requirement and obligation of each Registry Operator and each Registrar pursuant to its respective Registry Agreement or Registrar Accreditation Agreement.

4. Policy Effective Date

   This Policy is effective on 21 August 2025. The Interim Registration Data Policy for gTLDs will remain in effect until 20 August 2025. During the period of 21 August 2024 through 20 August 2025, Registry and Registrar may continue to implement measures consistent with the Temporary Specification for gTLD Registration Data or this policy in its entirety, or elements of both.

5. Data Protection Agreement

   ICANN, gTLD Registry Operators, and accredited Registrars MUST enter into required data protection agreements with each other and with relevant third party providers contemplated under this Policy where applicable law requires. The terms may include legal bases for processing Registration Data.

   Where such agreements between Registry Operator or Registrar and ICANN are required to comply with applicable law, ICANN MUST upon request and without undue delay, enter into data protection agreement or agreements with Registry Operator or Registrar as implemented pursuant to this Policy.

   If Registry Operator or Registrar determines that such agreements are required by applicable law, it MUST make the request without undue delay pursuant to this policy.

   The data protection agreements MAY also be modified and updated from time-to-time based on additional guidance from relevant data protection authorities as provided for by applicable law.

6. Collection of Registration Data

   6.1. Registrar MUST collect or generate (marked with an asterisk) values for the following data elements:

   6.1.1. Domain Name

   6.1.2. Registrar Whois Server*

   6.1.3. Registrar URL*

   6.1.4. Registrar*

   6.1.5. Registrar IANA ID*

   6.1.6. Registrar Abuse Contact Email*

   6.1.7. Registrar Abuse Contact Phone*

   6.1.8. Domain Status(es)*

   6.1.9. Registrant Name

   6.1.10. Registrant Street

   6.1.11. Registrant City

   6.1.12. Registrant State/Province

   6.1.13. Registrant Postal Code

   6.1.14. Registrant Country

   6.1.15. Registrant Phone

   6.1.16. Registrant Email

   6.1.17. Registrar Registration Expiration Date*

   "State/Province" and "Postal Code" values are only required to be collected if applicable for the country or territory, as defined in UPU postal addressing standards or other equivalent standards for the country or territory.

   "Registrar Whois Server" value is only required to be generated if required by the Registrar Accreditation Agreement or ICANN Consensus Policy.

   6.2. Registrar MAY provide the opportunity for the Registered Name Holder to provide values for the following data elements. If the Registrar offers the collection of the value and Registered Name Holder elects to provide the value, Registrar MUST collect it:

   6.2.1. Registrant Phone Ext

   6.2.2. Registrant Fax

   6.2.3. Registrant Fax Ext

   6.2.4. Tech Name

   6.2.5. Tech Phone

   6.2.6. Tech Email

   6.3. If the Registered Name Holder provides a technical contact, Registrar MUST advise the Registered Name Holder at the time of registration that in lieu of providing personal contact information, the Registered Name Holder may (a) designate the same person as the Registered Name Holder (or its representative) as the technical contact; or (b) provide contact information that does not constitute personally identifiable information of the technical contact (for example, an email address of tech-assistance@example.org instead of john.doe@example.org).

   6.4. Registrar MAY generate the Reseller data element value.

   6.5. Registrar MUST provide the opportunity for the Registered Name Holder to provide values for the following data elements. If provided by the Registered Name Holder, Registrar MUST collect the following data element values:

   6.5.1. Registrant Organization

   6.5.2. Name Server(s)

   6.5.3. Name Server IP Address(es)

   6.5.4. DNSSEC Elements

   6.6. If the Registered Name Holder enters a value for the Registrant Organization data element, Registrar MUST inform the Registered Name Holder that:

   6.6.1. The Registrant Organization will be published in RDDS if the Registered Name Holder agrees to the publication of the value; and

   6.6.2. The Registrant Organization will be considered the Registered Name Holder.

   6.7. Registrar MAY collect additional data elements as required by its Registry-Registrar Agreement and/or the Registry Operator's Registration Policy.

   6.8. Registrar MAY delete administrative contact data that was collected prior to the effective date of this Policy. Prior to deleting administrative contact data, Registrar MUST ensure that the values for the required Registered Name Holder data elements in Sections 6.1.9 through 6.1.16 have been collected.

7. Transfer of Registration Data from Registrar to Registry Operator

   7.1. Registrar MUST transfer the following data elements to Registry Operator:

   7.1.1. Domain Name

   7.1.2. Registrar URL

   7.1.3. Registrar

   7.1.4. Registrar IANA ID

   7.1.5. Registrar Abuse Contact Email

   7.1.6. Registrar Abuse Contact Phone

   7.1.7. Domain Status(es)

   7.2. Registrar MUST transfer the following data elements to Registry Operator if collected or generated:

   7.2.1. Registrar Whois Server

   7.2.2. Name Server(s)

   7.2.3. Name Server IP Address(es)

   7.2.4. DNSSEC Elements

   7.3. Registrar MUST transfer the following data elements to Registry Operator provided an appropriate legal basis exists and data processing agreement is in place.

   7.3.1. Registrant Name

   7.3.2. Registrant Street

   7.3.3. Registrant City

   7.3.4. Registrant Country

   7.3.5. Registrant Phone

   7.3.6. Registrant Email

   7.4. Registrar MUST transfer the following data elements to Registry Operator, if collected, provided an appropriate legal basis exists and data processing agreement is in place:

   7.4.1. Registrant Organization

   7.4.2. Registrant State/Province

   7.4.3. Registrant Postal Code

   7.4.4. Registrant Phone Ext

   7.4.5. Registrant Fax

   7.4.6. Registrant Fax Ext

   7.4.7. Tech Name

   7.4.8. Tech Phone

   7.4.9. Tech Email

   7.5. Registrar MAY transfer the following data elements to Registry Operator if supported by the Registry Operator:

   7.5.1. Registrar Registration Expiration Date

   7.5.2. Reseller

8. Transfer of Registration Data to Data Escrow Providers

   8.1. Registrar MUST submit an electronic copy, in a format specified by ICANN, of the following data elements to an ICANN-approved data escrow agent:

   8.1.1. Domain Name

   8.1.2. Registrar Registration Expiration Date

   8.1.3. Registrar IANA ID

   8.1.4. Registrant Name

   8.1.5. Registrant Street

   8.1.6. Registrant City

   8.1.7. Registrant State/Province

   8.1.8. Registrant Postal Code

   8.1.9. Registrant Country

   8.1.10. Registrant Phone

   8.1.11. Registrant Email

   "State/Province" and "Postal Code" values are not required to be transferred if not available for the applicable country or territory.

   8.2. If Registrar collects or generates the following data elements, Registrar MUST submit an electronic copy, in a format specified by ICANN, to an ICANN-approved data escrow agent:

   8.2.1. Registrant Organization

   8.3. If Registrar collects or generates any of the below data elements, Registrar MAY submit an electronic copy, in a format specified by ICANN, of the data elements described below to an ICANN-approved data escrow agent:

   8.3.1. Reseller

   8.3.2. Registrant Phone Ext

   8.3.3. Registrant Fax

   8.3.4. Registrant Fax Ext

   8.3.5. Tech Name

   8.3.6. Tech Phone

   8.3.7. Tech Email

   8.4. Registry Operator MUST submit an electronic copy, in a format specified by ICANN, of the following data elements to an ICANN-approved data escrow agent:

   8.4.1. Domain Name

   8.4.2. Registry Domain ID

   8.4.3. Registrar URL

   8.4.4. Creation Date

   8.4.5. Registry Expiry Date

   8.4.6. Registrar

   8.4.7. Registrar IANA ID

   8.4.8. Registrar Abuse Contact Email

   8.4.9. Registrar Abuse Contact Phone

   8.4.10. Domain Status(es)

   8.5. Registry Operator MUST submit an electronic copy, in a format specified by ICANN, of the following data elements to an ICANN-approved data escrow agent if transferred from Registrar or generated by Registry Operator:

   8.5.1. Registrar Whois Server

   8.5.2. Updated Date

   8.5.3. Registrar Registration Expiration Date

   8.5.4. Reseller

   8.5.5. Registry Registrant ID

   8.5.6. Registrant Name

   8.5.7. Registrant Organization

   8.5.8. Registrant Street

   8.5.9. Registrant City

   8.5.10. Registrant State/Province

   8.5.11. Registrant Postal Code

   8.5.12. Registrant Country

   8.5.13. Registrant Phone

   8.5.14. Registrant Phone Ext

   8.5.15. Registrant Fax

   8.5.16. Registrant Fax Ext

   8.5.17. Registrant Email

   8.5.18. Name Server(s)

   8.5.19. DNSSEC Elements

   8.5.20. Name Server IP Address(es)

   8.6. Registry Operator MAY submit an electronic copy, in a format specified by ICANN, of the following data elements to an ICANN-approved data escrow agent if transferred from Registrar or generated by Registry Operator:

   8.6.1. Registry Tech ID

   8.6.2. Tech Name

   8.6.3. Tech Phone

   8.6.4. Tech Email

9. Publication of Domain Name Registration Data

   9.1. RDDS Publication Requirements

   9.1.1. In responses to RDDS queries, Registrar and Registry Operator MUST Publish the following data elements:

   9.1.1.1. Domain Name

   9.1.1.2. Registrar URL

   9.1.1.3. Creation Date

   9.1.1.4. Registry Expiry Date (exception: Registrar MAY Publish)

   9.1.1.5. Registrar Registration Expiration Date (exception: Registry Operator MAY Publish)

   9.1.1.6. Registrar

   9.1.1.7. Registrar IANA ID

   9.1.1.8. Registrar Abuse Contact Email

   9.1.1.9. Registrar Abuse Contact Phone

   9.1.1.10. Domain Status(es)

   9.1.1.11. Last Update of RDDS

   9.1.2. In responses to RDDS queries, Registrar and Registry Operator MUST Publish the following data elements if collected, transferred, or generated:

   9.1.2.1. Registrar Whois Server

   9.1.2.2. Updated Date

   9.1.2.3. Name Server(s)

   9.1.2.4. DNSSEC Elements

   9.1.3. In responses to RDDS queries and subject to the requirements of Section 9.2, (a) Registrar MUST Publish the following data elements if collected or generated, and (b) Registry MUST Publish the following data elements if transferred from Registrar or generated by Registry Operator:

   9.1.3.1. Registry Domain ID

   9.1.3.2. Registry Registrant ID

   9.1.3.3. Registrant Organization

   9.1.3.4. Registrant Postal Code

   9.1.3.5. Registry Tech ID

   9.1.3.6. Tech Name

   9.1.3.7. Tech Phone

   9.1.3.8. Tech Email

   9.1.4. In responses to RDDS queries, (a) Registrar MUST Publish the Registrant State/Province data element if collected, and (b) Registry Operator MUST Publish the Registrant State/Province data element if transferred from Registrar.

   9.1.5. In responses to RDDS queries, (a) Registrar MUST Publish the Registrant Country data element and (b) Registry Operator MUST Publish the Registrant Country data element if transferred from Registrar.

   9.1.6. In responses to RDDS queries and subject to the requirements of Section 9.2, (a) Registrar MUST Publish the following data elements and (b) Registry MUST Publish the following data elements if transferred from Registrar:

   9.1.6.1. Registrant Name

   9.1.6.2. Registrant Street

   9.1.6.3. Registrant City

   9.1.6.4. Registrant Phone

   9.1.6.5. Registrant Email

   9.1.7. In responses to RDDS queries, Registrar and Registry Operator MAY Publish the Reseller data element.

   9.1.8. In responses to RDDS queries, Registrar MAY Publish the Name Server IP Address(es) data element.

   9.1.9. In responses to RDDS queries, Registry Operator:

   9.1.9.1. MUST Publish the Name Server IP Address(es) data element when the Registry Agreement calls for the publication of in-domain glue records (as defined in RFC8499).

   9.1.9.2. MAY Publish the Name Server IP Address(es) data element when not required by the Registry Agreement.

   9.1.10. In responses to RDDS queries and subject to the requirements of Section 9.2, Registrar and Registry Operator MAY Publish the following data elements:

   9.1.10.1. Registrant Phone Ext

   9.1.10.2. Registrant Fax

   9.1.10.3. Registrant Fax Ext

   9.2. Redaction Requirements for Publication of Registration Data

   9.2.1. Registry Operator and Registrar: (a) MUST apply the requirements of Section 9.2 in RDDS if redaction of Personal Data contained in Registration Data is required in order to comply with applicable law; (b) MAY apply the requirements of Section 9.2 IF (i) they have a commercially reasonable purpose to do so; OR (ii) where it is not technically feasible to limit application of the requirements of this section. In determining whether to apply the requirements of Section 9.2, Registry Operator and Registrar MAY, but are not required to, consider whether Registration Data pertains to a legal person or contains Personal Data; and the geographic location of the Registered Name Holder or relevant contact.

   9.2.2. For the purposes of Section 9.2, Redact is defined as satisfying the following conditions: Registry Operator and Registrar (a) MUST NOT include the value of the data element in the RDDS output and (b) MUST indicate that the value is redacted.

   9.2.2.1. Where Registry Operator or Registrar applies the requirements in Section 9.2.1, it MUST Redact the values for the following data elements subject to the exceptions outlined in the following subsections:

   9.2.2.1.1. Registry Domain ID

   9.2.2.1.2. Registry Registrant ID

   9.2.2.1.3. Registrant Name

   9.2.2.1.4. Registrant Street

   9.2.2.1.5. Registrant Postal Code

   9.2.2.1.6. Registrant Phone

   9.2.2.1.7. Registrant Phone Ext

   9.2.2.1.8. Registrant Fax

   9.2.2.1.9. Registrant Fax Ext

   9.2.2.1.10. Registry Tech ID

   9.2.2.1.11. Tech Name

   9.2.2.1.12. Tech Phone

   9.2.2.2. Where Registry Operator applies the requirements in Section 9.2.1, Registry Operator MUST Redact the values for the following data elements:

   9.2.2.2.1. Registrant Email

   9.2.2.2.2. Tech Email

   9.2.2.3. Where Registry Operator applies the requirements in Section 9.2.1, Registry Operator MAY Redact the Registrant Organization value.

   9.2.2.4. Where Registrar or Registry Operator applies the requirements in Section 9.2.1, it MAY Redact the Registrant City value.

   9.2.3. Where Registrar applies the requirements in Section 9.2.1, for the following data elements, Registrar MUST Publish an email address or a link to a web form to facilitate email communication with the relevant contact for the Email value, which MUST NOT identify the contact email address or the contact itself.

   9.2.3.1. Registrant Email

   9.2.3.2. Tech Email

   9.2.4. Where Registrar applies the requirements of Section 9.2.1 to the values of the data elements listed in Sections 9.2.2.1.1 through 9.2.2.1.9, 9.2.2.4, and 9.2.3.1, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to Publish the data element values. Registrar MUST Publish the value of the data element(s) for which the Registered Name Holder provided its Consent.

   9.2.5. For Registered Names using an Affiliated or Accredited Privacy or Proxy service, Registrar and Registry Operator MUST Publish the full Registration Data of the Privacy or Proxy Service, which MAY also include the existing privacy or proxy pseudonymized email.

   9.2.6. If the Registered Name Holder agrees to the Publication of the value of the Registrant Organization data element, Registrar MUST Publish the value. If the Registered Name Holder does not agree to its Publication, Registrar MAY Redact the Registrant Organization value.

10. Disclosure Requests

    10.1. Registrar and Registry Operator MUST publish on their homepage (a publicly available webpage where their domain name services are offered) a direct link to a page where the mechanism and process for submitting Disclosure Requests is detailed. The mechanism and process MUST specify (a) the required format and content of requests, (b) the means of providing a response to the requestor, and (c) the anticipated timeline for responses.

    10.2. Registrar and Registry Operator's required format and content of requests MUST include the following, at a minimum:

    10.2.1. The identity of the requestor, including:

    10.2.1.1. The contact information of the requestor,

    10.2.1.2. The nature/type of business entity or individual, and

    10.2.1.3. Power of Attorney statements or similar statements evidencing authorization to act on the requestor's behalf, where applicable and relevant.

    10.2.2. A list of data element values requested by the requestor.

    10.2.3. Information about the legal rights of the requestor and specific rationale and basis for the request.

    10.2.4. An affirmation that the request is being made in good faith.

    10.2.5. Agreement by the requestor to process lawfully any data element values received in response to the request.

    10.3. Registrar and Registry Operator MUST respond to Disclosure Requests which meet their respective required formats.

    10.4. Registrar and Registry Operator MUST consider each properly-formed Disclosure Request on its merits, considering the specific rationale and basis for each request.

    10.5. Registrar and Registry Operator MUST acknowledge receipt of a Disclosure Request which meets their respective required formats without undue delay, but no more than two (2) business days from receipt and MUST respond without undue delay, but no more than thirty (30) calendar days from acknowledgement absent exceptional circumstances.

    10.6. Responses to Disclosure Requests MUST either:

    10.6.1. Provide the requested data; or

    10.6.2. Provide rationale for why Registry Operator or Registrar cannot provide the requested data (in whole or in part) that identifies the specific reason(s) for such denial, including a clear explanation of how it arrived at its decision that is sufficient for a requestor to objectively understand the reasons for the decision. This includes an analysis and explanation of how the fundamental rights and freedoms of the data subject were weighed against the legitimate interest of the requestor (if applicable).

    10.7. Registry Operator or Registrar MAY take corrective action to address abusive requests/requestors. Corrective action MAY include denying repetitive or incomplete requests, requiring additional information as a default for abusive requestors, and other measures it deems appropriate. The corrective actions taken MUST be communicated to the Requestor

11. Log Files

    11.1. Where Registrar applies the requirements in Section 9.2.3, the Registrar:

    11.1.1. MUST maintain log files that confirm that a relay of the communication from the requestor to the Registered Name Holder email address has occurred. The log files MUST NOT include the origin, recipient, contents of the message, or any Personal Data.

    11.1.2. MAY maintain log files that confirm that a relay of the communication from the requestor to the Tech email address has occurred. The log files MUST NOT include the origin, recipient, contents of the message, or any Personal Data.

    11.1.3. MUST make available, the log files related to the relay of communication to the Registered Name Holder email, to ICANN org for compliance purposes upon request. Nothing in this provision should be construed to prevent Registrar from taking reasonable and appropriate action to prevent the abuse of Registrar's contact process.

    11.2. Registry Operator and Registrar MUST maintain logs of requests, acknowledgements, and responses to Disclosure Requests in accordance with standard business recordation practices, so that they are available to be produced as needed including, but not limited to, for audit purposes by ICANN org.

12. Retention of Registration Data

    Registrar MUST retain those data elements necessary for the purposes of the Transfer Dispute Resolution Policy for a period of no less than fifteen (15) months following end of Registrar's sponsorship of the registration or an inter-registrant (change of registrant) transfer of the registration.

Addendum I

Implementation of WHOIS (available via port 43) and web-based Whois directory services SHALL comply with:

1. For data elements where no value data has been collected, generated, or transferred, (a) the key (i.e., the string to the left of the colon) MUST be shown with no information in the value section (i.e., right-hand side of the colon) of the field; or (b) no key or value MUST be shown.
2. For data elements where there is value data and subject to the requirements in Section 9.2.2 of this Policy, the value section (i.e., right-hand side of the colon) MUST be replaced with the string "REDACTED".

Note: this Addendum I applies to each Registrar and Registry Operator providing WHOIS (available via port 43) or web-based Whois directory services.

Addendum II

For existing domain name registrations with creation dates prior to the effective date of this Policy:

1. Registrar MUST contact Registered Name Holders that have entered a value for the Registrant Organization data element and (a) request review and confirmation from the Registered Name Holder that the value is correct; and (b) confirm whether the Registered Name Holder agrees to publication of the Registrant Organization value.
2. If the Registered Name Holder confirms or corrects the value of the Registrant Organization, and agrees to its Publication, Registrar MUST (a) notify the Registered Name Holder that the Registrant Organization value will be treated as non-Personal Data and be Published by the effective date of this Policy and (b) Publish the Registrant Organization value as described in Section 9.1.3 by the effective date of this Policy.
3. If the Registered Name Holder declines publication of the Registrant Organization value, or does not respond to the query, the Registrar, as described in Section 9.2.6, MAY Redact (as defined in Section 9.2.2) the Registrant Organization value, or MAY delete the Registrant Organization value that was collected prior to the effective date of this Policy. Prior to deleting Registrant Organization value, Registrar MUST ensure that the value for the required Registered Name Holder data element in Section 6.1.9 has been collected.

Implementation Notes

1. Processing of Registration Data:

   1. Nothing in this Policy prohibits Registry Operator or Registrar from processing data for other purposes, which are beyond the scope of this Policy. For example:
      1. The collection of credit card information for the purpose of processing a payment for a domain name registration.
      2. The collection or generation of additional data elements in order to create a contact, such as: <contact:id>, <contact:authInfo>; or technical contact city (<contact:city>) and country (<contact:cc>).
      3. If Registrar collects additional contact data, it may Publish the relevant contact data in the RDDS. For example, if Registrar collects technical contact data from the Registered Name Holder under Section 6.2 and redacts the data elements values listed in Sections 9.2.2.1.10 through 9.2.2.1.12, Registrar MAY provide the opportunity for the relevant contact to provide Consent to Publish the data element values. Registrar MAY Publish the data element value(s) for which the relevant contact has provided its Consent.

2. Transfer of Registration Data

   1. Nothing in this Policy prevents Registrar or Registry Operator from transferring additional data elements to the data escrow agent (for example: for the provision of Registry Services as defined in the Registry Agreement).
   2. Nothing in this Policy prevents Registry Operator from requiring Registrar to transfer additional data element values provided a legal basis exists, where a legal basis is required by applicable law.
   3. If a legal basis is required to transfer data from Registrar to Registry Operator pursuant to Section 7, the determination of legal basis will be made by the parties of the transfer. The existence of a legal basis is not determined by ICANN org or subject to enforcement. In the event that the Registry Operator and Registrar establish the existence of a legal basis, and the Registry Operator and Registrar have entered into a data protection agreement that covers the data to be transferred, ICANN org may be able to enforce the transfer requirements under Section 7.
   4. Registry Operator and Registrar are not required to establish legal basis to process Personal Data, including transfer from Registrar to Registry Operator, if not required by applicable law.

3. Transfer of Registration Data to Escrow Providers

   For purposes of clarity, pursuant to the applicable Registry Agreement, Registry Operator must escrow all data elements necessary in order to offer all of its approved Registry Services

4. Publication of Registrant Organization

   1. The Registrant Name will be considered the point of contact at the Registrant Organization.
   2. Registrar may use its own process to obtain the Registered Name Holder's agreement to publish the Registrant Organization value and inform the Registered Name Holder of the requirements in Sections 6.6.1 and 6.6.2, for example, by presenting a disclosure, disclaimer, or request for confirmation of the value of the Registrant Organization and agreement to its publication, by way of a pop-up window advisory, opt-in requirement, graying out the Registrant Organization until the Registrant explicitly agrees to the data element's publication (by checking a box), etc. These examples do not provide an exhaustive list.

5. Response to Reasonable Requests for Lawful Disclosure

   In assessing Registrar's or Registry Operator's response time for Disclosure Requests, ICANN org may consider: the number of requests received; the number of domain names under management; the average response time; and the number of requests denied.

6. Retention of Registration Data

   1. Nothing in this policy prohibits Registrar and Registry Operator from setting retention periods, if required by law, legal proceedings, or other appropriate legal basis, which may include Requesting a Waiver of Data Retention Obligations as appropriate.
   2. Registrar does not need to seek a waiver to establish longer retention periods. ICANN org's data retention waiver procedure permits registrar to request shorter data retention periods.
   3. For purposes of clarity, the data retention requirement in Section 12 applies to Registration Data only (as defined within this Policy) and does not prevent Requestors, including ICANN Compliance, from requesting disclosure of these retained data elements for purposes other than Transfer Dispute Resolution Policy (TDRP).

7. Affiliated and Accredited Privacy or Proxy Services

   Affiliated is defined in the Registrar Accreditation Agreement Section 1.3 and further explained in Registrar Accreditation Agreement Section 1.7. Accredited Privacy or Proxy service providers, if and when available, will be subject to this requirement beginning on the effective date of the Privacy and Proxy Services Accreditation Policy

8. Creation Date

   "Creation Date" for the purposes of this policy refers to the point in time when the creation of the domain object took place in the registry database.

9. Updated Date

   For Registrar, the "Updated Date" for the purposes of this policy refers to the most recent update on any of the data elements listed in Section 7 that took place in the registrar database or the registry database.

Background

On 17 May 2018, the ICANN Board adopted the Temporary Specification for gTLD Registration Data. The Temporary Specification modified existing requirements in the Registrar Accreditation and Registry Agreements to comply with the European Union's General Data Protection Regulation (GDPR), to ensure continued availability of the WHOIS service to the greatest extent possible and other processing of gTLD registration data while complying and avoid fragmentation of WHOIS. In accordance with the ICANN Bylaws and the Consensus Policies and Temporary Policies specifications in the Registry Agreement (RA) and Registry-Registrar Agreement (RAA), the Temporary Specification can only remain in force for up to one year from the effective date of 25 May 2018.

On 19 July 2018, the Generic Names Supporting Organization (GNSO) Council initiated an Expedited Policy Development Process (EPDP) to be developed in two phases, and chartered the EPDP on the Temporary Specification for gTLD Registration Data Team. During Phase 1 of its work, the EPDP Team was tasked with determining if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy as is, or with modifications. In addition, the charter directed that the result must comply with the GDPR and take into account other relevant privacy and data protection laws. The purpose of Phase 2 of the EPDP Team's charter was to evaluate a System for Standardized Access/Disclosure of non-public gTLD Registration Data, address issues noted in the Annex to the Temporary Specification, and address other issues deferred from Phase 1.

On 21 November 2018, the EPDP Team published its Phase 1 Initial Report for public comment. The Initial Report contained the EPDP Team's preliminary recommendations and a set of questions for public comment. The EPDP Team also examined and made recommendations about: (i) the validity, legitimacy and legal basis of the purposes outlined in the Temporary Specification, (ii) the legitimacy, necessity and scope of (x) the registrar collection of registration data and (y) the transfer of data from registrars to registries, each as outlined in the Temporary Specification, and (iii) the publication of registration data by registrars and registries as outlined in the Temporary Specification.

On 20 February 2019, the EPDP Team published its Final Report, which was adopted on 4 March 2019 by the GNSO Council. ICANN org commenced a public comment period on the Final Report on 4 March 2019. The public comment proceeding sought to obtain community input prior to Board action on the final policy recommendations of the GNSO EPDP on the Temporary Specification for gTLD Registration Data. The Summary and Analysis report for the public comment was published on 23 April 2019. The Board resolved to adopt the recommendations, with some exceptions, on 15 May 2019.

A Consensus Policy Implementation Team was formed to begin work on the implementation plan. An Implementation Review Team (IRT) consisting of members of the PDP Working Group and interested community members was also formed to work with the Consensus Policy Implementation Team in line with the Consensus Policy Implementation Framework (CPIF) developed by ICANN org and adopted by the GNSO Council.

Working in advance of the Board resolution, the implementation team produced the concept of three stages of the policy implementation.

• Stage 1: Continue to implement measures consistent with the Temporary Specification for gTLD Registration Data that expires on 25 May 2019. This is an Interim Registration Data Policy while the permanent policy is prepared and published based on the recommendations,
• Stage 2: This stage will begin after the ICANN organization publishes a Registration Data Policy as a Consensus Policy and formally notifies the contracted parties. During this stage, contracted parties may implement the Interim Policy, the Registration Data Policy, or elements of both as they prepare for the effective date of the Registration Data Policy.
• Stage 3: Contracted parties must comply with the Registration Data Policy.

On 17 May 2019, ICANN org published the Interim Registration Data Policy for gTLDs pursuant to the Board's 15 May 2019 resolution. The Interim Policy effective as of 20 May 2019 requires contracted parties to continue to implement measures consistent with theTemporary Specification for gTLD Registration Data, which expired on 25 May 2019.

The EPDP Team completed the Phase 2 of their work and published the final report consisting of four recommendations termed EPDP Phase 2 Priority 2 recommendations. On 21 June 2021, the Board adopted the Recommendations 19-22 and the implementations of these recommendations were added to the Registration Data Policy Implementation work scope.

On 24 February 2022, the Board adopted the GNSO Council's Supplemental Recommendation for EPDP Recommendation 12, concerning the deletion of data in the Organization field as it addresses the Board's overarching concern of loss of essential data.