1. Openprovider
  2. Quick Start
  3. Frequently Asked Questions

Openprovider and GDPR

Question

Is Openprovider GDPR compliant?

Answer

On May 25, 2018, the General Data Protection Regulation or GDPR, became effective.

This regulation was created to protect the personal data of private individuals within the European Union.What can a reseller expect from Openprovider with respect to the GDPR?

This article contains information about the following topics:

Data processing agreement

Openprovider has created a data processing agreement which clearly defines which data we collect for what purpose and defines your (being the controller) and our (being the processor) responsibilities with respect to personal data of the data subject. This agreement is additional to the general Terms and Conditions, and you can accept the agreement from your control panel. If the reseller has already accepted it, it can be found here in the Contracts section of the control panel.

Data collection

Data collection will not require technical changes on the reseller's side in short term. Openprovider collects two types of data:

  • Data that Openprovider uses by itself: the data that Openprovider collects about the reseller, our customer, is required for the performance of the service: creating the reseller account, sending invoices, newsletters, ... Of course, resellers can unsubscribe from our newsletters at any moment, but please know that this is our primary means of communication for important updates to Openprovider products, services, terms, and prices. If a reseller accidentally unsubscribes, a re-subscription can be made through the Openprovider homepage.
  • Data collected for product delivery: the data that Openprovider collects about your customers (the domain contacts and the contacts of other products and services) will not notably change. Almost all providers will keep requiring full contact data for operational and legal purposes, though these data are not shared publicly anymore. However, some registries do not require all contact types anymore with a domain registration:
    • NIC AT (.at) removes the administrative contact.
    • DENIC (.de) removes the administrative and technical contacts.
    • Ficora (.fi) removes the administrative contact and does not allow private individuals to use the technical contact anymore.
    • NIC LT (.lt) will remove the technical contact; it also adds a requirement for the company registration number (for legal entities).
    • IIS (.nu and.se)  no longer require a VAT number; the corporate identity number or personal identification number remain required.
    • NASK (.pl) removes the technical contact. Additionally, the current optional “reason for registration” has been removed.
    • In general, it’s good practice to stop using personal e-mail addresses for administrative and technical contacts for domain names. Openprovider advises relying on role-based e-mail addresses like support@ or webmaster@.

Openprovider is investigating how to fine-tune Openprovider's data collection and retention: data elements that are not used at all may be removed; data elements that are used for specific extensions only will be removed as soon as no such domains are linked to that contact anymore. Unused contacts in Openprovider will be removed with a notification.

In all cases, Openprovider system (control panel and API) will be fully backwards compatible; Openprovider do not force changes from the reseller side.

Whois

For the Openprovider product domain registration, the reseller will face the biggest changes in the whois. Most European registries already show a limited set of data in their whois registers because of current privacy laws, and Openprovider will see these data being minimized even further. In many cases, no personal data will be shown at all.

For generic extensions (gTLDs), the registrar community is working together with ICANN and the European DPAs on a solution that meets both the requirements of GDPR and ICANN policies.

The final solution will be full implementation of the new RDAP protocol, but in the short term, the whois is changed according to ICANN's interim model. This model allows registries and registrars to hide all personal data from the whois, except for the organization name, the state and country (for legal purposes) and a replacement for the e-mail address (either an anonymized e-mail address of a web form), though some registries may skip this. Access to full whois data is possible only for selected purposes and only through an accreditation process (for example, law enforcement organizations).

An example of the new whois output is:

Contacting a domain holder

Of course, those changes have effect as well if you wish to contact the domain holder of a domain not running at Openprovider. Depending on the registry, there may be three options:

  • An anonymized e-mail address is published; the reseller can still send an e-mail, and the registry or registrar will forward it to the real e-mail address of the domain contact.
  • Instead of an e-mail address, a link to a web form is published. The registry or registrar will send the message to the domain contact.
    • This is the model that Openprovider implements.
  • In some cases, there may not be any contact method for the domain holder. In that case, search the website published on this domain name for contact details or address the registrar of the domain name.

gTLD transfers

The transfer policy changes proposed by the Registrar Stakeholder Group were adopted by ICANN.

The requirement to send an e-mail to the owner and/or administrative contact (the so-called "Form of Authorization" or "FOA") can no longer be enforced, as for the above-mentioned whois limitations: even if an e-mail address is listed in the whois, it might be a dummy address that does not receive any e-mail at all.

Therefore, the gTLD transfers will now be initiated directly at the registry, skipping the required e-mail approval by the domain contact. This will reduce the transfer time to a maximum of five days. Please note that each registry and registrar defines its own policy. For some domains, an FOA may still be required.

A big change compared to the current policy, is that the losing registrar may reject a transfer within five days if he gets no affirmative response from the domain holder. In the current policy, refusal of an outgoing transfer by the losing registrar is only possible in a few very strictly defined cases. We do not know yet if any registrar will implement an "auto-reject" policy, but it may be wise to inform your customers that they should not ignore any transfer e-mails. 

GDPR in other languages

For searchability options, those are a few of the local terms for GDPR used in other languages:

  • Dutch: AVG / Algemene Verordening Gegevensbescherming
  • French: RGPD / Règlement général sur la protection des données
  • German: DSGVO / Datenschutz-Grundverordnung
  • Spanish: RGPD / Reglamento general de protección de datos
Was this article helpful?
Additional questions? Submit a request