Article 27 Registry of entities: requirements and evidence

NIS2 Article 27 registry: who must register and by when

If your organization provides DNS, TLD, domain registration, cloud, data center, CDN, managed or managed security services, or an online marketplace, search engine or social network, you need to establish whether Article 27 applies to you. The registration duty required Member States to make these providers submit registration information by 17 January 2025. If you missed that date in your Member State, treat it as an open gap and check with your national competent authority or single point of contact what filing channel is now in use and whether a late submission is expected. Do not assume that a missed deadline has been waived.

The duty exists because authorities cannot supervise or warn providers they cannot find. Many of these providers serve customers across the Union from infrastructure hosted elsewhere, so a regulator in one Member State may have no direct way to know that a service matters to its market. The filing gives each authority a contact point and a view of which providers operate on its territory. For the provider, the practical work is assembling the required data: the entity name, sector and type, the address of the main and other EU establishments or of the EU representative, contact details, the Member States where services are provided, and the IP ranges. Confirm each item against your current records, because the IP ranges are often the hardest to pin down. They can be spread across cloud accounts, data centers, CDN edges and contractor-managed blocks, and some may be shared with other customers.

Keep the filing current. Changes must be notified without delay and in any event within three months of the change, so assign an owner for registry updates and tie that owner to the processes that change your footprint, such as new EU establishments, new service markets or new address ranges. The registry is a filing, not a certificate: no authority issues a document confirming that you are registered, and the filing does not show that your controls meet NIS2 Article 21. Your organization owns the data it submits and must be able to reproduce it on request. Independent advisers can help you collect and reconcile the information, but the submission and its accuracy remain your responsibility.

Which entities the NIS2 Article 27 registry covers

Article 27 applies a separate registration duty to a fixed list of digital and infrastructure providers, whatever their size. The cards below separate the entity types named in the Article, the EU footprint questions that decide who must register, and how this duty differs from the national list that other essential and important entities join.

DNS and TLD providers

The registry covers DNS service providers and top-level domain name registries. Both are named in Article 27(2) and must register whatever their size. Check whether the operator runs authoritative or recursive DNS for third parties, or only for its own organization, because that decides whether it is a DNS service provider in scope. Confirm this with the national competent authority, since the sector definitions are applied through national transposition laws.

Domain name registration providers

Domain name registration providers are the registrars and resellers that register domain names for customers. The Article 27(2) duty applies to them, so a registrar that operates in several Member States must submit its registration information even if it is small. Map which customers and TLDs it serves, and record the Member States where it offers services, because that list is part of the submission.

Cloud, data center and CDN providers

Cloud computing service providers, data center service providers and content delivery network providers form one group of infrastructure entities. Article 27 does not apply a size threshold to them. Their IP ranges are part of the submission, which makes accurate ownership records essential. Organizations that run their own data centers for internal use only should confirm with their authority whether they provide services to others, since that changes the answer.

Managed and managed security service providers

Managed service providers and managed security service providers must register when they fall in scope. A provider that runs monitoring, patching or security operations for clients in several Member States has to name each Member State where it provides services. Contracts with EU clients, EU subsidiaries and non-EU parent companies should be reviewed together to find the correct establishment and representative details.

Online marketplaces, search engines and social networks

Online marketplaces, search engines and social networks are named in Article 27(2) and form the online platform group. Their registration duty follows the same information list as the infrastructure providers. Operators should check whether they have an EU main establishment or an EU representative, because that address is the one the authority will use for contact. Non-EU platforms serving EU users need this check before the first submission.

EU establishment and representative

The address of the main establishment in the EU, or of the EU representative where the entity has no establishment, is a required field. An entity with no EU presence that offers services in the Union must still register, and it must name a representative. Confirm where decisions on cybersecurity risk measures are taken, because that location typically decides which Member State is treated as the main establishment.

Article 3(4) national list for other entities

Other essential and important entities do not use the Article 27 registry. They give their name, contact details including IP ranges, sector, subsector and Member States of service for the national list under Article 3(4), often through national self-registration mechanisms. Check the national portal of each Member State, because the process and deadlines are set nationally, and do not assume a submission in one country covers another.

How a supervisor checks NIS2 Article 27 registration

This table compares five checks a competent authority can run on an Article 27 registration, the evidence it is likely to ask for, and the gaps that tend to surface. Read each row as a question the supervisor can put to the entity, with the record that answers it. The main takeaway is that the filing is only as good as the data behind it, so the entity should be able to reproduce every submitted field from its own records.

Check	Evidence the entity should be able to produce	Common findings
Filing exists and was made by 17 January 2025	Dated submission record or confirmation for the registration information, and the name of the person who filed it	No record of submission, filing made under a generic mailbox, or no internal sign-off showing who was responsible
Submitted data matches actual EU establishments	Current list of EU establishments with addresses, the EU representative appointment where relevant, and the filed address for the main establishment	Filed address is an old office or a holding entity, or an EU representative is named but no longer in place
Member States where services are provided	Service map showing customers and service delivery by Member State, reconciled to the filed list	Services delivered in more Member States than filed, or filed countries that no longer receive services
IP ranges and contact details	Current inventory of public IP ranges, with the owner and the contact details filed for each	Ranges added after filing, ranges belonging to a cloud or hosting provider without clear attribution, or contact mailboxes that bounce
Change notifications made on time	Change log linking each change to its date, the notification date and the filed update, including changes to the Article 3(4) list information within two weeks	Changes made without notification, late updates beyond the three-month outer limit, or no process that triggers a review after mergers or new services
Entity appears in the registry the authority can access	Confirmation from the national single point of contact that the entity was forwarded to ENISA, and the registry entry the authority can view on request	Entity not forwarded because of an incomplete filing, or a national contact point that cannot confirm status

How to prepare an NIS2 Article 27 registration filing

This sequence turns the Article 27(2) registration data into a verified, signed filing and a maintained record that stays accurate after submission. Each step ends with a document or check that you can show a competent authority.

Confirm the entity type under Article 27
Start by checking whether your organization falls within one of the Article 27 categories: DNS service providers, TLD name registries, domain name registration services, cloud computing providers, data center service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, or social networking services platforms. Work this out with legal counsel and the entity's governance owner, since the category depends on the service you actually provide, not on how your marketing describes it. The output is a short written determination naming the category, the service line that triggers it, and the person who approved it. If you are unsure whether you are in scope at all, confirm this with the competent authority in your Member State before filing.
Assemble the Article 27(2) data inventory
Gather the information the Directive requires: your name, sector and type of entity, the address of your main EU establishment and any other EU establishments, or the address of your EU representative if you are not established in the EU, plus contact details. Owners are typically the legal team for names and addresses, and IT or platform engineering for technical contacts. Record each item in one controlled spreadsheet with a named owner and a source document for each field. The output is a draft data sheet that every field traces to a registry extract, corporate filing or internal record.
Build the IP range register with owners
Article 27(2) requires IP ranges in the filing, and these are not forwarded onward by the single point of contact in the same way as other data. Export the address blocks you announce, host or operate from your routing, cloud accounts, data center contracts and CDN configurations. For each range, record the owning system, the business owner, the technical owner and whether the range is announced by you or by a third party. Check the list against your asset inventory and BGP or cloud console exports. The output is an IP range register with a named owner for each line and a reviewer's sign-off dated to the export.
Record Member States of service and contact points
List every Member State where you offer the relevant services, not only the one where you are headquartered. Sales, hosting and support footprints are the usual sources, and product teams can confirm where customers are served. Assign at least one security contact and one operational contact with a monitored mailbox and a telephone route that works outside office hours, because these are the addresses authorities will use. The output is a country list tied to specific services, plus a contact matrix with role, named person, mailbox and escalation path.
Check the national submission route
Establish how your Member State receives the filing. Under Article 27(1) and (4), the single point of contact forwards the information to ENISA, but the entry point, format and portal are set nationally and may differ from one country to another. Confirm the route, the accepted format, the language, and whether you must register in each Member State where you provide services. Ask the authority for written confirmation of the process if the guidance is unclear. The output is a short note recording the authority, the submission channel, the required format and the date you confirmed these details.
Submit the filing and retain the record
Have an accountable officer review the completed data sheet, IP register and contact matrix, then approve and submit the filing through the confirmed route. Keep the submitted version, the submission receipt or confirmation message, and the list of who approved it. Store these in a controlled repository, since you will need to show what was reported and when. The output is a signed filing package and a submission record that together show what you declared, to whom, and under whose authority. Note that the filing is a declaration by your organization, so an implementation partner may prepare the package but does not sign it on your behalf.
Set change monitoring triggers
Article 27(3) requires you to notify changes without delay and in any event within three months of the change, and changes to the Article 3(4) list information within two weeks. Turn these rules into internal triggers: new IP ranges, new Member States of service, new establishments, changes in legal name or contacts, and mergers or divestments. Connect each trigger to the owner who must raise it, usually through change management tickets, procurement onboarding and cloud account creation. The output is a documented trigger list and a change log that records each change, its date, its owner and the date the filing was updated.
Reconcile the filing on a fixed cycle
Schedule a periodic reconciliation in which the owners re-export IP ranges, service footprints and contacts, then compare them with the submitted filing and the change log. Investigate every difference, decide whether it is a notifiable change, and file an update where it is. Set the cycle in your governance calendar and have the management body or the accountable officer review the results. The output is a signed reconciliation record that shows the filing matched your environment on the review date, with any corrections and their notification dates listed.

Evidence that shows the registration is complete and current

An Article 27 registration is only as good as the proof behind it. The six artifacts below let an entity show a competent authority what it filed, when it filed it, and that the filing still matches reality. Each one needs an owner and a trigger for updates, not just a one-time export.

Submission receipt from the national route

Keep the confirmation or receipt issued when the registration was submitted through the national channel, along with the date, the submitting account and the version of the form used. Store it with the filing itself so you can show the authority exactly what was sent and when. Confirm with your national competent authority whether it issues a reference number, and record that number in the registry file. Check the receipt again whenever the national portal changes its form or account rules.

Controlled data record matching the filing

Maintain one controlled record holding the name, sector and type of entity, EU establishment addresses, contact details, Member States where services are provided and IP ranges. Compare it line by line against what was filed, and document every difference. Assign a single owner to approve changes so the filing and internal records cannot drift apart unnoticed. Review the record whenever a new service, country or legal entity appears.

IP range inventory with owners and review dates

List every public IP range the entity reported, with the system it serves, the accountable owner and the date of the last review. Cloud and hosting changes often add or retire ranges without anyone updating the filing, so reconcile the inventory against cloud accounts, DNS records and firewall rules. Ask your authority which ranges it expects to receive, since IP ranges are handled differently from other registration fields. Record an update whenever a range is provisioned, moved or decommissioned.

Change notification log with timing

Log each change to the registered information with the date it occurred, the date it was known, the date it was notified and the channel used. Measure each entry against the three-month outer limit for changes and the two-week limit for changes to the Article 3(4) list information. Notify without delay wherever possible, since the three-month period is a maximum, not a target. A log that shows short, consistent intervals is far easier to defend than one that reaches the outer limit.

EU representative appointment where relevant

If the entity is established outside the EU but offers services in the Union, keep the written appointment of its EU representative, the representative's accepted mandate and the address and contact details filed for that representative. Confirm with counsel whether your entity falls into this category, since the answer depends on where services are offered. Review the appointment whenever the representative changes or the contact details lapse. Missing or stale representative details are a common reason a filing is judged incomplete.

Record of who maintains the data

Document the named individuals responsible for the registration, the backup contact for each, and the approval path for changes. Include the role that receives authority correspondence, since missed messages can delay responses to information requests. Update the record when staff leave or change roles, and test the contact path at least once a year. This record shows an auditor that the registration is an owned process rather than a one-time task.

What NIS2 Article 27 registration costs to meet

This table breaks registration effort into its cost components, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for scoping a quote: no fee or duration is stated because none has been published for this duty, so the right-hand column tells you what to ask for. The main takeaway is that most of the lasting cost sits in keeping IP ranges and entity details current, not in the first filing.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it and what to ask a quote to include
Staff time to compile and verify registration data	Internal legal, compliance and network staff, or an implementation partner preparing the data	One-time, then recurring on updates	Number of establishments and service Member States. Ask the quote to list each data field and who verifies it.
IP range inventory maintenance	Network or platform engineers, or a partner who builds the asset inventory	Recurring	Number of IP ranges and how often cloud or CDN addressing changes. Ask whether the quote covers exporting ranges from existing tools.
Legal or EU representative fees	An external EU representative or legal adviser, where the entity uses one	Recurring where a representative is appointed	Whether the entity has an EU establishment and how many Member States it serves. Ask for the appointment terms and renewal basis in writing.
Change monitoring and notification effort	Compliance owner, with engineers supplying change events	Recurring	Frequency of infrastructure and corporate changes. Changes must be notified without delay and within three months under Article 27(3), so ask how change events reach the owner.
Two-week notification of Article 3(4) list changes	Compliance owner and legal team	Recurring, event-driven	How often the entity's list status or the national list changes. Ask the quote to show the escalation path for these shorter deadlines.
Periodic reconciliation of submitted data	Compliance lead and engineers comparing filings with live systems	Recurring	Size of the environment and number of reconciliation cycles agreed. Ask for the cycle frequency and the evidence each cycle produces.

Who keeps the registry data and who checks it

The entity owns the registry data and the notification duty. Under Article 27, the information about the entity's name, sector, addresses, contact details, Member States of service and IP ranges must be accurate when submitted, and the entity must notify later changes without delay and in any event within three months. Management and the named compliance or security owner decide what is true about the entity, so no outside party can take that decision over.

Named owner: Assign one accountable person who signs off each submission and each change, and who is reachable by the national authority.
Change triggers: Define which events, such as a new Member State of service, a new data center or a new IP range, start the clock for notification.
Record keeping: Keep dated copies of every submission and change so the entity can show what it reported and when.
Changes to the Article 3(4) list: Confirm with the national authority the separate timing that applies to changes in list information, which the Article sets at two weeks.
Internal review: Have a second person check the data before filing, since errors in IP ranges and contact details are common causes of follow-up.

Check that the owner can name every source system that holds registry data and that the change log reflects actual operations, not a yearly memory exercise.

Where registrations usually fall short

Article 27 registrations are simple in form but easy to get wrong in practice. The gaps below share one root cause: the filing describes an infrastructure picture that stops matching reality as soon as systems, vendors or contacts change. Each card names a gap, why it matters, and what to check before the next update is due.

IP ranges held by a vendor

The registration must include the entity's IP ranges, and these are often held by a cloud, hosting or CDN provider rather than the entity itself. If the ranges sit in a vendor's account, the entity may not hold a current list at all. Ask each provider for the exact ranges assigned to your services, store them in your asset inventory, and confirm they match what you submitted. Note that ENISA receives the registry without IP ranges, so the national channel and your own records must hold them.

Infrastructure changes not reported

Changes must be notified without delay and in any event within three months of the change. Teams often update their own systems but forget the registration, especially after a new Member State, a new data center or a new CDN is added. Assign a named trigger for each change type, such as a new region in the cloud console or a new DNS zone, and log the date the change took effect. That log shows the authority when the notification was due and when it was filed.

Article 27 confused with national registration

Article 27 covers the listed digital providers, filed through the single point of contact. Other essential and important entities register for the national list under Article 3(4), often through a national self-registration mechanism, and the content differs. Entities that assume one filing covers both may miss a deadline or submit the wrong fields. Confirm with your national competent authority which route applies to your entity type, and keep a separate record of each submission and its reference.

Outdated EU representative details

Entities without an EU establishment must give the address of an EU representative, and that person's contact details must stay current. Representatives change roles, leave firms or change addresses, and a stale record means authorities cannot reach the entity. Set a review date for the representative's details, confirm the mandate in writing, and check that the contact points monitored are staffed during business hours in the relevant Member State. Include the review in the same calendar as the three-month change window.

No named owner for the data

Registration information touches IT, security, legal and procurement, so it often belongs to nobody. When an update is needed, the form is filled in by whoever notices first, and the record drifts. Name one accountable owner with authority to approve changes, a deputy for absences, and a documented approval step. The owner should also confirm the record at each review and sign off on the content, which gives the management body evidence that oversight exists.

Inventory that does not match production

The registration is only as accurate as the asset inventory behind it. Inventories built from procurement records or architecture diagrams often omit shadow services, decommissioned systems that still resolve, and services run by managed providers. Reconcile the inventory against DNS records, cloud account listings and network scans, and record which Member States each service reaches. A mismatch found during a supervisory information request is harder to explain than one found in your own review.

Questions buyers ask about the NIS2 Article 27 registry

Does my organization have to register under NIS2 Article 27, and by when?

Yes, if your organization is one of the entity types listed in Article 27(1), such as DNS, TLD, domain registration, cloud, data center, CDN, managed service, managed security service or online platform providers. Member States had to require these entities to submit registration information by 17 January 2025 (Article 27(2)). Whether your organization falls in one of these categories depends on its service type and its establishment in the EU, so confirm the classification with your national competent authority or a qualified legal adviser before filing. Do not rely on the sector list alone, because the registry duty and the Article 3(4) list are separate obligations.

How much staff time does the registry filing take, and is a partner worth it?

The filing itself is a short administrative task, but the preparation is not. The main effort is confirming the entity type, the EU establishments, the Member States where services are provided, the contact details and the IP ranges, and getting management to approve the submission. Costs come from internal time and, if you hire help, from a fixed-scope engagement priced on the written scope. A partner is worth considering when your IP ranges are spread across cloud accounts or when several group entities file. Ask any provider to state in writing which items they prepare and which the organization must confirm, and never accept a quote that promises the filing will be accepted.

How long does the registry work take, and what does the team need to provide?

The supplied facts do not give a duration for preparing or submitting a registry filing, so confirm timing with your national authority and any partner you consider. The team needs to provide the legal name, sector and type of entity, the address of the main establishment and any other EU establishments or the EU representative, named contacts, the Member States where services are offered, and a current inventory of public IP ranges. Assemble the inventory from cloud consoles, DNS records and network teams before you start, because gaps there cause the most delays.

Can we file the registration ourselves without an outside consultant?

Yes, an organization can prepare and submit its own registration if it has someone who knows its legal structure, its service footprint and its network ranges. Submission routes and forms are set by the national authority or the single point of contact, so check the current process in your Member State. Outside help is most useful for scoping the entity type and building the IP range inventory, not for the submission. Keep ownership of the content inside the organization, since the registered information must be accurate and management is accountable for the filing.

What happens if the registration is late or a change is not reported?

Article 27(3) requires entities to notify changes without delay and in any event within three months of the change. Changes to the information used for the Article 3(4) list must be notified within two weeks. A late or missed notification can lead to supervisory action, because national authorities oversee compliance through information requests, inspections and security audits, and can impose administrative fines under the national law that transposes NIS2. Ask your authority which penalties apply to registry failures in your Member State, and build a trigger into change management, such as new IP ranges, new services or new EU establishments, so updates are not missed.

Does the registration produce an audit report or certificate?

No. NIS2 creates no certificate of compliance, and a registry submission is not an audit, attestation or certification. Authorities and independent assessors may later check your registry data during supervision, but the filing itself does not confirm that your controls work. Any provider offering to issue a NIS2 certificate for registration should be questioned closely. DeployOpen prepares systems and evidence, and only an independent auditor or certification body issues reports or certificates.

How does the Article 27 registry relate to the Article 3(4) list?

They are separate lists with different inputs. Article 27 covers the specific entity types named in that article, which send their information to ENISA through the single points of contact, except IP ranges, and ENISA keeps a registry that competent authorities can access on request. The Article 3(4) list covers other essential and important entities, which give their name, contact details including IP ranges, sector and subsector, and Member States of service, often through national self-registration mechanisms. Check your Member State's process to see which list applies to you, and confirm whether any of your entities appear on both.

How DeployOpen prepares registration evidence

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For Article 27 registration, we help teams assemble the registration data, the ownership records and the change-tracking process that the organization then reviews, owns and submits itself.

How we scope

We confirm with you whether your entity type falls under the Article 27 registration duty before any work starts.
The written scope lists the registration fields, IP ranges, establishments and Member States to be documented.
We agree who submits to the competent authority and who approves each registration record, in writing.
Engagements are fixed-scope, with deliverables and timelines agreed before work begins.

How we build

We document the inventory of public IP ranges and services that the registration information must reflect.
We configure the internal records system that holds entity details, contacts and establishment data under your control.
We set up a change-tracking workflow so that updates are raised and reviewed well within the three-month outer limit.
We test the workflow with a dry run of a sample change, and record the results for your review.

How we hand over

You receive the registration data set, the change log and the named owner for each field as written deliverables.
We provide runbooks describing how to update records, who to notify and where each submission is stored.
We confirm with you which registration evidence is kept, and for how long, under your retention policy.
Only your organization submits information; DeployOpen does not register entities or act on your behalf with authorities.

How we support

Ongoing support, upgrades and reviews of the registration records are available as a retainer.
We can review the records again when your IP ranges, services or Member States of operation change.
Confirm with your national authority which self-registration mechanism applies and what it requires before you start.
Independent assessors or competent authorities decide compliance; we prepare the records and evidence they will review.