Article 38: Exercise of the delegation

Article 38: exercise of the delegation requirement is not an operational security control for your organization; it governs how the European Commission can adopt future delegated acts under NIS 2 and under what conditions. Your job is to operationalize “change readiness”: track delegated-act updates, assess applicability, and translate changes into controlled updates to your NIS 2 obligations register, policies, incident workflows, and third-party risk controls. (Directive (EU) 2022/2555, Article 38)

Key takeaways:

• Treat Article 38 as a regulatory-change trigger, not a technical requirement.
• Maintain an exam-ready change-management trail from “new delegated act” to “controls updated.”
• Use a NIS 2 obligation register to assign owners, milestones, and jurisdictional applicability notes.

Compliance teams often mis-handle Article 38 because it reads like “EU institutional plumbing.” That’s accurate, but it still creates a real operational requirement for a CCO or GRC lead: you must be able to absorb legal change without losing control of scope, accountability, or evidence.

Article 38: exercise of the delegation requirement establishes that the European Commission has the power to adopt delegated acts, subject to conditions set out in the Article. (Directive (EU) 2022/2555, Article 38) For operators, the practical impact is that NIS 2 obligations can be refined or extended through delegated acts over time. If you cannot show a disciplined method to identify changes, assess applicability to your entity and jurisdictions, and implement updates with owners and proof, you will end up with “paper compliance” and gaps that become findings during supervisory inquiries.

This page focuses on rapid operationalization. You’ll leave with a minimal set of governance steps, artifacts to retain, and audit questions you should be able to answer cleanly. The target is exam readiness: clear traceability from regulatory change to implemented control changes.

Regulatory text

Excerpt (provided): “1. The power to adopt delegated acts is conferred on the Commission subject to the conditions laid down in this Article.” (Directive (EU) 2022/2555, Article 38)

Plain-English interpretation (what it means for an operator)

• The Commission can issue future delegated acts under NIS 2, but only within boundaries and conditions defined in Article 38. (Directive (EU) 2022/2555, Article 38)
• Your organization does not “comply with” Article 38 by deploying a control. You comply by staying current with delegated acts that may change what you must do under NIS 2, then implementing those changes in a controlled, provable way. (Directive (EU) 2022/2555, Article 38)

Why auditors and supervisors still care

Even though Article 38 is addressed to the Commission, supervisory outcomes often depend on whether you can demonstrate:

• a reliable regulatory-change intake process,
• consistent translation of requirements into internal controls across jurisdictions,
• evidence that incident handling and third-party dependency controls are implemented and provable. (Directive (EU) 2022/2555, Article 38)

This maps directly to two common risk patterns in NIS 2 programs:

• Scope drift across jurisdictions and business units because applicability is tracked informally.
• “We have a policy” without exam-ready evidence for incidents and third-party dependencies. (Directive (EU) 2022/2555, Article 38)

Who it applies to

Entity scope

• Regulated entities in NIS 2 scope (essential or important entities under the Directive) that must maintain ongoing compliance as NIS 2 evolves through EU and national actions. (Directive (EU) 2022/2555)

Operational context (when it becomes real work)

You need this operationalized when:

• You operate in multiple EU jurisdictions and must track national transposition and EU-level updates.
• You run a mature security program but struggle to show “change-to-control” traceability during audits.
• You depend on critical third parties (cloud, managed security providers, OT suppliers, software publishers) and need to update third-party requirements as NIS 2 evolves. (Directive (EU) 2022/2555)

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

The goal: build a lightweight, repeatable “delegated acts intake → applicability → implementation → evidence” workflow.

Step 1: Define ownership and triggers (one page)

Assign a single accountable owner (often GRC) and named collaborators (Legal, CISO org, Procurement/TPRM, IT Ops).

Define triggers you will monitor:

• Updates and delegated acts in the NIS 2 legal corpus on EUR-Lex. (Directive (EU) 2022/2555)

Practical tip: If you cannot explain “who reviews EUR-Lex updates and how often,” you do not have a defensible change process.

Step 2: Stand up a NIS 2 obligation register (your system of record)

Create or formalize a register that contains, at minimum:

• Requirement reference (article / subject)
• Applicabile jurisdictions and entities
• Control owner (named role)
• Mapped controls/procedures (policy, SOP, technical standard)
• Current status and next review trigger
• Evidence pointer (where proof lives) This directly aligns with the recommended control: “Maintain a NIS 2 obligation register with jurisdictional applicability notes, control owners, and implementation milestones.” (Directive (EU) 2022/2555, Article 38)

Operator outcome: When a delegated act appears, you update the register first, then drive downstream changes through controlled tasks.

Step 3: Create a “delegated act impact assessment” template (repeatable)

Use a short template so each update yields consistent outputs:

1. Change description: What changed and where (link to EUR-Lex record). (Directive (EU) 2022/2555)
2. Applicability: Which legal entities, services, or systems are in scope.
3. Control impact: What policies, standards, and procedures require updates.
4. Operational impact: Tooling/config changes, new logs, new reporting fields, supplier contract updates.
5. Timing: Internal deadline and implementation milestones (don’t confuse with statutory deadlines; document your internal commitments).
6. Residual risk decision: Accept / mitigate / transfer, with approver.

Step 4: Translate changes into controlled work items

For each impacted area, create tracked work items with owners and acceptance criteria:

• Governance documentation updates (policy/standard revisions, RACI updates).
• Incident readiness updates aligned to a codified workflow: “Codify incident triage, escalation, and reporting workflows with timing triggers and evidence retention requirements.” (Directive (EU) 2022/2555, Article 38)
• Third-party risk updates aligned to: “Integrate critical third-party dependencies into risk assessments, remediation tracking, and assurance activities.” (Directive (EU) 2022/2555, Article 38)

Make it auditable: every work item should link back to the obligation register entry and the impact assessment.

Step 5: Validate implementation (prove it works, not that it exists)

Pick validation methods that match the change:

• Tabletop exercise for incident workflow changes.
• Sampling of third-party files for updated due diligence and contract language.
• Configuration review for technical control changes.
• Evidence pack review for “can we answer the supervisor’s follow-up questions quickly?”

Step 6: Close the loop with a management sign-off and evidence pack

Your close-out should include:

• Updated obligation register entry
• Completed impact assessment
• Approved policy/procedure revisions
• Implementation tickets closed with proof
• Validation results and any residual risk acceptance

Required evidence and artifacts to retain

Keep these artifacts in a structured repository with stable naming:

Governance and change control

• Regulatory change log (date identified, source link, reviewer, decision)
• Delegated act impact assessment (completed template)
• Approvals (Legal/GRC/CISO sign-off), including dated versions

Obligations and control mapping

• NIS 2 obligation register with:
  • jurisdictional applicability notes,
  • control owners,
  • implementation milestones,
  • evidence pointers. (Directive (EU) 2022/2555, Article 38)

Operational proof (two areas exam teams commonly probe)

• Incident triage and escalation SOPs, call trees, on-call procedures, and retention requirements for incident records. (Directive (EU) 2022/2555, Article 38)
• Third-party inventory for critical dependencies, due diligence records, assurance results, and remediation tracking. (Directive (EU) 2022/2555, Article 38)

Common exam/audit questions and hangups

Use these as readiness checks:

1. “How do you monitor NIS 2 changes, including delegated acts?”
   Hangup: teams rely on informal newsletters with no evidence trail.

2. “Show me how a regulatory update becomes a control change.”
   Hangup: no traceability from legal interpretation to tickets, policy versions, and validation.

3. “Which entities and services are in scope by jurisdiction?”
   Hangup: scope documented once, then not maintained as org structure changes.

4. “Prove incident reporting readiness.”
   Hangup: playbooks exist, but evidence retention and escalation timing triggers are unclear. (Directive (EU) 2022/2555, Article 38)

5. “How do you manage critical third parties tied to essential services?”
   Hangup: procurement has contracts, security has assessments, but there’s no unified view of critical dependencies and remediation. (Directive (EU) 2022/2555, Article 38)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Better approach
Treating Article 38 as “not applicable” and ignoring it	You miss the operational need for change readiness and traceability	Record Article 38 as a “change trigger” requirement in your obligation register with a monitoring workflow. (Directive (EU) 2022/2555, Article 38)
Monitoring legal updates but not documenting decisions	Auditors see ad hoc judgment calls	Keep a change log and impact assessment for each item, even when the decision is “no impact.”
Updating policies without operational tickets	Results in paper updates that don’t change how teams work	Require tickets, validation steps, and closure evidence for each impacted control area.
Third-party work is split across teams	No consolidated proof for critical dependencies	Maintain one critical third-party dependency view tied to risk assessments and remediation tracking. (Directive (EU) 2022/2555, Article 38)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list enforcement examples.

Operational risk still exists: if delegated acts or EU-level clarifications change expectations, supervisors will test whether your program detects and implements those changes in a controlled way. The practical exposure is avoidable findings tied to inconsistent scope, weak incident readiness evidence, and incomplete third-party dependency governance. (Directive (EU) 2022/2555, Article 38)

Practical execution plan (30/60/90-day)

You asked for speed; here is a plan you can run without waiting for perfection. Timelines are internal execution guidance.

First 30 days (stand up the mechanism)

• Assign a single owner for “NIS 2 regulatory change intake” and document RACI.
• Create the NIS 2 obligation register structure and populate it with your current interpretations. (Directive (EU) 2022/2555, Article 38)
• Establish a regulatory change log with a required link back to EUR-Lex source entries. (Directive (EU) 2022/2555)
• Draft the delegated act impact assessment template and approval workflow.

By 60 days (make it auditable)

• Run a dry-run: pick one recent NIS 2-related change or internal interpretation update and push it through the workflow end-to-end.
• Tie incident triage/escalation workflows to evidence retention requirements and test record retrieval. (Directive (EU) 2022/2555, Article 38)
• Identify critical third-party dependencies and connect them to risk assessments and remediation tracking. (Directive (EU) 2022/2555, Article 38)

By 90 days (operate and prove)

• Hold a management review of the obligation register: confirm owners, scope by jurisdiction, and open milestones. (Directive (EU) 2022/2555, Article 38)
• Build an “exam pack” folder structure that mirrors likely supervisory requests (scope, incidents, third parties, change log).
• If you use Daydream, configure it as your system of record for obligations, ownership, and evidence pointers so updates from Article 38-driven changes don’t fragment across spreadsheets and ticketing tools.

Frequently Asked Questions

Does Article 38 create a direct technical control requirement for my security team?

No. Article 38 is about the Commission’s authority to adopt delegated acts and the conditions for doing so. Your operational requirement is to monitor for those acts and translate any changes into controlled updates with evidence. (Directive (EU) 2022/2555, Article 38)

Can we mark Article 38 as “not applicable” in our control framework?

You can document that the Article is institutional, but you still need a mapped internal requirement for regulatory change management tied to NIS 2 updates. Auditors will look for a repeatable intake-to-implementation process. (Directive (EU) 2022/2555, Article 38)

What’s the minimum evidence set to prove we operationalized this?

Keep a change log with source links, an impact assessment per relevant change, updates in your NIS 2 obligation register, and proof that impacted controls (incident workflows, third-party governance) were updated and validated. (Directive (EU) 2022/2555, Article 38)

We operate in multiple EU countries. How should we handle jurisdictional differences?

Track applicability per legal entity and service in your obligation register, with a named owner for each jurisdictional view. Use the same impact assessment template, but document jurisdiction-specific deviations and approvals. (Directive (EU) 2022/2555)

How do incident response and third-party risk tie to Article 38?

Delegated acts can change expectations over time, so your incident and third-party processes must be easy to update with clear evidence. Supervisors commonly test whether incident workflows and critical third-party dependency governance are real and retrievable. (Directive (EU) 2022/2555, Article 38)

What should Legal do versus GRC or the CISO team?

Legal should interpret the legal change and confirm applicability; GRC should drive the obligation register and evidence trail; the CISO org should implement and validate control changes. Document approvals so the decision path is clear. (Directive (EU) 2022/2555, Article 38)