Article 6: Definitions

To operationalize the article 6: definitions requirement under NIS 2, you need a controlled “definitions layer” that your policies, incident reporting, third-party risk, and scope decisions consistently use across jurisdictions. Treat Article 6 as a binding glossary: map each defined term to an internal owner, system/process scope, and downstream obligations, then hardwire those terms into procedures and evidence. (Directive (EU) 2022/2555, Article 6)

Key takeaways:

• Build a NIS 2 definitions register and bind it to your obligation register, incident workflow, and third-party inventory.
• Resolve ambiguity early (entity classification, incident significance, critical third parties) and record your rationale.
• Train control owners on defined terms so operational decisions match regulatory language during supervision. (Directive (EU) 2022/2555)

Article 6 looks non-operational because it’s “only definitions,” but for a CCO or GRC lead it is a control point. Definitions decide your scope (are you an essential or important entity), your reporting thresholds (what is an “incident”), and your supply-chain expectations (what counts as a “direct supplier” or relevant third party dependency). If your teams use inconsistent interpretations, you get inconsistent execution: late incident notifications, mis-scoped assets, missing third parties, and audit evidence that does not line up with what your regulator expects.

Operationalizing the article 6: definitions requirement means you translate the NIS 2 vocabulary into internal, version-controlled language that shows up in tickets, playbooks, and committee minutes. You also need traceability: when someone classifies an event as “not reportable” or a supplier as “not critical,” you can point to a defined term, your internal interpretation note, and an approval trail.

This page gives you a fast path: what to build, who owns it, how to roll it into incident handling and third-party risk management, and what artifacts to keep exam-ready, without over-lawyering the effort. (Directive (EU) 2022/2555, Article 6)

Regulatory text

Excerpt: “For the purposes of this Directive, the following definitions apply:” (Directive (EU) 2022/2555, Article 6)

Operator interpretation: Article 6 is the directive’s authoritative dictionary. Your job is to ensure that every place you make a NIS 2-relevant decision uses the directive’s defined terms consistently, and that you can show your working (how you interpreted and applied the terms in your environment). (Directive (EU) 2022/2555, Article 6)

What regulators test in practice is not whether you can recite definitions, but whether your governance and operational processes align to the definitions you rely on for scope, incident triage, and supplier dependency management. (Directive (EU) 2022/2555)

Plain-English interpretation of the requirement

Article 6 requires you to use NIS 2’s terms the way NIS 2 defines them, not how your company casually uses them. If you call something an “incident,” “significant incident,” “essential entity,” “important entity,” “risk,” or “security of network and information systems,” those words must mean the NIS 2 meaning in the contexts where the directive applies. (Directive (EU) 2022/2555, Article 6)

In operational terms, you need:

• A single source of truth for definitions that affect NIS 2 obligations.
• Documented internal interpretation notes where definitions require judgment.
• Consistent adoption across policies, procedures, tooling, and reporting. (Directive (EU) 2022/2555)

Who it applies to (entity and operational context)

Applies to: Organizations in scope of NIS 2 and the teams executing NIS 2 obligations, typically including security, IT operations, privacy/legal, compliance/GRC, procurement/TPRM, and business continuity. (Directive (EU) 2022/2555)

Operational contexts where definitions matter most:

1. Scope and classification: Determining whether business units, subsidiaries, and services fall under NIS 2, and whether the organization is treated as an essential or important entity under applicable rules. (Directive (EU) 2022/2555)
2. Incident handling and reporting: Triage criteria, escalation thresholds, and when the reporting clock starts depend on defined terms (for example, what you treat as an “incident” in the NIS 2 sense). (Directive (EU) 2022/2555)
3. Third-party dependency governance: What counts as a relevant supplier, managed service, or dependency for risk assessment and remediation tracking is shaped by shared definitions across procurement and security. (Directive (EU) 2022/2555)

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

Step 1: Build a “NIS 2 Definitions Register” (controlled document)

Create a register (spreadsheet, GRC system object, or policy annex) with:

• Defined term (as used in NIS 2)
• Internal operational meaning (plain-language interpretation for your org)
• Decision impact (what obligations/process steps depend on it)
• Owner (role accountable for keeping it accurate)
• Where implemented (policy names, playbooks, ticket categories, vendor tiering rules)
• Version and approval record (who approved, date, change notes) (Directive (EU) 2022/2555, Article 6)

Practical tip: keep the register short enough that people will use it, but strict enough that it is the only reference during incident calls and supplier escalations.

Step 2: Link definitions to an obligation register and control owners

For each definition that drives an obligation, link it to:

• The specific internal control or procedure
• The operational owner (SOC manager, IR lead, TPRM lead, etc.)
• The required evidence outputs (tickets, call logs, notices) (Directive (EU) 2022/2555)

This is where many programs fail: they maintain a compliance matrix, but definitions live in legal memos that operators never see.

Step 3: Embed definitions into incident triage and reporting workflows

Update your incident response (IR) artifacts so that NIS 2 terms are present at decision points:

• Triage checklist: “Does this meet our NIS 2 ‘incident’ criteria per definitions register?”
• Escalation runbook: “If yes/unclear, notify Compliance/Legal and open the NIS 2 reporting track.”
• Ticket fields: include a required field for “NIS 2 classification” with dropdown values mapped to definitions. (Directive (EU) 2022/2555)

Evidence target: the incident record should show the definition used, who decided, and what facts supported the decision.

Step 4: Align third-party inventory and risk tiering to defined terms

Make sure your third-party inventory and tiering logic uses the same defined language your security team uses.

• Tag third parties that support in-scope services or systems.
• Add a “critical dependency” flag that triggers enhanced due diligence, contractual checks, and monitoring.
• Require a rationale note when a high-impact supplier is not treated as critical, tied back to your definitions register. (Directive (EU) 2022/2555)

This is a clean place to “earn” automation: Daydream can keep your obligation register and third-party dependency map in one workspace, so definition changes propagate into vendor tiering rules and control evidence requests without manual rework.

Step 5: Train operators on the few definitions that change decisions

Run short, role-based sessions:

• SOC/IR: definitions that trigger notifications and executive escalation.
• Procurement/TPRM: definitions that change supplier classification and assurance depth.
• Business owners: definitions that affect service scope and downtime communications. (Directive (EU) 2022/2555)

Training evidence should include materials, attendance, and a quick knowledge check tied to the definitions register.

Step 6: Add a “definition drift” check to governance

Establish a lightweight review cadence triggered by:

• National transposition updates impacting your jurisdictions
• Material incidents
• Major sourcing changes (new MSP, cloud migration)
• Audit findings that show inconsistent terminology (Directive (EU) 2022/2555)

Output: a change log entry and, if needed, updated procedures and re-training.

Required evidence and artifacts to retain

Keep artifacts that prove the definitions are alive in operations:

Core artifacts

• NIS 2 Definitions Register (version-controlled) (Directive (EU) 2022/2555, Article 6)
• NIS 2 obligation register cross-referenced to definitions and control owners (Directive (EU) 2022/2555)
• Policy and procedure excerpts showing defined terms embedded (IR plan, escalation matrix, supplier risk standard) (Directive (EU) 2022/2555)

Operational evidence

• Incident tickets with NIS 2 classification fields populated and rationale notes
• Incident bridge notes / post-incident reviews referencing definition-based decisions
• Third-party inventory exports showing dependency tags and tiering outcomes
• Exception approvals where a definition-based rule was not followed, with compensating controls

Governance evidence

• Steering committee minutes where scope and definitions were approved
• Training records for relevant roles
• Internal audit results or control self-assessments referencing definitional alignment

Common exam/audit questions and hangups

Auditors and supervisors tend to probe consistency and traceability:

1. “Show me how you decide whether an event is a NIS 2 incident.” Expect follow-ups: who decides, what evidence is required, and where it’s documented. (Directive (EU) 2022/2555)
2. “Which parts of the organization are in scope, and why?” They will look for a repeatable method, not a one-time legal conclusion. (Directive (EU) 2022/2555)
3. “How do you identify and manage critical third-party dependencies?” They will test whether procurement and security share the same terms and tiering triggers. (Directive (EU) 2022/2555)
4. “What changed since last year?” Definition drift is a common weakness: policy language stays static while operational reality changes.

Hangup to anticipate: different jurisdictions may transpose NIS 2 with local nuance. Your register should include “jurisdictional applicability notes” and an owner for maintaining them. (Directive (EU) 2022/2555)

Frequent implementation mistakes and how to avoid them

Mistake	What it looks like	How to avoid it
Definitions live in legal-only documentation	Operators use internal jargon during incidents and sourcing	Publish a definitions register in the same place as IR and TPRM procedures, and require it in runbooks. (Directive (EU) 2022/2555, Article 6)
No binding to systems of record	Tickets and vendor records cannot show definition-based decisions	Add required fields and dropdowns mapped to your definitions register in IR and TPRM tools.
Ambiguity handled ad hoc	Different managers interpret “incident” differently	Pre-approve interpretation notes and require documented rationale for borderline calls.
Third-party scope is incomplete	Critical SaaS/MSP dependencies are not tagged	Maintain a dependency map tied to in-scope services, and reconcile it with procurement data quarterly as a control activity.
Definitions not updated	Policy uses outdated or inconsistent terms after organizational change	Add a governance trigger: major org changes or major incidents require a definitions review and change log entry.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement context as supervision-readiness risk rather than case-law-driven guidance.

Practical risk: definitions drive whether you are late, incomplete, or inconsistent in mandatory actions. If you cannot show a consistent, documented interpretation of key terms, you create avoidable exposure during supervisory requests, incident follow-ups, and third-party assurance reviews. (Directive (EU) 2022/2555)

A practical 30/60/90-day execution plan

Use this as an execution sequence, not a calendar promise. Adjust for your transposition jurisdictions and existing maturity.

First 30 days (stabilize scope and language)

• Stand up the NIS 2 Definitions Register with owners, version control, and approval workflow. (Directive (EU) 2022/2555, Article 6)
• Identify the top decision points that depend on definitions: entity classification, incident triage/reporting, third-party criticality.
• Publish interim interpretation notes for the terms that cause the most internal disagreement.
• Add a “NIS 2 definition reference” link inside IR and procurement playbooks.

By 60 days (embed into workflows and evidence)

• Update incident triage forms and ticket fields to capture NIS 2 classification and rationale.
• Update third-party intake and tiering workflows to tag dependencies supporting in-scope services.
• Run role-based training for SOC/IR, procurement/TPRM, and IT service owners, tied to the register.
• Perform a tabletop exercise where participants must use the definitions register to classify an incident and a critical supplier dependency.

By 90 days (prove it works; close gaps)

• Test evidence retrieval: pick a recent incident and produce a complete “definition-to-decision” trail.
• Reconcile third-party inventory to your dependency map and document exceptions.
• Add internal audit-style checks: sample incidents and suppliers to confirm definition alignment.
• If you need a system to keep this operational, configure Daydream to connect the definitions register to your obligation register, control owners, and third-party evidence requests so updates do not break downstream workflows.

Frequently Asked Questions

Do we need to reproduce the exact legal definitions verbatim in our policies?

Keep the official language accessible, but what auditors need is consistent operational meaning and traceability to decisions. A register that references the directive term and includes your internal interpretation note usually works better than copying long text into every policy. (Directive (EU) 2022/2555, Article 6)

Which teams should own the definitions register?

Compliance/GRC should own the register as a controlled artifact, but each definition needs an operational owner for implementation (IR lead for incident terms, TPRM lead for supplier terms). Shared ownership prevents “legal-only” definitions that operators ignore.

How do we handle differences across EU member state transposition?

Add jurisdictional applicability notes per definition and track where local language changes your thresholds or scope decisions. Keep a change log so you can show when and why your interpretation changed. (Directive (EU) 2022/2555)

What’s the minimum evidence to prove we operationalized Article 6?

A version-controlled definitions register, plus proof it is used in at least your incident workflow and third-party tiering workflow. Ticket samples and supplier records with definition-based fields and rationale notes are strong evidence. (Directive (EU) 2022/2555, Article 6)

Our SOC already has severity levels. Do we need a new NIS 2 classification?

Keep your severity model, but add a mapping layer that answers the NIS 2 question clearly: “does this meet our NIS 2 incident criteria.” Without an explicit mapping, you risk inconsistent escalation decisions during real events. (Directive (EU) 2022/2555)

How do we prevent definition drift after reorganizations or tool changes?

Add a governance trigger: changes to in-scope services, major vendor swaps, or IR process changes must include a definitions impact assessment and register update. Treat it like change management, not a yearly policy refresh.