Skip to main content

Introducing ICANN’s Chief Data Protection Officer (CDPO)

Data protection and privacy laws and regulations are constantly evolving. One of the ICANN organization’s top priorities continues to be data protection and privacy compliance and maintaining the security of personal data we collect in the course of our operations. As part of the ICANN organization’s overall data protection and privacy governance framework, we are creating a new role: the Chief Data Protection Officer (CDPO).

We have asked Daniel Halloran to be ICANN’s Chief Data Protection Officer. Dan will take on this role, in addition to his current responsibilities as Deputy General Counsel. Dan has been deeply involved in our efforts surrounding data privacy and protection, and he will be an excellent fit for this new role. Dan will continue to report to me in both roles.

The CDPO will focus on ICANN organization-level data, to ensure ICANN’s internal data protection and privacy program is compliant and up to date. While this is a new role within the ICANN organization, it’s by no means a new type of position. Many similar-sized organizations that collect and retain personal data also have a CDPO (or similarly named ‘chief privacy officer’).

The CDPO will also advise the ICANN organization on how to best handle and process personal information we collect, as we continue to fulfill our core commitments and obligations and provide both internal and external services in a compliant manner.

This position allows us to be even more responsive to changes in data privacy regulations, working closely with our internal teams to ensure our personal data processing activities are in line with our overall data protection and privacy framework. In this role, Dan will conduct regular reviews and risk assessments to ensure our organizational actions remain in compliance with applicable laws, regulations and internal policies.

The organization-level role is not intended to cover the use of data by Registrars and Registries under ICANN’s contracts, which is part of the broader discussion relating to the European General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) and the impact of these regulations on ICANN contracts, which is a discussion taking place in broader ICANN community discussions.

Creating this new position is an important step, and supplements other ongoing processes we’re undertaking in regards to data privacy. To get an idea of the other related projects being worked on, please visit


    Jual Obat Aborsi  04:51 UTC on 07 August 2017

    saya setuju dengan itu... good post

    Thomas Plantu  06:35 UTC on 09 August 2017

    Thank you, Data Protection is indeed very important.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."