> For the complete documentation index, see [llms.txt](https://www.mica.wtf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.mica.wtf/nis2/chapter-ix-final-provisions-art.-40-46/guidelines/nis-cg-2024-article-28-domain-registration.md). # NIS CG — Article 28 recommendations NIS Cooperation Group recommendations on implementing the NIS2 database of domain-name registration data requirements. | | | | --------------- | ------------------------------------------------------------------------------------------------ | | **Authority** | NIS Cooperation Group | | **Reference** | Final version, September 2024 | | **Legal basis** | [Article 28](/nis2/chapter-v-jurisdiction-and-registration-art.-26-28/28.md) NIS2 | | **Status** | Final non-binding recommendations | | **Date** | September 2024 | | **Source** | [NIS Cooperation Group](https://digital-strategy.ec.europa.eu/en/policies/nis-cooperation-group) | | **Document** | [Official PDF](https://ec.europa.eu/newsroom/dae/redirection/document/108437) | Recommendations for the implementation of NIS2 Directive Article 28 (Database of domain name registration data) Final Version, September 2024 ## NIS Cooperation Group recommendations relevant to Article 28 of the Directive (EU) 2022/2555 ## 1. Introduction This document includes the recommendations of the NIS Cooperation Group on article 28 of the Directive (EU) 2022/2555 as set out by the relevant Work Stream on WHOIS (WHOIS WS) and its established Task Forces with the support of ENISA. Article 28 calls Member States (MS) to enforce specific requirements on TLD name registries and entities providing domain name registration services to ensure the accuracy, completeness, and accessibility to legitimate access seekers of domain name registration data, in compliance with Union data protection laws. This includes implementing verification procedures, and promptly responding to lawful and duly justified data access requests by legitimate access seekers within 72 hours. Recommendations are not legally binding; they serve as an advisory guideline. However, the recommendations are to be considered as minimum requirements that the Member States are recommended to include in their transposition laws to fulfil the objectives of Article 28 of the NIS2 Directive. If Member States wish to enforce recommendations, they need to transpose them into their respective national legislation. The goal of this document is to provide non-binding guidance to national competent authorities, registries and registrars, with regard to formats and procedures regarding the implementation of Article 28 of the NIS2 Directive, to facilitate alignment in the implementation on the NIS 2 Directive across the EU. The main target audiences of this document are the national competent authorities and the entities in scope of Article 28 of the NIS 2 Directive. ## 2. Definitions For the purposes of this document, the terms defined in Directive (EU) 2022/2555 apply. In addition, the following definitions are used in the document: * Syntactic validation is meant as the practice to ensure that submitted attributes are properly formatted and consistent across fields. * Operational verification is meant as the practice for ensuring the contactability and functionality of the collected information, for example assurance that an email address represents an existing account and that it is functional (i.e., the email gets delivered) or assurance that the phone number is operational. * Identity verification includes collection and validation of information about a registrant, such as ID, to ensure that the registrant is who they say they are. * Point of contact administering the domain name, is meant to identify those cases when the domain name is not administered directly by the registrant (which is often the case with legal persons). The 'contact administering the domain name' whether administrative or technical contact -is meant as the one who can perform all the possible actions on a domain name (DNS records change, renew, transfer, etc.), in the same way as the registrant. In case there is a separate technical contact and another entity 'administering the domain name' , Article 28 NIS2 refers to the contact details of the latter. 'Contact administering the domain name' in Article 28(2)(d) does not refer to the registrars as such, although a registrar might also be entrusted with the administration of certain domain names. ## 3. Recommendations ## 3.1 Recommendations on verification processes **1.** It is recommended that, for every new domain name and renewal of existing domain name, the contact email address and the telephone number of the registrant are both syntactically validated and operationally verified. At the time of the registration and at the time of renewal the following verification should be done: > **(a)** Email address should be in the proper format according to RFC 5322 1 (or its successors) and operationally verified to assure that an email address represents an existing account b) Telephone number should be in the proper format according to ITU-T E 164 2 notation for international telephone numbers and operationally verified to assure the telephone number is functional 3 1 IETF RFC 5322 Internet Message Format, RFC 5322 - Internet Message Format (ietf.org) 2 The international public telecommunication numbering plan, E.164 : The international public telecommunication numbering plan (itu.int) 3 See f. ii ICANN WHOIS Accuracy Specification, If applicable, the same recommendation should apply to the email address and telephone number of the point of contact administering the domain name 4 if they differ from the one(s) of the registrant itself. The same syntactic validation and operational verification of telephone number and email address should be applied during the lifetime of a domain name when the registry or the entity providing domain name registration services are performing periodic checks or when the domain is flagged as suspicious on the basis of the risk-based assessment (see 2 nd recommendation). **2.** It is recommended as a minimum requirement that a risk-based approach is used in the procedure for verification of the name of the registrant at registration of the domain name and at renewal of a domain name. Methods for identity verification (either through third parties, own verification or mixed) should be in place for both natural and legal entities (i.e., such methods should be available to be used immediately if and where needed). Electronic identification should be the preferred means anytime it is available in the respective Member State and for the category of registrant. For all new registrations after the date of application of the national transposition measures for the NIS2 Directive and for the subsequent renewals of such registrations, in order to determine whether the name of the registrant needs to be verified, a risk-based method, based on best practices used within the industry, including taking account of the state of art of predictive algorithms techniques, should be adopted. All registrations (new and existing) that present a medium to high risk of malicious registration (taking into account factors such as, for instance, the type of abuse and the reporting source) should undergo identity verification. **3.** It is recommended to use procedures for periodic checks of the database for domain names of medium to high risk. At certain points in the lifecycle of the domain name, in addition to the registration and renewal of the domain name, verification of data should also be done: * When a domain name is being transferred to another registrar, checks of contact data are necessary, (i.e., checks of the email address and telephone number). * For every domain name which is the subject of a written motivated complaint or if a notification is received that the contact information is invalid, the email address and telephone number, as well as the name should be verified. 4 The wording 'points of contact administering the domain names' is already used in EU legislation \[.eu Regulation ((EU) 2019/5 17]. It is meant to identify those cases when the domain name is not administered directly by the registrant (which is often the case with legal persons). The 'contact administering the domain name' whether administrative or technical contact -is meant as the one who can perform do all the possible actions on a domain name (DNS records change, renew, transfer, etc.), in the same way as the registrant. In case there is a separate technical contact and another entity 'administering the domain name', Article 28 NIS2 refers to the contact details of the latter. * When changing important information, such as email address, telephone number or name. **4.** In case the foreseen verification fails for new registrations, the registrant should have the opportunity to correct the WHOIS data before the domain name becomes active. The registrant should be given notice to fulfil the verification within a given time. In case where an existing domain name fails a verification (name, telephone or email) as a result of a complaint, a renewal of the domain name or in connection with other checks, the domain name holder should have the possibility to correct the registration data before the domain name is suspended. The registrant should have no more than 1 month to correct the WHOIS data before the domain is suspended or cancelled, if not yet expired. In case of domain names used for malicious purposes, prompt actions should be taken to remove or de-activate the domain names. ## 3.2 Recommendations on legitimate access seekers **1.** As a minimum, Member States need to ensure that all national authorities that are competent cybersecurity authorities under NIS2 and those that are responsible for the prevention, investigation, detection or prosecution of criminal offences, CERTs or CSIRTs have a legal basis and are designated as legitimate access seekers in the national legislation implementing NIS2. **2.** Optionally Member States might also designate other public authorities and private entities, the latter for justified cases in the context of private enforcement, which combat other DNS related infringements as e.g. Intellectual Property (IP) rights infringements. **3.** For requests from legitimate access seekers the requested data (not just the information whether the data will be provided or not) should be provided within the 72-hour period set out in Article 28(5) of NIS2. **4.** For any requests for disclosure of non-public domain name registration data to an entity in the scope of Article 28 NIS2 (i.e., a TLD name registry or entity providing domain name registration services), such entity should respond within 72 hours whether or not the access to the requested data will be granted and the time frame for receiving the information. It is recommended that in case of negative replies -i.e., when access to the data is refused -the reply includes a statement of the reasons. In case of an access request to the wrong addressee (i.e., a registrar or registry that is not in possession of the data because it falls under a different zone file), the addressee should inform the requestor immediately and, in any case, no later than within 72 hours, however in case of an urgent request no later than within 24 hours. **5.** Optionally, Member States may establish that for urgent requests from legitimate access seekers the requested data should be provided within 24 hours 5 . Urgent requests should be defined as circumstances that pose an imminent threat to life, serious bodily injury, threat to government institutions, critical infrastructure, or child exploitation in cases where disclosure of the data is necessary in combatting or addressing this threat. In this context, critical infrastructure means the physical and cyber systems that are vital in that their incapacity or destruction would have a debilitating impact on economic security or public safety. 5 Within ICANN, governments in the Governmental Advisory Committee (GAC) are of the opinion that Urgent Requests for Lawful Disclosure of domain name registration data should be delivered within 24 hours. See GAC Washington Communique of 20 June 2023, page 9, --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.mica.wtf/nis2/chapter-ix-final-provisions-art.-40-46/guidelines/nis-cg-2024-article-28-domain-registration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.