Our last GDPR Update 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.

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.

ICANN – GDPR compliance models

Finally, I want to dial back our focus to draw attention to 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.

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 OpenSRS’ approach to the policy

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