The European Union's General Data Protection Regulation (GDPR) will come into effect as of May 25, 2018, and will change the way that Enom and it's resellers are required to handle customers' data. As such, we've been preparing to adjust our processes which will be affecting our resellers. We've created the following informational package to help with that process.  

 

Reseller resource links

 

How Enom processes data

1. Why are you applying GDPR-related changes platform-wide? I don’t have European customers, and I’d prefer not to have to accommodate these changes.

Enom's decision to implement our GDPR-related process changes platform-wide is twofold. First, there are other privacy policies with similarly strict requirements to the GDPR in place today, and it’s expected that more will be introduced as governments around the world are called on to create a policy that properly addresses the privacy concerns of our modern, digital age. It is in our best interest, and that of our resellers and registrants, to prepare for a world of heightened data sharing and privacy standards. Second, Enom believes in the principles that the GDPR upholds, and we, along with other key players in our industry, feel that extending the benefits of the GDPR to registrants worldwide is simply the right thing to do.

Back to top

2. Why does the Data use consent settings page mention Enom? I thought the whole point of wholesale services is that Enom is invisible?

Enom remains committed to providing a white-labeled solution for our resellers, but this commitment must be met in balance with the legal obligations we have as a data processor and controller. Modern privacy laws and regulations, including the GDPR, require service providers to disclose what personal data they are processing, how this data is being held and processed, and by whom it is being processed. In order for us to obtain informed, affirmative consent from registrants to process their personal data, we must be transparent about the fact that Enom is processing their data.

Back to top

3. What is the difference between consent and contract, and why does it matter whether a data element is processed based on contract or consent?

To an end-user, checking a consent box and accepting a contract may feel very similar, but legally these are two distinct concepts. Each one is a separate legal basis with unique applicabilities and limitations. Any data elements that Enom or the registry/service provider requires in order to provide a TLD or other product will be processed on a contract basis, meaning they’ll be included in our contractual agreement with the registrant. We do not need to send a consent request to process these data.

Any additional pieces of data, those that are not contractually required but are helpful to have, or have been requested by the registry but not included in their contractual requirements, can only be processed with consent from the registrant. We are also obligated to provide registrants an easy and accessible method to revoke this consent. Our Data use consent settings page accomplishes both of these tasks: collecting registrant consent, and providing them a means to revoke it. Asynchronous services are a special case in this regard because although Enom doesn’t require these additional, consent-based data, the registry or service provider does, despite the fact that they have not provided a contractual legal basis for processing them.

Back to top

4. What’s the difference between a Data Controller and a Data Processor? Is Enom a Data Controller or a Processor?

The Data Controller determines what data will be processed or selects the means of processing data, while the Processor handles the data based on the requirements set by Controllers. In cases where two different controllers determine data processing requirements for the same piece of data, they are joint controllers. So, for a domain name, the registrar is a Controller; the registry can be a Controller; and, in some cases, ICANN is also a Controller. The reseller is also a controller, as it owns the customer relationship and selected the means of processing the data, through Enom.

Here at Enom, although we don’t have a direct relationship with the domain owner, we do have a contractual one, as required by ICANN and other TLD policies. This relationship is governed by our Domain Registration Agreement, and in order for us to enter into this contract to sell a customer a domain name, we require certain pieces of personal data. These are the registrant’s first and last names, the organization name (if one is provided), their email address, and their country. So, the legal basis for us to process those pieces of data is the performance of a contract, and we are a Controller for those data elements.

The contract between us and the registry also outlines exactly which data elements the registry requires and their legal basis for collecting each piece of data. In turn, we become a Processor for those data elements which the registry requires contractually, and the registry is the Controller.

Back to top

5. How long do you keep personal data on file?

Data processed as part of fulfilling our service contract will be kept for the lifetime of the service, plus up to 7 years after the service’s termination.

Any data that we process under the legal basis of consent will be held by Enom for the same period as the contract-based data unless that consent is withdrawn, in which case it would be erased at the time of withdrawal of consent. Please note that for asynchronous services, Enom will log the registrant’s choice to revoke consent, but will direct the end-user to their reseller to cancel services. Upon canceling the service, the registrant’s choice to withdraw consent will take effect.

Back to top

6. Doesn’t ICANN policy require something different?

We will continue to comply with ICANN policy to the greatest extent possible, as we have always done. However, until ICANN policy has been updated in response to the GDPR and other similar worldwide data privacy legislation, we will be faced with many instances where the requirements that ICANN lays out for its registrars conflict with our legal obligations. In these instances, we will follow the law first and comply with ICANN as best we can.

Back to top

 

Whois information

1. Will resellers still be able to see all available Whois data or will they be required to use the gated Whois?

Resellers will be able to access all the Whois contact data that we hold for their end-users, within the reseller control panel.

Back to top

2. Why can’t I see real contact information in the public Whois anymore?

Under the GDPR, personal data may be collected and processed only when there is a legal reason to do so. One such justification would be the performance of a contract; another is a situation where the data subject (the person to whom the data pertains) has given explicit consent for their data to be processed or collected. Data can only be shared when necessary to fulfill the intended purpose of the data collection. This means that the public Whois system as it exists today is incompatible with the principles of data privacy that the GDPR affirms.

Back to top

3. Is it possible to opt-in to the display of real data in the public Whois?

At this time, it is not possible to choose to have real registrant data displayed in the public Whois record. We are working on making this option available in the near future while remaining compliant with data privacy regulations.

Back to top

4. Will the public Whois output still display domain dates, status, nameservers, and sponsoring registrar?

Yes. The technical data (the top section of current the Whois output) will show up in the public-facing lookup.

Back to top

5. In the gated Whois, what data will be displayed?

Registrant contact data which is held based on contract, or for which we have consent, will be displayed in the gated Whois — unless the domain is privacy-protected. If the domain has ID Protect, the privacy masking data will be displayed both publicly and within the gated Whois.

Back to top

6. Will the changes to the Whois affect non-EU domain registrants?

Yes. We are applying all Whois-related changes platform-wide, meaning all registrants will receive the same level of data protection regardless of citizenship or location.

Back to top

7. Will the gated Whois show information for privacy-protected domains?

Access to the gated Whois will only reveal information which was, prior to May 25, 2018, public. It will not reveal the Whois information for privacy-protected domains. In fact, the Whois output for privacy-protected domains will be the same in both the public and gated Whois, and we will continue to require a court order or other legal documentation for access to this information, as we do today.

Back to top

8. What is the difference between the gated Whois and the domain privacy Whois?

The gated Whois is a portal where accredited third-parties can access “full” Whois information, and the output available here includes personal data that is hidden from the public Whois. However, the Whois output for domains with ID Protect will remain the same as it is prior to May 2018, both in the public Whois and in the gated Whois. This means that contact privacy details, including a contact privacy email, will be displayed for domains with ID Protect in the gated Whois. For a helpful visual snapshot of the difference, check out our Whois changes blog post.

Back to top

9. How does this affect domain transfers?

We have made some minor updates to how the transfer process is accomplished.  We have removed the email standard form of authorization. Instead, we will now simply rely on the EPP code provided by the registrant as the form of authorization for inbound transfers.  Additionally, each completed inbound transfer will be treated like a new registration where a registrant verification email will be sent to the registrant email address to verify the accuracy of the domain contact information. For more information, you may refer to our Changes to the domain transfer process blog post.

Back to top

 

Understanding the end-user consent management process

1. What TLDs and products show up on the Data use consent settings page?

When a registrant visits their Data use consent settings page, they will find an up-to-the-minute list of all the active products they have registered, as well as any products which are pending consent before the order can be completed.

Back to top

2. Why are some TLDs asynchronous while others are synchronous? Why is consent sometimes required and sometimes optional?

The data elements that Enom or the GDPR-compliant provider requires are collected and processed under the legal basis of a contract. However, for some TLDs and services, the provider requests additional pieces of data for which there is no legal contractual basis to process. When this is the case, we will ask the registrant for consent to share these additional pieces of data with the provider.

In most cases, even if the registrant should withhold or fail to provide consent, Enom is still able to immediately register the domain by sending the registry a combination of the contractual data and placeholders for any data elements that can only be processed with consent. We refer to such services as “synchronous”—they can be registered right away, without the use of additional personal data beyond that which is covered in the contract.

For some TLDs, however, placeholder data will not be accepted by the registry, and because we don’t have assurance from the registry that the data will only be used in ways that conform with modern data privacy regulations such as the GDPR, Enom cannot in good conscience provide the actual data to the registry without the registrant’s consent. We refer to these types of services as “asynchronous” — because the service cannot be provided without sharing certain pieces of the registrant’s personal data with the service provider, and there is no GDPR-compliant contract to protect the data, we need the registrant’s permission to share it before we proceed. This permission must be provided in the form of affirmative consent.

Back to top

3. Why is my customer’s asynchronous domain pre-consented? They haven’t yet provided consent.

To provide an intuitive and transparent experience for the registrant, the consent status for any already active, asynchronous service is set to “yes-consent” by default. This is because the client is considered to have consented to the data processing by purchasing the service prior to these enhanced data protection requirements coming in to effect. Additionally, although consent has not yet technically been provided, an affirmative consent status accurately indicates the current data use settings: the end user's personal data have already been processed and shared with Enom and our registry partner(s).

For registrants wishing to revoke consent, a “yes-consent” status also makes the required action very clear: they must uncheck the box and submit, at which point they will be directed to their reseller to complete their request and cancel service. While ideally, we would replace these consent-based data with placeholder data until consent is provided, we are not permitted to do so by the registry, and so the service would need to be canceled in order for the withdrawal of consent to have any real effect.

Please note, that for synchronous services, for which placeholder data are accepted by the registry or service provider, the consent checkbox will always start in an ‘empty’ state and only show a ‘checked’ state indicating that consent was given if the registrant provides consent.

Back to top

4. What happens if the user does not provide, or revokes consent?

The answer depends on whether the product is asynchronous or synchronous.

For synchronous products:

If the registrant withholds or revokes consent, any existing services will remain active, and any pending orders will be processed normally. Enom will simply substitute placeholder data for any consent-based personal data.

For asynchronous products:

If the order is currently pending, failure to provide consent within 10 days or the decision to withhold consent will result in the order being placed on hold in the Enom system. We are not able to complete orders for asynchronous products without consent from the registrant because placeholders for consent-based data will be rejected at the registry level and true personal data may not be handled in a GDPR-compliant manner.

If an asynchronous service is currently active and the registrant chooses to “withdraw” consent, they will be instructed to work with their service provider to cancel the service. Again, this is because, while Enom does not require this consent-based data, it is required by the registry or service provider, and that registry or provider has not offered a GDPR-compliant data erasure request process. While ideally, we would replace these consent-based data with placeholder data, we are not permitted to do so by the registry or provider, and so the service would need to be canceled in order for the withdrawal of consent to have any real effect.

Back to top

5. My customer is canceling a service in order to have their data erased from the provider’s system. Will I and, by extension, my customer, be refunded?

Enom does not provide a refund in cases where the end-user decides to cancel an active service because they wish to revoke consent. Please note that in these cases, Enom will log the registrant’s choice to revoke consent, but will direct the end-user to work with their reseller to cancel services.

Enom will refund any pending orders that are canceled because the end-user chooses to withhold consent. The cost of the transaction will be returned to the reseller’s account once the order is canceled. Consent requests remain pending for ten days, after which the order will default to a non-consented status, and the pending order is canceled.

Back to top

6. How are products grouped together on the Data use consent settings page?

Each service or product offered through Enom falls into a particular consent group within our system, and once the consent preference is logged for a group, that choice is applied to any future purchases of products within that same group.

In order for two products to fall within the same consent group, they must be:

• Offered through the same service provider
• Contractually require the same data elements
• And must request the same consent-based data elements

For example, a registry might operate multiple TLDs and for each of them contractually require the registrant name, email, and country, but also request consent to process the registrant’s phone number. These TLDs would fall into the same consent group, and once the registrant sets their consent preferences for one of these TLDs, the registrant’s choice would be applied to all future purchases of other TLDs within this group. This means that no future consent request emails would be sent to the registrant for purchases within this group. However, if this same registry offers another TLD for which they request consent to process the registrant’s postal address, in addition to their phone number, the registrant would receive a consent request upon purchasing this TLD, as it would fall into a distinct consent group.

Enom groups products this way, so we’re able to reduce the number of consent requests the registrant receives while ensuring the registrant has complete control over which elements of their personal data are shared and with whom.

Back to top

7. Why does the order in which services are listed on the Data use consent settings page change?

The order in which services are presented to the registrant is prioritized so that any actionable or important items are seen first. This means services will be listed in the following order if they are available:

1. New products still requiring consent from asynchronous products
2. New products still requiring consent from synchronous products
3. Older products where the consent choice has been made for asynchronous products
4. Older products where the consent choice has been made for synchronous products

Back to top

8. Why is my customer receiving multiple consent request emails?

Once a purchase is made, the Enom system waits one minute before sending a consent request email. So if multiple services are purchased together, or multiple purchases are made within one minute of each other, a single consent request email will be sent for all services. In cases where an end-user makes multiple purchases more than one minute apart, multiple consent request emails would be sent.

Back to top

9. Does the consent request timeout?

Yes, though this only poses an issue for registrants of asynchronous services. Ten days following the initial consent request, the registrant’s consent status will default to “non-consent” if we haven’t received a response.

Synchronous services will be unaffected by this as Enom will continue to use placeholders for any data elements that we process until consent is given. Pending orders for asynchronous services, however, will be canceled at this 10-day mark if we haven’t yet received a response from the registrant.

Back to top

10. What triggers the consent request to be sent?

The initial consent request can be triggered by the registration, update, or transfer of a domain. When the registrant sets their consent preferences, their choices will be logged and applied to any future purchases of products within the same consent group. However, if they purchase a service for which the provider requests additional pieces of data, beyond those for which the registrant has already granted or withheld consent to process, they may receive another consent request.

Back to top

11. Who receives the consent request?

The consent request will be sent to the registrant email address that Enom has on file for the domain or service.

Back to top

12. Can the consent request be sent to any other email like the domain admin, billing, or tech contacts?

No, these requests will only be sent to the registrant email address. Sending a consent request to an email address other than the registrant’s would not be considered secure and would violate the GDPR. For legal reasons, Enom will no longer process admin, billing, or technical contact information, except in cases where the registry specifically requires these contact points, and whenever possible, we will replace these fields with placeholder data.

Back to top

13. Why did my customer get a consent request and then find a “nothing further is required” notice on the consent page?

For some TLDs, all the data elements that are used are included in the provider’s contract. Since the only data used is used based on contract, no consent is required. In these cases, Enom will still send an initial consent request email to the registrant to ensure they have access to the Data use information page. We do this to fulfill our commitment to maintaining a high level of transparency about which personal data elements we hold, how they are used, and who they are shared with.

Back to top

14. On their Data use consent settings page, my client saw a notice reading, “The data collected will depend on whether you have registered the service as an individual or an organization. Accordingly, some of the data described here may not actually be collected.” What does this mean?

Some registry and service providers will request different information if the registrant is listed as an organization than they do if the registrant is listed as an individual. Our Data use information page outlines all the data we collect for each service, both on a contract and consent bases, and clearly indicates any differences between data collected for individual and organization registrant types.

Back to top

15. Can the consent request emails and Whois verification emails be combined?

For now, the consent request email and Whois verification email will be sent to the registrant separately. In the future, we may combine them to create a more streamlined experience for the registrant.

Back to top

 

Reseller controls and management

1. Can I omit certain pieces of domain contact info or stop sending domain contact details to Enom?  

Certain information, such as the registrant name (first and last) and organization, email address, and country, will still be required. We need this data for our contractual use, as we must be able to identify the owner of the domain, and our Domain Registrant Agreement requires the registrant provide complete and accurate information. The list of contractually required data elements for a particular TLD or service may be longer, depending on Enom's contract with the registry or service provider (see question below).

While it is not recommended, you can choose to substitute placeholder data for any data elements that we process using consent as the legal basis when placing orders, but you cannot leave these data fields empty. Placing an order for an asynchronous service using placeholder data is possible, but this data will likely not be accepted at the registry level, and the pending order may not be fulfilled by the registry or service provider. For synchronous services, although the consent-based data could be withheld and placeholders used instead, if the client decides to consent to the data being used, they may be confused to discover that even after they have consented the data is not listed on their domain registration record.

Back to top

2. Can I turn off the Data use consent settings page and consent request process entirely?

No, there is no option to disable this feature. Enom is legally obligated to collect consent from our registrants and to provide them with a straightforward, accessible means of revoking consent. The Data use consent settings page is our solution for fulfilling these obligations and is an essential part of our domain and service registration process.

Back to top

3. Can I edit the consent page?

This page cannot be edited. We try to provide the ability to customize registrant-facing content whenever possible, but the majority of the text on the Data use consent settings page is legal information that we are obligated to disclose so it cannot be modified. However, we are in the process of modernizing many of our other confirmation pages to make them customizable. 

Back to top

4. My client lost the link to their consent page. How can I provide it to them?

You will be able to resend a link to the consent page to the registrant email by initiating a request through your control panel or via the API.

Back to top

5. How can I determine whether a specific TLD is asynchronous?

A Data use information page will be made available to all resellers and registrants. It will include an exhaustive list of the TLDs and services offered through Enom, and important data-use information about each, including its status as either an asynchronous or synchronous service.

Back to top