Article 27: Registry of entities

Article 27 requires certain digital infrastructure and online platform providers to ensure their identifying and contact details are correctly captured by their national “single point of contact,” so ENISA can maintain an EU-level registry of those entities (Directive (EU) 2022/2555, Article 27). To operationalize it, you need a clear applicability decision, a maintained legal-entity inventory for in-scope services, and a controlled workflow for submitting and updating registry information via national channels.

Key takeaways:

• Treat Article 27 as a data-governance and regulatory-notification workflow, not a cybersecurity control.
• Your fastest path is an “Article 27 data packet” per legal entity mapped to the in-scope service category.
• The audit risk is stale or inconsistent entity/service details across jurisdictions, especially after M&A, rebrands, or hosting changes.

Article 27: registry of entities requirement sits in an awkward place for many CCOs and GRC leads. It is part of NIS 2, but it does not read like incident reporting or baseline cyber hygiene. It reads like “administrative plumbing,” and teams often ignore it until a regulator asks why the organization is missing from, or incorrectly listed in, a registry.

Operationally, the obligation is simple: if you provide certain services listed in Article 27 (for example, cloud computing services, managed services, or domain name-related services), your information will flow from national authorities to ENISA so ENISA can maintain a registry (Directive (EU) 2022/2555, Article 27). Your job is to (1) determine whether your organization fits one of the Article 27 categories in the jurisdictions where you operate, (2) prepare accurate entity and service metadata, and (3) implement a controlled process to submit, validate, and refresh it when reality changes.

This page gives requirement-level guidance you can execute quickly: scope test, owners, workflow, evidence, and the exam questions you should expect.

Regulatory text

Excerpt (provided): “ENISA shall create and maintain a registry of DNS service providers, TLD name registries, entities providing domain name registration services, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, as well as providers of online marketplaces, of online search engines and of social networking services platforms, on the basis of the information received from the single points of conta…” (Directive (EU) 2022/2555, Article 27)

Operator interpretation:
ENISA maintains the registry, but your organization still has a compliance task: make sure the national authority(ies) can collect accurate, complete, and current information about your in-scope entities and services, and that you can correct it quickly if it becomes wrong (Directive (EU) 2022/2555, Article 27). In practice, you operationalize Article 27 by building a repeatable “registry information management” process that is owned, version-controlled, and triggered by business change.

Plain-English interpretation (what the requirement means)

If you are one of the entity types listed in Article 27, the EU expects you to be identifiable and reachable through an EU-level registry maintained by ENISA based on information supplied by Member States (Directive (EU) 2022/2555, Article 27). That means:

• Your legal entity identity needs to be unambiguous (correct name, registration identifiers, headquarters, etc.).
• Your service category alignment needs to be consistent (for example, whether you are acting as a managed service provider versus a cloud computing service provider).
• Your regulatory contact points must be current so authorities can engage you during supervision, cross-border coordination, or major incidents.

Treat it like regulatory “know-your-entity” data hygiene.

Who it applies to (entity and operational context)

In-scope entity types (from Article 27)

Article 27 names the categories that will be included in ENISA’s registry, including:

• DNS service providers
• TLD name registries
• Domain name registration service providers
• Cloud computing service providers
• Data centre service providers
• Content delivery network providers
• Managed service providers
• Managed security service providers
• Providers of online marketplaces, online search engines, and social networking services platforms
  (Directive (EU) 2022/2555, Article 27)

Operational context (where compliance usually breaks)

Article 27 work typically falls between functions:

• Legal owns legal-entity structure, registrations, and corporate changes.
• Security/GRC owns NIS 2 applicability decisions and regulator engagement.
• Product/Engineering owns what service you actually provide and from where.
• Procurement/TPRM may need to map subcontracted components, because your service category claims must match delivery reality.

Any mismatch between “what Legal says we are,” “what Product sells,” and “what Ops delivers” creates registry errors.

What you actually need to do (step-by-step)

Step 1: Make an applicability decision you can defend

1. Map your offerings to Article 27 categories. Use a short, written decision memo per offering (one page is enough) that states which category applies and why, using the language of Article 27 categories (Directive (EU) 2022/2555, Article 27).
2. Bind each offering to legal entities and jurisdictions. Many groups sell centrally but contract locally; the registry record needs the right legal entity.
3. Assign an accountable owner. Pick a single control owner (often GRC or Compliance) and a data steward (often Legal Ops or Regulatory Affairs) for the registry data packet.

Deliverable: “Article 27 applicability & classification memo” per in-scope service line.

Step 2: Build the “Article 27 data packet” per legal entity

Create a structured template (spreadsheet, GRC tool object, or controlled document) that captures the fields you expect to provide via the national single point of contact. Article 27 does not list the precise fields in the excerpt provided, so keep the template flexible but include the data regulators always ask for in practice:

• Legal entity name(s) and any trading names
• Registered address and operational address(es) relevant to the service
• Primary regulatory contact mailbox and phone (avoid a single person where possible)
• Service category (from Article 27 list) and short description of the service
• Countries where the service is offered and where key operations are located
• Escalation contact for urgent security coordination (often your incident response on-call alias)

Tie each field to a system of record (Companies House equivalent, ERP vendor master, IAM directory group, etc.) and document it. This is how you keep the packet current.

Deliverable: “Article 27 registry data packet” with sources of truth listed for each field.

Step 3: Implement a submission and update workflow through national channels

Because ENISA maintains the registry “on the basis of the information received from the single points of contact” you need an operational process for dealing with the national authority interface (Directive (EU) 2022/2555, Article 27):

1. Identify each relevant national single point of contact. Keep this in your NIS 2 obligation register by jurisdiction (Directive (EU) 2022/2555).
2. Define triggers for updates. Minimum triggers: new legal entity, merger/acquisition, rebrand, change in headquarters, new service category, major hosting/processing location change, change to regulatory contact points.
3. Route changes through change management. Add “Regulatory registry impact?” as a checkbox in your corporate change intake (Legal entity management, product launch governance, and major supplier changes).
4. Submit and track. Log the submission date, what was submitted, and confirmation received. If the channel is email-based, store the full email thread in a controlled repository.
5. Periodic validation. Perform a scheduled attestation where Legal and the service owner confirm the packet is still accurate.

Deliverables: workflow diagram, RACI, and a tracker of submissions/confirmations.

Step 4: Make it exam-ready (documented, owned, repeatable)

Authorities rarely accept “we would do it if asked.” Prepare:

• A written procedure for maintaining registry information and responding to correction requests.
• Evidence that it operates (change tickets, attestations, confirmations).
• A clear mapping from each in-scope service to the legal entity and contact points.

This is also where Daydream fits naturally: teams use Daydream to keep a jurisdiction-tagged NIS 2 obligation register, assign owners, and track implementation milestones so Article 27 updates do not get lost in inboxes during corporate change.

Required evidence and artifacts to retain

Keep artifacts that prove accuracy, ownership, and lifecycle management:

• Article 27 applicability & classification memos ¹ (Directive (EU) 2022/2555, Article 27)
• Registry data packets ¹ with version history
• Source-of-truth mapping for each data field (data lineage note)
• Submission records to national single point(s) of contact and confirmations (Directive (EU) 2022/2555, Article 27)
• Change-management tickets showing the trigger, review, approval, and completion of updates
• Periodic attestation records signed by Legal and service owners
• RACI and procedure for registry maintenance (with named roles, not just teams)

Common exam/audit questions and hangups

Expect these questions from internal audit, external assessors, or regulators:

• “Which of your products/services fall into the Article 27 registry categories, and why?” (Directive (EU) 2022/2555, Article 27)
• “Which legal entity is the provider of record for each in-scope service?”
• “Who is accountable for keeping registry information current?”
• “Show me the last time you updated registry information after a corporate or operational change.”
• “What controls prevent a stale regulatory contact mailbox or a departed employee being listed?”
• “How do you ensure consistency of entity data across jurisdictions and subsidiaries?”

Hangup to plan for: business owners may disagree on whether they are “managed service provider” versus “cloud computing service provider.” Resolve it with a written classification decision and stick to it unless facts change.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in practice	How to avoid it
Treating Article 27 as “ENISA’s job, not ours”	ENISA depends on national inputs; your data quality drives the outcome (Directive (EU) 2022/2555, Article 27)	Assign an owner and run it like a regulatory reporting obligation
Using a single named person as the contact	People leave; inboxes go dark	Use role-based mailboxes and an escalation rota owned by Compliance/SecOps
No tie-in to corporate change	Registry data becomes stale after M&A, rebrands, new regions	Add registry-impact checks to legal-entity and product launch governance
Uncontrolled spreadsheets	Multiple versions, no audit trail	Put the data packet in a controlled repository or GRC system with versioning
Category drift	Marketing language diverges from regulatory categories	Maintain a classification memo and review during product changes

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 27, so this page does not list cases.

Risk still exists. If your registry information is wrong or missing, authorities may struggle to reach the right contacts during incidents or supervisory actions, and you may look disorganized during NIS 2 oversight. The practical impact is escalation friction at the worst time.

Practical execution plan (30/60/90-day)

First 30 days (foundation)

• Appoint an accountable owner and data steward; publish a RACI.
• Produce applicability & classification memos for any service that plausibly matches the Article 27 categories (Directive (EU) 2022/2555, Article 27).
• Draft the registry data packet template and identify sources of truth for each field.
• Identify the national single point(s) of contact relevant to your footprint and record them in your NIS 2 obligation register (Directive (EU) 2022/2555).

Next 60 days (operationalize)

• Complete a data packet for each in-scope legal entity; run Legal and service-owner review.
• Implement the update workflow: triggers, ticketing, approvals, and repository location.
• Run a tabletop “change event” (for example, rebrand or data center move) to prove the workflow works and generates evidence.

By 90 days (prove and harden)

• Submit/confirm registry information through the appropriate national channel(s) where required; retain confirmations (Directive (EU) 2022/2555, Article 27).
• Add registry-impact checks to corporate change intake (M&A, new entity creation, product launch governance).
• Schedule a recurring attestation and define KPIs that are evidence-based (for example, “all in-scope entities have a current data packet and a named owner”), without relying on unsupported numeric benchmarks.

Frequently Asked Questions

Does Article 27 apply to every NIS 2 “essential” or “important” entity?

Article 27 targets a specific list of provider categories (for example, cloud computing, data centre, managed service providers, certain online platforms) rather than every possible NIS 2 entity type (Directive (EU) 2022/2555, Article 27). You still need a documented applicability decision per service and jurisdiction.

What if we provide services through multiple subsidiaries in different EU countries?

Build a separate registry data packet per legal entity, then map each service offering to the contracting entity and operating footprint. Put a single function (often central GRC/Legal Ops) in charge of coordinating updates across subsidiaries.

What evidence should we keep if the national single point of contact process is informal (for example, email)?

Keep the full submission email thread, attachments, and any acknowledgment in a controlled repository, plus the internal ticket showing review/approval. Auditors usually accept this if it is searchable and tied to the correct legal entity.

We are a managed service provider and also resell cloud services. How should we classify ourselves?

Use written classification memos that match your actual delivery model to the Article 27 categories, and keep the rationale consistent across jurisdictions (Directive (EU) 2022/2555, Article 27). If multiple categories apply, document both and ensure contacts and entity mappings remain consistent.

Who should own Article 27 in a three-lines model?

First line (service owner/operations) should own data accuracy for the service description and operational locations; second line (GRC/Compliance) should own the requirement interpretation, workflow, and evidence quality. Legal should own legal-entity identity and corporate-change triggers.

How does Daydream help with Article 27 specifically?

Daydream is useful as the system where you maintain a jurisdiction-aware NIS 2 obligation register, assign owners, and track milestones so registry data stays current through business change. It also helps keep your evidence package exam-ready across entities and regions.

Footnotes

1. Directive (EU) 2022/2555, Article 27