Article 39: Committee procedure

Article 39: committee procedure requirement is not an operational duty for your organization; it governs how the European Commission adopts certain NIS 2 implementing measures through a formal EU committee process. Your job is to track downstream outputs (implementing acts/guidance) and convert them into owned, testable controls across your in-scope EU entities and third parties. (Directive (EU) 2022/2555, Article 39)

Key takeaways:

• Article 39 is a “watch-and-translate” requirement for regulated entities, not a “build-a-committee” requirement. (Directive (EU) 2022/2555, Article 39)
• Operationalize it by running regulatory change management: intake, applicability, control mapping, and evidence-ready rollout.
• Your audit risk is gaps between EU-level updates and your local procedures (incident reporting, supply chain, governance).

Compliance teams often misread Article 39 and waste time looking for a “committee” obligation that does not apply to them. Article 39: committee procedure requirement sits in the machinery of EU lawmaking. It explains that the European Commission is assisted by a committee under the EU “comitology” framework when adopting certain measures under NIS 2. (Directive (EU) 2022/2555, Article 39)

For a CCO, Compliance Officer, or GRC lead, the practical question is simple: how do you prevent EU-level changes made through this committee mechanism from blindsiding your program, controls, or evidence pack? The operational answer is a disciplined regulatory change process that (1) monitors NIS 2 outputs, (2) determines what applies to your footprint and services, (3) updates policies and procedures, and (4) proves the updates were implemented and tested.

This page gives you requirement-level implementation guidance: who owns it, what to implement, what to retain, and what auditors tend to probe. It also includes a practical execution plan and common pitfalls, with a bias toward exam-ready artifacts.

Regulatory text

Text (verbatim excerpt): “1. The Commission shall be assisted by a committee. That committee shall be a committee within the meaning of Regulation (EU) No 182/2011.” (Directive (EU) 2022/2555, Article 39)

Plain-English interpretation

• The European Commission uses an EU committee process to adopt certain NIS 2 measures. (Directive (EU) 2022/2555, Article 39)
• This clause is directed at EU institutions, not directly at your enterprise operations.
• Your operational exposure is indirect: committee-driven measures can change what “good” looks like for incident reporting mechanics, supervisory expectations, and control detail. Your obligation is to stay current and implement what becomes applicable through NIS 2 and national transposition. (Directive (EU) 2022/2555)

What the operator must do

Treat Article 39 as a trigger for regulatory change management:

1. Monitor EU-level NIS 2 outputs and national transposition updates.
2. Assess applicability to your entities, services, and cross-border operations.
3. Translate changes into control requirements, procedures, and third-party contract expectations.
4. Prove adoption with dated approvals, implementation tickets, training, and test results.

Who it applies to

Entity scope

• Direct legal addressee: the European Commission (institutional procedure). (Directive (EU) 2022/2555, Article 39)
• Practical scope for you: any organization building or operating a NIS 2 compliance program, especially where EU-level clarifications or implementing measures can affect your obligations. (Directive (EU) 2022/2555)

Operational contexts where it matters

Use this requirement as a control driver when you have:

• Multiple EU jurisdictions and entities, where change must be rolled out consistently.
• Centralized incident reporting and decentralized IT, where timing and thresholds can drift.
• Material reliance on third parties (cloud, MSSPs, SaaS, telecom, OT support) where contract and assurance changes are slow to implement.

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

Below is a fast, exam-friendly way to operationalize the article 39: committee procedure requirement without over-building.

1) Assign ownership and governance

• Control owner: Head of Compliance/GRC (or Regulatory Affairs if you have it).
• Contributors: CISO team, Legal, Procurement/TPRM, Incident Response lead.
• Decision forum: your existing security governance committee or risk committee. Do not create a new “NIS committee” unless you have a real governance gap.

Deliverable: documented RACI for “NIS 2 regulatory change intake and implementation.”

2) Stand up a NIS 2 obligation register (your translation layer)

Maintain a single register that answers, for each obligation:

• jurisdiction(s) in scope
• entity/service in scope
• control owner
• implementation status and milestones
• evidence location

This is the simplest way to prevent scope drift when EU-level measures or interpretations change. It is also the artifact auditors ask for first because it ties law to operations.

Practical tip: If you run Daydream, this register becomes your system of record for requirements-to-controls mapping and evidence pointers, reducing the “spreadsheet plus shared drive” failure mode.

3) Implement a “regulatory intake → change ticket” workflow

Create a workflow that turns updates into trackable work:

1. Intake: log the update (source, date, summary).
2. Triage: decide whether it impacts your obligations register.
3. Impact assessment: policies/procedures/controls/third parties affected.
4. Change tickets: create implementation tasks with owners and due dates.
5. Approval: compliance sign-off plus security sign-off for technical changes.
6. Closure criteria: evidence attached and test performed (where relevant).

Minimum viable tooling: your GRC platform or ticketing system plus a controlled repository. The key is traceability.

4) Update the operational “hot zones” first

Even though Article 39 is procedural, EU-level outputs commonly cascade into areas regulators care about during supervision. Prioritize evidence-ready execution in three zones reflected in common NIS 2 program builds:

• Obligation register + applicability notes (proves governance and scope discipline).
• Incident triage/escalation/reporting workflow (proves you can execute, not just describe).
• Third-party dependency integration into risk assessment and remediation tracking (proves supply chain governance).

These align with practical control expectations implied by running an exam-ready program under the directive. (Directive (EU) 2022/2555)

5) Test the change, then lock the evidence

For each implemented change:

• run a tabletop or control test (incident workflow changes lend themselves to tabletop validation)
• document what changed, who approved it, when it became effective
• capture training/communications to affected teams
• confirm third-party updates were executed (contract addenda, updated security schedules, assurance requests)

Required evidence and artifacts to retain

Keep artifacts that prove you monitor, you decide, and you implement:

Evidence pack (operator-grade)

• Regulatory change log (entries for NIS 2-related EU and national updates; include decision outcome)
• NIS 2 obligation register with applicability notes, owners, and implementation status
• Impact assessments (one-pagers are fine if consistent)
• Change tickets (with approvals, implementation notes, and closure evidence)
• Policy/procedure versions (redlines or change notes, approval records)
• Incident response workflow documentation (triage criteria, escalation paths, notification preparation steps)
• Third-party inventory for critical dependencies and the mapping to services in scope
• Third-party due diligence and assurance artifacts tied to the dependencies (questionnaires, SOC reports where applicable, remediation tracking)
• Test results (tabletop notes, control test scripts, after-action items, closure)

Common exam/audit questions and hangups

Auditors and supervisors rarely ask about the Commission’s committee mechanics. They ask whether you kept up with what came out of the system.

Expect questions like:

• “Show how you identify NIS 2 regulatory updates and assess applicability to each EU entity.”
• “Where is the authoritative mapping of NIS 2 obligations to controls and owners?”
• “How do incident reporting triggers flow from policy to on-call execution?”
• “Which third parties are critical to your in-scope services, and how do you validate their security posture over time?”
• “Show evidence that changes were implemented, trained, and tested.”

Hangup: Teams present policies without change traceability. Fix it with tickets plus dated approvals plus test artifacts.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating Article 39 as a requirement to form a company committee.
   Avoidance: Document in your obligation register that Article 39 is institutional, then link it to your regulatory change control.

2. Mistake: Monitoring EU-level updates but not translating them into local procedures.
   Avoidance: Require an impact assessment entry for every intake item, even if the conclusion is “no change.”

3. Mistake: Incident process exists, but evidence is not execution-grade.
   Avoidance: Keep a current runbook, on-call roster evidence, and at least one tested scenario record tied to the latest workflow.

4. Mistake: Third-party dependency governance stops at onboarding.
   Avoidance: Connect dependencies to ongoing risk reviews, remediation tracking, and renewal gating for critical third parties.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 39, so you should not expect a direct “Article 39 fine.” The risk is derivative: if EU-level measures or interpretations change and you miss the update, you can fall out of compliance with the substantive NIS 2 obligations that regulators do supervise. (Directive (EU) 2022/2555)

Practically, this shows up as:

• inconsistent implementation across EU entities
• missed or poorly executed incident reporting steps
• incomplete visibility into critical third-party dependencies that support essential or important services

Practical 30/60/90-day execution plan

Use this plan to operationalize the article 39: committee procedure requirement as regulatory change discipline, not a structural re-org.

First 30 days (Immediate stabilization)

• Name a control owner and publish RACI for NIS 2 regulatory change intake.
• Create the first version of the NIS 2 obligation register with jurisdictions, owners, and evidence pointers.
• Stand up a single intake channel (mailbox/form) and a change log template.
• Identify your “hot zone” processes: incident reporting workflow and critical third-party dependency list.

Days 31–60 (Translate into control updates)

• Implement the intake-to-ticket workflow in your GRC tool or ticketing system.
• Run an applicability workshop with Legal + Security + Procurement for your top services/entities.
• Update incident triage and escalation documentation so it is executable (roles, triggers, handoffs, evidence capture).
• For critical third parties, document dependency mapping and set assurance expectations (what you request, how findings track).

Days 61–90 (Make it exam-ready)

• Perform a tabletop that exercises the incident workflow and produces a clean evidence pack.
• Audit your obligation register for completeness: every requirement has an owner, status, and evidence location.
• Sample-test third-party dependency governance: pick a dependency, show onboarding artifacts, ongoing assurance, and remediation tracking.
• Package artifacts into a supervisor-ready binder: change log, register, tickets, and test outcomes.

Mapping to common frameworks (for internal alignment)

You can map this requirement to generic governance controls already in your program:

• ISO/IEC 27001-style governance: “management review,” “documented information control,” and “compliance obligations” mapping.
• NIST CSF / NIST governance patterns: identify-and-manage legal/regulatory requirements, and maintain response plans with testing.

Keep the mapping internal unless an auditor asks. The primary proof remains your change traceability and control execution artifacts.

Frequently Asked Questions

Does Article 39 require my company to create a committee?

No. Article 39 describes an EU institutional process where the Commission is assisted by a committee. Your operational requirement is to monitor and implement downstream obligations that affect your program. (Directive (EU) 2022/2555, Article 39)

What should I show an auditor if they ask about Article 39?

Show your regulatory change process, your NIS 2 obligation register, and evidence that updates are assessed and implemented. Tie at least one recent change to tickets, approvals, and updated procedures. (Directive (EU) 2022/2555)

How do I connect Article 39 to incident handling in practice?

Treat it as the reason you maintain a standing change pipeline for NIS 2 updates. When updates affect reporting expectations, convert them into runbook changes, training, and a tabletop test record.

We operate in multiple EU countries. What artifact prevents “local drift”?

A centralized obligation register with jurisdiction-specific applicability notes, plus a single workflow for approving and rolling out changes. Require local owners to attest implementation with evidence pointers.

How does third-party risk management fit under this requirement?

Article 39 itself is procedural, but changes adopted under NIS 2 can affect supply chain expectations. Keep a dependency map for critical third parties and a repeatable assurance and remediation process tied to in-scope services. (Directive (EU) 2022/2555)

Where does Daydream fit without adding tool sprawl?

Daydream can serve as your requirements-to-controls system of record, keeping the obligation register, ownership, milestones, and evidence pointers in one place so you can answer supervisory questions quickly and consistently.