Home / Blogs

Demystifying Art. 28 NIS2

This article provides an overview of the obligations under Art. 28 NIS2, its applicability and discusses the issue of duplication.


On December 14, 2022, the European Parliament adopted the Directive on measures for a high common level of cybersecurity across the Union (Directive (EU) 2022/2555) hereinafter referred to as “NIS2”), which was published in the official journal on December 27, 2022. Being a directive, NIS2 requires transposition into national law.

According to Art. 41 of NIS2, the transposition into national law must take place by October 17, 2024 and the measures must be applied as of October 18, 2024.

One of the concerns expressed by many stakeholders was that EU Member State legislators would impose different or even conflicting requirements when transposing the directive into national law.

Fortunately, with the first (draft) laws becoming publicly available, there seems to be a trend that Art. 28 NIS2 is being more or less translated into national languages with little or no changes of the substance. While this is good news as far as the risk of fragmentation is concerned, there is little to no guidance as to how the language of Art. 28 NIS2 should be understood and implemented.

There are a lot of questions and issues that have been discussed over the last months, and it seems unlikely that there will be alignment on how to operationalize the requirements. An overview of the issues can be found in the report of a workshop held by the eco Association on day zero of the ICANN meeting in Hamburg. This article aims to answer the question of who needs to do what.


Some interventions made during discussion of NIS2 suggest that NIS2 must be observed by all companies involved in domain name registrations. This is not true, but sometimes, it will be difficult to determine if and to what extent NIS2 is applicable.

What companies in the domain industry fall under NIS2?

“TLD name registries” and DNS service providers are considered essential infrastructure (Art. 3 (1) (b) NIS2) and need to observe a range of duties. It is worth noting that TLD name registries are excluded in “situations where TLD names are used by a registry only for its own use” (Art. 6 (21) NIS2), so dotBrands could be off the hook.

And then there is Art. 28 of NIS2, which addresses TLD name registries and “entities offering domain name registration services”, i.e., a registrar or an agent acting on behalf of a registrar, such as a privacy or proxy registration service provider or reseller (Art. 6 (21) NIS2).

In summary, TLD name registries and entities offering domain name registration services must comply with Art. 28 NIS2, but TLD name registries and DNS service providers need to do more.

However, there may be more to consider, so companies should assess the applicability of NIS2 to them, which may also arise from other roles they might play, for example in the context of a supply chain, cloud or hosting services.

The issue of extraterritoriality

If a TLD name registry or an entity offering domain name registration services is not established in the EU but offers services within the EU, it may fall under the scope of NIS2, and it must designate a representative in the EU according to Art. 26 (3) in conjunction with Art. 26 (1) (b) NIS2 (see also Recital 116 of NIS2).

In doing so, NIS2, like other EU laws such as the General Data Protection Regulation (GDPR), applies the Market Location Principle and extends its applicability to entities outside the EU if they provide services to the EU. The European Court of Justice (CJEU) has upheld the extraterritorial reach of EU laws in cases such as Google Spain (C-131/12) and Weltimmo (C-230/14), establishing that entities offering goods or services to EU data subjects are subject to EU regulations. This principle is consistent with the prohibition of extraterritoriality in international law, which limits the ability of a state to enforce its laws beyond its borders without a sufficient connection to the territory.

In operational terms, the question is when there is a sufficiently strong link to the EU is given. Clearly, this will be the case for EU-based TLD name registries working with EU-based registrars. If a TLD name registry outside the EU that does not fall under NIS2 works with a registrar that is not covered by NIS2, Art. 28 NIS2 should not apply to the domain name registrations in that business. For everything in between, careful assessment is warranted.

Tasks of Art. 28 NIS2 and the issue of duplication

Art. 28 NIS2 sets out four tasks for TLD name registries and entities providing domain name registration services, namely:

“1. For the purpose of contributing to the security, stability and resilience of the DNS, Member States shall require TLD name registries and entities providing domain name registration services to collect and maintain accurate and complete domain name registration data in a dedicated database with due diligence in accordance with Union data protection law as regards data which are personal data.

2. For the purposes of paragraph 1, Member States shall require the database of domain name registration data to contain the necessary information to identify and contact the holders of the domain names and the points of contact administering the domain names under the TLDs. Such information shall include:

(a) the domain name;

(b) the date of registration;

(c) the registrant’s name, contact email address and telephone number;

(d) the contact email address and telephone number of the point of contact administering the domain name in the event that they are different from those of the registrant.

3. Member States shall require the TLD name registries and the entities providing domain name registration services to have policies and procedures, including verification procedures, in place to ensure that the databases referred to in paragraph 1 include accurate and complete information. Member States shall require such policies and procedures to be made publicly available.

4. Member States shall require the TLD name registries and the entities providing domain name registration services to make publicly available, without undue delay after the registration of a domain name, the domain name registration data, which are not personal data.

5. Member States shall require the TLD name registries and the entities providing domain name registration services to provide access to specific domain name registration data upon lawful and duly substantiated requests by legitimate access seekers, in accordance with Union data protection law. Member States shall require the TLD name registries and the entities providing domain name registration services to reply without undue delay and, in any event, within 72 hours of receipt of any requests for access. Member States shall require policies and procedures with regard to the disclosure of such data to be made publicly available.”

It is noteworthy that Art. 28 (1) to (5) NIS2 contains the following language for all of these four tasks: “Member States shall require the TLD name registries and the entities providing domain name registration services….”, which may suggest that all of these entities must perform all of these obligations.

And then there is Art. 28 (6) NIS2, which reads:

“6. Compliance with the obligations laid down in paragraphs 1 to 5 shall not result in a duplication of collecting domain name registration data. To that end, Member States shall require TLD name registries and entities providing domain name registration services to cooperate with each other.”

The language of Art. 28 (6) NIS2 is ambiguous as it only mentions the processing activity of collection that shall not be duplicated.

There seem to be two ways in which Art. 28 NIS2 is understood, namely:

  1. Collection means that only one entity shall be required to obtain data from the data subject, but all entities involved in the domain name registration need to perform all obligations arising from Art. 28 (1) to (5) NIS2 after an “internal” transfer of the data to all entities;
  2. Collection not only means obtaining the data from the data subject but also the “internal” transfer, which means that multiple entities holding copies or being controllers or processors of registration data shall be avoided.

The first alternative would only prevent a duplication of the interaction with the registrant, but still require maintaining multiple databases, dealing with the verification of registration data, making non-personal registration data publicly available, and providing access to non-personal registration data.

Was it really the legislator’s intention to require such an approach which would not only require the duplication, but the multiplication of all but one of the obligations laid down in Art. 28 (1) to (5) NIS2?

There is some evidence in and around NIS2 that supports the view that this was not the case and that alternative 2 above is the right answer:

  1. Art. 28 (6) NIS2 was added to the draft text of the directive more or less at the last minute. When Art. 28 was still Art. 23 of the draft NIS2, paragraph (6) did not exist. Assuming that all entities are actually required to carry out all obligations, Art. 28 (1) to (5) NIS2 makes sense as they are. However, the addition of paragraph (6) is a clear indication that a course correction was intended, not requiring all entities involved in a domain registration to perform all tasks. Unfortunately, no changes to Art. 28 (1) to (5) NIS2 were made to reflect the possibility of the entities involved in a domain name registration actually cooperating and agreeing on shared responsibilities. Thus, what we see in Art. 28 NIS2 looks very much like a drafting error.
  2. Recital 14 of NIS2 reads: “Union data protection law and Union privacy law applies to any processing of personal data under this Directive. In particular, this Directive is without prejudice to Regulation (EU) 2016/679 of the European Parliament and of the Council and Directive 2002/58/EC of the European Parliament and of the Council.” Recital 51 reads: “... the requirements of data protection by design and by default laid down in Regulation (EU) 2016/679 should be fully exploited.” These two recitals support the principle of data minimization, which aims to limit processing activities to what is necessary to achieve the purposes for which the data are processed. The purposes can be achieved by having one actor process the data in order to fulfill the obligations laid down set forth in Art. 28 NIS2.
  3. Recital 109 NIS2 reads: “Maintaining accurate and complete databases of domain name registration data (WHOIS data) and providing lawful access to such data is essential to ensure the security, stability and resilience of the DNS, which in turn contributes to a high common level of cybersecurity across the Union. For that specific purpose, TLD name registries and entities providing domain name registration services should be required to process certain data necessary to achieve that purpose. Such processing should constitute a legal obligation within the meaning of Article 6(1), point (c), of Regulation (EU) 2016/679. That obligation is without prejudice to the possibility to collect domain name registration data for other purposes, for example on the basis of contractual arrangements or legal requirements established in other Union or national law. That obligation aims to achieve a complete and accurate set of registration data and should not result in collecting the same data multiple times. The TLD name registries and the entities providing domain name registration services should cooperate with each other in order to avoid the duplication of that task.” This recital describes the objective of Art. 28 NIS2 in the first two sentences, namely the obligation of “maintaining accurate and complete databases of domain name registration data”. The recital continues to refer to “that obligation” (singular), even though the objective described includes several processing activities that go beyond the mere collection of data. The last sentence does not use the word collection, but speaks of avoiding the duplication of “a task”. This suggests that the task is not only limited to collection, but also includes other processing activities necessary to achieve the objective.
  4. Art 28 (1) NIS2 reads “Member States shall require TLD name registries and entities providing domain name registration services to collect and maintain accurate and complete domain name registration data”, which indicates that you have to collect to be able to maintain accurate and complete data. Since gTLD registries never collect data from the data subject, the consequence is that the term collection must describe the process of obtaining the data from the registrar, reseller or privacy and proxy service provider as well.
  5. Many of the registries offering gTLDs are not based in the EU. Requiring all registration data to be transferred to these TLD name registries would require international data transfers of personal data of millions of data subjects. Note that even the possibility of providing access rights to the data to the TLD name registries while e.g. the registrar physically stores the data would legally constitute an international data transfer. It is doubtful that the legislator intended such transfers to be mandatory, particularly since many registry operators are located in countries where there is no adequacy decision and adequate safeguards cannot be provided to make the transfers legal. This would, however, be required according to Art. 44 pp GDPR.


If the relevant parties cooperate, none of the tasks need be duplicated. However, if there is no cooperation, each party must fulfill the obligations.

As a consequence, it is possible for gTLD name registries to move to the minimum data set according to the new Registration Data Policy. Also, it is possible for TLD name registries (most likely many ccTLD name registries will use this option) to collect the registration data and share the responsibilities with registrars, resellers, and privacy and proxy service providers differently. It all depends on the operating model and the appropriate agreements. Fortunately, the national laws transposing NIS2 that have been published so far leave room for such diversity.

By Thomas Rickert, Managing Partner at rickert.law, Director Names & Numbers at eco

Thomas Rickert is a member of the GNSO (Generic Names Supporting Organization) Council of the Internet Corporation for Assigned Names and Numbers (ICANN). In 2022, he initiated the topDNS Initiative (topdns.eco) that unites members of the eco Association to fight DNS abuse. Furthermore, Thomas Rickert is managing director of the law firm Rickert Rechtsanwaltsgesellschaft mbH (rickert.law), which specializes in legal issues of the digital economy.

Visit Page

Filed Under


Alternative Perspective - Option 1 Michael D. Palage  –  Jun 10, 2024 10:37 PM

Kudos Thomas on a well-researched and written article. We agree there are two potential interpretations for the “collection” requirement outlined in Art. 28 (6). However, allow me to explain why I believe your first definition/option is the more likely interpretation based upon existing European ccTLD best practices, as well as some additional data points that were omitted from your initial analysis.


DENIC has taken a very thoughtful and measured response in collaboration with its registrar members toward its NIS 2.0 obligations. While DENIC is deferring to its Registrars to collect and verify the Registrant data, DENIC is still maintaining a copy of that data from its registrars for several reasons. First, DENIC has a direct contractual relationship with the domain name registrant, therefore it makes no sense for them not to have a copy of this data. Second, DENIC is running a series of algorithms to determine high-risk and very high-risk domain names. Having access to this underlying registration data is likely critical to making these determinations, although DENIC has not made public their specific algorithm data points.

Punktum (.DK)

Punktum is in the final consultative process with its registrar network regarding its NIS 2.0 obligations, and its approach also appears to be consistent with your first option/definition. Punktum has traditionally taken the point in verifying registrants, using MitID for Danish registrants, and an out-of-band process for non-Danish registrants.  Under the newly proposed procedures under consideration, Punktum would permit Registrars to do registrant verification but they would be required to provide the registration data to Punktum. Punktum would also reserve the right to audit the verification process undertaken by the Registrar.

I could continue with several additional European ccTLD best practices but that is the subject of another paper I am currently working on, so you will have to wait for that further analysis.

There are several additional data points that I think are missing from your initial analysis which should factor into any final determination by the Cooperation Group in interpretating Art. 28 (6):

- Your statement that “gTLD registries never collect data from the data subject” is just not correct. While the vast majority of gTLD Registries do not collect data from the data subject, there are some gTLDs that do, e.g. .BANK, .PHARMACY, as well as most/all Spec 13 Registries.
- The vast majority of ccTLD Managers have historically distinguished between natural and legal registrants. Unfortunately, most gTLD Registries do not. This feature alone could greatly minimize the potential duplication of PII.
- It is possible for a Registry Operator to process Registrant verification data without processing PII. I again would like to applaud the work that Verisign has done in various RSEP filings to comply with regulatory requirements imposed by the People’s Republic of China. See RSEPs 2023055, 2022044, and 2016030
- In addition to Verisign, multiple other ICANN registry operators have demonstrated how it is possible to comply with national registrant verification requirements.
- I believe the following excerpt for recital 111 will also play an important role in interpreting the text of Art. 28 (6), “TLD name registries and the entities providing domain name registration services should adopt and implement proportionate procedures to verify domain name registration data. Those procedures should reflect the best practices used within the industry and, to the extent possible, the progress made in the field of electronic identification.” I spent last week in Berlin attending the European Identity Cloud (EIC) conference where I saw several presentations on the European Digital Identity Wallet Architecture and Reference Framework. There are already several European ccTLDs that have integrated national digital IDs into their registration process and eIDAS 2.0 will likely expand this use. In fact, one of the eIDAS 2.0 Large Scale Pilots has already proposed using a wallet in connection with the registration and maintenance of domain names.

While I respect that we may not see eye to eye on this definitional issue, I would like to leave CircleID readers with the following reference point to determine which option/definition was most likely the intent of the legislators.

Occam’s razor states that all things being equal, simpler explanations are generally better than more complex ones.
- The purpose of NIS 2.0 was to “achieve a high common level of cybersecurity across the Union”
- It is widely acknowledged that European ccTLD have some of the lowest fraud/abuse rates of any TLD.
- Option/Definition 1 is consistent with the current and proposed business practices of DENIC and Punktum, but also many other European ccTLDs.
- Option/Definition 1 provides a framework for the European Union to advance other legislative initiatives such as eIDAS 2.0
- Option/Definition 2 has the potential to impede or break existing European ccTLD best practices that have resulted in the lowest fraud/abuse rates.
- Option/Definition 2 only appears to primarily benefit large non-European domain name registration authorities (registries and registrars) advancing their business interests.



Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign


Sponsored byVerisign