Over the past few months, we’ve talked quite a bit about the concept of our Tiered Access registration directory, also referred to by its informal title, “gated Whois”. This has sparked many questions from our reseller partners and other interested parties who are curious about how the system works, who may have access, and what the accreditation process looks like. Today, we’ll address these topics and discuss why we believe a gated Whois system is the best solution for our platform, our resellers, and our registrants.

Why are we implementing a gated Whois?

As we’ve written before, in updating our platform to achieve GDPR compliance, we used data privacy laws as our starting point. We worked from the ground up to design processes that we believe comply with those laws and their underlying principles, and adhere to our contractual requirements with ICANN and other TLD registries to the fullest extent possible. The changes we made, including the decision to remove contact data from the public Whois, are necessary to protect ourselves and our reseller partners from the possible legal repercussions of improperly processing or exposing personal data. Furthermore, we believe this change to the public Whois makes sense — data protection should be extended to all domain owners, and we don’t see any legal basis or justifiable need to publicly display unredacted contact data.

That said, we acknowledge that, in many cases, third parties may have a real, justifiable need to access a registrant’s personal data, and these legitimate interests are also provided for within the GDPR’s definition of “lawful processing”. By restricting the general public’s access to personal data and introducing our Tiered Access registration data directory, we are complying with the GDPR and extending its protections to all registrants on our platform while ensuring that those with a legitimate legal basis have access to the data they need in order to protect the public and exercise their own rights.

Who will have access and how will they be accredited?

Through a rigorous authentication process, Tucows will ensure that only those with a legitimate interest are given access to the gated Whois system and that this access is restricted to only those data elements that the user needs. Parties with a “legitimate interest” may include law enforcement agents, members of the security community, and commercial litigators.

At present, we are actively responding to requests for accreditation from members of those communities. In the near future, interested parties will be able to click an application link on tieredaccess.com to submit an email with the required application information. This will include the requestor’s first and last name, organization, and email address, which specific domains they want to access, and the requested duration of access. They will also be asked to provide any other pertinent details such as the legal basis for the request.

What data will be displayed in the Tiered Access Directory?

There are three factors, that in combination, determine what contact data will be visible to an accredited Tiered Access user by default: the user’s permission access level, the registrant’s data use consent settings, and whether the domain is privacy-protected.

Permission Access Levels for Accredited Users

In designing our gated Whois system, we started from the principle of data minimization and determined that a Tiered Access directory was the best way to protect the privacy of our customers while providing parties with legitimate interest access to relevant registrant data. At a high level there are three permission access tiers, and within each we can further restrict permissions by many different factors.

Through conversations with stakeholders, we determined three major categories of requestors: law enforcement, commercial litigation interests, and security researchers. We then examined the various personal data points we collect and identified those which are most pertinent to the above-mentioned parties. We have done our best to balance individual privacy and the rights of registrants with the rights of law enforcement and the people they protect, the rights of commercial litigators and their clients, and the need for a safe and secure Internet.

Tier One – Law Enforcement Authorities

Users within this tier must be a member of a law enforcement authority with jurisdiction over Tucows or one of its companies, and are provided access to the widest range of registrant data available through our Tiered Access system. Our aim is to supply these parties with data elements that may be relevant to a legal investigation while still respecting the registrant’s privacy and consent choices.

Please Note: For the small subset of ccTLDs whose registries contractually require the admin and tech contact info, a portion of those datasets may be included in tier-one results.

Tier Two – Commercial Litigators

Access for users within this tier will be limited to those elements deemed necessary to exercise their clients’ rights to pursue legal action against the owner of a domain registered on our platform.

Tier Three – Security Community Members

Users belonging to this tier provide a valuable public service by examining trends in online criminal activity, helping to make the Internet safer for everyone. They may only view a limited set of information because, while they inarguably play an important role in online security, they have no official jurisdiction or legal authority.

Data Use Consent Settings and Whois Privacy Status

For domains without Whois Privacy protection, the Tiered Access system (gated Whois) can display the following data:

• Data that we require by contract: registrant name, country, email, and organization (if applicable)
• Data that the registry requires by contract
• Data which we have consent from the registrant to process

This means that, in instances where the registry does not contractually require any data elements and we do not have consent to process any additional elements, only the minimum data that we require contractually will be shown.

Tip: Through a quick search on our Data Use Information Page, you can determine which data are processed as per the registry’s contract and which are processed by consent.

For domains with Whois Privacy protection, the Tiered Access system will only display the Whois Privacy contact data, just as it appears for privacy-protected domains in the public Whois. It’s also important to note that the process to reveal the underlying ownership information has not changed with the introduction of a gated Whois; we would still require the tiered-access-accredited party to provide a court order, subpoena, or similar legal justification before our Compliance team would provide the underlying contact data. In short, all the benefits of Whois Privacy carry over into our gated Whois system.

Further Customizing User Access

As we outlined above, the actual data elements visible by default to any accredited user of the Tiered Access system depend not only on the data use consent settings and privacy status of the domain, but also on the accredited user’s permission access level. On top of these controlling factors, we can also place additional custom restrictions on a user’s account.

Our Tiered Access system uses the Registration Data Access Protocol (RDAP), developed by the Internet Engineering Task Force as an eventual replacement for the current WHOIS protocol. One of the essential benefits of using RDAP is that it allows us to define user access options at a very granular level. We can, for example, restrict the number of domains a user can query per day, the data fields returned by each query, which specific domains can be queried, and which data elements are returned in the response. We can also set the specific duration for which a user’s account remains active.

This means that some users may have access to the full set of registrant data we hold, restricted only based on the registrant’s data use consent settings and the Whois Privacy status of the domain. For other users, it may be that only the registrant’s email address, only the registrant’s name and country, or, perhaps, only contract-based data, will be shared.

What’s important to take away is this: our high-level tiers are a starting point; we have the flexibility to customize as needed and make adjustments as we find the best way to balance the rights of multiple parties.

How will the Tiered Access system be accessed?

The sign-in portal is available at tieredaccess.com. This page also includes an explanation of the Tiered Access registration directory and some information about who may be accredited. Over the next few phases, we’ll add an option to apply for access, a link to the applicable Terms and Conditions, and a public Whois lookup option, allowing the page to function as a Whois directory for both the public and gated versions of the service.

Will resellers have access to the Tiered Access system?

We have no plans to provide our reseller partners access to the gated Whois, but, if you’re one of our resellers, this shouldn’t be cause for concern — the data that appear in Tiered Access for any domains in your account are accessible to you through the Domains tab of the Control Panel or the GetContacts API command. Also, keep in mind that with the new domain transfer process, the gaining registrar no longer has to send the initial Form of Authorization to the registrant email address, which has historically been retrieved from the contact details in the public Whois.

Finding a Balance

Much of the debate over the concept of a gated Whois system has focused around finding a balance between protecting individual privacy and ensuring that those using domains to perpetrate malicious activities can be held accountable. A recent Techdirt article described the debate’s central question as, “which is more important for society: protecting millions of people from spammers, scammers and copyright trolls by limiting the publicly-available Whois data, or making it easier for security researchers to track down online criminals by using that same Whois information?” As a registrar, our central concerns are compliance with law and protecting the data we process. However, we also believe that, as far privacy laws permit, those who play an essential role in keeping the Internet safe should have access to the data they require in order to do so. Our Tiered Access system is a solution that accomplishes both objectives.

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)