sota.io
2026-04-17·15 min read·

NIS2 Art.27: Entity Status Change Notifications — When and How to Update Your NCA Registration (2026)

Post #419 in the sota.io EU Cyber Compliance Series

Art.24 got your entity on the NCA's registry. Art.27 keeps it accurate.

Most NIS2 compliance programmes spend weeks on Art.21 security measures and Art.23 incident reporting — and rightly so. But one obligation gets systematically underestimated: the duty to tell your national competent authority when your NIS2 status or registration data changes. Art.27 creates that obligation, and getting it wrong can mean operating under the wrong compliance tier, notifying the wrong NCA after a cross-border restructuring, or — most expensively — missing the point at which you became an essential entity and owed the higher Art.32 supervision regime.

Art.27 is not about a one-time filing. It is a living obligation that follows your entity through M&A, growth milestones, service pivots, and geographic expansion. Understanding exactly which events trigger an Art.27 notification — and within what timeframe — is the practical gap between a compliant and a non-compliant NIS2 programme.

This guide covers:

NIS2 Chapter IV Context: Where Art.27 Fits

Art.27 is the final article in NIS2 Chapter IV. The chapter builds a complete lifecycle: governance obligations (Art.20) → security measures (Art.21) → supply chain (Art.22) → incident reporting (Art.23) → initial registration (Art.24) → domain name data (Art.25) → vulnerability disclosure (Art.26) → ongoing status maintenance (Art.27).

ArticleTopicWho it Applies To
Art.20Management body cybersecurity obligationsEssential + Important entities
Art.21Cybersecurity risk-management measures (10 sub-categories)Essential + Important entities
Art.22Union-level supply chain risk assessmentsENISA + Member States
Art.23Incident reporting (24h early warning / 72h notification / 1 month final)Essential + Important entities
Art.24Initial NCA registration obligationsEssential + Important entities
Art.25Domain name registration data (WHOIS)TLD registries + Registrars + DNS providers
Art.26Coordinated vulnerability disclosure (CVD)Essential + Important entities
Art.27Entity status change notificationsEssential + Important entities

Think of Art.24 as the application and Art.27 as the maintenance contract on that registration. An entity that registers once under Art.24 and never updates is non-compliant if anything material changes.

Art.27 Text: What the Directive Actually Requires

Art.27 establishes the obligation for entities to proactively keep their NCA registration current. The core structure across Art.27's paragraphs:

Art.27(1) — The general update obligation: Essential and important entities shall notify the competent authority without undue delay — and in any event within three months — of any changes to the information they previously submitted pursuant to the initial registration requirement. The notification obligation covers changes to: contact information, the entity's legal form, the services it provides, and the Member State under whose jurisdiction it falls.

Art.27(2) — Threshold changes: Where an entity ceases to meet the size thresholds or sector criteria that qualified it as essential or important under Art.2 and Annexes I–II, it shall notify the competent authority within three months. The competent authority may then remove or reclassify the entity in the national registry. The entity retains its NIS2 obligations until the competent authority confirms reclassification or removal.

Art.27(3) — New essential status: Where an entity that was previously classified as important becomes aware that it now meets the criteria for classification as an essential entity (e.g., due to exceeding the large enterprise thresholds of Art.2), it shall notify the competent authority without undue delay. Reclassification to essential status triggers the enhanced Art.32 proactive supervision regime.

Art.27(4) — Cross-border establishment changes: Where an entity changes its main establishment — or establishes new significant operations — in a different Member State, it shall notify both the previous and new competent authorities. The new Member State's NCA assumes jurisdiction. The notification shall include the effective date of the establishment change and the new primary EU contact.

Art.27(5) — Registry information exchange: Member States shall ensure that their competent authorities share the information in the national registry with other Member States' authorities and with ENISA where relevant for cross-border supervision or information exchange. Entities are not directly obligated by Art.27(5), but must ensure that the information they submit is sufficient for such exchange (accurate legal entity identifiers, LEI codes where applicable).

The Six Change Triggers: What Actually Requires Notification

Art.27's three-month window sounds generous. In practice, organisations that lack a defined process regularly miss it. Here are the six categories of change that a compliant NIS2 programme must monitor:

1. Size Threshold Changes

NIS2 Art.2 and Annexes I–II define essential entities (large enterprises: ≥250 employees OR ≥€50M turnover OR ≥€43M balance sheet in a covered sector) and important entities (medium enterprises: ≥50 employees OR ≥€10M turnover).

Trigger scenarios:

Key point: NIS2 does not create an annual self-assessment cycle like DORA's Art.30 register. You are responsible for monitoring your own thresholds in real time.

2. Sector Reclassification

NIS2 Annex I (highly critical sectors) and Annex II (critical sectors) define the scope. A change in primary business activity can move an entity between annexes or out of scope entirely.

Trigger scenarios:

The sector change notification must specify: (a) the previous sector classification, (b) the new sector classification, (c) the effective date of the change, and (d) supporting evidence (e.g., updated company registration, product descriptions).

3. M&A and Corporate Restructuring

Mergers, acquisitions, spin-offs, and asset transfers can change which legal entity holds the NIS2 obligation and which NCA has jurisdiction.

Trigger scenarios:

Timeline note: M&A transactions often close before the three-month Art.27 window. Build notification into the M&A closing checklist, not the integration backlog.

4. Change of Primary EU Establishment

This is the highest-stakes Art.27 scenario. Jurisdiction under NIS2 follows the entity's main establishment in the EU — typically the place of central administration, or where the entity's security decisions are made (Art.26 NIS2, jurisdictional rules).

Trigger scenarios:

Multi-NCA notification requirements:

  1. Notify the outgoing NCA that the main establishment has changed (include: effective date, new establishment details, any ongoing incidents or open notifications)
  2. Notify the incoming NCA with a full Art.24-equivalent registration (as if registering for the first time)
  3. Coordinate any open Art.23 incident reports that straddle the transition

5. Contact Information and Organisational Changes

Less dramatic than M&A, but the most common Art.27 notification type in practice:

These are Art.27(1) notifications. They must be submitted within three months, but best practice is within 30 days to ensure that Art.23 incident reports reach the right person.

6. Entity Dissolution or Exit from NIS2 Scope

If an entity ceases operations, is dissolved, or permanently exits all covered sectors, it must notify the NCA. The NCA removes the entity from the national registry.

Trigger scenarios:

Note: Simply stopping operations temporarily (e.g., a planned service shutdown) does not trigger Art.27 unless the entity genuinely ceases to be in scope. Short-term operational pauses remain subject to NIS2 obligations.

Notification Content Requirements

Art.27 does not prescribe a universal notification form — Member States implement their own submission portals (BSI's MELDEPFLICHT system, ANSSI's services-numeriques.anssi.fr, BSI's UPTIME portal, etc.). But the core content requirements are consistent:

Required in every Art.27 notification:

  1. Legal entity identifier — company registration number + LEI code (if applicable)
  2. Entity classification — current tier (essential/important) and sector/subsector
  3. Nature of the change — which of the six trigger categories applies
  4. Effective date — when the change occurred or will occur
  5. Description — brief explanation of the change and its impact on NIS2 classification
  6. Updated contact information — current SPOC, security email, 24/7 emergency contact
  7. Declaration — confirmation that the information is accurate as of the submission date

Additional content for threshold changes:

Additional content for establishment changes:

Notification Timelines: The Three-Month Rule and Its Exceptions

Art.27's three-month window is the standard. But there are practical distinctions:

ScenarioRecommended TimelineRationale
Contact information change30 daysArt.23 incident reports must reach the right person
SPOC/CISO change30 daysNCA needs to know who to call during incidents
Size threshold breach (upward)Within 3 months of year-end confirmationThreshold determined annually
Sector reclassification30 days from effective dateDetermines applicable compliance regime
M&A closingOn closing date (or within 7 days)Multiple NCAs may need simultaneous notification
Establishment changeBefore effective date (if possible)Outgoing NCA must be informed; incoming NCA must receive full registration
Entity dissolutionWithin 30 days of dissolution decisionNCA removes entity from registry
Downward threshold changeWithin 3 months of year-endEntity remains on register until NCA confirms removal

One important nuance: the three-month window starts from the trigger event, not from when you noticed the trigger. If an M&A deal closed on 1 February and you notice the Art.27 obligation on 1 April, you are already past the deadline.

Art.27 × Art.24 Interaction: Initial Registration vs. Ongoing Updates

Art.24 and Art.27 work together as a two-stage lifecycle:

Art.24 (Initial Registration)
  → First classification as essential or important
  → Submit: entity details, sector, SPOC, services, establishment

Art.27 (Ongoing Maintenance)
  → Any change to any Art.24-submitted data
  → Trigger: threshold, sector, M&A, establishment, contact, dissolution
  → Timeline: 3 months (1 month recommended for contact changes)

One source of confusion: Art.24 requires entities to self-identify — they are not always formally notified by the NCA that they are in scope. This means the same self-identification logic that triggered Art.24 registration must run continuously for Art.27 compliance.

Practical implication for SaaS companies: Your legal/compliance team needs an annual NIS2 status review (ideally tied to financial year-end) that checks:

  1. Do our latest headcount and turnover numbers keep us in scope?
  2. Have our primary services or customer sectors changed?
  3. Has our main EU establishment changed?
  4. Have our security contacts changed since last year?

Python NIS2EntityStatusTracker Implementation

from dataclasses import dataclass, field
from datetime import date, timedelta
from enum import Enum
from typing import Optional
import json


class EntityTier(Enum):
    ESSENTIAL = "essential"
    IMPORTANT = "important"
    OUT_OF_SCOPE = "out_of_scope"


class ChangeCategory(Enum):
    SIZE_THRESHOLD = "size_threshold"
    SECTOR_RECLASSIFICATION = "sector_reclassification"
    MA_RESTRUCTURING = "ma_restructuring"
    ESTABLISHMENT_CHANGE = "establishment_change"
    CONTACT_UPDATE = "contact_update"
    DISSOLUTION = "dissolution"


@dataclass
class EntityProfile:
    legal_name: str
    registration_number: str
    lei_code: Optional[str]
    sector: str          # "annex_i" | "annex_ii"
    subsector: str       # e.g., "dns_services", "cloud_computing", "digital_infrastructure"
    tier: EntityTier
    employees_fte: int
    annual_turnover_eur: float
    balance_sheet_eur: float
    main_establishment_member_state: str  # ISO 3166-1 alpha-2, e.g., "DE"
    spoc_email: str
    spoc_phone: str
    emergency_contact_24h: str
    registration_date: date
    last_updated: date


@dataclass
class StatusChange:
    change_id: str
    entity_id: str
    change_category: ChangeCategory
    trigger_date: date
    notification_due_date: date
    description: str
    previous_state: dict
    new_state: dict
    submitted: bool = False
    submission_date: Optional[date] = None
    nca_reference: Optional[str] = None


class NIS2EntityStatusTracker:
    """
    Tracks NIS2 Art.27 status changes and generates NCA notifications.
    Call check_threshold() annually at financial year-end.
    Call record_change() immediately for M&A, establishment moves, contact updates.
    """

    def __init__(self, profile: EntityProfile):
        self.profile = profile
        self.pending_changes: list[StatusChange] = []
        self.submitted_changes: list[StatusChange] = []
        self._change_counter = 0

    def _next_id(self) -> str:
        self._change_counter += 1
        return f"ART27-{self.profile.registration_number}-{self._change_counter:04d}"

    def _notification_deadline(self, trigger: date, category: ChangeCategory) -> date:
        """Art.27 standard window is 3 months; contact changes recommended within 30 days."""
        if category in (ChangeCategory.CONTACT_UPDATE,):
            return trigger + timedelta(days=30)
        elif category == ChangeCategory.DISSOLUTION:
            return trigger + timedelta(days=30)
        elif category == ChangeCategory.ESTABLISHMENT_CHANGE:
            return trigger + timedelta(days=14)  # Before effective date if possible
        elif category == ChangeCategory.MA_RESTRUCTURING:
            return trigger + timedelta(days=7)   # Closing date or within 7 days
        else:
            return trigger + timedelta(days=90)  # Standard 3-month window

    def check_threshold(
        self,
        new_employees: int,
        new_turnover: float,
        new_balance_sheet: float,
        check_date: date,
    ) -> Optional[StatusChange]:
        """
        Run annually at financial year-end. Returns StatusChange if tier changed.
        Essential: ≥250 FTE OR ≥€50M turnover OR ≥€43M balance sheet.
        Important: ≥50 FTE OR ≥€10M turnover.
        """
        def classify(emp: int, turnover: float, bs: float) -> EntityTier:
            if emp >= 250 or turnover >= 50_000_000 or bs >= 43_000_000:
                return EntityTier.ESSENTIAL
            elif emp >= 50 or turnover >= 10_000_000:
                return EntityTier.IMPORTANT
            return EntityTier.OUT_OF_SCOPE

        new_tier = classify(new_employees, new_turnover, new_balance_sheet)

        if new_tier == self.profile.tier:
            # Update profile without triggering notification
            self.profile.employees_fte = new_employees
            self.profile.annual_turnover_eur = new_turnover
            self.profile.balance_sheet_eur = new_balance_sheet
            self.profile.last_updated = check_date
            return None

        change = StatusChange(
            change_id=self._next_id(),
            entity_id=self.profile.registration_number,
            change_category=ChangeCategory.SIZE_THRESHOLD,
            trigger_date=check_date,
            notification_due_date=self._notification_deadline(
                check_date, ChangeCategory.SIZE_THRESHOLD
            ),
            description=(
                f"Entity tier changed from {self.profile.tier.value} to {new_tier.value}. "
                f"FTE: {self.profile.employees_fte} → {new_employees}, "
                f"Turnover: €{self.profile.annual_turnover_eur:,.0f} → €{new_turnover:,.0f}"
            ),
            previous_state={
                "tier": self.profile.tier.value,
                "employees_fte": self.profile.employees_fte,
                "annual_turnover_eur": self.profile.annual_turnover_eur,
                "balance_sheet_eur": self.profile.balance_sheet_eur,
            },
            new_state={
                "tier": new_tier.value,
                "employees_fte": new_employees,
                "annual_turnover_eur": new_turnover,
                "balance_sheet_eur": new_balance_sheet,
            },
        )

        # Update profile
        self.profile.tier = new_tier
        self.profile.employees_fte = new_employees
        self.profile.annual_turnover_eur = new_turnover
        self.profile.balance_sheet_eur = new_balance_sheet
        self.profile.last_updated = check_date
        self.pending_changes.append(change)
        return change

    def record_establishment_change(
        self,
        new_member_state: str,
        effective_date: date,
    ) -> StatusChange:
        """
        Records change of main EU establishment. Triggers dual-NCA notification.
        """
        change = StatusChange(
            change_id=self._next_id(),
            entity_id=self.profile.registration_number,
            change_category=ChangeCategory.ESTABLISHMENT_CHANGE,
            trigger_date=effective_date,
            notification_due_date=effective_date - timedelta(days=1),  # Before effective date
            description=(
                f"Main EU establishment changes from {self.profile.main_establishment_member_state} "
                f"to {new_member_state} effective {effective_date}. "
                f"Dual-NCA notification required: outgoing ({self.profile.main_establishment_member_state}) "
                f"and incoming ({new_member_state})."
            ),
            previous_state={
                "main_establishment": self.profile.main_establishment_member_state,
                "nca_jurisdiction": self.profile.main_establishment_member_state,
            },
            new_state={
                "main_establishment": new_member_state,
                "nca_jurisdiction": new_member_state,
                "effective_date": effective_date.isoformat(),
            },
        )
        self.profile.main_establishment_member_state = new_member_state
        self.profile.last_updated = effective_date
        self.pending_changes.append(change)
        return change

    def record_contact_change(
        self,
        new_spoc_email: str,
        new_spoc_phone: str,
        new_emergency_contact: str,
        change_date: date,
    ) -> StatusChange:
        change = StatusChange(
            change_id=self._next_id(),
            entity_id=self.profile.registration_number,
            change_category=ChangeCategory.CONTACT_UPDATE,
            trigger_date=change_date,
            notification_due_date=self._notification_deadline(
                change_date, ChangeCategory.CONTACT_UPDATE
            ),
            description="Security point of contact (SPOC) information updated.",
            previous_state={
                "spoc_email": self.profile.spoc_email,
                "spoc_phone": self.profile.spoc_phone,
                "emergency_contact_24h": self.profile.emergency_contact_24h,
            },
            new_state={
                "spoc_email": new_spoc_email,
                "spoc_phone": new_spoc_phone,
                "emergency_contact_24h": new_emergency_contact,
            },
        )
        self.profile.spoc_email = new_spoc_email
        self.profile.spoc_phone = new_spoc_phone
        self.profile.emergency_contact_24h = new_emergency_contact
        self.profile.last_updated = change_date
        self.pending_changes.append(change)
        return change

    def overdue_notifications(self, as_of: date = None) -> list[StatusChange]:
        """Returns pending changes whose notification_due_date has passed."""
        as_of = as_of or date.today()
        return [c for c in self.pending_changes if not c.submitted and c.notification_due_date < as_of]

    def compliance_report(self, as_of: date = None) -> dict:
        as_of = as_of or date.today()
        overdue = self.overdue_notifications(as_of)
        pending = [c for c in self.pending_changes if not c.submitted]
        upcoming = [
            c for c in pending
            if (c.notification_due_date - as_of).days <= 14 and c.notification_due_date >= as_of
        ]
        return {
            "entity": self.profile.legal_name,
            "current_tier": self.profile.tier.value,
            "jurisdiction": self.profile.main_establishment_member_state,
            "last_updated": self.profile.last_updated.isoformat(),
            "pending_notifications": len(pending),
            "overdue_notifications": len(overdue),
            "upcoming_deadlines_14d": len(upcoming),
            "compliance_status": "NON_COMPLIANT" if overdue else ("ACTION_REQUIRED" if upcoming else "COMPLIANT"),
            "overdue_detail": [
                {
                    "change_id": c.change_id,
                    "category": c.change_category.value,
                    "due": c.notification_due_date.isoformat(),
                    "days_overdue": (as_of - c.notification_due_date).days,
                }
                for c in overdue
            ],
        }

    def generate_notification_payload(self, change_id: str) -> dict:
        """Generate the structured payload for NCA submission."""
        change = next((c for c in self.pending_changes if c.change_id == change_id), None)
        if not change:
            raise ValueError(f"Change {change_id} not found in pending changes")
        return {
            "notification_type": "NIS2_ART27_STATUS_CHANGE",
            "submission_date": date.today().isoformat(),
            "entity": {
                "legal_name": self.profile.legal_name,
                "registration_number": self.profile.registration_number,
                "lei_code": self.profile.lei_code,
                "main_establishment_member_state": self.profile.main_establishment_member_state,
                "sector": self.profile.sector,
                "subsector": self.profile.subsector,
                "current_tier": self.profile.tier.value,
            },
            "change": {
                "change_id": change.change_id,
                "category": change.change_category.value,
                "trigger_date": change.trigger_date.isoformat(),
                "notification_due_date": change.notification_due_date.isoformat(),
                "description": change.description,
                "previous_state": change.previous_state,
                "new_state": change.new_state,
            },
            "current_contact": {
                "spoc_email": self.profile.spoc_email,
                "spoc_phone": self.profile.spoc_phone,
                "emergency_contact_24h": self.profile.emergency_contact_24h,
            },
        }

Usage Example

# Initial profile (registered under Art.24)
profile = EntityProfile(
    legal_name="CloudStack GmbH",
    registration_number="HRB-12345-DE",
    lei_code="5299001234567890ABCD",
    sector="annex_i",
    subsector="cloud_computing",
    tier=EntityTier.IMPORTANT,
    employees_fte=80,
    annual_turnover_eur=15_000_000,
    balance_sheet_eur=8_000_000,
    main_establishment_member_state="DE",
    spoc_email="nis2-spoc@cloudstack.example.com",
    spoc_phone="+49-30-12345678",
    emergency_contact_24h="+49-30-12345679",
    registration_date=date(2024, 10, 17),
    last_updated=date(2024, 10, 17),
)

tracker = NIS2EntityStatusTracker(profile)

# Annual threshold check — company grew to 280 FTE and €55M turnover
change = tracker.check_threshold(
    new_employees=280,
    new_turnover=55_000_000,
    new_balance_sheet=12_000_000,
    check_date=date(2026, 3, 31),  # Financial year end
)
if change:
    print(f"Tier change detected: {change.description}")
    print(f"Notification due: {change.notification_due_date}")
    payload = tracker.generate_notification_payload(change.change_id)
    # Submit payload to BSI portal / NCA API
    print(json.dumps(payload, indent=2))

# SPOC change (CISO left the company)
tracker.record_contact_change(
    new_spoc_email="ciso@cloudstack.example.com",
    new_spoc_phone="+49-30-98765432",
    new_emergency_contact="+49-30-98765433",
    change_date=date(2026, 4, 1),
)

# Compliance check
report = tracker.compliance_report(as_of=date(2026, 4, 17))
print(report["compliance_status"])  # "ACTION_REQUIRED" if deadline within 14 days

Cross-Border Scenarios: Multi-NCA Coordination

For organisations operating across multiple EU Member States, Art.27 intersects with NIS2's jurisdictional rules (Art.26 of the directive). The key principle: one entity, one primary NCA (the main establishment Member State). But transitions require dual notification.

Scenario 1: Acquisition by Foreign Parent

Situation: A Dutch SaaS company (registered with NCSC-NL) is acquired by a German Holding. The post-M&A entity's management decisions will be made in Berlin.

Art.27 obligations:

  1. Notify NCSC-NL: entity has been acquired; management of cybersecurity decisions transfers to Germany effective [closing date]; recommend transfer of NIS2 registration to BSI.
  2. Register with BSI (or update the German subsidiary's registration to include the Dutch operations).
  3. List any open Art.23 incident reports with NCSC-NL and indicate transfer status.

Timeline: On closing date or within seven days.

Scenario 2: EU Headquarters Relocation

Situation: A company re-domiciles from Ireland (CII registry with NCSC-IE) to France (ANSSI) for operational reasons.

Art.27 obligations:

  1. Notify NCSC-IE at least 30 days before the effective relocation date (if possible), including the new main establishment address and effective date.
  2. Register with ANSSI before the effective date (ANSSI needs time to process; initiate at least 45 days in advance in practice).
  3. Ensure Art.23 incident reporting switches to ANSSI on the effective date.

Timeline: Before effective date; minimum 45 days lead time recommended.

Scenario 3: Organic Growth Crossing Thresholds in Multiple States

Situation: A company with significant operations in Germany and France grows beyond essential thresholds. Both BSI and ANSSI have previously received registration (as the entity has a split operation — this is unusual but possible for entities with equivalent operations in two states).

Clarification: NIS2 assigns one primary NCA based on main establishment. If there is genuine ambiguity, the entity should contact both NCAs and request a jurisdictional determination. Art.27(4) requires notification of the Member State where the main establishment is located — that is the authoritative NCA.

Art.27 × GDPR × DORA Cross-Map

ObligationNIS2 Art.27GDPR Art.30 (RoPA update)DORA Art.30 Register
TriggerEntity status or data changeNew processing activity / changeNew ICT arrangement / material change
RecipientNCA (via national portal)Internal record (DPA on request)NCA / ESA on request
Timeline3 months (standard)As soon as practicableWithin 20 working days (material change)
ContentClassification, contact, servicesProcessing description, purposes, recipientsService criticality, jurisdiction, concentration
EntityEssential + Important (NIS2 scope)Any controller/processorFinancial entities (DORA scope)

For financial entities that are also NIS2-covered (e.g., a cloud provider serving financial sector clients), a single corporate event (M&A closing) triggers all three update obligations simultaneously:

Build a single corporate-event trigger checklist that covers all three. An M&A team member checking off "NIS2 Art.27 notification" should simultaneously trigger "GDPR Art.30 review" and "DORA Art.30 register update."

Common Art.27 Failures

Failure 1: Treating Art.24 as a One-Time Filing

The most common failure. An entity registers once under Art.24, changes its CISO, grows past the essential threshold, acquires a competitor — and never updates the NCA. NCA supervisors checking the registry find stale contact information that would make Art.23 incident notification impossible.

Fix: Annual NIS2 status review process. Calendar event on 31 December: "Check NIS2 status: headcount, turnover, SPOC, establishment, services."

Failure 2: Missing M&A Closing Deadlines

M&A teams typically focus on Day 1 integration priorities. NIS2 Art.27 is rarely on the closing checklist, and the three-month window starts from closing.

Fix: Add NIS2 Art.27 (and DORA Art.30 for financial entities) to the standard M&A closing checklist. Legal/compliance sign-off required before integration Day 30.

Failure 3: Notifying Only the Incoming NCA During Establishment Changes

Entities correctly notify the incoming NCA but forget the outgoing NCA. The outgoing NCA continues to count the entity in their registry and may attempt to initiate Art.32 supervisory contact.

Fix: Dual-NCA notification template. The outgoing NCA notification must include: effective date, new establishment details, open incident reports, and confirmation that the entity is completing a new registration with the incoming NCA.

Failure 4: Waiting for NCA Confirmation Before Complying with New Tier's Obligations

When a threshold change moves you from important to essential, you cannot wait for the NCA to confirm your new status before implementing Art.32's enhanced supervision requirements. The obligation attaches when the threshold is first exceeded.

Fix: Treat threshold breach as the trigger date. Submit Art.27 notification immediately. Begin Art.32 compliance gap assessment in parallel.

Failure 5: No Process for Downward Changes

Companies correctly handle threshold growth (the risk of non-compliance is obvious) but forget to notify when they shrink. An entity that has laid off staff and dropped below the important-entity threshold is still on the NCA registry, still potentially subject to Art.32 supervision, and still filing (or failing to file) Art.23 incident reports.

Fix: Include downward threshold checks in the annual review. If you believe you are below threshold, notify the NCA and request removal from the registry.

NCA Portals and Submission Mechanics (by Member State)

Member StateNCAPortal / Submission Method
GermanyBSImeldepflicht.bsi.bund.de
FranceANSSIservices-numeriques.anssi.fr
NetherlandsNCSC-NLncsc.nl/nis2
AustriaBMI (RTR)Registration via RTR or national CSIRT
BelgiumCCN / CCBRegistration via CCB portal
IrelandNCSC-IENCSC-IE online registration portal
SwedenNCSC-SEMSB (Myndigheten för samhällsskydd och beredskap)
PolandCERT-PLCERT Polska NIS2 portal

Art.27 notifications typically follow the same portal path as Art.24 initial registration — they are amendments to the existing registration record, not new registrations. Most portals offer an "update registration" flow distinct from the initial registration form.

20-Item Art.27 Compliance Checklist

Monitoring and Triggers (Items 1–6)

Notification Content (Items 7–12)

Timelines and Deadlines (Items 13–16)

Cross-Border and Multi-Tier (Items 17–20)

Conclusion: Art.27 Is Compliance Infrastructure

Art.27 is not a one-time action. It is an ongoing obligation that requires your legal, compliance, and security teams to operate a lightweight but persistent registration maintenance function.

The practical minimum: an annual review process triggered by financial year-end, an M&A checklist item, and a CISO offboarding trigger. These three mechanisms catch the vast majority of Art.27-triggering events. Add automated threshold monitoring via NIS2EntityStatusTracker.check_threshold() and you have a defensible compliance posture.

The cost of failure is asymmetric. Missing an Art.27 notification is the kind of non-compliance that surfaces during Art.32 supervision audits — supervisors check the registry, find stale data, and conclude that the entity's compliance programme lacks basic administrative hygiene. That is not the finding you want when an Art.32 enforcement action begins.

See also:

Disclaimer: This guide is for informational purposes only and does not constitute legal advice. NIS2 transposition varies by Member State. Consult qualified legal counsel for your specific compliance obligations.