As we get closer to May 25, 2018, I see more attention paid to the GDPR and to how service providers will need to change to accommodate these new data privacy regulations. At the same time, we’re hearing questions from our resellers about whether this will affect them. I want to take a moment to emphasize that the GDPR is a Really Big Deal and that anyone who sells services online should be looking into what changes they need to make to be compliant by that May deadline.

Why is the GDPR different?

This isn’t the first data privacy regulation to hit the Internet, but it is the first one to carry such significant fines and such a broad scope. If a data controller is found to have infringed upon the basic data processing principles in the GDPR, such as the requirement to obtain appropriate consent from the data subject, the fine can be up to 20 million Euros, or 4% of annual turnover, whichever is higher — that’s huge! And I’m not sure about you, but I tend to think of laws as applying only to the country or union where the law is in effect. But the GDPR’s scope is much wider — it applies not only to businesses based in the EU, but also to businesses in the rest of the world that sell services to EU-locals.

If you’re a reseller with clients in the EU, it’s likely that some element of your data processing falls under the scope of the GDPR, whether that means setting up accounts for EU-locals in your system, taking their payment for a domain name, or providing them with services on an ongoing basis. Due to the scope and the significant penalties involved, non-compliance with the GDPR is a big risk not only for registrars but for every reseller.

With that context about the GDPR’s scope and penalties in mind, I think it’s clear that the GDPR affects almost everyone doing business on the Internet. Remember, nothing I’m saying here is legal advice — this is my domain-industry perspective, I’m not a lawyer, and you should be talking to one.

Why is data privacy so important?

I’ve done most of my holiday shopping already, and as much as I try to shop locally and support small businesses, some gifts are just better purchased online. But one thing I kept in mind this year, probably because the GDPR has me thinking so much about data privacy, is how much information is generated by my online shopping.

I remember a story in the news a few years ago about how Target, a major North-American retailer, used data analytics for marketing, which ended up revealing a young woman’s pregnancy to her family. Would my online shopping be revealed to my partner, via well-placed browser ads and coupons sent to our shared email address? Could I stop that from happening? I used a private browser window, but that doesn’t stop the retailers from tracking my purchases, creating a profile based on data they collect from me and bought from third-parties, and serving up targeted advertising that might give away some holiday surprises. If only they had to get my permission before processing my personal data! And on a more serious note, concerns around data privacy shouldn’t be limited to annoying marketing emails and spoiled surprises — data privacy is a necessary element of modern democracy.

When does the GDPR allow processing of personal data?

Processing of personal data is only permitted under the GDPR if it is done “lawfully, fairly and in a transparent manner” (GDPR Article 5). The details of what is considered “lawful” are found in Article 6, where six different legal bases for data processing are given; the first two of these clearly apply to the relationship between a registrar and registrant:

• The data subject consented to the processing of their personal data
• Data processing is necessary as part of fulfilling a contract with the data subject

Other ways that data processing can be legal are when it’s done in order to protect the vital interests of the data subject or when processing is necessary for the public interest; those don’t usually apply to domain names. Finally, there’s a legal basis of “legitimate interests,” which is defined in recital 47 of the GDPR. This definition says “processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller” — this one could relate to domains since most companies offering paid services use personal data in some manner to protect against fraud and to process payment data.

But let’s venture back to consent for a moment. Consent is a difficult legal basis to rely on since there are many conditions laid out in the GDPR which determine what consent means, how consent can be requested, and what kinds of data use can be consented to. If these conditions are not met then the processing is not lawful. However, in some situations, consent is the most appropriate legal basis for the processing of personal data. To get a better sense of when consent does suffice, we took a close look at what constitutes consent under the GDPR.

How does the GDPR define consent?

In Article 4 of the GDPR, consent is defined as follows:

“…any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;”

There’s a lot going on in that first sentence, and we talked about this a bit in our first GDPR post. But let’s break it down. Consent must be:

• freely given – there can’t be negative consequences for not consenting to more data use than is required to fulfill the contract;
• specific – consent needs to be requested for each data use individually, they can’t be bundled together;
• informed – the way the data will be used must be clear in the consent request; and
• unambiguous – consent has to be a clear, active choice on the part of the data subject rather than a passive allowance.

The requirement that consent be provided “by a statement or by a clear affirmative action” goes hand-in-hand with the “unambiguous” indication of consent. We’ll be revamping our existing processes under the assumption that it’s not enough to display a pre-checked box that the domain owner simply scrolls past; instead, the domain owner must actively grant consent. This may still be done by checking a box, but whatever process we choose, we will ensure the option to grant consent isn’t pre-selected.

Article 7 of the GDPR delves more into the conditions for consent. It requires that the data controller (the party who determines “the purposes and means of the processing of personal data”) can demonstrate that the data subject (the person to whom the data pertains) did consent. It also talks about how the consent request may be presented and requires that consent can be withdrawn at any time, by a method no more difficult than that used to give consent. In other words, withdrawing consent has to be a straightforward process. That’s a lot of requirements to meet for consent to be valid.

Consent vs. Contract: what’s the difference?

Consent is one possible legal basis for data use and, as mentioned earlier, fulfillment of a contract is another legal basis that often applies to the domain registration world. It may seem that signing a contract is the same thing as providing consent, but legally these are two different things. Contract and consent may achieve the same purpose (to allow data processing) but the underlying legal basis is different. Any data processing required in order to provide the service must be included in the contract; for collecting data that’s “nice to have” while not essential to that service, consent is required.

There are requirements around contractual data use as well, including data minimisation (which we talked about in the Whois changes blog post), and the requirement to provide an explanation of which data elements are collected on the basis of contractual need and how those elements are processed.

We do need some personal data in order to fulfill our domain registration contract with the domain owner. Because those specific data elements are processed on the basis of fulfillment of a contract, rather than consent, there’s no option to withdraw consent from the use of that data. This is important because it’s what ensures that our compliance with the GDPR won’t result in situations where we must suspend domains. If consent is requested but never provided, we won’t use personal data in any way other than what’s covered in the contract  —  this means we can still provide the domain registration, we just can’t use more data than the bare minimum, and we can’t share the data in ways that are not required to fulfil the contract.

How does this apply to the domain industry?

We’re all accustomed to accepting lengthy and incomprehensible Terms and Conditions; it’s so common that it’s become a joke in popular culture. But this setup fails to fulfill a basic requirement under the GDPR: informed consent. So after May 25, 2018, that just won’t fly.

Once the GDPR is in effect, we’ll be using a detailed consent request, sent to each domain owner after the registration request has been processed. This will disclose all the uses of personal data that are required by contract in order for us to provide the requested domain service, and will request consent from the data subject for those uses where our legal basis is their consent. Once the initial consent is granted, each domain owner will also have the ability to review and modify their consent choices on an ongoing basis. Finally, as required, we’ll ensure that there’s a way to withdraw consent as needed.

Bringing contract and consent together

To put this into real-life terms, when a domain is registered, we need to collect some data in order to enter into a domain registration contract with the registrant. This includes the registrant’s name, organization name (if one is provided, otherwise we assume the domain owner is an individual rather than a business), email address, and country code. Other pieces of data, such as the postal address and telephone number, are not required by contract. However, the domain owner might want to consent to us using this data, for a number of reasons. For example, it could provide a backup authentication method in case the registrant ever loses access to their email address.

It’s not only about the contract the registrant enters into with us, however — there’s also a contract between us and the registry and, if that contract is GDPR-compliant, it will outline exactly which data elements the registry requires and their legal basis for collecting each piece of data. In turn, those data elements become required by us in order to be able to provide that domain registration service to the registrant — so that base set of data that I listed above will change, depending on the requirements of the specific TLD.

That said, in some cases, we won’t be able to get a GDPR-compliant contract in place with the registry before May. In order to process registrations in these TLDs, we’ll need the domain owner to consent to the sharing of their data with the registry. Our other option would be to stop selling those TLDs entirely, but we don’t want to make that decision for the domain owner; we’d rather offer the choice, and let the registrant decide if they want the data shared (and the domain name registered) or not.

What impact will this have on domain resellers?

What does this mean for you as a domain reseller? The biggest changes that you’ll see resulting from to the GDPR’s consent requirements are around how we inform the domain owner about the ways their data is used and our need to obtain consent for any data use that is not required by contract. All these changes will put the domain owner in charge of how their data is used, which can only be a good thing.

As we mentioned earlier, consent is needed if the domain owner wants to allow more data use than is required by contract, or if we don’t have a GDPR-compliant contract in place with our registry-provider but still want to offer the TLD. Keep in mind, though, domains are only one piece of the puzzle, one part of a reseller’s service offering. Anyone who takes orders, provides services, collects data, etc., needs to do their own work around disclosing data use, updating contracts, and gathering consent from customers. With the help of a lawyer, you can apply the same logic I described above to your business — be it web hosting, online presence building, or something else entirely. Work with your legal team to determine what data is truly needed to provide the service, make sure that’s included in the relevant service contracts, and gather consent for the rest. This way, your risk is greatly reduced and your clients can rest assured that they’re with a trusted provider, committed to the principles of transparency and consent.

If you found this post helpful, check out our  GDPR page. We also encourage you to sign up for our GDPR newsletter so you don’t miss a thing!

Learn more about the GDPR:

GDPR Updates – Understand Enom’s approach to the policy

• GDPR-Related Contract Changes (Published on Mar. 5, 2018)
• The GDPR’s Right to Be Forgotten (Published on Jan. 18, 2018)
• How will the GDPR impact Whois? (Published on Nov. 9, 2017)
• The GDPR Overview (Published on Oct. 30, 2017)

GDPR Resources – View third-party resources on a specific GDPR topic

• Right-to-be-forgotten-related resources (Published on Feb. 1, 2018)
• Consent-related resources (Published on Jan. 4, 2018)
• Whois-related resources (Published on Dec. 7, 2017)
• GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

In the weeks since my last update, a lot of behind-the-scenes work has gone on for our GDPR implementation project. One aspect of this project, which we can now share more specific information about, concerns changes to the Whois system. I also have some details around how collecting and processing data will influence both our Reseller Agreement and resellers’ own end-user service agreements (and we’ll share some recommendations on that). The information here is geared towards those who resell Enom services, but our clients who have registered a domain directly with us may also find it helpful.

Update: March 6, 2018

Before we dive into Whois changes, I want to go back to something that was mentioned in our initial GDPR post – to whom does the GDPR apply? At the time, we were proceeding on the basis of applicability by citizenship, meaning that the GDPR would apply to EU Citizens. Since that post went live, however, our legal analysis has led us to interpret the GDPR as applicable to any individual residing in the EU, regardless of their citizenship. Even more recently, we made the decision to work toward a unified implementation plan that will extend the same heightened privacy protections to all Enom reseller partners and end-users, regardless of their location. Learn more about our GDPR approach.

Changes to Whois

The Whois directory is a powerful tool. You can look up who owns a domain to find their phone number, email, even their postal address. You can check when a domain was first registered, where it’s hosted, when it expires — that’s a lot of information available with just a few clicks. And because this system has been around for so long, and is such a fundamental aspect of the internet, we often assume that how it currently works is how it should work. But just because something has been a certain way for a long time doesn’t mean it must always be that way, and the GDPR’s looming deadline has prompted the re-examination of many processes and policies.

Instead of “how have we always done this?”, we’re asking questions such as “what’s the best way to do this?”,  “what information is it truly necessary to include?” and “is there a legitimate legal basis for this process?”

What will change?

The GDPR was drafted and brought into law without consideration for its effects on the domain name industry, leaving us to interpret how this regulation applies to our world. One particularly impactful section of the GDPR is Article 5, which lays out “principles relating to processing of personal data.” This is highly relevant to the Whois system, which is essentially just a repository of data, much of which is personally identifiable information about individuals. Warning: we’re going to briefly venture into the legal thicket here, but bear with me!

Under the GDPR, personal data may be collected and processed only when there is a legal reason to do so. For example, 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.

The principle of data minimization requires that the data collected be relevant and limited to what’s truly necessary to carry out the agreed-upon purpose for which the data is being collected. To add to this, the principles of purpose limitation and confidentiality limit the handling of personal data such that it cannot be processed or shared for any purpose other than that to which the individual initially agreed.

Simply put, under the GDPR:

1. We can only collect the minimum amount of data necessary to perform a specific action (e.g. register a domain)
2. Data can only be shared when there’s a legal basis to do so
3. Data can only be shared when necessary to fulfill the intended purpose of the data collection

So how will this impact Whois? Well, it’s certainly difficult to argue that there’s a legal basis for openly sharing contact details of a domain’s owner, administrator, or technical contact in the public Whois record. And we can’t claim that it helps to accomplish the original purpose for which the information was collected (registering the domain). This means that the public Whois system as it exists today is incompatible with the principles of data privacy that the GDPR affirms.

All that being said, the GDPR recognizes that there are times when there is a real, justifiable need for a third party to obtain personal data, such as domain ownership information, and these “legitimate interests” are also provided for within the policy. Think about, for example, an intellectual property lawyer who wants to know the owner of a domain in order to submit a trademark dispute, or a law enforcement officer tracking down the people behind a phishing scheme; they should be able to find out who owns the domain name under investigation. We need some way for Whois information to be provided to the people and organizations who have a legitimate reason for requesting it — but one that doesn’t involve publicly exposing this sensitive data by default.

A different kind of Whois

This leads us to one of the biggest domain industry changes prompted by the GDPR: a gated Whois system.

Not all parts of a domain’s Whois record constitute personal data. The registrar information, initial registration, last update and expiry dates, domain status, and nameservers will all remain publicly available as they are today.

The registrant information — name, organization, address, phone number, and email — is personal data that can no longer be published in the public Whois. Instead, we plan to provide authenticated access in a specific and limited manner, so that those with legitimate reason to request personal data can access the information they require while the privacy of individuals remains protected.

We’ve summarized changes to the Whois output in a quick PDF:  

Don’t worry — this basic user data will still be visible to resellers through the Reseller Control Panel. As we work out the legalities, which will include updates to our Reseller Agreement, we’ll keep you updated.

Do we still need Whois ID Protect?

Absolutely.

Regardless of any changes to the Whois system, Whois Privacy will remain a valuable service to registrants worldwide. Even when the public Whois “goes dark”, it is certain that there will still be a gated Whois, where registrant data will be made available to parties with a legitimate interest. So, while the audience for registrant data may no longer be the entire public, it will still be sizable. This is where Whois Privacy comes in — if privacy is active on a domain, the personal data in the registration record will remain protected from those with access to the gated Whois. The service also provides a way for third parties to contact the domain owner via the privacy service email address displayed in the Whois output, an option that will not be provided as part of GDPR data protection. In addition, the personal data associated with a domain that is protected by Whois privacy will not be shared with registries.

Now, there will always be the occasional, ostensibly savvy registrant who’s tempted to simply supply false information, seemingly avoiding the need for Whois ID Protect altogether. This is something we would never suggest. For legal reasons, ownership disputes being one example, it’s important that the domain contact information be accurate. Additionally, the registration agreement that all domain owners accept as part of registering a domain through an Enom Reseller confirms that all information provided will need to be accurate, current, and reliable. These are ICANN imposed conditions, and registrants risk having their domain suspended or canceled if these requirements are not met.

Reseller changes coming in the new year

All this talk about new restrictions on data processing and collection, and the various process changes they entail, brings me to my final point: how will it all impact you, our resellers? In the lead-up to May 2018, we’re doing as much as possible on our side to minimize the changes you have to make on yours. But despite all our best efforts, there will inevitably be things you need to do as a reseller.

This involves another (even briefer) journey into the legal thicket. According to our interpretation, Enom is a data controller (we determine “the purposes and means of the processing of personal data”) for specific data elements: registrant first and last name, organization, email address, and country. This is all the information we require in order to enter into the registration agreement with the domain owner. For all other data elements (e.g. address, phone, and fax numbers, among others), we are simply a data processor. The difference here is that we are handling this data on behalf of either the registry or the reseller, without actually requiring it ourselves. For example, we don’t need a registrant’s physical address to provide them with a domain name, but you may require it for billing purposes. Various data requirements will also exist at the registry level. As a data processor, we store and transmit this information on behalf of both registries and resellers, and in order for the exchange of all this information to occur, it must be covered in a GDPR-compliant agreement.

To that end, one thing that is definitely coming is an update to our Reseller Agreement — we need to add some information around what we require as a data controller, as well as the changes mentioned earlier, which will remove any concern around resellers accessing clients’ personal data in the Control Panel.

As a reseller, you’ll want to work with your own legal team to review your customer agreements and work through any changes that may need to be in place before that May 25th deadline. We’ll also have some recommended language for resellers to include in end-user service agreements, so stay tuned.

What’s next?

Next month’s GDPR update post will focus on how we plan to request consent from individuals for the use of their personal data. Until then, we’ll continue working hard on our implementation. As a reseller, you can use this time to seek your own legal advice, and think about what information you’re collecting from customers — how does it align with the GDPR’s principles of data minimisation, purpose limitation, and confidentiality?

You can wrap your head around the basics, and find helpful context on our GDPR page. Our previous blog post also highlights some fantastic resources that outline emerging GDPR best practices. And finally,  we encourage you to sign up for our GDPR newsletter so you don’t miss a thing!

Learn more about the GDPR:

GDPR Updates – Understand Enom’s approach to the policy

• GDPR-Related Contract Changes (Published on Mar. 5, 2018)
• The GDPR’s Right to Be Forgotten (Published on Jan. 18, 2018)
• Consent and the GDPR (Published on Dec. 21, 2017)
• The GDPR Overview (Published on Oct. 30, 2017)

GDPR Resources – View third-party resources on a specific GDPR topic

• Right-to-be-forgotten-related resources (Published on Feb. 1, 2018)
• Consent-related resources (Published on Jan. 4, 2018)
• Whois-related resources (Published on Dec. 7, 2017)
• GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)