Article 1: Subject matter

Article 1: Subject matter requirement sets the directive’s purpose: you must run a NIS 2 program that produces a demonstrably high level of cybersecurity across your EU footprint, consistent enough to support cross-border operations and supervision. Operationally, translate NIS 2 into a jurisdiction-scoped obligation register, assign accountable owners, and prove incident and third-party readiness with audit-ready evidence. (Directive (EU) 2022/2555, Article 1)

Key takeaways:

• Treat Article 1 as the “program charter” for NIS 2: align scope, governance, and outcomes to a common cybersecurity baseline across the Union. (Directive (EU) 2022/2555, Article 1)
• Build a jurisdiction-by-jurisdiction obligation register with owners, milestones, and evidence expectations to prevent scope drift under national transposition. (Directive (EU) 2022/2555)
• Prove execution where supervisors test hardest: incident handling readiness and third-party dependency coverage with retained artifacts. (Directive (EU) 2022/2555)

Article 1 looks simple, but it drives how regulators interpret everything else you do under NIS 2. It tells you what the directive is trying to achieve: a “high common level of cybersecurity across the Union,” and it ties that outcome to the functioning of the internal market. (Directive (EU) 2022/2555, Article 1) For a CCO or GRC lead, this means you need more than a policy set. You need a program that is consistently implemented across relevant EU entities and operations, and you need to show that consistency on demand.

Because NIS 2 is a directive, day-to-day obligations become enforceable through national transposition. Your operational risk is mismatch: one business line implements strong controls while another EU subsidiary runs on an older standard, or your incident reporting workflow works in one country but fails to meet expectations in another. Article 1 is the anchor you use to justify central governance, minimum baselines, and a single source of truth for obligations, ownership, and evidence.

Use this page as a requirement-level playbook: interpret Article 1 in plain English, identify where it applies, implement it through concrete governance and evidence practices, and prepare for supervisory scrutiny. (Directive (EU) 2022/2555, Article 1)

Regulatory text

Text (excerpt): “This Directive lays down measures that aim to achieve a high common level of cybersecurity across the Union, with a view to improving the functioning of the internal market.” (Directive (EU) 2022/2555, Article 1)

What the operator must do with this: Article 1 does not list controls or deadlines. It sets the supervisory expectation that your NIS 2 compliance program must (a) be outcome-oriented (high cybersecurity), (b) be consistent across the EU where you operate (common level across the Union), and (c) support cross-border business resilience (internal market). (Directive (EU) 2022/2555, Article 1)
Your job is to operationalize “common level” into: defined scope, minimum baseline requirements, accountable ownership, and evidence that proves consistent implementation across entities, services, and critical third parties.

Plain-English interpretation (what this requirement really means)

Article 1: subject matter requirement is the program mandate. If your organization is in scope for NIS 2, you must stand up governance and execution that can withstand two realities:

1. Multiple jurisdictions: National transposition will vary in detail, but supervisors will still expect coherence. You need a method to translate NIS 2 into country-specific obligations without fragmenting your program. (Directive (EU) 2022/2555)
2. Operational proof beats intent: A policy that says “we manage incidents” is not enough. You must show incident triage and reporting readiness, and you must show that third-party dependencies are identified and governed because they can drive real outages and reportable incidents. (Directive (EU) 2022/2555)

Put differently: Article 1 is why you should run NIS 2 as a managed compliance program with measurable implementation and audit-ready artifacts, not as a one-time legal mapping exercise. (Directive (EU) 2022/2555, Article 1)

Who it applies to (entity and operational context)

Article 1 applies indirectly to any organization that falls within NIS 2’s scope once your relevant Member States transpose and supervise it. Practically, you should treat it as applying to:

• In-scope EU legal entities and branches that provide covered services or operate covered sectors under the directive. (Directive (EU) 2022/2555)
• Shared service organizations that support EU operations (central IT, SOC, IAM, network, cloud platform teams), because “common level” requires centralized baselines and consistent execution. (Directive (EU) 2022/2555, Article 1)
• Business owners of critical services delivered into the EU market, including product teams and operations teams who own uptime, security controls, and incident response outcomes. (Directive (EU) 2022/2555)
• Third parties that underpin service delivery (cloud, MSPs, telecoms, software suppliers, and other dependencies). You may not regulate the third party directly under Article 1, but you must govern the dependency to meet your own “high common level” objective. (Directive (EU) 2022/2555)

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

Below is an operator’s build sequence that turns Article 1 into exam-ready execution.

1) Create a NIS 2 obligation register (single source of truth)

Deliverable: A living register that maps NIS 2 obligations to jurisdictions, owners, and evidence. (Directive (EU) 2022/2555)

Minimum fields to include:

• Applicable Member State(s) and entity/service in scope
• Obligation statement (plain English) and source reference to NIS 2
• Control owner (named role), executor team, approver
• Implementation status and milestone dates (your internal planning dates)
• Evidence required (specific artifacts, location, retention owner)

Why this satisfies Article 1: It operationalizes “measures” into a managed system and reduces fragmentation across the Union. (Directive (EU) 2022/2555, Article 1)

2) Define a “common baseline” cybersecurity control set

Deliverable: A minimum baseline that every in-scope EU entity and supporting platform must meet, even if local country rules differ in detail. (Directive (EU) 2022/2555, Article 1)

How to define it quickly:

• Start with your existing control framework (ISO 27001, NIST CSF, CIS, etc.).
• Map controls to NIS 2 obligations in your obligation register.
• Add “jurisdictional overlays” as deltas, not separate programs.

Practical test: If you cannot explain, in one page, which controls are globally mandatory vs locally additive, you do not yet have a “common level” program. (Directive (EU) 2022/2555, Article 1)

3) Codify incident triage, escalation, and reporting workflows

Deliverable: A written, rehearsed incident workflow with clear triggers, role assignments, and evidence capture steps. (Directive (EU) 2022/2555)

What to include so it survives scrutiny:

• A severity model that ties to reporting decision points (who decides, based on what facts)
• Escalation paths: SOC to IR lead to legal/compliance to exec sponsor
• A reporting “data pack” template: what facts you gather early (service impact, affected geographies, suspected cause, containment status)
• Evidence retention instructions: where tickets, logs, timelines, and decisions are stored and who can retrieve them fast

Why this connects to Article 1: Supervisors interpret “high common level” through operational readiness, and incident handling is the fastest way to test it. (Directive (EU) 2022/2555, Article 1)

4) Integrate critical third-party dependencies into risk and assurance

Deliverable: A third-party dependency inventory tied to your critical services, with risk assessments and tracked remediation. (Directive (EU) 2022/2555)

Minimum actions:

• Identify critical services delivered in the EU and list their third-party dependencies (cloud, DNS, IAM provider, payment processor, data center, key SaaS).
• Classify which third parties are “critical to service continuity.”
• Require baseline security assurances (contract clauses, security addenda, audit reports, incident notification terms).
• Track open risks and remediation owners in the same system you use for internal security findings.

Operator note: Many teams have a vendor risk program that is procurement-driven. Article 1 pushes you toward service-driven dependency governance: start from the service, then map third parties. (Directive (EU) 2022/2555, Article 1)

5) Make it “exam-ready”: assign ownership and prove operation

Deliverable: RACI + evidence map for each obligation, plus a retrieval path (who can produce which artifact within a business day). (Directive (EU) 2022/2555)

This is where tools can help. Daydream is a natural fit when your pain is fragmentation: one place to maintain the obligation register, link owners to controls, and attach evidence artifacts so you can answer supervisory questions without a spreadsheet scramble. (Directive (EU) 2022/2555)

Required evidence and artifacts to retain

Retain artifacts that prove both design (you defined measures) and operation (you run them consistently).

Governance and scope

• NIS 2 applicability memo per Member State and entity/service
• Obligation register with owners, milestones, and evidence links (Directive (EU) 2022/2555)
• Common baseline control standard and approved exceptions process

Incident readiness

• Incident response policy and playbooks
• Triage/escalation matrix with named roles
• Tabletop exercise records, after-action items, and closure evidence
• Incident case files: timeline, decisions, tickets, logs, communications approvals (Directive (EU) 2022/2555)

Third-party dependency governance

• Critical service inventory with mapped third parties
• Third-party risk assessments for critical dependencies
• Contractual clauses or addenda addressing security obligations and incident notification
• Remediation tracker and closure artifacts (Directive (EU) 2022/2555)

Common exam/audit questions and hangups

Expect questions that test whether “common level across the Union” is real in your operating model. (Directive (EU) 2022/2555, Article 1)

Typical prompts:

• “Show us your NIS 2 scope and how it is maintained as your business changes.” (Directive (EU) 2022/2555)
• “Which controls are mandatory across all EU entities, and where do local rules add requirements?” (Directive (EU) 2022/2555, Article 1)
• “Walk through your incident escalation from detection to notification decision; who signs off and what evidence is produced?” (Directive (EU) 2022/2555)
• “What third parties are critical to the continuity of your covered services, and how do you monitor their risk?” (Directive (EU) 2022/2555)

Hangups that slow teams down:

• No single inventory of critical services and dependencies.
• Evidence exists but is scattered across ticketing, SOC tools, and shared drives with inconsistent retention.
• Country-by-country compliance is treated as separate programs, causing gaps and inconsistent baselines. (Directive (EU) 2022/2555, Article 1)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails under Article 1	Better pattern
Treating Article 1 as “no action required”	It sets the supervisory lens for coherence and outcomes. (Directive (EU) 2022/2555, Article 1)	Use it as your program charter and justify centralized baselines.
Building separate NIS 2 programs per Member State	Creates inconsistent “common level” implementation. (Directive (EU) 2022/2555, Article 1)	One baseline program with jurisdictional overlays in the obligation register.
Incident response documented but not runnable	Supervisors test speed and accuracy of execution. (Directive (EU) 2022/2555)	Codify triage triggers, decision rights, and evidence capture; rehearse it.
Third-party risk treated as procurement paperwork	Misses service continuity dependencies and operational risk. (Directive (EU) 2022/2555)	Build dependency maps per critical service; govern the highest-impact third parties.
Evidence retention is an afterthought	You cannot prove “measures” were operating consistently. (Directive (EU) 2022/2555, Article 1)	Define artifact lists per obligation and a retrieval owner; test retrieval quarterly (internal practice).

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for this page, so don’t anchor your internal messaging to specific penalties or case outcomes here. (Directive (EU) 2022/2555) The practical risk is supervisory friction: inconsistent program scope, weak incident readiness, and unmanaged third-party dependencies are the fastest routes to adverse findings because they signal the “common level” objective is not being met across your EU operations. (Directive (EU) 2022/2555, Article 1)

Practical 30/60/90-day execution plan

You asked for speed and operability. Use phases, not date promises.

First 30 days (Immediate stabilization)

• Name an executive sponsor and a single program owner for NIS 2 across EU operations. (Directive (EU) 2022/2555, Article 1)
• Draft the obligation register structure and populate it with initial scope, Member States, and owners. (Directive (EU) 2022/2555)
• Identify your critical EU services and top third-party dependencies for each service (start with your highest-impact services). (Directive (EU) 2022/2555)
• Document the incident escalation workflow and evidence checklist; run a short “walkthrough” with SOC, legal, and comms. (Directive (EU) 2022/2555)

Next 60 days (Build the common baseline and evidence system)

• Approve the common baseline control standard and an exceptions process tied to risk acceptance. (Directive (EU) 2022/2555, Article 1)
• Implement evidence mapping: for each obligation, define artifacts, systems of record, and retention owners.
• Standardize third-party assurance intake for critical dependencies (security addendum, reporting expectations, and remediation tracking). (Directive (EU) 2022/2555)
• Centralize the obligation register and evidence links in a system that supports ownership and audit trails; Daydream can reduce the operational load if you’re currently spreadsheet-driven. (Directive (EU) 2022/2555)

Next 90 days (Prove operation and close readiness gaps)

• Run a tabletop exercise that tests cross-functional incident decision-making and evidence production; track after-action remediation to closure. (Directive (EU) 2022/2555)
• Perform an internal “supervisory pack” dry run: retrieve scope, baseline, incident artifacts, and third-party evidence as if requested by an authority.
• Review jurisdictional overlays for completeness and consistency, then lock a governance cadence to keep the register current as services and third parties change. (Directive (EU) 2022/2555, Article 1)

Frequently Asked Questions

What does the article 1: subject matter requirement require me to implement right now?

Implement governance that produces a consistent cybersecurity baseline across your EU scope, then prove it with an obligation register, owned controls, and runnable incident and third-party processes. Article 1 supplies the objective authorities use to judge whether your measures are coherent and effective. (Directive (EU) 2022/2555, Article 1)

Does Article 1 impose specific controls or reporting deadlines?

No. Article 1 states the directive’s purpose and sets the expectation of “measures” that achieve a high common level of cybersecurity. The specific operational requirements appear elsewhere in the directive and in national transposition. (Directive (EU) 2022/2555, Article 1)

How do I prove “a high common level of cybersecurity across the Union” in an audit?

Show a single baseline standard applied across in-scope EU entities, plus documented jurisdictional overlays. Then provide evidence that key processes (incident handling and third-party dependency governance) operate consistently and produce retrievable artifacts. (Directive (EU) 2022/2555, Article 1)

We have different security maturity levels across EU subsidiaries. What’s the fastest way to align?

Set a minimum baseline and manage exceptions formally with risk acceptance and time-bound remediation plans. Track it all in your obligation register so you can demonstrate controlled convergence instead of informal variance. (Directive (EU) 2022/2555, Article 1)

Does this apply to third parties directly?

Article 1 frames your obligation to implement measures that achieve the directive’s cybersecurity objective; it does not “regulate” your vendors by itself. You still need to govern third-party dependencies because they affect your ability to meet that objective and to operate consistently across the EU. (Directive (EU) 2022/2555, Article 1)

What artifact do examiners ask for first in practice?

They typically start with scope, ownership, and evidence of operation. Have your obligation register, common baseline, incident workflow, and critical third-party dependency list ready to produce without rework. (Directive (EU) 2022/2555)