Categories
Articles

WHOIS access and the NIS2 Directive

The European Commission’s proposed update of the Network and Information Security Directive may revive discussions about access to WHOIS data. When a domain name is registered, contact details are typically requested for various purposes, including billing, administrative and technical questions. For most of the history of the DNS this ‘WHOIS’ data – including names, postal and email addresses – was published openly by domain name registries or registrars.

Although its quality is patchy, WHOIS became a frequent source for a much wider range of parties than had originally been envisaged, including law enforcement, incident responders, rightsholders and spammers. European privacy regulators expressed concern about this for most of the 21st century, but it was only when the GDPR introduced the possibility of massive fines that many European registrars and registries changed their behaviour, often by stopping publishing, or even collecting, WHOIS data at all.

Recital 60 of the Commission’s proposal now notes that (I’ve added one set of parentheses for easier reading):

The availability and timely accessibility of these data to public authorities, including competent authorities under Union or national law for the prevention, investigation or prosecution of criminal offences, CERTs, CSIRTs, and (as regards the data of their clients) to providers of electronic communications networks and services and providers of cybersecurity technologies and services acting on behalf of those clients, is essential to prevent and combat Domain Name System abuse, in particular to prevent, detect and respond to cybersecurity incidents.

Recital 62, and Article 23, therefore call on registries and registrars

  1. to publish WHOIS data that is not subject to GDPR, and
  2. to make data that is subject to GDPR available to “legitimate access seekers”.

That raises a number of questions:

  • Which WHOIS data are “not personal data” and required to be published by Art.23(4)? Although it is recommended practice to enter role-based contact details, which will survive the departure of an individual member of staff, that’s very hard for registrars to check or enforce.

And, for data that are personal:

  • Which groups are “legitimate access seekers” who must be given access according to Art.23(5)?
  • What is the “lawful, and duly justified” basis for that access? The NIS Directive repeatedly stresses that this must be in accordance with GDPR, and does not appear to be creating any new basis for the processing.
  • How (technically, since Rec.62 suggests “the use of an interface, portal or other technical tool”) can those “access seekers” be authenticated, authorised and provided with access?

Back in 2018, I sketched out how, if registries and registrars wished to give access to CSIRTs/CERTs, they could use GDPR Recital 49 and Legitimate Interest as a GDPR lawful basis, and how membership organisations such as FIRST and TF-CSIRT might be able to provide the necessary authentication, authorisation and policy infrastructures to ensure this delivers data protection benefits, rather than risks, to domain registrants. Now that such access is being recognised as “essential … to prevent, detect and respond to cybersecurity incidents” (Rec.60) that approach may be worth revisiting.

The draft Directive – partly because it is a Directive – leaves open the question of who might do that. Member States have considerable flexibility whether to add their own detail, or simply pass on the Commission’s wording to registrars and registries within their jurisdiction. But there’s an interesting hint of a more coordinated approach right at the end of Recital 62: “With a view to promoting harmonised practices across the internal market, the Commission may adopt guidelines on such procedures without prejudice to the competences of the European Data Protection Board”.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *