NIS2 Article 28: Why Selling Domain Names Puts You in Scope

A twelve-person IT consultancy outside Utrecht registers about 400 domains a year for clients. It never set out to be a registrar. Domains are a convenience bundled with hosting, resold through an upstream partner, invoiced at a few euros of margin. On headcount and turnover the firm sits nowhere near the NIS2 size thresholds, and its owner has told clients — correctly — that the directive's risk-management duties do not land on his own company.
He is still wrong about being out of scope. NIS2 Article 28 does not run through the essential and important entity classification at all. It names an activity, and that activity is selling domain name registrations.
This is the quietest scoping trap in the directive, and it catches a large share of the MSPs and IT consultancies that spend their time worrying about Article 21 on behalf of everyone else.
Article 28 attaches to the activity, not to the entity type
Most of NIS2 works through a two-step filter. Is the entity in a sector listed in Annex I or II, and does it meet the size criteria in Article 2? Clear that gate and you become an essential or important entity, with the Article 21 risk-management measures and the Article 23 reporting duties attached.
Article 2(2) carves out a short list that skips the size test: DNS service providers, TLD name registries, trust service providers and providers of public electronic communications networks and services. Registrars are not on that list. Neither are resellers.
Article 28 sits outside that machinery entirely. Its opening line requires Member States to impose duties on "TLD name registries and entities providing domain name registration services" — full stop. No headcount. No turnover. No essential or important label.
The practical consequence: a firm can be outside NIS2 for every other purpose and squarely inside Article 28.
"Entities providing domain name registration services" is broader than registrars
The directive defines the term in Article 6 as a registrar or an agent acting on behalf of a registrar — including a privacy or proxy registration service provider, or a reseller.
Read that again if you run a hosting or managed services business. A reseller is named explicitly. So is a proxy or privacy service. If your client's domain is registered in your company's name, or through your account with an upstream registrar, you are an agent acting on behalf of a registrar.
That covers a very ordinary arrangement: the web agency that holds 300 client domains in a single control panel, the MSP that includes DNS management in a managed-workplace bundle, the consultancy that registers defensive typo-domains for a brand.
Four data points, and one difficult word
Article 28(2) is unusually specific about what the database must hold:
- 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, where those differ from the registrant's
Nothing exotic. The difficulty is in Article 28(1), which requires that data to be "accurate and complete", collected and maintained "with due diligence" and in line with EU data protection law.
Accurate is not the same as supplied. A registrant who typed a real-looking email address into a form in 2019 and has since left the company has given you data that is complete and wrong. Under Article 28 that is your problem, not theirs.
The GDPR overlay matters here too. You are collecting personal data for a legal obligation, which changes your lawful basis, your retention logic and what you have to tell registrants. Copying your old privacy notice forward is not a defensible answer. If you want a structured view of where your own obligations start and stop, our guide on which regulator supervises your client is the companion piece to this one.
Verification procedures must exist, work, and be published
Article 28(3) is the sentence that changes operations. Registries and registration services must have "policies and procedures, including verification procedures" to ensure the database holds accurate and complete information — and those policies and procedures must be made publicly available.
The directive does not define verification. Recital 111 gives the shape of it: procedures should reflect industry best practice and, as far as possible, progress in electronic identification. It offers both ex ante controls at registration and ex post controls afterwards, and says registries and registration services should verify at least one means of contact of the registrant.
Two things follow that most compliance programmes miss.
First, a verification procedure you run but never wrote down does not satisfy Article 28(3), because there is nothing to publish. Second, publication means a regulator, a competitor or a rights holder can read your procedure and compare it against what you actually do. Very few resellers have a published page describing how they confirm registrant contact details.
The NIS Cooperation Group — the Commission body coordinating Member States on implementation — issued recommendations on Article 28 on 18 September 2024, setting out a risk-based approach: baseline syntactical and operational accuracy checks for all registrations, with deeper identity verification triggered for suspicious ones, and suspension or cancellation where verification fails.
Legitimate access seekers get an answer within 72 hours
Article 28(4) requires non-personal registration data to be published without undue delay after registration. Article 28(5) is the operational one: access to specific registration data, including personal data, must be granted on lawful and duly substantiated requests by legitimate access seekers — and the reply must come "without undue delay and in any event within 72 hours".
Recital 110 defines a legitimate access seeker broadly: any natural or legal person making a request under Union or national law. In practice that is law enforcement, CERTs, brand protection teams and anti-abuse researchers.
Seventy-two hours is a service level, not a target. It runs from receipt, including over a weekend. If domain requests arrive at an unmonitored info@ address, you do not have a process — you have an exposure. And like the verification procedures, the disclosure policy itself must be publicly available.
Several Member States have already gone past the Directive text
Article 28 has produced more transposition variation than almost any other provision, which matters because a reseller serving clients across borders can face several versions of it at once.
Belgium transposed early and went further: its law lets registries and registration services block a domain and prevent its transfer where registration data are incorrect or incomplete, and adds a 24-hour response window for emergency access requests on top of the standard 72 hours.
Croatia allows registration to be refused and the domain deleted where the registrant does not comply, and imposes long data retention. Czechia attached specific penalties to its Article 28 transposition, with fines running to CZK 50 million per offence. Poland's amended national cybersecurity system act, in force since 3 April 2026, brings DNS service providers, domain registrars and resellers into its expanded entity catalogue regardless of business scale.
The Netherlands wrote the domain registration database duty into article 49 of its Cyberbeveiligingswet, in force since 15 August 2026, with the Rijksinspectie Digitale Infrastructuur supervising. Germany's revised BSIG took effect in December 2025, and DENIC has required verified holder data for all .de domains since 14 April 2026 — unverified domains can be deactivated and deleted.
France and Spain have still not adopted their transposing laws.
NIS2 Implementation Status by Country (2025–2026)
Fully in force
BelgiumCroatiaHungaryLithuaniaLatviaItaly6 countriesAdopted — late 2025
GermanyCzech RepublicFinland3 countriesIn progress — expected 2026
NetherlandsFranceSpainPolandAustriaSwedenIreland7 countries
The penalties do not come from Article 34
This is the point most summaries get wrong. Article 34 requires administrative fines for infringements of Article 21 and Article 23 — the risk-management and incident-reporting duties. Article 28 is not in that list.
That does not mean Article 28 is unenforceable. It means the consequences are whatever national law attached to it, and those vary enormously: administrative fines in some states, criminal offences in Czechia, and in Belgium and Croatia something sharper than a fine — the power to block, refuse or delete the domain itself.
For a reseller, domain suspension is the real risk. A fine is survivable. Four hundred client domains going dark because the registration data behind them failed verification is a business-ending event, and the client will not accept "the registry did it" as an explanation.
NIS2 Penalty Escalation — Beyond the Fine
!Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose▼Non-Monetary Penalties1Compliance orders with binding deadlines
2Mandatory security audits at your expense
3Public disclosure of violations
4Binding instructions on specific security measures
Escalates to▼Operational & Personal Consequences1Suspension of certifications or operating licences
2Temporary ban on management functions for individuals
3Public naming of responsible natural persons
TriggerNon-monetaryOperational / personal
Being outside the EU does not put you outside Article 28
Article 26(3) lets Member States act against TLD registries and entities providing domain name registration services that offer services to registrants in their territory, whether or not the entity is established there or has a point of contact there. Non-EU providers in scope must designate a representative in the Union.
A US-based registrar with European resellers, or a European reseller working through a non-EU registrar, cannot resolve this by pointing at the other party's jurisdiction. Article 28(6) tells them to cooperate rather than duplicate collection — it does not tell either of them that the duty is someone else's.
What to check this quarter
If you or your client sell domain registrations in any form, four questions settle most of the exposure:
- Is there a dedicated database holding the four Article 28(2) fields for every domain under management, separate from the billing system?
- Is there a written, published verification procedure, and does the documented procedure match what the support team actually does at registration?
- Who answers a data access request, from which mailbox, against what published disclosure policy, and can they demonstrate a reply inside 72 hours?
- Which national law applies to each registrant's jurisdiction, and does the strictest of them — Belgium's blocking power, Poland's registration duty — reach your book?
Most firms that run this check find the same gap: the data exists, and nothing about how it is kept accurate has ever been written down. That is a documentation problem before it is a technology problem, and it is cheap to fix now and expensive to fix under a supervisory request.
If you want a structured starting point, our NIS2 readiness assessment maps your current position against the directive's obligations, including the ones that catch you through activity rather than size.
Article 28 is four hundred words of directive text that quietly regulates every reseller in Europe. Read it before a registry reads it to you.
Still have a question?
Answers are generated from our articles and are not legal advice. Do not enter personal or confidential data.
