Article 5: Minimum harmonisation

Article 5 of NIS 2 is short, but operationally expensive if you run across multiple EU jurisdictions. It says NIS 2 does not block Member States from adopting or keeping rules that impose a higher cybersecurity level, as long as those rules fit within broader EU law obligations. (Directive (EU) 2022/2555, Article 5)

For a CCO, GRC lead, or Compliance Officer, the practical implication is simple: you cannot implement a single “EU-wide NIS 2 program” and assume it is sufficient everywhere. You need a repeatable mechanism to detect national “uplifts” created during transposition and convert them into enforceable internal requirements with owners, milestones, and evidence. If you do this well, you reduce two failure modes that show up in supervision: (1) scope drift across countries and entities, and (2) controls that exist on paper but are not exam-ready, especially around incident workflows and critical third-party dependencies. (Directive (EU) 2022/2555)

This page focuses on requirement-level execution: what Article 5 means, who should care, what to build, and what to retain so you can answer supervisory questions without scrambling.

Regulatory text

Text (verbatim): “This Directive shall not preclude Member States from adopting or maintaining provisions ensuring a higher level of cybersecurity, provided that such provisions are consistent with Member States’ obligations laid down in Union law.” (Directive (EU) 2022/2555, Article 5)

Operator interpretation: NIS 2 sets a baseline across the EU, but each Member State can add stricter cybersecurity obligations through national law. Your program must therefore:

• implement NIS 2 baseline obligations; and
• identify, track, and implement national “uplift” obligations where you operate; and
• ensure your local approach does not conflict with other EU-law constraints (handled with counsel, but operationally you document the dependency and decision).

What regulators will expect in practice is not a legal memo about harmonisation. They will expect evidence that you know which national rules apply to you, and that your controls and reporting processes meet the strictest applicable requirement for each in-scope business line and system.

Plain-English interpretation (what this requirement really asks of you)

Article 5 does not add a new standalone control like “deploy MFA” or “encrypt data.” It adds a governance requirement: manage regulatory variance.

If you operate in more than one Member State, you need a structured way to answer:

• Where are we subject to NIS 2 obligations (and through which local law)?
• Where do local rules go beyond NIS 2 baseline?
• Which internal controls satisfy each uplift requirement?
• Who owns implementation, and what evidence proves it works?

Even if you operate in one Member State, Article 5 still matters because local law may exceed NIS 2 baseline. You need a method to identify that uplift, then implement it without waiting for an audit finding.

Who it applies to (entity + operational context)

Entity scope: This affects organizations that are in scope for NIS 2 as Essential Entities or Important Entities, and also teams supporting those entities (security, IT, compliance, internal audit, third-party risk). (Directive (EU) 2022/2555)

Operational contexts where Article 5 becomes “real”:

• Multi-country operations: Shared services, centralized SOC, and unified incident response across EU entities.
• Cross-border technology stacks: Single IAM/SIEM/EDR design supporting multiple national perimeters.
• Third-party dependency chains: Cloud providers, managed security providers, OT vendors, and critical suppliers whose failure triggers incident handling and reporting obligations.
• M&A / rapid expansion: Newly acquired entities create hidden jurisdictional obligations you cannot “average out.”

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

Use the steps below as a practical build order. The goal is a defensible system, not a one-time assessment.

Step 1 — Build a “NIS 2 + national uplift” obligation register

Create a register that, at minimum, includes:

• Jurisdiction (Member State)
• In-scope entity/legal entity mapping
• Business services and systems in that jurisdiction
• Baseline NIS 2 obligations you map to (your internal control framework)
• Identified national uplift items (what is stricter than baseline)
• Owner (control owner, not just a policy owner)
• Implementation status, target date, blockers
• Evidence pointers (where proof lives)

This is the single most useful artifact to operationalize the article 5: minimum harmonisation requirement because it turns “variance exists” into an executable backlog. (Directive (EU) 2022/2555, Article 5)

Practical tip: If you use Daydream, model this as a jurisdiction-scoped obligation register with control mappings and evidence links so you can answer “what changed in Country X?” without rebuilding spreadsheets.

Step 2 — Define your rule for conflicts: “highest applicable requirement wins,” with documented exceptions

Create a written decision rule used by security and compliance:

• Default to implementing the strictest applicable requirement across the relevant scope (service/system/entity).
• If you cannot apply the strictest standard globally (due to architectural, contractual, or legal constraints), document the exception with:
  • rationale,
  • compensating controls,
  • scope boundary (what is excluded),
  • approval path, and
  • planned remediation.

Article 5 allows Member States to go higher, so your governance must be able to absorb higher standards quickly. (Directive (EU) 2022/2555, Article 5)

Step 3 — Translate obligations into operational requirements (tickets, control statements, runbooks)

For each uplift item, produce an internal requirement statement that is testable, for example:

• “Incident triage must classify NIS 2-reportable incidents using defined criteria and initiate escalation to the reporting owner.”
• “Critical third parties must be included in the service risk assessment and assurance plan.”

Then implement through:

• control design updates,
• engineering work items,
• SOC runbook updates,
• third-party due diligence workflow changes.

The emphasis is evidence-ready execution, not policy restatement. (Directive (EU) 2022/2555)

Step 4 — Make incident handling exam-ready across jurisdictions

Because national rules may vary, incident response is where “minimum harmonisation” becomes painful.

Operationalize with:

• A single triage workflow that captures jurisdictional triggers (which country’s reporting rules might apply based on impacted entity/service).
• A clear escalation path to the person accountable for regulatory notifications.
• Evidence retention requirements aligned to your register (tickets, timelines, decision logs).

This aligns with the practical risk that many organizations have governance controls but cannot demonstrate incident handling readiness under supervisory scrutiny. (Directive (EU) 2022/2555)

Step 5 — Integrate critical third-party dependencies into your NIS 2 risk lifecycle

Your third-party risk program must reflect jurisdictional uplift where applicable:

• Identify critical dependencies by service and geography.
• Ensure contracts and assurance activities support the higher local requirement where needed.
• Track remediation items for third parties the same way you track internal control gaps.

This is a common gap area because dependency mapping and assurance evidence are often incomplete. (Directive (EU) 2022/2555)

Step 6 — Run a periodic “transposition change” review and update the register

Article 5 exists because national regimes can differ and evolve. Set an internal cadence to:

• monitor relevant national changes,
• update obligations and mappings,
• re-score impacted services,
• open remediation items,
• close out with evidence.

Avoid one-and-done compliance. Your future audit questions will focus on how you detect change and respond.

Required evidence and artifacts to retain

Store these in a system that supports versioning and retrieval by jurisdiction:

1. NIS 2 obligation register with jurisdictional applicability notes, owners, milestones, and evidence pointers.
2. Control mapping from obligations (baseline + uplift) to internal controls and procedures.
3. Incident triage and escalation runbooks including decision trees and notification ownership.
4. Incident tabletop outputs (scenarios, gaps, remediation items) tied to jurisdictions and services.
5. Third-party dependency inventory for critical services, plus assurance plans and remediation tracking.
6. Exception register for where “highest applicable requirement wins” could not be implemented globally, including approvals and compensating controls.

Common exam/audit questions and hangups

Expect questions like:

• “Which Member States’ transpositions apply to this service, and how did you determine that?” (Directive (EU) 2022/2555, Article 5)
• “Show me the delta between your NIS 2 baseline and Country X’s uplift, and where you implemented it.”
• “Who owns regulatory notification decisions, and how do they get engaged during an incident?”
• “Which third parties are critical to the service, and where is the assurance evidence?”
• “How do you detect and implement changes in national requirements over time?”

Hangups that slow teams down:

• unclear entity/service scoping across countries,
• reliance on policies without runbooks and records,
• third-party inventories that do not map to business services.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Treating NIS 2 as uniform across the EU	Article 5 allows higher national standards; auditors test local applicability. (Directive (EU) 2022/2555, Article 5)	Maintain a jurisdiction-by-jurisdiction obligation register with deltas and owners.
“Policy compliance” without operational evidence	Supervisors ask for timelines, tickets, and decision logs.	Build runbooks and evidence capture into SOC/IR workflows.
Third-party risk kept separate from NIS 2 program	Critical dependencies drive operational resilience and incident outcomes.	Map third parties to critical services and track assurance/remediation.
No change management for transposition updates	Local requirements evolve; your compliance drifts.	Add a recurring obligation review and a formal update workflow.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids specific enforcement claims.

Practically, Article 5 raises your risk in three ways:

• Regulatory mismatch risk: You meet baseline but miss local uplift.
• Operational readiness risk: You cannot demonstrate incident handling and reporting readiness tied to jurisdictions.
• Supply-chain exposure: You cannot evidence control over critical third-party dependencies.

The cost of failure is usually not “we didn’t know Article 5 existed.” It is “we couldn’t show how we tracked and implemented the national deltas.”

A practical 30/60/90-day execution plan

Time-box the work into phases. Adjust sequencing based on how many Member States and legal entities you cover.

First 30 days (stabilize and scope)

• Name an executive owner and working owner for the obligation register.
• Define your scoping model: entities, services, and systems by jurisdiction.
• Create the obligation register structure and populate NIS 2 baseline mappings.
• Identify top critical services and their critical third-party dependencies for initial coverage. (Directive (EU) 2022/2555)

Days 31–60 (implement the variance mechanism)

• Add national uplift items per jurisdiction (with counsel input where needed) and document applicability.
• Publish the “highest applicable requirement wins” rule plus an exception process.
• Update incident triage and escalation runbooks to capture jurisdictional triggers and evidence requirements.
• Start remediation tracking for the top uplift gaps and third-party assurance gaps.

Days 61–90 (make it testable)

• Run at least one jurisdiction-focused incident tabletop and capture artifacts and remediation items.
• Validate evidence retrieval: for a given jurisdiction/service, produce the mapping and proof quickly.
• Close or formally exception the most material uplift gaps.
• Operationalize the recurring change review cycle for national updates.

Daydream fits naturally here as the system of record for obligations, control mappings, owners, and evidence pointers, so audits do not turn into spreadsheet archaeology.

Frequently Asked Questions

Does Article 5 mean we must always implement the strictest EU Member State rule everywhere?

Article 5 permits Member States to set higher cybersecurity requirements, but it does not instruct you to globalize every uplift. (Directive (EU) 2022/2555, Article 5) Operationally, default to the highest applicable requirement for the scoped service/entity, and document exceptions with compensating controls.

We operate in one Member State only. Do we still need an obligation register?

Yes. Even in one country, the national transposition may exceed baseline NIS 2. (Directive (EU) 2022/2555, Article 5) A register gives you a durable way to show what applies and who owns it.

What’s the minimum evidence an auditor will accept for “national uplift” compliance?

Expect to show (1) your jurisdictional determination, (2) the mapped control/procedure, and (3) operational records (tickets, logs, exercises) proving it works. Keep evidence pointers in the same register entry that states the uplift.

How does this affect third-party risk management?

Article 5 drives the need to incorporate stricter national expectations into third-party requirements for services operating in that jurisdiction. (Directive (EU) 2022/2555, Article 5) Map critical third parties to services, then align due diligence, contractual terms, and assurance evidence to the uplift.

Our incident response is centralized. How do we handle different national expectations?

Keep one centralized process, but add jurisdiction-aware triggers in triage and escalation, plus clear ownership for regulatory notifications per impacted entity/service. Store decision logs and timelines so you can evidence why you reported (or did not report).

Who should own Article 5 operationally: Legal, Security, or Compliance?

Compliance/GRC should own the obligation register and monitoring workflow, Security should own control implementation and incident runbooks, and Legal should advise on interpretation and conflicts with EU law. (Directive (EU) 2022/2555, Article 5)