WHOIS Data Under NIS2: Obligations for Registries and Registrars

Understand NIS2 Article 28 WHOIS data obligations. Learn what domain registries and registrars must implement to maintain DNS security.

Daniel Grigorovich
Daniel Grigorovich
Founder · 8 Jun 2026 · 9 min read
NIS2
WHOIS Data Under NIS2: Obligations for Registries and Registrars

Who should read this: Domain Registries, Domain Registrars, Registry Operators, ICANN-Related Organisations, Compliance Officers in Domain Industry.

The NIS2 Directive’s inclusion of specific requirements for WHOIS data maintenance and access marks a significant moment in the governance of the domain name system. Article 28 establishes comprehensive obligations for TLD name registries (the organisations that manage top-level domains like .de, .fr, .eu) and entities providing domain name registration services (registrars and their agents). These obligations are designed to ensure that accurate WHOIS data is maintained and that legitimate parties can access domain name registration information needed to investigate cybersecurity incidents and maintain DNS stability.

For registries and registrars, Article 28 represents a new regulatory mandate imposed by NIS2 in addition to whatever obligations may exist under ICANN contracts, GDPR, and other legal frameworks. Compliance is mandatory, and registries and registrars are classified as important entities under NIS2, meaning they must implement the full suite of Article 21 cybersecurity risk-management measures in addition to the specific WHOIS obligations.

The Security and Stability Purpose

DNS is critical infrastructure. Every internet user relies on the domain name system to translate human-readable domain names into the IP addresses required to access services. If the DNS system is compromised or unstable, the effects cascade across the entire internet ecosystem. WHOIS data, that is, the registration information associated with domain names, is essential to investigating DNS abuse, identifying malicious domains, and responding to cybersecurity incidents.

The Directive recognises that maintaining accurate, accessible WHOIS data contributes to DNS security and stability. Article 28(1) states that the purpose of the requirements is “contributing to the security, stability and resilience of the DNS.” This is not merely a privacy or administrative matter; it is a cybersecurity governance issue.

Data Collection and Maintenance Obligations

Article 28(1) requires that TLD name registries and entities providing domain name registration services collect and maintain accurate and complete domain name registration data in a dedicated database. This seems straightforward until you consider the complexities. Accuracy and completeness are not binary qualities; they exist on a spectrum. Registries and registrars must establish data governance processes to ensure that the information they collect is correct and that it is regularly updated as domain holders change details.

Article 28(2) specifies what information must be maintained. First, the domain name itself. Second, the date of registration. Third, the registrant’s name, contact email address, and telephone number. Fourth, the contact email address and telephone number of the point of contact administering the domain name, if different from the registrant.

This information set is intentionally designed to enable identification and contact of the domain holder and the person administering the domain. Cybersecurity incidents often involve malicious use of domain names, including domains used for phishing, malware distribution, or command-and-control communication. Being able to identify and contact the registrant is essential to investigating these incidents and taking remedial action.

Article 28(2) also requires that this information be maintained in a “dedicated database with due diligence in accordance with Union data protection law as regards data which are personal data.” This is important language because much of WHOIS data involves personal data (individual registrants’ names, addresses, telephone numbers, email addresses). The requirement to maintain this data in accordance with GDPR and other Union data protection law means that registries and registrars must balance the cybersecurity need for accessible WHOIS data with privacy obligations. This balance is addressed through the public access and restricted access provisions discussed below.

Accuracy Verification Procedures

Article 28(3) requires that registries and registrars establish policies and procedures, including verification procedures, to ensure that their databases include accurate and complete information. These procedures must be made publicly available. This is a substantive obligation requiring registries and registrars to document their data quality assurance processes.

Effective accuracy procedures typically include several elements. First, verification at the time of registration: registrars should verify that the information provided by domain applicants is accurate before accepting registration. This might involve email verification (confirming that the registrant controls the email address provided), telephone verification, or in some cases, identity verification.

Second, periodic re-verification: registries and registrars should periodically contact registrants to confirm that stored information remains accurate. This is particularly important because contact information can become outdated over time as people change jobs, move, or update their contact preferences.

Third, procedures for updating information: registrants must be able to update their registration information, and registries and registrars must ensure that updates are processed correctly. This includes procedures to verify updates (confirming that the person requesting an update is authorised to make it).

Fourth, procedures for detecting inaccurate data: registries and registrars should monitor for signs of inaccurate data. If a domain’s contact email bounces, or if a registrant’s telephone number appears to be fictitious, the registry or registrar should investigate and seek to obtain accurate information.

Fifth, data quality monitoring: registries and registrars should track metrics related to data quality. What percentage of domains have valid contact information? What is the average age of the most recent data verification? These metrics help identify systemic data quality problems.

Public and Restricted Access

Article 28(4) requires that registries and registrars make publicly available, without undue delay after domain registration, domain name registration data that are not personal data. This provision recognises that some WHOIS information can be disclosed broadly without privacy concerns. The date of registration, the fact that a domain is registered, and some registrant information can typically be disclosed publicly.

However, Article 28(5) addresses personal data and sensitive information. Registries and registrars must provide access to specific domain name registration data (including personal data) upon lawful and duly substantiated requests by legitimate access seekers, in accordance with Union data protection law. This is the critical provision that enables cybersecurity incident investigators and law enforcement to access WHOIS data without disclosing it to the entire public.

Article 28(5) requires that registries and registrars respond to access requests without undue delay and in any event within 72 hours of receipt. This is a very tight timeline. For legitimate access seekers (law enforcement, cybersecurity incident response teams, CSIRTs investigating abuse), this fast response is essential. If investigating a phishing attack or a malware distribution network takes days to get WHOIS data, the investigation is significantly hampered.

What makes someone a “legitimate access seeker”? NIS2 does not define this term; it leaves it to registries and registrars to establish policies and procedures specifying who qualifies as a legitimate access seeker and what documentation is required to demonstrate legitimate interest in accessing WHOIS data. Typically, legitimate access seekers include law enforcement agencies, CSIRTs, cybersecurity incident response teams, intellectual property enforcement organisations, and contracted security researchers.

Article 28(5) also requires that registries and registrars publish policies and procedures regarding disclosure of WHOIS data. These policies must be publicly available so that potential access seekers understand what information is available, what requests are necessary to obtain access, and what their obligations are regarding use of that information.

Balancing Privacy and Security

The inclusion of WHOIS obligations in NIS2 highlights a fundamental tension in modern internet governance: the need for accurate, accessible registration information to support cybersecurity and law enforcement, and the need to protect individuals’ privacy. GDPR restricts the collection and use of personal data. Privacy advocates argue that making WHOIS data publicly available exposes individuals to targeted attacks, identity theft, and harassment.

Article 28 attempts to balance these interests through a tiered access model. Personal data is not disclosed publicly, but it is accessible to legitimate access seekers upon request. This preserves privacy for most individuals whilst ensuring that those with genuine security or law enforcement needs can access the information required to investigate incidents.

Registries and registrars must implement technical and organisational measures to protect WHOIS data. The data must be secured against unauthorised access, and registries and registrars must ensure that access to personal data is logged and auditable. Access seekers who receive WHOIS data are typically subject to confidentiality obligations and must use the data solely for the stated lawful purpose.

Coordination Between Registries and Registrars

Article 28(6) requires that registries and registrars cooperate with each other to avoid duplication of data collection. This recognises that the domain registration ecosystem involves multiple parties. A registrant might register a domain through a registrar, which in turn maintains an account with a registry. Both the registry and the registrar maintain registration data. To avoid unnecessary duplication and to ensure consistency, registries and registrars must establish coordination mechanisms.

In practice, this means that registries and registrars should establish clear data-sharing agreements specifying which party is responsible for collecting and maintaining which information. Typically, registrars collect information from registrants and transmit it to registries. Registries then maintain the authoritative source of registration data. However, the specific arrangements can vary depending on the registry operator’s and registrar’s policies.

Important Entity Status and Broader NIS2 Obligations

Article 28 establishes specific WHOIS obligations, but registries and registrars are also important entities under NIS2. This means they are subject to the full suite of Article 21 cybersecurity risk-management measures. They must implement risk analysis, incident handling, business continuity, supply chain security, secure development practices, training, cryptography policies, access controls, and multi-factor authentication.

For registries and registrars, this has particular implications. A registry’s cybersecurity measures must protect not only the registry’s own systems but also the security and integrity of the DNS data it maintains. A compromise of a registry could affect millions of domains and their users. Similarly, a registrar’s compromised systems could be exploited to fraudulently transfer domains, modify registration data, or create new malicious domains.

Supply chain security is particularly important in the domain industry, where registries and registrars depend on numerous service providers, such as DNS service providers, data centre operators, and backup service providers. These relationships must be scrutinised and managed as part of the Article 21 supply chain security obligation.

Incident Reporting

Registries and registrars are subject to Article 23 incident reporting obligations. If they experience a significant incident affecting the integrity or availability of their services or the WHOIS data they maintain, they must report the incident to their national CSIRT without undue delay. A breach of a registrar’s systems exposing customer contact information, or a compromise of a registry affecting DNS resolution, would clearly be reportable.

Key Takeaways

  • Article 28 requires TLD name registries and domain name registration services to collect and maintain accurate, complete domain name registration data including registrant name, contact information, and administrative contact details.

  • Registries and registrars must establish published policies and procedures for data accuracy verification, including verification at registration, periodic re-verification, update procedures, and data quality monitoring.

  • Personal data must not be publicly disclosed but must be accessible to legitimate access seekers upon request. Registries and registrars must respond to lawful access requests within 72 hours and must publish policies specifying who qualifies as a legitimate access seeker.

  • WHOIS data must be maintained in accordance with GDPR and other EU data protection law. Registries and registrars must implement technical and organisational security measures to protect the data and must establish coordination mechanisms to avoid duplication.

  • Registries and registrars are important entities under NIS2 and must implement Article 21 cybersecurity risk-management measures, establish incident response capabilities, and report significant incidents to their national CSIRT.

Daniel Grigorovich

Daniel Grigorovich · Founder

I believe that no business should suffer from "compliance checklists" or navigating vague regulatory text. While I still stand by the principle that all software products should be reliable and secure, I want to give companies a way to overcome the challenges faced when implementing these requirements.