As we get closer to May 25, 2018, more attention is being paid to how service providers will need to change to accommodate these new data privacy regulations. At the same time, we are hearing questions from our resellers about whether this will affect them. We want to re-emphasize that the GDPR is a Very Big Deal and that anyone who sells services online should be looking into what changes they need to make to be compliant by the May deadline.
What makes the GDPR different?
This is not 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. And where one can generally assume that a laws only applies to the country or union where the law is in effect, this is not the case with the GDPR. 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 are a reseller with clients in the EU, it is 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, it is clear that the GDPR affects almost everyone doing business on the Internet. Remember, nothing here is legal advice — this is our domain-industry perspective. We are not your lawyer, and you should be talking to one.
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 is done in order to protect the vital interests of the data subject or when processing is necessary for the public interest; these grounds do not usually apply to domain names. Finally, there is the legal basis of “legitimate interests,” as 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.” Legitimate interest 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 us return 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, 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;”
This is a lot of information at once so let us break it down. Consent must be:
- freely given – there cannot 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 data uses cannot 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. EPAG will 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 is not 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 is a lot of requirements to meet for consent to be valid.
Consent or contract: how are they different?
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 is no option to withdraw consent from the use of that data. This is important because it is what ensures that our compliance with the GDPR will not result in situations where we must suspend domains. If consent is requested but never provided, we will not use personal data in any way other than what has been covered in the contract — this means we can still provide the domain registration, we just cannot use more data than the bare minimum, and we cannot share the data in ways that are not required to fulfil the contract.
What does this mean for domains?
You are probably accustomed to accepting lengthy and incomprehensible Terms and Conditions. But this setup fails to fulfill a basic requirement under the GDPR: informed consent. So after May 25, 2018, this will no longer be legal.
Once the GDPR is in effect, we will 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 will ensure that there is 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.
However there is not just a contract between us and the registrant; there is 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 will not be able to get a GDPR-compliant contract in place with the registry before May. In order to process registrations in these TLDs, we will 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 do not want to make that decision for the domain owner. Instead, we would rather offer the choice, and let the registrant decide if they want the data shared (and the domain name registered) or not.
How will this affect domain resellers?
What does this mean for you as a domain reseller? The biggest changes that you will 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 do not 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 we describe 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 is 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 are with a trusted provider, committed to the principles of transparency and consent.
If you found this post helpful, check out our GDPR Page.
