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.

What makes 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 data privacy matters

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 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 minimization (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 fulfill the contract.

What does this mean for domains?

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.

How will this affect domain resellers?

What does this mean for you as a domain reseller? The biggest changes that you’ll see resulting from 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 workaround 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 OpenSRS’ approach to the policy

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