NIS2 Article 28 requires 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. They must verify it under published procedures, publish the non-personal data and reply to lawful access requests within 72 hours. Resellers are covered too.
This guide covers what Article 28 requires, who it applies to, the required data, what “accurate” means, publication and access, GDPR, duplication, the other NIS2 duties, what the text leaves open, and a checklist.
| Article 28 | Obligation | Typical evidence |
|---|---|---|
| (1) | Collect and maintain accurate and complete data in a dedicated database, with due diligence | Data model, database, data protection records |
| (2) | Minimum content: domain name, registration date, registrant and admin contacts | Field specification |
| (3) | Policies and procedures, including verification, published | Public verification policy, verification logs |
| (4) | Publish non-personal data without undue delay after registration | Public lookup output |
| (5) | Give access to specific data on lawful, duly substantiated requests; reply within 72 hours; publish the disclosure policy | Request log with timestamps, public disclosure policy |
| (6) | No duplicated collection; registries and registrars cooperate | Registry-registrar agreement, data flow map |
What does NIS2 Article 28 require?
Article 28 is titled “Database of domain name registration data”. Its purpose is stated in paragraph 1: “contributing to the security, stability and resilience of the DNS”. Recital 110 gives the operational reason: timely access to registration data is essential “for the prevention and combating of DNS abuse, and for the prevention and detection of and response to incidents”.
Like the rest of NIS2, Article 28 is addressed to Member States (“Member States shall require”). The obligations reach you through national transposing law, due to apply from 18 October 2024. Read the law of the Member State with jurisdiction over you: it may add procedural detail.
Who does Article 28 apply to?
Two kinds of entity, both defined in Article 6.
- TLD name registry (Article 6(21)): an entity delegated a specific TLD and responsible for administering it, including the registration of domain names and the technical operation of the TLD, whether it does this itself or outsources it. A TLD used by a registry only for its own use is excluded.
- Entity providing domain name registration services (Article 6(22)): “a registrar or an agent acting on behalf of registrars, such as a privacy or proxy registration service provider or reseller”.
Article 2(4) applies the directive to domain name registration services regardless of their size. A small hosting company that resells domains on behalf of a registrar falls within the definition. Size does not take it out.
Three other provisions name these entities. Article 3(3) required Member States to list them by 17 April 2025. Article 27 required them to submit their details for the ENISA registry by 17 January 2025. Article 26 puts them under the Member State of their main establishment; a provider outside the EU that serves the EU must designate a representative. See NIS2 jurisdiction and main establishment.
What registration data must be collected?
Article 28(2) requires the database to contain the information needed to identify and contact domain holders and the points of contact administering the domains. It “shall include”:
- the domain name;
- the date of registration;
- the registrant’s name, contact email address and telephone number;
- the contact email address and telephone number of the point of contact administering the domain name, if they differ from the registrant’s.
This is a minimum. Recital 109 says the obligation is without prejudice to collecting registration data for other purposes, for example under contracts or other Union or national law. You can collect a postal address, but the legal basis for it is not Article 28.
What does “accurate registration data” mean under NIS2?
The directive does not define “accurate” and does not prescribe a verification method. Article 28(1) requires accurate and complete data, maintained “with due diligence”. Article 28(3) requires policies and procedures, “including verification procedures”, to ensure accuracy and completeness, and requires them to be public.
Recital 111 says what those procedures should look like:
- policies and procedures to collect and maintain accurate and complete data, and to prevent and correct inaccurate data;
- proportionate verification procedures reflecting industry best practice and, to the extent possible, progress in electronic identification;
- examples: ex ante controls at registration and ex post controls after it;
- at a minimum, verification of “at least one means of contact of the registrant”.
Accuracy is not a yes or no property of a database. It is a rate, and it decays: people change jobs, mailboxes close, companies are dissolved. A check at registration proves the data was right once. The ex post controls, such as re-verification on change and on bounced email, keep it right. The verification checklist below sets out a proportionate procedure.
What must be published, and what stays private?
Article 28(4) requires registries and registrars to publish, without undue delay after registration, the registration data that are not personal data.
Recital 112 is more specific. Data outside the scope of Union data protection law, such as data about legal persons, should be published. For a legal person, that means at least the registrant’s name and contact telephone number. The contact email address should also be published, “provided that it does not contain any personal data, such as in the case of email aliases or functional accounts”.
In practice, record at registration whether the registrant is a legal or a natural person, because publication depends on it. A company registrant using a named employee’s address is a common case: the address still identifies a person, so a functional address such as a role mailbox is the safer thing to publish.
Who is a legitimate access seeker, and how fast must you reply?
Article 28(5) requires access to “specific domain name registration data upon lawful and duly substantiated requests by legitimate access seekers”, in accordance with Union data protection law. The reply must come “without undue delay and in any event within 72 hours of receipt”. The disclosure policies and procedures must be public.
Recital 110 describes legitimate access seekers as “any natural or legal person making a request pursuant to Union or national law”. They can include NIS2 competent authorities, authorities responsible for preventing, investigating, detecting or prosecuting criminal offences, and CERTs or CSIRTs. The request should come with a statement of reasons that allows the necessity of access to be assessed. Access covers the specific data needed for the request, not the full record.
Recital 112 adds three points: registries and registrars should set service level agreements for access requests, they may use an interface, portal or other technical tool, and Member States should ensure that all types of access to registration data are free of charge.
The clock runs from receipt of “any requests for access”. The text says 72 hours, not three working days, so a request that arrives on Friday evening needs an answer by Monday evening.
How does Article 28 relate to GDPR?
Article 28(1) and (5) both require compliance with Union data protection law. Recital 109 settles the legal basis: the processing Article 28 requires “should constitute a legal obligation within the meaning of Article 6(1), point (c)” of the GDPR. That is the legal basis for collecting and keeping the Article 28 data set. Data collected for other purposes needs its own basis.
Disclosure to an access seeker is still processing of personal data. The request has to be lawful and duly substantiated, and only the specific data necessary is released. The wider interplay between the two regimes, including incidents that are also personal data breaches, is in NIS2 and GDPR.
How do registries and registrars avoid duplication?
Article 28(6) says compliance “shall not result in a duplication of collecting domain name registration data” and requires registries and registrars to cooperate to that end. Recital 109 repeats the point: the aim is one complete and accurate data set, not the same data collected several times.
In practice, the registry agreement or policy should state for each step who does it: who collects, who verifies, who publishes, who answers access requests, and how corrections flow back. Where resellers sit between the registrar and the registrant, the registrar’s contract with them needs the same split. A verification done by a reseller that nobody else can see is hard to rely on in front of an authority.
Are registries and registrars essential or important entities?
Not in the same way. The directive treats the two differently.
- TLD name registries are essential entities regardless of size (Article 3(1)(b)). The management body duties in Article 20, the risk-management measures in Article 21 and incident reporting in Article 23 apply. Implementing Regulation (EU) 2024/2690 sets the technical requirements for them. The measures themselves are in NIS2 Article 21, the 10 measures.
- Registrars and resellers are not listed in Annex I or II, so they are not essential or important entities on that basis. Article 2(4) brings them into the directive for the duties that name them, principally Articles 3(3), 26, 27 and 28. Articles 21 and 23 apply to essential and important entities.
Two cautions. Many registrars also run authoritative DNS for customers’ domains, and a provider of “authoritative domain name resolution services for third-party use” is a DNS service provider under Article 6(20), essential regardless of size. National law can also go further. The DNS and wider digital infrastructure position is in NIS2 for digital infrastructure, and the general scope test in the NIS2 scope guide.
On penalties, the fine ceilings in Article 34 concern Articles 21 and 23. For other infringements, including Article 28, Article 36 leaves penalties to Member States, which must make them effective, proportionate and dissuasive.
What Article 28 leaves open, and what closing it looks like
Article 28 sets outcomes. It does not say what accuracy rate is enough, how much verification is proportionate, what makes a request “duly substantiated”, or how a registry, a registrar and a reseller prove their share. The authority will ask how you know your data is accurate and how you know you replied in time. Both are questions about records, not policies.
Closing that in practice means a verification record for every domain: method, timestamp, result, and the reason for any later re-check. It means an accuracy rate measured by sampling, not assumed. It means an access-request log with receipt time, reply time and decision, and an alert well before hour 72. For a registry, the registration database is also one of the assets it protects under Article 21.
That evidence should come from the registration and ticketing systems themselves, with a person reviewing the exceptions. That is how the CloudSoul platform works. If you want to know where you stand first, a security audit against Article 28 and your national law will show the gaps, and the wider programme is on the NIS2 compliance page.
ARTICLE 28 VERIFICATION CHECKLIST (per registration or change)
At registration (ex ante)
[ ] Domain name and registration date recorded automatically
[ ] Registrant name, email and telephone present and well-formed
[ ] Admin contact email and telephone recorded if different
[ ] Registrant type recorded: legal person or natural person
[ ] At least one means of contact verified (email link, SMS code)
[ ] Verification method, timestamp and result logged
After registration (ex post)
[ ] Re-verify when registrant or contact data changes
[ ] Re-verify on bounce, failed call or inaccuracy report
[ ] Sample records periodically; record the accuracy rate
[ ] Correction request sent, deadline set, outcome recorded
Publication and access
[ ] Non-personal data published without undue delay
[ ] Legal persons: name and telephone published; email only if
functional (no personal data)
[ ] Access request logged on receipt, with timestamp
[ ] Legal basis and statement of reasons checked
[ ] Only the specific data needed disclosed
[ ] Reply sent within 72 hours; decision and reasons loggedNIS2 Article 28 checklist
- Confirm which Member State has jurisdiction and read its transposing law.
- Map the data flow from registrant through reseller and registrar to the registry.
- Check the database holds every Article 28(2) field.
- Publish the verification policy and the disclosure policy.
- Verify at least one means of contact for every registration and log it.
- Measure accuracy by sampling and correct what fails.
- Run access requests through a logged queue with a 72-hour alert.
- Agree in writing who collects, verifies, publishes and discloses.
Sources
- Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 6, 20, 21, 23, 26, 27, 28, 34 and 36 and recitals 109 to 112, EUR-Lex.
- Regulation (EU) 2016/679 (GDPR), Article 6(1)(c), EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2690, EUR-Lex.
Frequently asked questions
What does NIS2 Article 28 require?
Article 28 requires Member States to make TLD name registries and entities providing domain name registration services collect and maintain accurate and complete domain name registration data in a dedicated database, verify it, publish the data that is not personal data, and reply to lawful access requests within 72 hours.
What registration data must be collected under NIS2?
At least the domain name, the date of registration, the registrant's name, contact email address and telephone number, and the contact email address and telephone number of the point of contact administering the domain name if they differ from the registrant's.
Does NIS2 Article 28 apply to domain resellers?
Yes. NIS2 defines an entity providing domain name registration services as a registrar or an agent acting on behalf of registrars, such as a privacy or proxy registration service provider or reseller. Article 2(4) applies the directive to these entities regardless of their size.
How quickly must a registrar answer a WHOIS access request under NIS2?
Without undue delay and in any event within 72 hours of receipt. Access is owed for lawful and duly substantiated requests from legitimate access seekers, in accordance with EU data protection law.
Is WHOIS data processing under NIS2 compatible with GDPR?
Recital 109 says the processing required by Article 28 should constitute a legal obligation within the meaning of Article 6(1)(c) GDPR. Data outside data protection law, such as data about legal persons, is published, while personal data is disclosed only on lawful and duly substantiated requests.
