MENU
  • Enom.com
  • Resellers

Enom Blog

  • GDPR Checklist for Enom Resellers

    May 17, 2018

    Advice, Announcement, Featured, GDPR, Uncategorized

     Like

    Views: 120

    Any time there’s a dramatic shift in our industry, we focus on minimizing the impact on our resellers and providing you as much information and assistance as possible. Admittedly, our GDPR communications work has proven fairly challenging, in part because we’ve simply never seen a shift quite as dramatic as that prompted by the GDPR. While we wanted to equip our resellers with specifics about our implementation plan and a concrete list of action-items right from the get-go, developing long-term solutions that both achieved GDPR compliance and established processes in which registries, registrars, and resellers can play their specific, essential roles required considerable collaborative efforts from players across our industry.

    There’s still much work to be done, but today we’re happy to be able to offer a concrete list of GDPR action-items for Enom Resellers and helpful resources in the form of flowcharts, example landing pages, and FAQs. We’re even happier to say that the to-do list is a short one which will likely require minimal work on your end.

    Having said that, we must remind you that legal counsel is an essential part of any comprehensive GDPR compliance strategy. This checklist is not legal advice, and ensuring its completion by no means guarantees your compliance with the GDPR. Speak with a lawyer who is familiar with your business and equipped to judge whether your internal practices achieve compliance.

    Reseller Action-Items

    Most of these items will necessitate adjustments on your end. You may determine that some do not require action on your part, but all are significant and important for our clients to understand.

    1. Make Sure You’re Familiar with Our Newly Introduced Consent Management Process

    Moving forward, Enom will reach out to end-users to request their consent to process certain pieces of personal information. This “Consent Management” flow involves the sending of a request email which contains a link to the registrant’s unique Data use consent settings page. This Data Use Consent Settings page serves as the registrant’s means to view their settings, manage their settings, and withdraw consent, should they choose to do so. It also contains a link to the Data use information page, which provides more information about how personal data is processed.

    To the registrant, it’s a straightforward experience that makes clear Enom’s relationship with their Registration Service Provider (Reseller). We recommend you take a look at these samples, so you’re aware of what this process will involve for your customers:

    Consent management sample flow – new registration
    Consent management sample flow – consent choice change

    Resellers will be able to view the GDPR consent status for each domain they have under management from the Domain Control Panel, within their Enom reseller account. If you’d like more information on why we require the end-user’s consent to process certain personal data, please check out our Consent blog post.

    2. Understand How to Provide Your Customers Access to Their Data Consent Settings Page

    According to the GDPR, “It shall be as easy to withdraw as to give consent.” With this in mind, we’ve provided our resellers two straightforward options to email a registrant the URL for the registrant’s Data Use Consent Settings page upon request:

    • Option 1: Via the API using the SendConsentEmail command
      Resellers can use this command to integrate into their own end-user portal an option for users to request that the Data Use Consent Settings page URL be sent to the registrant email.
    • Option 2: Via the soon-to-be-available “Send Consent Email” option in your Enom reseller account.
      Resellers can use this new button in the “Domain Control Panel” section of your Enom reseller account to send out the Data Use Consent Settings page URL to the registrant email listed for any domain in their account.

    3. Ensure You’re Prepared for Our Updated Domain Transfer Process

    Once the public Whois “goes dark” in the days leading up to May 25, 2018, Enom will begin using a new process for domain transfers. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

    You can check out our blog for the full details, but here’s a snapshot of the updated process:

    4. Enom Is Moving to a Gated Whois System

    For the full scoop, refer back to our Whois Changes blog post; for today, just keep in mind that after that go-live date, most public whois servers will cease the publication of personal data, and providers will start offering a “gated” or “tiered access” Whois system. Enom resellers don’t need to make any changes — your own clients’ data will continue to appear in your Enom reseller account, and we’ll take care of making sure the public Whois output is fully compliant with privacy regulations, so you’re good to go.

    These changes are also summarized in this quick PDF.

    5. Our Updated Reseller Agreement Now Requires That Resellers Process Data in a GDPR-Compliant Manner

    Hopefully, you’re well on your way to compliance with the GDPR. Enom has updated our Reseller Agreement to include information about the consent management process and the addition of a Data Processing Addendum (DPA), with EU standard contractual clauses to allow data transfer from the EU to non-EU jurisdictions. We encourage you to familiarize yourself with all the recent GDPR-related changes we’ve made to our Reseller Agreement by taking a look the updated version.

    6. We’ve Updated Our Agreement with Registrants

    Our Domain Registration Agreement serves as the service contract between Enom and the domain owner (registrant). We don’t expect the GDPR-related updates to this agreement to be reseller-impacting, these changes primarily relate to the registrant’s consent management flow and the data retention and erasure policy. Keep in mind that all resellers need to display this updated agreement to customers as part of the domain registration process.

    Reseller Resources

    All important Enom resources relating to the GDPR can be found in our central GDPR knowledge base article, but for convenience, we’ve also listed them below. We hope the following resources help our reseller partners assist your clients with GDPR-related changes:

    Overview

    Our GDPR Webinar
    Central GDPR knowledge base article and FAQ

    Specific Platform & Process Changes

    Consent Management

    Consent management sample flow – consent choice change
    Consent management sample flow – new registration
    Consent management FAQ

    End-user consent request emails – The means by which we send the Data Use Consent Settings page URL (see below) to the registrant.
    Data use consent settings pages – The location from which a registrant can set, view, and update their consent preferences or revoke consent.

    Domain Transfers

    Transfer process changes infographic – a before and after GDPR comparison
    Transfer-in approval email example
    Transfer-in approval landing page example

    Whois Changes

    Whois Changes Overview PDF
    Whois Changes FAQ

    API Changes

    A new SendConsentEmail command has been introduced.

    Contract Changes

    Updated Reseller Agreement
    Updated Domain Registration Agreement
    Data Processing Addendum

    And there you have it. We appreciate that for those resellers affected by the GDPR, achieving compliance has involved a great deal of internal work, in addition to that required to accommodate the changes Enom is making to our platform. And while we’ve made every effort to keep this Reseller Checklist short and easy-to-implement, we know, as members of that same complex registry-registrar-reseller channel in which you operate, that small changes made by one player can have a big impact on others. We view our GDPR implementation work as essential to ensuring that the Enom platform evolves to meet the long-term needs of our resellers and the demands of a highly interconnected internet ecosystem. Greater control over one’s personal data is a good thing, and we’re happy to be able to extend to all users on our platform the rights and protections outlined in the GDPR.

    Read More

  • Important Changes to our Legal Agreements

    May 10, 2018

    Announcement, GDPR

     Like

    Views: 277

    We appreciate the work that our reseller partners have done, alongside our own, to come into compliance with the GDPR. In support of that work, please review our updated Reseller Agreement and Domain Registration Agreement. These updated contracts will go into effect 25 May, 2018.

    These changes primarily relate to the registrant’s consent management flow and include the addition of a Data Processing Addendum (DPA), with EU standard contractual clauses to allow data transfer from the EU to non-EU jurisdictions.

    We also understand that ICANN will be adopting a standard Data Processing Addendum, which would apply to its role with us (and you), our role (and yours) with gTLD registries, and our role (and yours) with data escrow providers. We were hoping to make this available to you along with our updated agreement, but in the interests of time and the need to achieve compliance on the set schedule, we are using our own data processing addendum instead for the present.

    If, as we anticipate, ICANN develops and issues to registries and registrars a new binding policy under the terms of our Registrar Accreditation Agreement, with a mandatory or recommended DPA, we will likely amend certain terms of our Master Services Agreement and the associated exhibits to conform to industry standards and assure contractual compliance with ICANN.

    We also anticipate that gTLD and ccTLD registries will continue to amend their contracts in the days and weeks ahead, so please ensure that you are always pointing your users to the most current version of the relevant registry terms and conditions, as referenced in our Domain Registration Agreement.

    Should any additional changes be required in this rapidly evolving area, we will inform you via our blog and newsletter.

    Read More

  • Changes to the Domain Transfer Process

    April 30, 2018

    Announcement, GDPR, Industry Insight, Uncategorized

     Like

    Views: 785

    TL;DR
    The registrar transfer process for gTLDs needs to change once the public Whois “goes dark”. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

    Upcoming Changes to the Domain Transfer Process

    Among the most noticeable and significant changes to result from the domain industry’s implementation of the GDPR are those to the Whois system. As we’ve written in past blog posts, as of May 25, 2018, Enom and many other domain registrars and registries will cease the display of personal data in the public Whois.

    The industry discussion around the effects of the Whois “going dark” has largely focused on the possible lack of access that law enforcement or the security community members may have to Whois data, the potential problems this presents, and how parties with legitimate legal interest in the data may still be able to obtain it. However, the impact of the change goes beyond the simple ability for a person to look up a domain’s contact data. There are automated processes and systems which rely on access to the public Whois contact details in order to function, and we need to make accommodations for these processes as well.

    The most significant impacted process, which we are working hard to ensure is not interrupted by these changes, is the registrar transfer process. Here, we’ll provide details about how we will modify the transfer process to accommodate new, heightened privacy measures for the handling of registrant contact data, and we’ll suggest some changes that our resellers may want to undertake. Ultimately, the updated transfer process will not only provide a work-around for the lack of a publicly displayed contact email, but will result in a simpler, more streamlined experience for the domain owner while continuing to protect against unauthorized transfers and ensure the privacy of personal data.

    The Domain Transfer Process Today

    Let’s start with a review of the registrar transfer process as it stands today. For reference, we’ve provided a flow chart which compares the current and updated transfer processes.

    Step 1

    The domain owner works with their current (losing) registrar to unlock the domain and obtain the transfer authorization code, also called an EPP Code. This step will remain the same even after the transfer process is updated since the current registrar can and should verify that the person unlocking the domain and requesting the authorization code truly has the authority to do so.

    Step 2

    Once the domain has been prepared for transfer, the domain owner works with the new registration service provider to initiate the transfer. Here at Enom, we’ve always required the authorization code to initiate inbound transfer orders. Contact information may also be provided as part of the transfer order; if this information is not included, the Enom system will automatically use the account contact info for the domain transfer.

    Step 3

    In the current transfer process, the gaining registrar sends the initial Form of Authorization (FOA) to the domain transfer contact email, which they acquire from the public Whois. The domain transfer contact email may be either the registrant or the administrative contact; at Enom, our current practice is to send the FOA to both contacts. This FOA must be responded to within five days, and the transfer will only proceed if it is approved at this stage (Step 3a). Once the transfer contact approves the transfer, the gaining registrar submits the transfer order to the registry, who then notifies the current registrar (Step 3b).

    Step 4

    The current (losing) registrar sends a secondary FOA, which is optional for the domain transfer contact to complete. If the domain transfer contact does not respond to it within five days, the transfer will proceed automatically at the end of this five-day period. Alternatively, the domain transfer contact can choose to use this step to cancel the transfer or confirm it again.

    Step 5

    The registry operator completes the transfer process by moving the domain to the gaining registrar’s credential, typically renewing the domain for one year. At this time, the domain is usually locked for 60 days, although standard procedure may differ among registries.

    How Will Transfers Work Post-GDPR?

    At present, the gaining registrar initiates a domain transfer by sending an FOA to the domain contact email, but once the public Whois “goes dark,” registrars may not be able to identify the contact email for a domain that isn’t under their accreditation. The question becomes, how can we securely and efficiently process a domain registrar transfer without a publicly accessible domain contact email? Many registrars have been thinking about this as part of their GDPR compliance work and have taken a collaborative approach to finding an industry-standard solution.

    The TechOps Subcommittee of the Registrar and Registry Stakeholder Groups has proposed modifications to the current transfer process which are intended to resolve this issue; their March 8 letter can be read on the ICANN website. Enom will proceed with the changes to the inbound transfer process as described in that letter, to ensure that the inter-registrar transfer process continues to operate smoothly after contact data is no longer available via the public Whois.

     

    Keeping Domain Transfers Secure

    In the Enom platform, there will be no required changes to how resellers initiate inbound transfers (Step 2), since both the contact data and the transfer authorization code are already required. The only real change is that, in cases where we are the gaining registrar, once the transfer order has been submitted in our system we will move directly to submitting the transfer request to the registry (Step 3b). We are making the required change to deprecate the initial Form of Authorization, with no action needed by our resellers.

    Registrar transfers for many ccTLDs already follow a process very close to this, where the authorization code for an unlocked domain is all that’s required before submitting the transfer to the registry. Making this change across the board allows us to ensure that inbound transfers continue to function for all domains coming into our platform.

    Another security measure that we would encourage registrants to take is to keep the domain locked, using the “ClientTransferProhibited” status, at all times unless specifically intending to transfer to another registrar. As a registration service provider, you can help your customers maintain their domain security in several ways, including requiring strong account passwords, enabling 2-factor authentication, and locking domains by default until otherwise requested by the domain owner.

     

    Additional Changes We’re Making at Enom

    Moving forward, whenever a transfer into Enom is completed, the domain’s contact data will be updated to match that which was used for the transfer order. This is currently optional, but will become mandatory; we will no longer be able to rely on the registry-provided contact data to be correct and not include placeholder information, because other registrars may no longer share registrant contact data with registries. In cases where the owner contact is new to our platform, the registrant verification process will begin as soon as the transfer is complete.

    To better illustrate the streamlined transfer process, we have created this diagram:

    Enom Transfer process before & after

    You can also review the updated inbound transfer approval email and landing page content:

    Transfer In approval email

    Transfer In approval landing page

     

    Is This Really OK?

    Adjusting the inter-registrar transfer process in response to GDPR-related industry changes is a priority for Enom. We believe that domain owners should continue to be able to choose their registrar and move between registrars at their discretion, as long as sufficient security measures to protect against domain theft remain in place. Absent an ICANN-approved transfer policy modification, our best option is to conform with this model proposed by leading registrars, including Enom.

    The modified transfer process meets our requirements around security and anti-theft: only the authorized domain contact has the ability to unlock the domain and obtain the transfer authorization code, and only they may approve the transfer away from the current registrar.  

    We can already point to examples of the transfer process working as it is described here, in use today. Most ccTLDs, .CA and .DE, to name a few, currently follow a process like the one we’ve outlined above, where the authorization code is required to initiate the transfer, but there is no Form of Authorization requirement for the gaining registrar.

    And from the client’s perspective, this is just one less step for them to complete as part of the transfer process, making it easier for them to move to their preferred service provider. This change is something registrants have asked about for years, and it removes one of the barriers to transferring registrars without compromising the domain’s security.

     

    How Does This Relate to the Consent Management Process?

    There is, of course, a connection between this updated transfer process and the newly introduced consent management process — any domain coming into our system must have a consent settings profile that lets us know how to handle all personal data related to that domain. Transferring from one registrar to another, or from one Enom reseller to another reseller, will thus trigger a consent request to the domain owner, just like a new registration would.

    Enom resellers who use the “pushdomain” API command or the “push” option in the Control Panel to move domains between distinct reseller accounts should keep this in mind so that clients are not surprised by consent requests resulting from a domain push.

     

    When is This Happening, and How Should I Prepare?

    We will adopt this new domain transfer process when our other GDPR-related changes go live, on or shortly before May 25, 2018. We appreciate that this will require our resellers to educate their support staff and we hope this post serves as a valuable resource.

    While we cannot speak for other registrars or registry operators, who will no doubt soon be announcing their own plans for handling domain transfers in a post-GDPR world, we’d like to again emphasize the fact that the model we are following was born from the collaborative efforts of leading registrars, ourselves included, and has already proven to be secure and efficient when used for ccTLDs. It is our hope that other registrars will plan to follow this model, and that eventually ICANN and the community-led policy development process will bring us to an industry-wide standard; at such time as ICANN provides a working and mandatory transfer policy, we will certainly comply with it to the fullest extent that we are able. That said, our primary concern is that domain owners on our platform maintain full control over their private information, products and services, and the ability to select the registrar or service provider that they prefer, while we remain compliant with data privacy laws and ensure the appropriate levels of security are in place. These transfer process changes are significant, necessary, and ultimately create a streamlined process that benefits registrants, resellers, and registrars.

    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)

    Read More

  • GDPR Q&A for Domain Resellers

    March 27, 2018

    Featured, GDPR, Industry Insight

     Like

    Views: 5391

    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)

    Read More

  • The GDPR in 25 Minutes

    March 12, 2018

    GDPR, Industry Insight

     Like

    Views: 5246

    Business woman considers the GDPR in front of parliament building in Brussels

    If you’re looking for a short and sweet summary of the GDPR (well, as short and sweet as a summary of any legal policy can be), this is the video for you! Presented by one of our resident GDPR experts, our Reseller webinar explains the fundamental concepts of the GDPR, why it matters to service providers, and offers some tips on how to prepare. Created with Resellers in mind, it also provides a concise overview of the reseller-impacting changes we’re making at Enom.

    If you’re looking for more info on one of the topics that we touch on here, check out our GDPR blog posts. We also provide a handy Reseller FAQ on our GDPR resource page.

    Note: The information contained in this video is non-exhaustive and should not be considered legal advice. You should consult with your lawyer to determine the impacts of the GDPR on your business.

    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

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

    Read More

  • GDPR-Related Contract Changes

    March 5, 2018

    Announcement, Featured, GDPR

     Like

    Views: 4922

    If you’re reading this, chances are you have questions about the GDPR and how Enom is preparing. We’ve got answers! Sign up for our GDPR webinar on March 7 or March 8 to learn from one of our GDPR experts.

    The GDPR can be approached in terms of three fundamental concepts:

    1. Consent and control

    2. The Right to be forgotten

    3. Transparency

    We’ve talked about two of these concepts in past blog posts, and today we’ll look at the third: Transparency.

    Transparency is one of the core principles in the GDPR, emphasized in Article 5 of the policy, which states that personal data must be “processed lawfully, fairly and in a transparent manner in relation to the data subject,” and must be collected for “specified, explicit and legitimate purposes.” In short, the data subject has to be kept informed as to what data is being collected and how that data is being used.

    One of the main ways that we inform our clients about how their data is being used is through our contracts, and we are now ready to share more information about the upcoming changes to our reseller and end-user service agreements, which are being made as part of our GDPR implementation efforts.  

    Before we dive into the specifics, I want to emphasize again how important it is to read the GDPR for yourself, and to engage legal counsel who is competent to support your business through the process of coming into compliance with the GDPR.

    As we work in partnership with our clients to ensure that we accept, collect, process, and share personal data in a GDPR-compliant manner, there will be changes to our contracts, in the form of either a stand-alone Data Processing Agreement or an Addendum to the Reseller Agreement and Domain Registration Agreement. Regardless of whether we take the stand-alone-agreement or addendum route, there are a few things that you need to be aware of as a reseller.

    Changes to Our Contracts with Registries

    As a registrar, we have a Registry/Registrar Agreement in place with every registry with which we are accredited. We expect that many of these Agreements will be updated by the affected registries to be compliant with the GDPR. To this point, however, we’ve seen inconsistent approaches from the European ccTLD registries, and no GDPR-related contract updates from gTLD registries. We are working together with other industry groups to standardize a model for what these contractual changes will look like; without a standardized approach, we would have to negotiate individual amendments with each registry, a difficult undertaking to complete by May 25, 2018, given the number of registries with which we partner.

    Moving Toward an Industry-Standard Approach to Contracts

    Given the changes we expect to see from registries, changes we expect registrars will make, and changes that we believe will be recommended by ICANN, we are hopeful that industry-standards will develop in the coming weeks which we can incorporate in our changes to our own agreements. These efforts are ongoing, but once a final decision about exact language has been made, we will update you. 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 have our own contract changes out to our partners.

    Changes to Our Contract with Reseller Partners

    Our amendments to our reseller agreement will outline the obligations for both ourselves and our clients that are necessary to ensure that every user on our platform is fully protected in a way that aligns with the GDPR. We expect that contract changes will track certain standardized language that has been approved by the European Commission in years past, such as this European Commission decision, which provides some standardized contract language for data sharing.

    Here are some of the changes that you can expect to see in our Reseller Agreement which governs the services we provide to resellers. These updated requirements will apply both to us and to our resellers:

    Data Storage
    • All personal data must be stored securely and handled with appropriate protections
    • Any subcontractors who are allowed to access data also must have adequate security in place
    Data Sharing
    • Any data sharing must be done in accordance with the GDPR  
    • Data that is shared must be maintained securely by both the sending and the receiving parties
    • Any data exporter will be liable for damages suffered by the data subject for any violations of the GDPR
    Disclosure
    • The data subject will be informed about the collection and sharing of their personal data in a GDPR-compliant manner
    • All contracted parties (including Tucows and the reseller partner) agree to work cooperatively with Data Protection Authorities if questions arise about the use and sharing of personal data

    Changes to Our Contract with Registrants (End-Users)

    For our Domain Registration Agreement, which governs our relationship with the domain registrant, changes will include:

    • Clear explanation of which data elements are required by contract — we require the registrant’s first and last name, organization name (if provided), email address, and country; Registry agreements may extend this contractual data set.
    • Confirmation that, if a third-party’s contact information is used as the domain’s administrative, billing, or technical contact, the registrant will have the appropriate contract and/or consent with that third-party to satisfy the GDPR’s requirements around data use

    Moving forward

    Rest assured, there will be no major surprises found in the changes to the Master Services Agreement or Domain Registration Agreement, provided your business is GDPR compliant. As always, we’re taking care of the heavy lifting to minimize the effort required on your end. We hope this allows you to remain focused on your day-to-day business and whatever internal changes you may need to make to come into compliance with the GDPR. Take a look at the European Commission’s standard contract text, and keep an eye out for our future updates. And don’t forget to sign up for our GDPR webinar, where we’ll share more details about exactly how this new regulation is affecting the Enom domain service offering. Hope to see you there!

    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

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

    Read More

  • GDPR Resources: The Right to Be Forgotten

    February 1, 2018

    GDPR, Industry Insight, Uncategorized

     Like

    Views: 2019

    Business woman considers the GDPR in front of parliament building in Brussels

    Our last GDPR post covered the basics of the right to erasure, as outlined in the GDPR. This week, we’re expanding on the topic by highlighting a few recently published resources that address the requirement’s potential impact on service providers and the domain industry, and explore some paths to compliance.

    GDPR Compliance Models From ICANN

    I wanted to start off on a more general, but highly significant, development in the domain world. ICANN’s “Legal Analyses, Proposed Compliance Models, & Community Feedback” page has been updated with several models for GDPR compliance. I would strongly encourage everyone interested in the topic to familiarize themselves with the contents of this page. Domain providers have been working on GDPR compliance for months, if not longer, and the ECO playbook (“CM3” on this page) is the result of collaborative efforts from many key players within the industry, including Tucows. While this work was being done, the internet community awaited— with great anticipation—the release of ICANN’s own official approach.

    After a long silence, ICANN came back with three suggested models, each of which has significant flaws. To name a few, the ICANN

    models focus mainly on Whois, rather than the whole ecosystem of data sharing that a typical domain registration ties into, and the models continue to require collection and sharing of more data elements than our assessment believes are acceptable under the principle of data minimization (which restricts data processing to those elements necessary to provide the contracted service). At present, there’s an industry conversation around what model can be accepted both by contracted parties (registrars and registries) and ICANN, but we are proceeding with our GDPR implementation work as planned, relying on our legal counsel to help find the balance between compliance with ICANN and the GDPR itself.

    Fuhgettaboutit: the GDPR “Right to Erasure”

    This article delves into the details of the right to erasure and its operational impacts on service providers. Placing an emphasis on the wide scope of the requirement, it provides a general perspective, not specific to the domain name industry, and gives the reader a good sense of how much work fulfilling just a single erasure request could entail.

    GDPR, Right of Erasure (Right to be Forgotten), and Encryption Key Management

    The GDPR requires that data be held securely which, in a digital world, usually requires encryption. But one thing I hadn’t considered was using encryption not only for security but also to fulfill right-to-erasure requests. That’s what’s proposed here: if the encryption key no longer exists, the data can never be revealed, and essentially no longer exists. Receive a request-to-be-forgotten from a customer? Erase the key that decrypts all their personal data, and the data itself is effectively erased. I will admit that I’m not an encryption and data security expert, but it seems to me that there’s a difference here—encryption can be broken, or could already be compromised, so I’m not convinced that we can equate the erasure of a key to the erasure of the data the key decrypts. I’d love to hear from people in that field as to whether this is indeed a viable approach to data erasure and, more specifically, if it would satisfy the requirements laid out in the GDPR.

    Where does this leave us?

    At this point, it seems clear that service providers across industries should be thinking about right-to-erasure requirements and the significant work it will take to reach a state of compliance. What’s still a bit unclear is the “how” of it all. Encryption key management, which we’re sure to see further discussion about, may prove be a viable method for some providers, and other approaches are sure to surface in the months leading up to May 25, 2018.

    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

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

    Read More

  • The GDPR’s Right to be Forgotten

    January 18, 2018

    Featured, GDPR, Industry Insight

     Like

    Views: 5187

    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)

    Read More

  • GDPR Resources: Consent

    January 4, 2018

    Featured, GDPR, Industry Insight

     Like

    Views: 3901

    Business woman considers the GDPR in front of parliament building in Brussels

    The GDPR’s requirements around consent for data processing are complex, and we aren’t the only ones thinking about what this means for our business or how to best comply with the regulation. Below, we’ve shared a few links that give some added context around consent as it relates to the GDPR.

    How the GDPR will disrupt Google and Facebook

    The title says it all. This article speculates on how Google’s and Facebook’s current consent request processes might have to change in order to become compliant with the GDPR’s consent and data use requirements. It lays out a GDPR risk scale, examines where different consent methods fall on this scale, and then evaluates personal data use by Facebook and Google to estimate where those different data uses rank and what changes the tech giants may need to make in order to continue processing this data in a post-GDPR world. The conclusion is that, while much of this personal data processing can be done in a way that is GDPR-compliant, the requirement to obtain consent will disrupt the ability to use data for marketing and advertising purposes. The extent to which this impact will be visible to the average user remains to be seen.

    WP29 Guidelines on Consent under Regulation 2016/679

    In our GDPR Resources: Whois Changes post, we looked at a letter that the Article 29 Working Party (“WP29”) sent to ICANN; here’s another great publication from the same advisory body, offering guidelines on how consent can be used as the legal basis for data processing under the GDPR. WP29’s interpretation of the GDPR aligns with our own understanding of the consent requirements and serves as a helpful resource for anyone working to create their own consent request processes.

    ICANN’s GDPR legal analysis

    The second and third memos from Hamilton Advokatbyrå have been published, following the first memo which we discussed in a previous GDPR Resources post. The most recent memo focuses on how the Whois system would need to change to be compliant with the GDPR, and refers to a conclusion drawn in the first memo: although consent would be a possible legal basis for publication of Whois information, it would not result in a fully accessible Whois like we have today, since data subjects will be able to withdraw consent, preventing any “extra” data (which isn’t necessary to providing domain registration services) from being published. Anyone keeping up with GDPR policy will want to keep a close eye on these Hamilton memos and the domain industry’s responses to them.

    We’re happy to see that many of the assessments and practices being discussed by other key players in the industry are in line with our own plans for a gated Whois system and revamping of our consent request processes. We want to support our resellers through this transition by providing useful resources and maintaining a high level of transparency about our own GDPR implementation plans. Sign up for GDPR updates to make sure you’re kept in the loop!

    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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • Consent and the GDPR

    December 21, 2017

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 5237

    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)

    Read More

  • GDPR Resources: Changes to Whois

    December 7, 2017

    Featured, GDPR, Industry Insight

     Like

    Views: 2232

    Business woman considers the GDPR in front of parliament building in Brussels

    Following last week’s discussion of the significant Whois changes that compliance with the GDPR will require, here are some resources that I hope will help put things into a broader context.

    A letter to ICANN from Article 29 Working Party December 6 2017 (PDF)

    The Article 29 Working Party (“WP29”) is an advisory body established in 1996 under the EU’s Data Protection Directive (soon to be replaced by the European Data Protection Board under the GDPR). This letter to ICANN directly addresses the public Whois and how that system intersects with data privacy laws. WP29 says “unlimited publication of personal data of individual domain name holders raises serious concerns regarding the lawfulness of such practice under the current European Data Protection directive,” suggesting that this will be the case under the GDPR as well since it is based on the same principles. WP29 also states:

    “Whilst the data protection authorities united in WP29 recognize that, inter alia, enforcement authorities entitled by law should have access to personal data in the WHOIS directories, they also underline that the original purposes of the WHOIS directories can be achieved via layered access. In this respect, the unlimited publication of WHOIS-data does not appear to meet the criteria of article 6.1 (c) of directive 95/46/EC (personal data must be adequate, relevant and not excessive in relation to the purposes of the WHOIS directories).”

    This is the same conclusion that we arrived at — the public Whois system as it exists today is incompatible with the principles of data privacy that the GDPR affirms. It is gratifying to see this strong statement coming out of the EU, especially since it aligns with our own understanding of the changes to our domain registration infrastructure that the GDPR will require. Hopefully, this prompts ICANN to review and update their policies, allowing Registrars and Registries to comply with applicable laws with no concerns about breaching the affected sections of their ICANN contracts.

    “ICANN under pressure over GDPR preparations, as future of WHOIS is mired in uncertainty”

    Originally posted on World Trademark Review, this blog post was written for the benefit of trademark holders but contains useful insights for anyone with a connection to the world of domain names. If you’re looking for an overview of recent events related to how ICANN’s Whois plans—and those of its larger community—are progressing, this article outlines many of the challenges the GDPR presents to those operating within the domain industry, and highlights some conflicting opinions put forth by various stakeholders.

    ICANN’s GDPR legal analysis

    ICANN is working with an EU-based law firm, Hamilton Advokatbyrå, to gather legal advice related to the GDPR’s impacts on the domain name system; this page on the ICANN site will hold analysis from Hamilton as well as related documents. The first part of this analysis was posted on October 16, 2017 and responds to a series of questions that ICANN had laid out. In this response, Hamilton suggested that ICANN should evaluate the purposes for which personal data is being processed (displayed in the Whois). They also confirmed that these purposes could likely be achieved while remaining in compliance with the GDPR by using a gated Whois model, as we discussed in our previous post. We don’t yet know how ICANN will act on this information. Part 2 of the Hamilton analysis, which will look at the GDPR’s broader impact beyond the Whois system, is said to be “coming soon.”

    Dutch DPA: unlimited publication of Whois-data violates privacy law

    The .AMSTERDAM and .FRL registries are at odds with ICANN over the publication of personal data in the public Whois for these two TLDs. You can read the letters back and forth between ICANN and Jetse Sprey, who represents the .FRL registry, on ICANN’s data protection page and there’s a good recap of the situation at Domain Incite. The Dutch Data Protection Authority stepped in with this statement indicating that publication of personal data in the public Whois does, in fact, violate current Dutch law, and will also violate the GDPR. This gave .AMSTERDAM and .FRL a basis to argue to ICANN that they’re not in breach of their Registry Agreement. The statement also acknowledges that there may be technical or legal reasons why personal data should be accessed, but argues that default publication of registrants’ full contact details in the public Whois should not be permitted.

    Letter from CENTR answering ICANN questions (PDF)

    ICANN contacted various registries with a series of questions requesting information about how data protection laws are currently addressed. You can read the initial request here (PDF). CENTR, the Council of European National Top-Level Domain Registries, was unable to share some of its confidential discussions but provided general information that came out of a June 2017 survey. One notable statistic from this survey is that over 40% of these registries plan to hide some fields from the public Whois. I’m looking forward to the results from the next survey, which should hopefully be available before the end of 2017, and will tell us more about the ‘state of mind’ of these European ccTLD registries.

    Looking ahead

    While the future of Whois may be unclear at this point, it is clear that change is coming. We are moving ahead on our work towards a gated Whois, a solution which resulted from extensive legal and regulatory investigation and which we believe balances our legal obligations with our contractual requirements to ICANN. While a consistent, industry-wide approach to Whois, led by ICANN, would be ideal, it seems right now to be a far-off prospect.

    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)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • How will the GDPR impact Whois?

    November 23, 2017

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 4258

    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)

    Read More

  • The nTLD Reseller Starter Guide: Which new gTLDs should I offer?

    November 14, 2017

    Uncategorized

     Like

    Views: 2220

    If you currently sell or are considering selling domain names as part of a business, you may have asked this question to yourself before. The huge variety of gTLDs out there can turn the task of curating a lineup that makes sense for your business into a rather daunting undertaking. Instead of getting bogged down by all the variables that could weigh into your final decision, I suggest you focus on the handful of key considerations that really matter. The questions below will help you better evaluate TLDs and equip you to make smart choices as you expand or refocus your offering. And in case you still feel stuck, we’ve included a list of extensions you might consider.

    Is the TLD easy to implement?

    Most of the new gTLDs fall into the “easy-to-implement” category, free to be registered by anyone, anywhere, much like a .COM. Others have strict registration requirements, such as a local presence in their associated geographic area, or an affiliation with a particular professional group. If you ever need to verify whether an extension you’re considering is restricted, take a quick look at our TLD reference chart.

    The TLDs we’ll highlight in this post are all easy to implement, but that’s not to say you should steer clear of those that are restricted. In fact, offering restricted TLDs can be a great way to cater to a niche market. For example, many firms might find the credibility of a .LAW extension advantageous. Similarly, the appeal of geoTLDs like .NYC, .BARCELONA, or .BERLIN among local citizens make them a great choice if you attract a significant volume of customers in any of these cities. If you think you’re likely to sell a high volume of a certain restricted extension, the payoff may well be worth the extra implementation efforts involved. It really comes down to knowing your audience and presenting them with options they are likely to find meaningful.

    Is there a high level of interest in the TLD?

    Unless you’re catering to a highly specific market, you’ll benefit from starting with TLDs that have wide appeal. This appeal can be generated by both the generic nature of the extension (.WEBSITE or .ONLINE), or its specificity (.CLOUD, .BLOG, .SHOP, .STORE or .DESIGN). Note that each of those last five extensions has an unambiguous meaning that resonates with a huge number of potential buyers.

    This doesn’t mean a small TLD offering shouldn’t include more niche extensions. Again, the level of interest your customers show for a particular TLD will always depend on who your customers are. I had a musician friend, for example, that was thrilled to launch her new business with a .STUDIO name. And I’m willing to bet there are a lot of artists out there who might be open to a similar departure from the traditional, more corporate-sounding extensions.

    Does the pricing make sense?

    Most potential nTLD buyers compare new possibilities to .COM alternatives. So presenting them with fresh, viable options in a similar price range is smart. There are many solid performers, with broad applications, that fall into this category. Of course, this isn’t to say that a high price tag should deter you from offering an extension that seems particularly well-suited to your customer base.

    It’s also not just the initial purchase price you should be aware of. Simple and predictable pricing structures are an important factor in building an enduring customer base. So while offering TLDs with substantial first-year discounts might translate into increased registrations, you could find yourself unpleasantly surprised by relatively low renewal rates. A customer who purchases a domain on promotion might not be put off by a slightly higher renewal fee. But there are numerous registries that present enticing first-year TLD price tags in the .COM range, with renewal fees that might be 10x greater. These kinds of discrepancies not only deter savvy buyers from making the initial purchase, and put a dent in your renewal rates, but also place you at risk of angering customers who are caught totally off guard by the increase.

    In short, it’s advantageous to offer first-year promotional prices, as they can be a real incentive to potential buyers. But it’s also important to make sure you’re transparent about the renewal price, displaying it clearly within your purchase flow. For those who sell domains as a part of a larger bundle or package, the renewal price, and the margin it allows for, should be factored into your pricing structure.

    Is the renewal rate and customer quality fairly high?

    It’s been a few years since the launch of the first nTLDs, which means we’re now in a much better position to evaluate their long-term potential. When determining the value of a new extension, look into its renewal rate and whether its registrations are, generally, being used in a meaningful way. Arguably, there’s a link between the two.

    That latter point is what I mean by “customer quality”. If you’re a hosting provider or CMS business, you stand to make more money off customers who are actually using their domains. They’re certainly far more likely to show interest in email, SSL and hosting services. They’re also more likely to renew. Not to mention, there’s a case to be made that websites that have valuable content, and employ a new TLD, effectively function as an advertisement for the extension itself. That certainly can’t hurt an extension’s organic growth over time.

    In this regard, .BLOG is a standout – according to ntldstats, only 27% of its registrations are “parked”, a term applied to any domain “in use as a parking page [displaying ads], or without any content.” To put this number in perspective, the average parked page percentage for the TLDs we highlight in the chart below is roughly 53%.

    Still feeling a little lost?

    That’s fair! The paradox of choice is a powerful thing. Here are some suggestions that might serve as good place to start. Judging them based on the checklist above, these TLDs don’t necessarily score high across the board, but they are all easy-to-implement and offer the potential to target a sizable audience – some because of their generic nature and global recognizability, and others because of their appeal to a specific, but substantial, market.

    To reinforce my early point: while we haven’t focused on geoTLDs in this post, they represent a sizable portion of the nTLD pie. Depending on your target market, they can be incredibly profitable.

    If you’re ready to explore what options might work best for your business, you can view all available TLDs at enom.com.

    Read More

  • GDPR Resources: Basics & best practices

    November 9, 2017

    Featured, GDPR, Industry Insight

     Like

    Views: 2535

    Business woman considers the GDPR in front of parliament building in Brussels

    If you’re anything like me, you’ve spent the days since our first GDPR blog post thinking nonstop about the policy’s potential impacts on the domain world. Okay, maybe you have other things to do with your time… But luckily, there are a lot of great minds at work on this issue. This week, I’d like to share a few links that give some useful background information and starting points as you think about what the GDPR means for you and your business.

    1. IAPP: Top 10 Operational Impacts of the GDPR

    The International Association of Privacy Professionals wrote ten articles looking at different aspects of the GDPR. I particularly liked their review of what Consent looks like under the GDPR and their Consequences for GDPR Violations piece really brought home just how much this new regulation overshadows other data privacy-laws, including the EU’s previous Data Protection Directive, in terms of its scope and enforcement mechanisms.

    2. ICANN: Data Protection/Privacy Issues

    ICANN is the global nonprofit organization that coordinates the technical and operational services of the internet. This page on ICANN’s website lists various data privacy-related projects, including information and resources about ICANN’s work related to the GDPR. Especially of interest are the October 18 blog post and the November 2 announcement from the Contractual Compliance team; the blog post acknowledges that the GDPR will affect how Whois is displayed, and the November 2 statement talks about how contractual obligations will be handled in a post-May-25-2018 world. Both are important starting points in understanding how aspects of the industry are likely to change under the GDPR; ICANN and the organization’s larger community have yet to determine a consistent, official approach to responding to the challenges presented by the policy.

    3. GeoTLD.Group: GDPR Info Page

    As its name might suggest, this not-for-profit represents the interests of the various registries that operate geographic top-level domains worldwide. The GeoTLD Group has put together several useful reports and presentations about the GDPR, including a review of best practices from registries that already follow similar regional data-privacy laws. They also conducted a general survey of the domain industry which provides insight into the policy’s impact on domain-related businesses and what measures these companies are incorporating into their implementation plans.

    Ultimately, I find it reassuring that so many different groups are thinking about what changes might be needed for compliance with the GDPR. Getting your business ready can seem like a daunting task, but seeking legal counsel and familiarizing yourself with the basic concepts will ensure that you’re prepared. You can subscribe for updates and helpful resources on our GDPR page.

    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)

    Read More

  • The GDPR: what it is and why it matters to you

    October 30, 2017

    Announcement, Featured, Industry Insight, News

     Like

    Views: 3433

    Update: March 6, 2018

    Previously, we had announced plans to apply GDPR-related requirements and processes only to domains registered by EU-local individuals. We have since changed our approach and now plan to extend these heightened privacy and security requirements to all registrants and reseller partners. This streamlined solution ensures that our platform is secure and GDPR-compliant, and recognizes that there are privacy laws worldwide, beyond the GDPR, which must be respected.

    “Data privacy by design, data privacy by default.” You may have heard this phrase recently, on Twitter or in blog posts, but where does it come from? What does it really mean? Most importantly, how does it affect your customers and their domain names?

    What is the GDPR?

    The European Union’s General Data Protection Regulation (“GDPR”), coming into effect in May 2018, lays out a new set of rules for how the personal data of people living within the EU (“EU-local individuals”)* should be handled. It sets out the protection of personal data as nothing less than a fundamental human right, alongside other rights such as freedom of expression, freedom of thought, and the right to a fair trial. The GDPR is complex and far-reaching, and we’ll look at a few of the most impactful areas in this blog post. You can also keep an eye out for updates on our dedicated GDPR page.

    Data privacy by design, data privacy by default

    How many times have you bought a concert ticket online or RSVP’d to an event, only to find your inbox unexpectedly filling up with the concert venue’s newsletters and invitations to other events that are only tangentially related? Wouldn’t it be great if service providers had to get permission to use your contact information for anything other than what you’d provided it for in the first place?

    That type of clear, informed consent is one of the basic requirements in the GDPR. Any business taking in your personal data not only has to explain what they need it for, they’re also simply not allowed to require you to provide more information than the absolute minimum they need to get the job done. What’s more, they can’t use your info for any purpose other than that to which you agreed to in the first place. This puts you in charge of how your info is used from the very start — by design and by default — instead of making you unsubscribe after the fact.

    Direct mail campaigns aren’t as popular as they used to be, but I still get a few pieces of paper mail each week, and I’m always both amused and a little scared at how companies I’ve never heard of get my contact information. A friend of mine used to put the name of the service provider in the second line of his address every time he signed up for something new, and he was amazed to find that his credit card and telephone providers shared his info with any number of sales companies.

    Online marketers these days use email rather than postal mail, of course, but the underlying issue of your personal data being shared by someone you trusted with it remains, and the GDPR takes aim at this problem as well. Not only should companies’ use of your data remain within the limits of what you consented to, but the data needs to be stored securely, accessed only for the reasons already agreed upon, and cannot be shared with third parties outside the bounds of this regulation and what you consented to.

    Quick, transparent reporting on data security breaches

    We all know mistakes happen, and security best practices are constantly evolving. Living in the world means accepting some measure of risk, and it seems that every few days there’s a news story about a major data breach affecting hundreds of thousands of people — but usually by the time we hear about it, the breach happened months ago, leaving sensitive information exposed to the world and the affected people unaware. The GDPR addresses this with a timeframe around breach notifications, requiring that people whose information has been compromised are notified as soon as possible. This notice must include an explanation of what happened, what’s being done to fix it, and what the affected people should do to protect themselves. This type of information empowers each person to respond the way they think is best in each circumstance in order to protect their own privacy.

    The right to be forgotten

    I once created an account with a subscription box service, the kind that would send me new makeup every month. Only after I signed up did I discover that they were all sold out… I wouldn’t get anything for at least six months, if not longer — I can’t wait that long for new lipstick! I canceled the account, but couldn’t get them to stop emailing me, asking me to reactivate, choose my colours, pick my brands. Why can’t they just forget all about me? Or, for a perhaps more serious example, how often do we hear stories about people who lose out on job opportunities for which they would be very well-suited, just because of youthful indiscretions that still come up high in online search results?

    That’s another important aspect of the GDPR: the right to be forgotten. Under these new rules, people can go back to service providers and revoke the consent to use their data, requiring the provider to remove all records and essentially erase them, giving them a fresh start. Now, this may not be without consequences (some services can’t be provided without personal information) and may not always be applicable (sometimes personal information has to be kept for reasons of public interest or relating to legal claims), but it’s certainly a lot more effective than sending an “unsubscribe” email, blocking the sender’s email address, and hoping for the best.

    How does this apply to the domains world?

    You might be thinking, “I’m not even in the EU! Why does it matter?” Are you a reseller with clients in the EU? Does your business have the potential to process the data of EU-locals? You now need to ensure that you’re obtaining permission from these customers to use their personal data, and meeting the updated requirements surrounding its handling. This should involve a talk with your lawyer(s). Though we’re making an effort to provide resources and context, the information we’re providing should not be considered legal advice. Seeking professional, legal counsel from someone who is familiar with your specific situation is critical.

    If you’re an Enom reseller, you’ll also need to familiarize yourself with the platform-wide changes we’ll be making (I recommend subscribing to receive GDPR updates). Among other changes, we’re working on amending our Agreements with our resellers, including Privacy Agreements, to allow resellers full access to the info in the Control Panel without any concerns around GDPR violations.

    While the rules outlined in the GDPR apply only to EU-local individuals*, changes to how data is collected and handled may happen on a global scale as companies modify their existing practices to ensure they are compliant with these new regulations. We will try to minimize any disruption to our domain management and registration processes for registrants and resellers.

    Going back to the “data privacy by design and by default” idea, what it means is that all these regulations around protecting personal information can’t just be afterthoughts, they need to be “baked in”, part of the system that’s on unless you turn it off. We’ll be empowering our clients to understand what information we hold and how it’s used, to give consent to us for that use, and to request erasure of data in cases where consent cannot be provided.  

    Changes we’re making at Enom

    These data privacy protections touch almost every aspect of the domain onboarding process and lifecycle. We’re working through our detailed plans now, and will soon be able to share more information about our implementation; today I will share some highlights. As we work through this project, we’re keeping two things in mind: our need to operate within the bounds of legal requirements, and our commitment to keeping domain purchase and management as straightforward, simple, and instantaneous as possible for the end-user.

    Thinking about consent, we’ll implement a post-purchase consent process, similar to the Registrant Verification request we send when a new domain is registered. We may combine the two into a single request if both verification and consent are needed at the same time. Watch for details on this process in upcoming blog posts and our GDPR page.

    We already store your data securely, but we’re doing some internal review to see how we can strengthen our protections to keep information safe. Thinking back to the example of the marketing company who shared info with third-party companies, I want to make it clear that Tucows does not share personal data beyond what’s needed to provide the service that the client ordered. We never sell our client’s personal information, and we certainly aren’t going to start now.

    Although in a perfect world every domain would stay with Tucows forever, I know that, realistically, some people want to use other Registrars, or don’t want to renew every domain they have registered until the end of time. And when they’re no longer our client, they may not be comfortable with Tucows storing their personal data. That’s where the right to be forgotten comes in; we’ll be reviewing our data retention procedures, and putting in place a method for people to request erasure of personal data from our platform. As I said earlier, this is not without consequences, but in some cases (like my ill-fated makeup box subscription) it’s necessary.

    Conclusion and Next Steps

    I hope that this overview of the GDPR and the changes we’re looking at making has been helpful, and explains why this new regulation is important not only for our European clients, but for our resellers worldwide. I know it’s a lot of information, and that you have many questions. We’ll be reaching out to resellers on implementation details soon, and keeping you informed as we move through this process. Until then, check out our blog and GDPR page for more details as May 25 2018 approaches!

    *Initially, this post employed the terms “EU citizens” and “EU customers” in place of “EU-local individuals.” The term “EU-local individuals” was introduced to provide clarity.

    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)

    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)

    Read More

1 2 … 13 Next »

FEATURED POSTS

  • GDPR Checklist for Enom Resellers

    May 17, 2018

  • GDPR Q&A for Domain Resellers

    March 27, 2018

  • GDPR-Related Contract Changes

    March 5, 2018

  • The GDPR’s Right to be Forgotten

    January 18, 2018

CATEGORIES

  • Advice
  • Announcement
  • Developers
  • DNS
  • Featured
  • Fun
  • GDPR
  • Industry Insight
  • New TLDs
  • News
  • Premium Domains
  • Promotion
  • Resellers
  • Roadmap
  • SSL
  • Uncategorized
  • WTB

ARCHIVES

  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • January 2016
  • December 2015
  • November 2013
Support
Report Abuse
Help Center
Contact Us

 Resources
WHOIS Lookup
Maintenance Alerts
Developers
Products & Services
Domain Name Search
Premium Domains
Web Hosting
SSL Certificates
Website Builder
Basic Email
Bulk Tools

© 2018 Enom Blog |