We had a great turnout for our GDPR webinar, and attendees asked many intelligent and insightful questions about the regulation and our implementation of its requirements. We’ve made available a PDF of the full Q&A session, but if you prefer a shorter read, here are some of the highlights:

1. What is the allowed time limit for the changes to take place on the side of the reseller?

First off, if you collect and process the data of EU-locals, or have the potential to, you need to ensure you are doing so in a GDPR-compliant manner by May 25, 2018. Otherwise, you are putting your business at risk. In addition, our agreements with resellers will be updated to require that resellers process data in a GDPR-compliant manner. As for changes that must be made on the reseller’s side which specifically relate to Tucows’ domain registration processes and modifications to our platforms, there are no mandatory changes you need to make, but there are changes on our end that you need to understand and adjust for if you feel it necessary.

One such change is our new Whois system. Another is the introduction of the consent management page for end users, the details of which we address in the question below. On that note, we are not expecting to have consent for all the millions of domains on our platform from day one (May 25), but by requesting consent at the time of domain registration, renewal, or transfer, we expect that the majority of the registrants in our system will have indicated their consent selection within the first year of this requirement being active. You should consult with your lawyer to determine how to handle consent collection and overall GDPR compliance for your own business.

2. What happens to pre-existing data, and do we need to send the consent management landing page link to all existing users?

Data that is used to perform the domain registration contract will be maintained in our system for as long as is legally required. For pre-existing data that now requires consent, we will request that consent on a timeline that has been deemed appropriate by our Legal team. We will send the consent management landing page link to the end user at three potential points in the domain lifecycle: when new registration is created, when a domain transfers into our system, or when a domain is renewed. Additionally, resellers may send out the link at their discretion via the option that will be in the control panel or the new API call that we will be offering.

3. Compliance sounds as simple as gaining consent from clients. If their consent has been given, then I’m covered under the GDPR, right?

It’s not that simple, in part because there are clearly defined limitations around what constitutes legitimate consent, all of which are outlined in our Consent blog post. Furthermore, the GDPR’s requirements go beyond consent to include things like data minimization, secure processing and storage of data, and more. I can say that from the domain services perspective, we’ve got things covered. This compliance will be achieved through a combination of contract-based and consent-based data processing and data minimization. If you are collecting and storing personal data for your own purposes, beyond what is required by us, we recommend that you talk to a lawyer who is familiar with the GDPR to fully assess the risk that you’re taking by not updating your own processes to comply with the new law.

4. How will domain transfers work moving forward? If a reseller cannot see who owns a domain how can they initiate its transfer with confidence that the request is legitimate?

As mentioned in the question, the problem with continuing to use the transfer process as it stands today is that the gaining registrar would not reliably know where to send the initial Form of Authorization (FOA), since the registrant email will no longer be publicly available to them. To address this issue, the Registrar and Registry Stakeholder Groups’ joint TechOps (Technical Operations) sub-group has sent a letter to ICANN, proposing changes to the transfer process. They suggest that the initial Form of Authorization should be optional, and instead, possession of the transfer authorization EPP code will be required to initiate the transfer. Then the current registrar, which does know the owner’s email, would send a mandatory confirmation FOA (this FOA is currently optional), and the transfer would only proceed if the domain owner completes the FOA sent by the current registrar within 5 days.

The letter in which this change was proposed was sent to ICANN very recently, so we don’t yet know how ICANN will respond. Changing the transfer process is not a simple task, as it’s a consensus-based policy with a specific protocol that must be followed to approve any modifications. Each registrar will have development work to do once the course of action has been determined, but the domain community is united in working towards a timely and viable solution.

5. How does the law address proving identity? As an example: I can create a domain using the registrant name “Donald Duck”. If another Donald Duck discovers this and asks for the info to be removed, what proof must he provide to verify that he is, in fact, the same Donald Duck that registered the domain?

The choice to give consent, and the related ability to request erasure of one’s personal data, is all tied to a user profile which consists of a unique combination of the data elements we require contractually: name, organization, email and country. If two registrants share the same name but have a different organization, email, and/or country, they are considered to be two separate people, with distinct user profiles in our system. If a request for erasure comes in from someone who does not match the full contact data set associated with a domain, but that someone still claims to be the registrant and data subject for that domain, our Compliance team would work to address the issue.

6. The current system in place requires law enforcement to have warrants or legal grounds in order for them to obtain the Whois information for a privacy-protected domain. If they get access to the gated Whois, does this mean that they can access this information without having to provide proof of legal grounds to get the data?

Access to the gated Whois will only reveal information which is currently (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.

7. Can we run our own privacy service, i.e. have our information show in Whois?

This is a complex decision for a reseller to make, for a few reasons. There are requirements in our Reseller Agreements around what privacy or proxy services may be used for domains on our platform. Additionally, ICANN has requirements for any privacy or proxy provider and is working now on an accreditation process for providers of those services. We encourage any reseller to review their options with the help of their legal counsel and the operative reseller agreement before beginning to offer such a service.

8. When will you publish the final updates being made to your contracts?

While we appreciate that uncertainty around these changes is difficult, we hope that an industry-standard amendment will make things easier for both our resellers and the industry as a whole. At the same time, we know that we can’t wait too long before sharing those changes with you. If the industry-wide amendment is not ready for distribution by the end of March, then in early April, we will release our own contract changes to our partners.

9. Can a non-EU domain registrant waive the protections and keep their data public?

Not at this time. We believe that providing such an option puts data at risk and exposes it unnecessarily, but this is currently the subject of discussions within ICANN and with various European DPAs, and we will reevaluate our implementation from time to time in light of further policy developments and guidance received from government authorities.

10. How will the fines for non-compliance be monitored and collected, and who will be enforcing them against US companies?

Each EU country, and in some countries each region, has a Data Protection Authority (DPA) who enforces the GDPR. If you have a presence in an EU country, that is likely the DPA with whom you would interact. If you do not, the DPA of the country where the violation occurred would probably be the enforcer. The enforcement process will rely on reporting, meaning the EU has not indicated that it plans to conduct audits, but instead, will investigate potential GDPR violations as they are brought to the DPAs’ attention.

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)
• 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)

New Year’s resolutions aren’t for everyone, but I think most of us like the idea of a restart, the sense that slates can be wiped clean (to an extent), and that a departure from one’s current path is possible. This notion of a fresh start takes on a higher level of significance in the digital era. These days, many of us have a substantial online presence that lives both in public-facing platforms like Facebook or Twitter and in the private databases of our service providers, and I think we all feel entitled to some level of control over our personal digital histories. The right to erasure, as outlined in the GDPR, is meant to give individuals this control.

What is the right to be forgotten?

Article 17 of the GDPR outlines the data subject’s right to erasure, also known as the right to be forgotten. It gives each data subject the right to request that a controller erase the subject’s personal data. It also requires the controller to comply with any such request “without undue delay” as long as one of six specific legal grounds applies. On top of this, it states that in cases where the controller has made personal data public, the controller must reach out to any other controller who is processing the data and inform them about the request for erasure so that the appropriate steps can be taken. Finally, Article 17 lays out several exceptions where the right to erasure does not apply. These include instances when processing of data is necessary for “exercising the right of freedom of expression and information,” for “compliance with a legal obligation,” or for “the establishment, exercise or defense of legal claims.”

Legal grounds for processing data

If you think back to our post about obtaining consent, you’ll recall that the GDPR gives several legal bases for using personal data. The two that most commonly apply to the domain registration world are when the processing is necessary for the fulfillment of a contract, and when the data subject consents to the processing. Our Registration Agreement outlines exactly what data is required in order to register a domain, so the data elements included there are what are required to fulfill the contract. Any extra data that someone chooses to provide, such as a phone number to be used as a backup authentication method, would be processed under the legal basis of consent.

What data falls under the right to erasure?

“The right to be forgotten” is not as straightforward as the phrase’s catchy nature might imply. While a data subject can place a request to a controller to have their data erased, the request is only legitimate under certain legal grounds. I’ll lay these out and then narrow our focus to what they mean for Enom (and very likely, for you!).

These legal grounds include:

• The data is no longer needed for the purpose for which it was originally collected,
• The processing is based on consent and the data subject withdraws that consent,
• The data subject exercises their right to object under Article 21 of the GDPR,
• Processing is not lawful (there was no legal basis in the first place),
• The controller is subject to a legal obligation that requires the erasure of the data,
• Some things related to children’s rights, which don’t apply since we don’t sell domains to children.

For Enom’s purposes, data that is processed based on consent is subject to the right to erasure — the data subject can withdraw their consent, the controller must erase this data, and, if the data has been made public, notify other controllers or processors to do so as well. Enom also uses data that is processed based on a contract and is not subject to the right to erasure; a request to erase would not apply to those data elements. In these cases, erasing the data would require terminating the contract. Even then, there are other legal obligations around data retention that may come into play, such as regional laws that require data to be stored for certain time periods.

How can a person exercise their right to erasure?

Article 7 of the GDPR lays out how consent works as a legal basis for data processing, and also requires that consent may be withdrawn at any time, specifically stating that “It shall be as easy to withdraw as to give consent.” We’re fulfilling this requirement by ensuring that the consent management landing page remains available and easily accessible to each data subject to whom we provide services. On this page, a subject can view the existing consent settings and also change or withdraw consent. A withdrawal request will trigger a process on our side to find and delete any data that is held based on consent. Data that is required by contract, however, would remain intact. This gives the data subject complete control over the use of their personal data, while also ensuring that the domain registration itself is not interrupted unnecessarily.

Looking ahead

The opportunity for a fresh start provided by the GDPR’s right to erasure is a year-round thing, not confined to the first of January. But now, with the glitter from New Year’s parties still stuck in our carpets, it might be a good time to think about how you’re preparing to provide this option to your clients. In our own development process, our mantra has been “it must be as easy to withdraw consent as it is to give it, and when erasure is requested, it must be completed ‘without undue delay’.” Work with your legal team to determine which of the data elements you collect are subject to the right to be forgotten, and develop a process to fulfill those requests promptly and completely. Giving your clients easy access to a “fresh start” will certainly require some development work on your end, but it’s an opportunity to employ some great UX and reassure them that you take the principles of transparency and privacy seriously.

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)
• Consent and the GDPR (Published on Dec. 21, 2017)
• 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)