Article 2: Scope

Article 2: Scope requirement tells you whether NIS 2 applies to your organization: you’re in scope if you are a public or private entity listed in Annex I or Annex II, you are at least a medium-sized enterprise (or larger), and you provide services or carry out activities within the EU. Operationalize it by completing and documenting a defensible scoping determination, then binding the resulting in-scope perimeter to owners, systems, third parties, and reporting workflows. (Directive (EU) 2022/2555, Article 2)

Key takeaways:

• Treat scope as a controlled compliance decision: document entity type (Annex I/II), size qualification, and EU activity nexus. (Directive (EU) 2022/2555, Article 2)
• Build an “NIS 2 applicability + obligation register” tied to business services, systems, and third parties, so scope does not drift.
• Examiners will test whether your scope is evidenced and operational (incident reporting readiness and third-party dependency mapping), not whether you can recite the text.

Article 2 is the gatekeeper for the entire NIS 2 program. If you get scope wrong, every downstream control decision becomes fragile: you may over-build controls for out-of-scope entities, or worse, under-build for in-scope operations and fail supervisory expectations. The operational goal is simple: produce a scoping determination that a regulator, internal audit, and your board can follow without tribal knowledge.

This page focuses on converting the “are we in scope?” question into a repeatable process you can run during acquisitions, reorganizations, rapid growth, and market entry. The directive text anchors scope on three factors: (1) entity type (Annex I or II), (2) enterprise size (medium-sized or larger), and (3) whether services/activities are provided within the Union. (Directive (EU) 2022/2555, Article 2)

You will leave with a concrete set of artifacts: a scope memo, an entity and service inventory mapped to EU operations, and an obligation register with clear control owners. Those artifacts are also the fastest way to align security, IT, procurement, and legal on the same perimeter.

Regulatory text

Regulatory excerpt (Article 2(1)): NIS 2 applies to public or private entities referred to in Annex I or Annex II that qualify as medium-sized enterprises (or exceed medium-size ceilings) and that provide services or carry out activities within the Union. (Directive (EU) 2022/2555, Article 2)

Operator interpretation (what you must do):

1. Decide and document applicability using the three-part test (Annex I/II type, size, EU nexus). (Directive (EU) 2022/2555, Article 2)
2. Translate the scope decision into an operational perimeter: which legal entities, business services, systems, locations, and third parties are governed under your NIS 2 program.
3. Maintain the decision over time as facts change (growth, M&A, outsourcing, new EU customers, new EU establishment).

Practical rule: treat “scope” like a controlled compliance configuration item. If you cannot show how you determined it and how you keep it current, you do not have a reliable scope.

Plain-English interpretation of the requirement

The article 2: scope requirement is asking: “Are you the kind of organization NIS 2 targets, are you big enough, and do you operate in the EU?” If yes, you must run a NIS 2-aligned security and incident readiness program for the in-scope part of the business, and be prepared to prove your scoping logic. (Directive (EU) 2022/2555, Article 2)

This is not a purely legal exercise. The scoping output becomes a work order for operations:

• Security needs to know which environments are in program scope.
• IT needs to know which assets must meet NIS 2 controls.
• Procurement needs to know which third parties become “in-scope dependencies.”
• Incident response needs to know which events trigger NIS 2 reporting workflows.

Who it applies to (entity and operational context)

Entity types: Public or private entities “of a type referred to in Annex I or II.” (Directive (EU) 2022/2555, Article 2)
Because Annex I/II are not included in your provided text pack, don’t guess. Your job is to identify your candidate entity types and record the basis (e.g., legal counsel mapping to Annex I/II categories) as part of the scope memo.

Size threshold: Medium-sized enterprises (or larger) per the EU SME definition referenced in the article. (Directive (EU) 2022/2555, Article 2)
Operationally, you must decide how you determine size for your corporate group and keep evidence supporting the determination.

EU nexus: The entity must “provide their services or carry out their activities within the Union.” (Directive (EU) 2022/2555, Article 2)
This usually means one or more of:

• EU establishment (subsidiary/branch) performing covered activities,
• EU-based operations delivering services,
• In-scope services delivered into the EU market (document the operational facts; avoid legal conclusions without counsel).

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

Step 1: Run a structured scoping assessment (and treat it as auditable)

Create a Scope Determination Worksheet with three sections:

1. Annex I/II mapping: list each legal entity and business line; capture “likely Annex I/II category” and the internal owner; attach counsel analysis if available. (Directive (EU) 2022/2555, Article 2)
2. Size qualification: record how your organization meets medium-size (or exceeds), and the data sources used (finance/HR). (Directive (EU) 2022/2555, Article 2)
3. EU activity nexus: list EU locations, EU staff supporting the service, EU-hosted infrastructure, EU customers where relevant, and which services are performed “within the Union.” (Directive (EU) 2022/2555, Article 2)

Output: a one-page Scope Memo signed by the accountable executive (often the CISO or CCO) and reviewed by legal.

Step 2: Convert “in scope” into an operational perimeter

Build a Scope Register that answers, for each in-scope service:

• Service name and criticality tier (your internal tiering is fine; document criteria).
• Owning legal entity and business owner.
• Supporting systems (apps, cloud accounts, networks).
• Data flows that cross boundaries (especially managed services).
• Critical third parties that support delivery.

This is where most programs fail. Teams decide the entity is in scope, but they never define which services and systems are governed. The register prevents scope drift during replatforming and outsourcing.

Step 3: Create the NIS 2 obligation register (mapped to owners and milestones)

Maintain a NIS 2 obligation register with jurisdictional applicability notes, control owners, and implementation milestones (best practice control from your data pack).
Minimum fields:

• Obligation name (e.g., incident reporting readiness, third-party dependency governance).
• Applies to (service/system/entity).
• Owner (role + name).
• Evidence produced (link to repository location).
• Jurisdictional notes (because NIS 2 is transposed nationally; your operating procedures must reflect where you operate). (Directive (EU) 2022/2555)

If you use Daydream, this is the natural place to run a controlled obligation register with ownership, evidence links, and scoping notes per jurisdiction, so your scope decision stays tied to execution rather than living in a static memo.

Step 4: Bind scope to incident triage and reporting workflows

Even though Article 2 is “scope,” examiners often pressure-test scope through incident readiness: “Show me which incidents are NIS 2-reportable for your in-scope services.” Implement the recommended control: codify incident triage, escalation, and reporting workflows with timing triggers and evidence retention requirements (from your data pack).
What to do:

• Add an “NIS 2 applicability check” step in triage: is the affected service/system in the Scope Register?
• Ensure the on-call path includes compliance/legal review for notifications.
• Define what evidence you retain from each incident to support later supervisory questions (timeline, impact assessment basis, comms approvals).

Step 5: Pull third-party dependencies into scope governance

Implement the recommended control: integrate critical third-party dependencies into risk assessments, remediation tracking, and assurance activities (from your data pack).
Practically:

• Tag third parties to in-scope services in your third-party inventory.
• For each critical dependency, document the service supported, concentration risk notes, and the minimum security assurance you require (contract clauses, audit reports, incident notification terms).
• Create a remediation queue for third-party findings tied to the in-scope perimeter.

Required evidence and artifacts to retain

Retain artifacts in a repository that internal audit can access without Slack archaeology.

Core scope artifacts

• Scope Memo (dated, versioned, approver, reviewer). (Directive (EU) 2022/2555, Article 2)
• Scope Determination Worksheet (Annex I/II mapping, size basis, EU nexus evidence). (Directive (EU) 2022/2555, Article 2)
• Legal entity list and org chart (in-scope entities marked).
• Scope Register (services, systems, owners, third parties).

Operational linkage artifacts

• NIS 2 obligation register (owners, milestones, evidence pointers).
• Incident triage SOP showing the “in-scope service” check.
• Third-party inventory with dependency mapping to in-scope services.
• Meeting minutes or steering committee decisions that approve scope changes.

Common exam/audit questions and hangups

Use these as your internal readiness checklist.

1. “Show me how you concluded you are (or are not) in scope.”
   Hangup: You have a narrative email, not a controlled memo with supporting evidence. (Directive (EU) 2022/2555, Article 2)

2. “Which legal entities and services are covered?”
   Hangup: You scoped the parent company, but you did not map services and systems to an operational perimeter.

3. “How do you keep scope current after M&A or new outsourcing?”
   Hangup: No trigger events, no periodic review cadence, no change control.

4. “Which third parties are critical to in-scope services, and how do you govern them?”
   Hangup: Procurement has a vendor list; security has a separate list; neither is mapped to in-scope services.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating scope as a one-time legal conclusion.
  Fix: Define scope change triggers (M&A, new EU establishment, major service launch, cloud migration) and require an updated memo and register entries.

• Mistake: Scoping by corporate entity only.
  Fix: Add the service/system layer. Regulators supervise operational reality; your register must point to systems and dependencies.

• Mistake: Forgetting “within the Union” operational evidence.
  Fix: Capture concrete facts: where the service is performed, where staff operate, where infrastructure sits, and which in-scope services are delivered in the EU. (Directive (EU) 2022/2555, Article 2)

• Mistake: Third-party risk not tied to NIS 2 scope.
  Fix: Tag third parties to in-scope services; require assurance evidence proportionate to dependency criticality.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so don’t anchor your program on specific penalty examples. Your practical risk is supervisory friction: if you cannot show a coherent scope perimeter, every downstream control discussion becomes a re-litigation of whether your program coverage is adequate. Article 2 is also where cross-border complexity starts; national transposition and supervision can vary, so you need jurisdictional notes in your obligation register. (Directive (EU) 2022/2555)

Practical 30/60/90-day execution plan

First 30 days (Immediate): Get to a defensible scope decision

• Assign a single accountable owner for the scoping determination (CCO/GRC lead with legal review).
• Draft the Scope Determination Worksheet and produce the first Scope Memo. (Directive (EU) 2022/2555, Article 2)
• Stand up the initial Scope Register with your top services, systems, and third parties.

Days 31–60 (Near-term): Bind scope to operations

• Publish the NIS 2 obligation register with owners and evidence placeholders (even if controls are in progress).
• Update incident triage to include the in-scope check and evidence retention expectations.
• Start third-party dependency mapping for in-scope services; identify gaps in contracts and assurance.

Days 61–90 (Execution hardening): Make it auditable

• Run an internal tabletop: pick an incident affecting an in-scope service and walk through triage, escalation, and notification readiness.
• Perform an internal audit-style review of your scope artifacts: can a reviewer reproduce your decision from evidence?
• Implement a scope change workflow (intake form + approval + register updates) and route it through change management.

Frequently Asked Questions

How do we determine if we are “a type referred to in Annex I or II” if we operate multiple business lines?

Treat it as a mapping exercise per legal entity and per business service, then document your basis in the Scope Determination Worksheet. Article 2 requires that the entity is of a type referred to in Annex I or II, so your memo should show how each relevant part of the business was assessed. (Directive (EU) 2022/2555, Article 2)

We are headquartered outside the EU but sell services into the EU. Are we in scope?

Article 2 turns on whether you “provide services or carry out activities within the Union,” plus the Annex I/II type and size threshold. Document the operational facts of how the service is delivered and obtain legal review for the final determination. (Directive (EU) 2022/2555, Article 2)

If only one subsidiary is in scope, do we need to apply NIS 2 controls enterprise-wide?

Article 2 is a scope test, so start by defining the in-scope legal entities and the services they run. Many organizations choose to standardize controls more broadly for efficiency, but keep a register that clearly marks what is required for the in-scope perimeter. (Directive (EU) 2022/2555, Article 2)

What evidence will an auditor expect for the size threshold (medium-sized enterprise or larger)?

Keep the data sources and calculation basis you used (HR/finance extracts, corporate structure context) attached to the scope worksheet and referenced in the Scope Memo. The key is repeatability: another reviewer should be able to reach the same conclusion from the retained evidence. (Directive (EU) 2022/2555, Article 2)

How do we prevent scope drift after acquisitions or reorganizations?

Define scope change triggers and require an updated scope worksheet, memo version, and register updates as part of the corporate change process. Track each change as a governed item with an owner, approval, and evidence trail.

Where should third-party risk management plug into Article 2 scope?

In the Scope Register, map critical third parties to each in-scope service and system. Then carry those tags into your third-party risk workflow so reviews, remediation, and assurance activity prioritize the dependencies that could disrupt in-scope services.